Re: [RFC PATCH v1 0/2] New sman(1) script

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

Hi Branden,

On 2026-01-27T23:48:05-0600, G. Branden Robinson wrote:
> At 2026-01-28T04:44:53+0000, Seth McDonald wrote:
> > On Tue, 27 Jan 2026 at 14:47:40 +0100, Alejandro Colomar wrote:
> > > On 2026-01-27T09:20:26+0000, Seth McDonald wrote:
> > > > G'day,
> > > > 
> > > > When parsing man pages, I've noticed I'm often only interested in
> > > > a particular set of sections within the page (e.g. SYNOPSIS,
> > > > HISTORY).  And since skimming through the page to get to these
> > > > sections can get monotonous, I wrote up a small bash script to
> > > > automate the process.
> > > 
> > > Agree.  I wrote mansect(1) for the same exact reason.
> > > 
> > > > As far as I can tell, no program in src/bin/ can currently do
> > > > this.  The closest is mansect(1), but that outputs the source code
> > > > rather than the rendered page.
> > > 
> > > You could use mansect(1) for that, and pipe it to man(1) (or
> > > groff(1)).
> > 
> > I honestly have no idea how that never crossed my mind.  Seems so
> > obvious in retrospect lol.
> 
> I have ideas for tackling this problem in groff as well, in a way that
> has the potential to be more powerful and selective.
> 
> https://savannah.gnu.org/bugs/?66401
> 
> One of the goals I have is to automatically generate link anchors for
> all `TP` paragraph tags in man(7), because these are so frequently used
> to set keywords, literals, and other parameters (like command-line
> option names) in lists.  Roughly, these are same sorts of things you
> want to have index entries for, if your man pages were indexed.

That sounds useful.  Thanks!

[...]

> None of the foregoing observations or plans intends to obviate the
> utility of mansect(1) for anyone.  If it works satisfactorily, use it.
> But if people encounter limitations in it, and those seem solvable only
> by getting a deeper look into the formatter's brain (program state),
> then the time may become ripe to work on these tickets.

So far, I'm pretty happy with mansect(1).  In fact, I'd like to have it
even if groff(1) added that feature.  The rationale is that mansect(1)
gives me the man(7) source, which I can then format with any formatter,
so I can use it to debug an arbitrary formatter.

> (Regardless, I want to attack #62264 because string processing in *roff
> is pure hell, and inflexible too, because diversions can be "handled"
> like strings if you tilt your head right, but only in limited ways.)

:-)


> Regards,
> Branden

Have a lovely day!
Alex

> 
> [1] And a great deal of forced learning due to
>       https://savannah.gnu.org/bugs/?63074
>     and
>       https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=52f93e69dddb39bbfbbf7c43e355538e35b8edab
>     ...which both taught me a lot.
> 
>     You can (in groff 1.24.0) take an NMRI of much of GNU troff's brain
>     in vivo without needing to use a debugger.  I consider that a win.



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]