Follow-up Comment #3, bug #66673 (group groff): Hi Dave,
I'll rearrange your comment a bit for my reply. At 2025-01-16T14:35:12-0500, Dave wrote: > Follow-up Comment #2, bug #66673 (group groff): > > Alternately, you could skip the flag and always ax the trailing > spaces. Not now. The way I chose to achieve the newly regular syntax was by having all the requests that read (potentially) multi-word arguments hand that responsibility off to a single function, `read_string()` (not the greatest name--I'll change it one of these days). https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp?id=d19927eed63ac9c9696a308442b1a1b90f8b4109#n8425 > 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. Yes, and I kind of want to maximize its capability within the remaining constraint (that being, if you can't spell your file name with ASCII, you can go pound sand, a proud *roff tradition since, well, forever). > 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. That's true but I am averse to scheduling more multi-stage transitions than I have to. > [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. I don't understand this comment, at this level of the implementation we're (just about) reading a byte stream. If we're re-reading something that has been predigested, there might be nodes in it, or special tokens like those in "input.h". https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.h?id=d19927eed63ac9c9696a308442b1a1b90f8b4109 But pretty much, for this function, a space is a space, and nothing else is a space. > When you (could/should?) care is when you go to open the file. `read_string()` doesn't know if its argument is a file or not. And yes, with an argument, we could have it caller tell it. But this raises another question. Should we handle system command arguments (`pso`, `pi`, `sy`) the same way? For that matter, should we apply that rule to this specimen? .length len \*[url] \" measure the URL The foregoing overmeasures the `url` string contents by 1. And "always" has. $ printf '.ds str abc\n.length len \\*[str] \\"\n.tm len=\\n[len]\n' | ~/groff-1.22.3/bin/nroff len=4 $ printf '.ds str abc\n.length len \\*[str]\\"\n.tm len=\\n[len]\n' | ~/groff-1.22.3/bin/nroff len=3 > 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. I think that proposal is isomorphic to the one I just stated. Likely not difficult--I'm simply resistant to the complexity. >> 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. If people would actually evaluate our release candidates when we make them, we could do better than guessing... We do get useful feedback, but it pretty much stops at making sure the build works. That's valuable, but not all there is to QA. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66673> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
