Hi dvalin--, Off-topic, but I'm curious...where did this practice of suffixing user names with multiple hyphen-minuses come from?
At 2025-12-02T09:05:59+0000, dvalin--- via GNU roff typesetting system
discussion wrote:
> > .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.)
I wrote a footnote along the same lines in groff's Texinfo manual.
$ git show 57f802587f5
...
+expense of a more intuitive arrangement. The mechanism for control of
+hyphenation modes is a set of numbers that can be added up to encode the
+behavior sought.@footnote{The mode is a vector of booleans encoded as an
+integer. To a programmer, this fact is easily deduced from the
+exclusive use of powers of two for the configuration parameters; they
+are computationally easy to ``mask off'' and compare to zero. To almost
+everyone else, the arrangement seems recondite and unfriendly.} The
+entries in the table below are termed @dfn{values}, and the sum
+corresponding to the desired flags is the @dfn{mode}.
...
> 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.
I doubt anyone would deny that. The main problem is one of effort since
GNU troff's input interpreter is a bespoke recursive-descent combined
lexical analyzer and parser (the two grammatical properties are
intertwined at every point, making for some exciting ways to break it
while 's hacking).
I think the most economical way to solve this problem would be to come
up with a syntax for expressing bit flag vector manipulations, and then
assign humane mnemonics to each of the bit positions.
The most rewarding place to start would, I think, be the `warn` request,
because we _already have_ such mnemonics, so we need only solve the
first problem.
The idea I've been carrying around in my head looks somewhat like the
"symbolic" form of the chmod(1) command.
Some examples should get the idea across.
.warn +delim
.warn -char
.warn =all
.warn =w-delim
.warn -w+syntax+reg+mac
All of these are currently invalid syntax, so this should be a
compatible extension.
[snip]
> Here [in AVR assembly language] that implementational detail is
> exposed, but in groff, implementation is best hidden, I figure.
I agree. GNU troff extrapolated from AT&T troff's `hy` request.
...which, itself, I'd like to shove into a dusty corner for legacy
features.
https://savannah.gnu.org/bugs/?55070
> But ORing of named flags seems to be significantly more readable than
> groff syntax. Neh?
Even a bitwise or logical "or" is more of a demand upon the user than we
need to make. Why not plus, minus, and equals (in the assignment
idiom[1])?
> ¹ 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.
I wasn't writing my own programs quite yet at that point. I'm a
youngster.
Regards,
Branden
[1] ...which I have problems with, since ":=" should be assignment and
"=" should be equality. But the latter is a bit of brain damage C
programmers cherish even as they consider themselves far superior to
those who learned Microsoft BASIC, which does the same thing.
(At least Dartmouth BASIC [and ANSI Minimal BASIC] required `LET` to
make the context clear. Also, did these snooty C hackers ever
notice that Ken Thompson himself wrote a BASIC interpreter?)
https://www.tuhs.org/pipermail/tuhs/2021-December/024944.html
signature.asc
Description: PGP signature
