Re: Playground pager lsp(1)

[G. Branden Robinson]

At 2023-04-06T03:10:59+0200, Alejandro Colomar wrote:
> Hmm, now that I think, it's probably an issue of coordinating man(1)
> and less(1).  I sometimes wish that when I resize a window where I'm
> reading a man page, it would reformat the page from source.

Seems like it shouldn't be impossible to me, but what I imagine would
require a little reëngineering of man(1), perhaps to spawn a little
custom program to manage zcat/nroff pipeline it constructs.  This little
program's sole job could be to be aware of this pipeline and listen for
SIGWINCH; if it happens, kill the rest of the pipeline and reëxecute it.

Maybe I thought of it this way because (I suspect) it aligns with my
vision I've expressed elsewhere of man(1) having unfortunately
aggregated two separate functions: librarian vs. renderer.
Historically, of course the latter function was almost vestigial, since
early Unix systems had no pager program and their man pages required
little to no preprocessing; man(1) slowly accreted into a larger thing.

> Of course, that might be a problem for keeping track of where I was,
> since lines moved around.

That seems like a harder problem to me.  You'd need a way for the pager
to communicate position information back to the mini-man renderer
program I envision.  Two challenges here: (1) what part of the screen
was the reader actually looking at?  (2) how is the pager supposed to
know how to map any given location on the screen back to a place in the
unrendered source document so it can be accurately found when the
document is rerendered?  These feel nearly intractable to me.  But maybe
I have a poor imagination.

> Ahh, yes, this is true.  What I found missing is a kind of a map for
> knowing what I have available for navigating (also the fact that I
> don't usually run info(1) makes me be a bit fuzzy on detailing what
> is it that I miss from it).  So, info(1) has a map of the sections
> available in a page, and does it also have a map of all the pages
> in the system (or whatever you call your pages, I don't yet really
> understand the organization of info manuals).

The "install-info" program is run by packages that install info
documents to the system.  This creates or updates a file called "dir".

For instance, when I "make install" an everyday groff build, the
following shows up.

/home/branden/groff/share/info/dir
/home/branden/groff/share/info/groff.info
/home/branden/groff/share/info/groff.info-1
/home/branden/groff/share/info/groff.info-2
/home/branden/groff/share/info/groff.info-3

Since help-texinfo is on the distribution list of this mail, I'll take
this opportunity to note something from groff's INSTALL.extra file,
explaining how to uninstall the package.

  ... Run the command 'sudo make uninstall'.  (If you successfully used
  'make install', simply run 'make uninstall'.)  At a minimum, some
  directories not particular to groff, like 'bin' and (depending on
  configuration) an X11 'app-defaults' directory will remain, as will
  one plain file called 'dir', created by GNU Texinfo's 'install-info'
  command.  (As of this writing, 'install-info' offers no provision for
  removing an effectively empty 'dir' file, and groff does not attempt
  to parse this file to determine whether it can be safely removed.)
  All other groff artifacts will be deleted from the installation
  hierarchy.

Any chance 'install-info' could get savvy as noted above?  (Maybe it
already has--I'm running 6.7.0.)

Regards,
Branden

signature.asc
Description: PGP signature