Re: A less presumptive .info? (was: Re: Playground pager lsp(1))

[Eli Zaretskii <eliz@gnu.org>]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Dirk Gouders <dirk@gouders.net>, alx.manpages@gmail.com,
>  linux-man@vger.kernel.org, help-texinfo@gnu.org
> Date: Wed, 05 Apr 2023 22:38:12 +0200
> 
> I've been casually wondering if creating a new format that can host more
> formatting options and uses more precise syntax than 'plaintext with
> some binary tags' would be a decent thing to work on.
> 
> My thoughts were brief and undeveloped as this was thought of on the
> commute, but something that retains the binary offsets for indices and
> tags, but stores formatted data (perhaps as s-exprs, those would be easy
> to parse).  It is always easier to remove information than to
> reintroduce it.
> 
> Such a structure should resemble the input language, but with far less
> complexity (e.g. something at the level of abstraction that HTML5 sits
> at, so, macros would be expanded, and we'd be dealing with lists of
> paragraphs and formatted blocks, etc.).
> 
> This would allow for the reflowing that was talked about in this thread,
> and provide more readable output in graphical contexts, as it wouldn't
> be data generated with the assumption of a monospace font (rather, the
> format could store whether your context wants monospace or proportional
> fonts at a given point), or data generated for a given screen size, or
> with a given indentation size, or with the assumption of a lack of
> features like italics, etc.
> 
> For instance, info2html used by the KDE info viewer currently produces
> quite terrible results, because it fails to implement the heuristics the
> Info viewers have properly.  This problem would be hard to have with a
> better "at-rest" format for Info pages.
> 
> The alternative is, of course, bringing HTML up to par feature-wise
> (wrt. indices etc), but that'd be on the other end of the extreme, where
> instead of being too easy to parse and lacking important information,
> it'd be oververbose with and difficult to parse (not that such a thing
> should not be done too, so that folks using ordinary browsers can enjoy
> documentation, and so that projects can provide more accessible
> documentation by the merit of more people having HTML than Info
> viewers).
> 
> WDYT folks?

Gavin will tell, but AFAIU our plan is to develop js as the means
towards the goals you mentioned.  That will allow using HTML browsers
to read Texinfo documentation without losing the functionalities of
the Info readers we value.  HTML rendering reflows as integral part of
its workings, so that problem is not an issue if this plan succeeds.