[bug #63544] [troff] generate "grout" that is more easily lexically analyzed

Follow-up Comment #3, bug #63544 (project groff): _grops_ handles my proposed reform fine. Since all output drivers except _gropdf_ rely on _libdriver_ for their parsing, I believe this demonstrates that Clark anticipated this input. $ printf -- '.nf\na b\n-\\-\n' | tg -T ps -Z > ps-grout [edit

[bug #63544] [troff] generate "grout" that is more easily lexically analyzed

Follow-up Comment #4, bug #63544 (project groff): [comment #2 comment #2:] > Yes, See other discussion. This is a reference to bug #64360. ___ Reply to this item at:

[bug #63544] [troff] generate "grout" that is more easily lexically analyzed

Additional Item Attachment, bug #63544 (project groff): File name: 63544.ps Size:6 KB ___ Reply to this item at:

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #29, bug #64360 (project groff): [comment #27 comment #27:] > First I'd like to try to reduce the scope of this discussion, since it seems to have grown in multiple directions. Sure. > Am I correct in the assumption that the grout files for any given input would not be identic

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #30, bug #64360 (project groff): How about something briefer? [comment #29 comment #29:] > > I believe the change Branden has on his private branch is to output a new line after a w command, but this bug concerns white space after the w. Contrary to cstr#54, which classes space/

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Update of bug #64360 (project groff): Assigned to:gbranden => deri ___ Reply to this item at: ___ Messag

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #31, bug #64360 (project groff): Forgot the attachment, as usual. (file #55039) ___ Additional Item Attachment: File name: ps-grout3 Size:0 KB

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #32, bug #64360 (project groff): Again a long reply will be required since you've again extended the scope bringing in heirloom, dwb, libdriver. whereas i tried to limit the scope to examine whether gropdfs grout parser was cnformant to our current docs. You may consider our curr

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #33, bug #64360 (project groff): Hi Deri, [comment #32 comment #32:] > Again a long reply will be required since you've again extended the scope bringing in heirloom, dwb, libdriver. whereas i tried to limit the scope to examine whether gropdfs grout parser was cnformant to our

[bug #64559] [troff] does not diagnose trailing garbage in register assignment

URL: Summary: [troff] does not diagnose trailing garbage in register assignment Group: GNU roff Submitter: gbranden Submitted: Wed 16 Aug 2023 03:45:10 AM UTC Category: Core

[bug #64240] [troff] make numeric expression parser more sensitive to nonsense

Follow-up Comment #2, bug #64240 (project groff): Also see bug #64559. Need root-cause analysis to determine if it's a duplicate. ___ Reply to this item at: __

[bug #64559] [troff] does not diagnose trailing garbage in register assignment

Follow-up Comment #1, bug #64559 (project groff): Also see bug #6240. Need root-cause analysis to determine if it's a duplicate. ___ Reply to this item at: ___

[bug #64559] [troff] does not diagnose trailing garbage in register assignment

Follow-up Comment #2, bug #64559 (project groff): I mean bug #64240. :-| ___ Reply to this item at: ___ Message sent via Savannah https://savannah.gnu.

[bug #57667] rehabilitate refer(1)

Update of bug #57667 (project groff): Status: Need Info => Fixed Open/Closed:Open => Closed Planned Release:None => 1.23.0 Summary: