#143 Long text lines are not wrapped 1 year, 10 months ago

Comment by ~dominicm on ~sircmpwn/lists.sr.ht

+1

Adding white-space: pre-wrap fixes the issue. It's much more usable than the horizontal scrolling, with the exception of git patches on mobile.

While not perfect, I think this is a big improvement as many emails are not manually wrapped.

#36 Decide on variable naming 2 years ago

critical added by ~dominicm on ~dominicm/ham

#36 Decide on variable naming 2 years ago

Ticket created by ~dominicm on ~dominicm/ham

There should be a consistent naming scheme for special internal variables, possibly with aliases to the original names for backwards compatibility. Some thoughts:

• Should the variable prefix be HAM or JAM? If HAM, are HAM<X> and JAM<X> treated as the same variable? Should the aliasing only apply to variables that existed in Jam or all internal variables?
• Should there be a symbol prefix? (i.e. _HAM)

#34 Document special variables 2 years ago

documentation added by ~dominicm on ~dominicm/ham

#35 Create behavior compatibility mechanism 2 years ago

feature added by ~dominicm on ~dominicm/ham

#35 Create behavior compatibility mechanism 2 years ago

critical added by ~dominicm on ~dominicm/ham

#35 Create behavior compatibility mechanism 2 years ago

Ticket created by ~dominicm on ~dominicm/ham

Some Jam behaviors are unintuitive, but would break backwards compatibility if changed. Like Ham v1, behaviors can switch between possible behaviors at runtime to maintain compatibility. Unlike Ham v1, I'd like to incorporate this information into the build system rather than a command line switch.

The current idea is to have special variables HAM_COMPAT and HAM_<X> to set compatibility/behavior at any point during code execution. This lets the build system decide when it is ready to migrate, or even migrate incrementally by gating behavior changes at certain points.

#34 Document special variables 2 years ago

Ticket created by ~dominicm on ~dominicm/ham

SEARCH and LOCATE are currently mentioned, but all special variables should be centrally located, including:

• JAM_TARGETS
• JAMSHELL
• Platform info variables

Ham also plans to add:

• Behavior/compatibility variables

Special notes:

• JAMSHELL replaces any "!" argument with the job slot and "%" with the command

#33 Split language specification into separate pages 2 years ago

documentation added by ~dominicm on ~dominicm/ham

#33 Split language specification into separate pages 2 years ago

Ticket created by ~dominicm on ~dominicm/ham

Having the entire language specification in one page is difficult to read and makes how to structure the specification unclear. Having keywords be notes under their respective constructs makes the specification less searchable. Every keyword, syntactical structure, and built-in rule should have it's own page that clearly explains its behavior under all conditions.