Any reason the removal/renaming of read-only registers should be permitted?

2023-05-02 Thread G. Branden Robinson
(This is for groff 1.24.) I've opened the following ticket after getting a surprise. https://savannah.gnu.org/bugs/?64131 In AT&T troff, you cannot remove a read-only register like `.l`. It throws no diagnostic; it silently refuses the request. In groff, you can. As far as I can tell, this ha

Re: device-dependent warnings

2023-05-02 Thread G. Branden Robinson
Hi Alex, At 2023-04-28T15:56:13+0200, Alejandro Colomar wrote: > Considering a build system that builds man pages into several formats, > including utf8, PostScript, HTML, and PDF, it is interesting to be > able to see all available warnings, and see them only once. Where you're headed with this

Re: Split diagnostic about blank lines in input

2023-05-02 Thread G. Branden Robinson
Hi Alex, At 2023-04-28T15:10:08+0200, Alejandro Colomar wrote: > I've got some wish, which ISTR I already expressed at some point in > the past. There's this diagnostic: > > an.tmac:man3/nxt_unit_init.3:62: style: blank line in input > > The thing is, for example C programs I do need to violate

Re: device-dependent warnings

2023-05-02 Thread Alejandro Colomar
Hi Branden, On 5/2/23 17:10, G. Branden Robinson wrote: [...] > Where you're headed with this already sounds tricky, since GNU troff > (like AT&T device-independent troff) reads information about the device > for which it is preparing output at the time it starts. In fact, you > _cannot_ launch

Re: Split diagnostic about blank lines in input

2023-05-02 Thread Alejandro Colomar
Hi Branden, On 5/2/23 17:17, G. Branden Robinson wrote: > Hi Alex, > > At 2023-04-28T15:10:08+0200, Alejandro Colomar wrote: >> I've got some wish, which ISTR I already expressed at some point in >> the past. There's this diagnostic: >> >> an.tmac:man3/nxt_unit_init.3:62: style: blank line in in

Prefix for warnings (was: device-dependent warnings)

2023-05-02 Thread Alejandro Colomar
Hi Branden, On 5/3/23 00:21, Alejandro Colomar wrote: > > troff:man3/unlocked_stdio.3:123: warning [p 2, 1.8i, div '3tbd1,0', 0.3i]: > cannot break line > > an.tmac:man4/cciss.4:164: style: blank line in input > > man4/console_codes.4:324: warning: table wider than line length minus > indenta

Re: Behaviour of .so differs between mandoc and groff

2023-05-02 Thread Alexis
"G. Branden Robinson" writes: In practice, as I understand it, `so` doesn't achieve anything for man pages that can't be done with symbolic links and (importantly) a man page indexer that is symlink-aware. Perhaps `so` support was preserved, and its practice retained, for a long time becau

Re: Warn on mid-input line sentence endings

2023-05-02 Thread Alejandro Colomar
Hey Josh, On 5/2/23 05:59, josh wrote: [...] > Here's a relevant passage about the origin of the phrase from > https://vanemden.wordpress.com/2009/01/01/ventilated-prose, > >> In the 1930s Buckminster Fuller (he of the domes, but also of many other >> things) was doing research for the Phelps Do

Re: Prefix for warnings (was: device-dependent warnings)

2023-05-02 Thread Ingo Schwarze
Hi Alejandro, Alejandro Colomar wrote on Wed, May 03, 2023 at 01:26:55AM +0200: > I find it more readable when there's one space between the program > that generates the warning and the file. That's what mandoc(1) does, > and in general, what any program that relies on perror(3) does (I'm > assu

Re: Warn on mid-input line sentence endings

2023-05-02 Thread Ingo Schwarze
Hi, Alejandro Colomar wrote on Wed, May 03, 2023 at 02:35:41AM +0200: > Heh! > Branden wasn't enthusiastic my emails when I wrote poetry in them, though :/ > Any chance we can warn users that they should write poems, not prose? [...] > Just kidding, but technically, it's probably more accurate, a