On 02.12.25 00:45, G. Branden Robinson wrote: > At 2025-12-01T00:37:42-0600, Dave Kemper wrote:
> > On Tue, Nov 18, 2025 at 12:45 AM G. Branden Robinson > > < [email protected] > wrote: > > > Is it really asking too much of the user to write: > > > > > > .class \[EOS] .?!\[em] > > > .cflags 1 \C'[EOS]' > > > .cflags 5 \[em] > > > > > > instead of: > > > > > > .class \[EOS] .?!\[em] > > > .cflags 1 \C'[EOS]' > > > > > > ? > > > > Yes, it is. To set a new cflag on arbitrary character x, you're > > saying the user must examine every macro package that document loads > > to see if one of them already sets any flags on character x, so that > > he can do his own arithmetic to add those values to the new one he > > wants. > > Not at all. To set a new character flag on an arbitrary character x, > one just does it. If one really means for `\[em]` to both end a > sentence (if followed by appropriate whitespace) and for the line to be > eligible for breaking after it, one says so. > > .cflags 5 \[em] Ah, fluent mental decimal/binary conversion mandatory, then. Easy enough for two or three flags, I admit. But maybe only for old-timers? In the days before assemblers, it was necessary to mentally combine bits to construct machine opcodes, OR them with binary source & destination register addresses, etc.¹ And the above appears equally primitive, opaque, and error prone. (Nearly as arcane as the Gcode used by CNC machinists, where cryptic G-numbers are still used instead of a human-readable form.) How much does it take to #define a name for each flag, and support a syntax like: .cflags (BREAK|END) \[em] OK, doing it at runtime is doubtless more effort than if it could be done at compiletime, but look at the readability. For comparison, in the current AVR assembler, there is much use of bit positions, rather than the single bit values, for flags. That requires the flag name to modulate a leftshift, as in this hardware register setting: ldi r16,(1<<ADEN|1<<ADIE|ADPS) ; ADC enable, ADC interrupt enable, out ADCSRA,r16 ; and 3-bit clock prescale setting, ; in the LSBs. Here that implementational detail is exposed, but in groff, implementation is best hidden, I figure. But ORing of named flags seems to be significantly more readable than groff syntax. Neh? ¹ I'm old enough to have done that for the TMS9900, before X86, PC's, etc. (Around 1979) It's only fun the first time - when there isn't anything better. Erik (Who is not likely to use this feature, so only chiming in to stimulate design thought - always the best part of an endeavor.)
