Follow-up Comment #20, bug #63332 (group groff): [comment #19 comment #19:] > The purpose of > [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=9a9d7b55b commit > 9a9d7b55b] was to "Create characters less aggressively." > > [comment #1 comment #1:] >> It appears that having a special character on the RHS of an >> `fchar` request marks it as defined for the purpose of the `c` >> conditional expression, even though it's not _really_ defined. > > As this complaint also concerns creating characters too aggressively, I was > hoping the above commit might accidentally have fixed this as well. Alas.
I would not have held out that hope, but I think I do not understand what's
going on better.
For character identifiers (among other things), GNU _troff_ has used a
dictionary with lazy, automatic insertion. Meaning if you look up an entry
that doesn't exist, boom--you just created it.
As commit 9a9d7b55b implies, we don't always want that--definitely not when
simply trying to look up character info for debugging purposes (a new
feature), and not when trying to _delete_ a character--an old feature which I
wonder now if it ever worked as intended. I'll have more to say about
character removal at some point (namely, "why can't we bypass character lookup
and remove exactly the sort ["mode"[*]] of character we created?"), but for
this ticket I think we need a way to populate a character definition with the
new "lookup only" semantics.
That would in turn imply that if the RHS of a character definition contained
any undefined characters (non-characters like Peter's neat image diversion
trick would not be affected), you'd get a diagnostic message in the "char"
category. Or maybe you should get an outright error, and the character
definition should fail--recursive character creation would not be allowed, and
you should build up your nested character definitions by stages.
Do either of these sound reasonable to you? Do you have a preference?
[*] "mode" here means one of "normal", "fallback", or "special [unstyled]
fallback". I note with interest that `fschar` and `rfschar` are already
nicely "orthogonal" with respect to character removal bypassing character
lookup.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63332>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
