Follow-up Comment #14, bug #68511 (group groff):

At 2026-07-11T21:44:51-0400, Dave wrote:
> Follow-up Comment #12, bug #68511 (group groff):
> [comment #5 comment #5:]
>> [comment #2 comment #2:]
>>> There's not really a good workaround to this.
>>
>> I don't think this was a deliberate change.
>
> I was pretty sure it wasn't.  The workarounds I provided here and in
> bug #68510 were so that that info could be taken into account when
> prioritizing work, in case they turned out to be thorny problems.
> Since #68510 had a fairly simple workaround, and this one didn't, that
> suggests (all else being equal, which it never is) prioritizing this
> bug higher.

Both were, conceptually simple, and both arose from regressions due to
refactorings I did on the same day.

Again, conceptually, the problem is that we've been muddling around with
a proper grammar for the groff language.  Several requests, like
`cflags`, `hcode`, and `rchar`, can "groff characters" (ordinary,
special, indexed) as "arguments", but unlike other "arguments" in *roff,
spaces need not separate them.

It's easier to think about a request handler if we factor the business
of gathering a "groff character" from the input stream--indifferently to
space separation--into its own function.

That's what I've done, and that made quick work of both of these
tickets.  I haven't refactored the `rchar` request yet.  Don't know when
that will happen.  Sooner if we find out I broke it, too.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68511>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to