[bug #65985] groff make process spews out a huge amount of errors/warnings

Follow-up Comment #3, bug #65985 (group groff): I suppose your request for the information below was largely superseded by <20240713-185904.sv108747.361...@savannah.gnu.org> and <20240713-202450.sv108747.384...@savannah.gnu.org> ? Anyway, in case you still want it, I supply it here: The paper fo

[bug #65985] groff make process spews out a huge amount of errors/warnings

Follow-up Comment #4, bug #65985 (group groff): [comment #3 comment #3:] > I suppose your request for the information below was largely superseded by <20240713-185904.sv108747.361...@savannah.gnu.org> > and <20240713-202450.sv108747.384...@savannah.gnu.org> ? Not necessarily. I had hopes, though

[bug #65983] [troff] starts document prematurely upon `lf` request

Update of bug #65983 (group groff): Summary: [troff] starts document preumaturely upon `lf` request => [troff] starts document prematurely upon `lf` request ___ Reply to this item at:

[bug #65980] [troff] diagnose why directory operands can't be opened

Update of bug #65980 (group groff): Summary: [troff] emit diagnostic on unreadable input files => [troff] diagnose why directory operands can't be opened ___ Reply to this item at:

[bug #65980] [troff] diagnose why directory operands can't be opened

Follow-up Comment #3, bug #65980 (group groff): I recast the Summary because it was a little too vague. _groff_ has long issued diagnostics when an input file can't be _read_. $ echo "Hello, Dave." > dave.troff $ chmod 000 dave.troff $ nroff dave.troff troff: fatal error: cannot open 'dave.trof

[bug #65980] [troff] diagnose why directory operands can't be opened

Follow-up Comment #4, bug #65980 (group groff): Oh and of course a symbolic link, perhaps the second most obvious sort of *roff input file after the regular type. ___ Reply to this item at: __

[bug #65980] [troff] diagnose why directory operands can't be opened

Follow-up Comment #5, bug #65980 (group groff): [comment #1 comment #1:] > 2. Use of preprocessors with empty inputs causes the formatter to produce output that provokes complaints from output drivers. > > Example: > > $ echo . | tbl > .if !\n(.g .ab GNU tbl requires groff extensions; abortin

[bug #65985] groff make process spews out a huge amount of errors/warnings

Follow-up Comment #5, bug #65985 (group groff): [comment #4 comment #4:] > [comment #3 comment #3:] > > The paper format is reported as: > > > >checking default paper format... letter > > Interesting! I was intrigued by the fact that every technique the `GROFF_PAGE` macro uses to try to inf

[bug #65988] [Makefile] some tmac files are not listed as dependencies for compilations

URL: Summary: [Makefile] some tmac files are not listed as dependencies for compilations Group: GNU roff Submitter: bjarniig Submitted: Sun 14 Jul 2024 05:52:25 PM UTC Categor

[bug #65989] [mm] m.tmac: error in the update of the file

URL: Summary: [mm] m.tmac: error in the update of the file Group: GNU roff Submitter: bjarniig Submitted: Sun 14 Jul 2024 06:49:31 PM UTC Category: Macro package mm

[bug #65989] [mm] m.tmac: error in the update of the file

Update of bug #65989 (group groff): Status:None => In Progress Assigned to:None => gbranden ___ Follow-up Comment #1: Whoops! Thanks, Bjarni

[bug #65989] [mm] unmatched parenthesis in `SP` argument checking

Update of bug #65989 (group groff): Summary: [mm] m.tmac: error in the update of the file => [mm] unmatched parenthesis in `SP` argument checking ___ Reply to this item at: __

[bug #65990] [mm] macro 'init@reset' is still used but not defined

URL: Summary: [mm] macro 'init@reset' is still used but not defined Group: GNU roff Submitter: bjarniig Submitted: Sun 14 Jul 2024 07:33:48 PM UTC Category: Macro package mm

[bug #65990] [mm] macro 'init@reset' is still used but not defined

Update of bug #65990 (group groff): Item Group: Incorrect behaviour => Lint ___ Follow-up Comment #1: Thanks for the report. It's interesting to me that this error on my part did not cause any regressi

[bug #65990] [mm] macro 'init@reset' is still used but not defined

Follow-up Comment #2, bug #65990 (group groff): Oh, never mind, these calls are when we're just entering an environment. So it probably does make sense to call `@reset` in the event the formatter and package defaults ever diverge in a sense that matters to memorandum type 4 or a _groff mm_ docume

[bug #65990] [mm] macro 'init@reset' is still used but not defined

Update of bug #65990 (group groff): Status:None => In Progress Assigned to:None => gbranden ___ Reply to this item at:

[bug #65990] [mm] macro 'init@reset' is still used but not defined

Update of bug #65990 (group groff): Item Group:Lint => Incorrect behaviour ___ Reply to this item at: ___ Message

[bug #65988] [Makefile] some tmac files are not listed as dependencies for compilations

Update of bug #65988 (group groff): Status:None => Need Info ___ Follow-up Comment #1: I don't understand this report. > For example 'an.tmac' and 'm.tmac' > These file are not created.

[bug #65988] [Makefile] some tmac files are not listed as dependencies for compilations

Follow-up Comment #2, bug #65988 (group groff): Let me clarify comment #1. The generation of "groff-man-pages.pdf" and "groff-man-pages.utf8.txt" are the only occasions during a build that "an.tmac" is a prerequisite of a target of a Makefile rule. _

[bug #64301] [troff] susceptible to integer overflow

Update of bug #64301 (group groff): Status:None => In Progress Assigned to:None => gbranden ___ Follow-up Comment #2: At long last I have thi

[bug #65980] [troff] diagnose why directory operands can't be opened

Follow-up Comment #6, bug #65980 (group groff): [comment #3 comment #3:] > I recast the Summary because it was a little too vague. I wrote it vaguely because I hadn't researched all the possible file types and didn't know if others also should be disallowed. But as you enumerate them here, every

[bug #65967] [docs] Say "input" instead of "input file" where appropriate

Update of bug #65967 (group groff): Summary: [PATCH] [docs] Say "input" instead of "input file" where appropriate => [docs] Say "input" instead of "input file" where appropriate ___ Follow-up Comment #8: Editing Summary: I

[bug #59442] [PATCH] [groff] move soelim before preconv in constructed pipeline

Follow-up Comment #13, bug #59442 (group groff): [comment #12 comment #12:] > we're already sunk, and have been for decades, by the simple > obstacle of a space character. Frustratingly, soelim can deal with this and raw troff can't. From soelim(1): "To embed a space [in the filename], write "\

[bug #65988] [Makefile] some tmac files are not listed as dependencies for compilations

Follow-up Comment #3, bug #65988 (group groff): This is a mistake of mine. I somehow thought that some man pages were created (from '*.in' files) and needed a '*.tmac' file for that. So this ticket is invalid. ___ Reply to this it

[bug #59442] [PATCH] [groff] move soelim before preconv in constructed pipeline

Follow-up Comment #14, bug #59442 (group groff): (I was a little surprised, when crafting that example, that I had to say "groff -Tascii" rather than "nroff" because nroff lacks the -s option. All this means is I forgot about bug #64450.)

[bug #65988] [Makefile] some tmac files are not listed as dependencies for compilations

Update of bug #65988 (group groff): Status: Need Info => Invalid Assigned to:None => gbranden Open/Closed:Open => Closed __

[bug #65988] some tmac files are not listed as dependencies for compilations

Update of bug #65988 (group groff): Summary: [Makefile] some tmac files are not listed as dependencies for compilations => some tmac files are not listed as dependencies for compilations ___ Reply to this item at:

[bug #59442] [PATCH] [groff] move soelim before preconv in constructed pipeline

Follow-up Comment #15, bug #59442 (group groff): [comment #13 comment #13:] ... > $ cat try.roff > I'll eat > .so the\ one.roff > soon. ... > What seems nuts about that is that the first error seems like a pointless restriction that, if lifted, would make the second error disappear. Fixing tha

[bug #64450] [nroff] reclaim -e, -s flags for preprocessors?

Follow-up Comment #1, bug #64450 (group groff): nroff preprocessor coverage can be expanded even without reclamation: the letters -g, -G, and -j are unused, and they respectively invoke the grn, grap, and chem preprocessors in groff. This is very low priority, because any preprocessor can be run

[bug #64450] [nroff] reclaim -e, -s flags for preprocessors?

Follow-up Comment #2, bug #64450 (group groff): [comment #1 comment #1:] > nroff preprocessor coverage can be expanded even without reclamation: the letters -g, -G, and -j are unused, and they respectively invoke the grn, grap, and chem preprocessors in groff. I very recently decided against tha