Update of bug #66673 (group groff):
Status: None => Confirmed
Assigned to: None => gbranden
Summary: Fix for bug #66434 breaks a common legacy syntax =>
[troff] fix for bug #66434 absorbs pre-comment spaces into request argument
_______________________________________________________
Follow-up Comment #1:
[comment #0 original submission:]
> The original submission of bug #57538 contains test input to demonstrate the
> originally reported problem. The first line of that input now fails in a way
> it didn't used to. That line is:
> .mso me.tmac \" -me macros
> It now produces this warning:
> warning: cannot open macro file 'me.tmac ': No such file or directory
> This is new within the last six months. I presume it's a consequence of the
> fix to bug #66434.
Ah, yup. I admit I didn't specifically contemplate this scenario, but now
that it's brought to my attention, I'd regard it as "expected, intended"
behavior.
Which doesn't mean it won't annoy anyone.
> But I wonder if this was an unintended consequence of that fix.
A ramification I didn't think specifically about while trying to unify the
syntax for requests that read "greedily", and that in turn to address the
weirdness/inconsistency of troff as a Unix tool that had no in-language means
of manipulating file names on the system that contained spaces. C has no
trouble with this, and even the shell can do it if you can remember its
quoting rules.
> The Texinfo manual has a big bold *caution* concerning .ds: "The 'ds' request
> treats the remainder of the input line as its second argument, including
> trailing spaces." This caution is not repeated for .mso and several other
> requests to which it now applies.
So first of all, I think it probably should be, especially for the aid of
long-toothed troff users who are used to being able to slap down _roff_
comments willy-nilly (but less so in GNU _troff_, which long before this, got
kind of angry if you tried to set those comments off with tab characters
instead of space).
> Similarly, the NEWS item for this change states only that groff "now accepts
> space characters" in these requests, but doesn't caution about this very
> common syntax for appending comments to lines of code.
Yes. Second of all, I'll need to flag this consequence, both in the item
itself and probably in a banner at the top of the NEWS file (along with,
unrelatedly, a warning to _mm_ users that **several** things have changed in
it).
> So this might be a documentation issue, and that's how I'm initially
> classifying this bug report.
That's my inclination.
> But if we approach the functionality from a DWIM standpoint (which, I
> realize, is not something troff has historically done), _internal_ spaces in
> filenames are common but _trailing_ spaces are not. So perhaps the default
> parsing should be to discard trailing space in these requests, especially if
> that space is followed by a comment symbol.
GNU _troff_'s parser, like--I think--AT&T's is pretty dumb and doesn't
maintain enough state to make this easy. We don't know that a run of _n_
spaces is "trailing" until we hit a token that _isn't_ a space, and at that
point we had better be sure that we remembered how many spaces we saw. This
isn't necessarily a challenge, but it is complication; the intention of my
syntactical reform here was to _simplify_ the language. The parser is not the
language, but I'd like to keep it as simple as possible, too.
I share your prediction that the statistical likelihood of file names ending
with a sequence of spaces is low.
Coming back to this:
> this very common syntax for appending comments to lines of code.
A thing to observe here is that it's a common thing within a categorical
rarity. _roff_ authors tend to be stingy with comments. Probably more so
than they should be.
But I think you're right that this change needs to be flagged in more ways.
And I may keep my head off the chopping block by offering helpful advice in
the same places. The most obvious workaround, the one we also suggest for
sequences of tabs, is to prefix the run of spaces with another comment escape
sequence. One can then discard or retain the subsequent comment escape
sequence at one's pleasure.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66673>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
