Follow-up Comment #2, bug #66673 (group groff): [comment #1 comment #1:] > We don't know that a run of _n_ spaces is "trailing" until we > hit a token that _isn't_ a space,
Without looking at the code, I can't say for sure, but conceptually this
doesn't seem like as onerous as that: you don't actually care while you're
scanning the input what any spaces represent. When you (could/should?) care
is when you go to open the file. At that point you have a string that may end
with spaces, and if you're also given a flag to say "keep 'em" or "ax 'em,"
you can act then. It may not be trivial to percolate such a flag from the
parser on to the file-opening function, but it doesn't require the sort of
precognition you sketch above.
Alternately, you could skip the flag and always ax the trailing spaces. This
prevents opening some particularly problematically named files--but groff
already couldn't open those anyway, and there are a lot more files groff _can_
open now than it could before. And if axing those spaces also throws a
warning saying that in a future release they'll be retained, you're giving
more prominent warning to users than even the flashing neon text in NEWS.
> 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.
Both good points. Trying to peer into the user's mind will always be more
complicated. We do agree that in this limited instance, the user's intent is
almost certainly guessable, but whether that makes it worth the trade-off of
turning that guess into more complicated code and documentation, I wouldn't
hazard to say.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66673>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
