linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Arsen Arsenović" <arsen@aarsen.me>
To: Eli Zaretskii <eliz@gnu.org>, Gavin Smith <GavinSmith0123@gmail.com>
Cc: Dirk Gouders <dirk@gouders.net>,
	alx.manpages@gmail.com, linux-man@vger.kernel.org,
	help-texinfo@gnu.org
Subject: A less presumptive .info? (was: Re: Playground pager lsp(1))
Date: Wed, 05 Apr 2023 22:38:12 +0200	[thread overview]
Message-ID: <865yaa81ru.fsf@aarsen.me> (raw)
In-Reply-To: <83zg7mqha4.fsf@gnu.org>

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


Eli Zaretskii <eliz@gnu.org> writes:

> Info files are formatted already, you cannot ask the reader to
> reformat them for a different line length.
>
> With man pages this is only possible if you never keep the formatted
> pages and reuse them once they were produced.

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?
-- 
Arsen Arsenović

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

  parent reply	other threads:[~2023-04-05 21:20 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-25 20:37 Playground pager lsp(1) Dirk Gouders
2023-03-25 20:47 ` Dirk Gouders
2023-04-04 23:45   ` Alejandro Colomar
2023-04-05  5:35     ` Eli Zaretskii
2023-04-06  1:10       ` Alejandro Colomar
2023-04-06  8:11         ` Eli Zaretskii
2023-04-06  8:48           ` Gavin Smith
2023-04-07 22:01           ` Alejandro Colomar
2023-04-08  7:05             ` Eli Zaretskii
2023-04-08 13:02               ` Accessibility of man pages (was: Playground pager lsp(1)) Alejandro Colomar
2023-04-08 13:42                 ` Eli Zaretskii
2023-04-08 16:06                   ` Alejandro Colomar
2023-04-08 13:47                 ` Colin Watson
2023-04-08 15:42                   ` Alejandro Colomar
2023-04-08 19:48                   ` Accessibility of man pages Dirk Gouders
2023-04-08 20:02                     ` Eli Zaretskii
2023-04-08 20:46                       ` Dirk Gouders
2023-04-08 21:53                         ` Alejandro Colomar
2023-04-08 22:33                           ` Alejandro Colomar
2023-04-09 10:28                       ` Ralph Corderoy
2023-04-08 20:31                     ` Ingo Schwarze
2023-04-08 20:59                       ` Dirk Gouders
2023-04-08 22:39                         ` Ingo Schwarze
2023-04-09  9:50                           ` Dirk Gouders
2023-04-09 10:35                             ` Dirk Gouders
     [not found]                 ` <87a5zhwntt.fsf@ada>
2023-04-09 12:05                   ` Compressed man pages (was: Accessibility of man pages (was: Playground pager lsp(1))) Alejandro Colomar
2023-04-09 12:17                     ` Alejandro Colomar
2023-04-09 18:55                       ` G. Branden Robinson
2023-04-09 12:29                     ` Colin Watson
2023-04-09 13:36                       ` Alejandro Colomar
2023-04-09 13:47                         ` Compressed man pages Ralph Corderoy
2023-04-12  8:13                     ` Compressed man pages (was: Accessibility of man pages (was: Playground pager lsp(1))) Sam James
2023-04-12  8:32                       ` Compressed man pages Ralph Corderoy
2023-04-12 10:35                         ` Mingye Wang
2023-04-12 10:55                           ` Ralph Corderoy
2023-04-12 13:04                       ` Compressed man pages (was: Accessibility of man pages (was: Playground pager lsp(1))) Kerin Millar
2023-04-12 14:24                         ` Alejandro Colomar
2023-04-12 18:52                           ` Mingye Wang
2023-04-12 20:23                             ` Compressed man pages Alejandro Colomar
2023-04-13 10:09                             ` Ralph Corderoy
2023-04-07  2:18         ` Playground pager lsp(1) G. Branden Robinson
2023-04-07  6:36           ` Eli Zaretskii
2023-04-07 11:03             ` Gavin Smith
2023-04-07 14:43             ` man page rendering speed (was: Playground pager lsp(1)) G. Branden Robinson
2023-04-07 15:06               ` Eli Zaretskii
2023-04-07 15:08                 ` Larry McVoy
2023-04-07 17:07                 ` man page rendering speed Ingo Schwarze
2023-04-07 19:04                 ` man page rendering speed (was: Playground pager lsp(1)) Alejandro Colomar
2023-04-07 19:28                   ` Gavin Smith
2023-04-07 20:43                     ` Alejandro Colomar
2023-04-07 16:08               ` Colin Watson
2023-04-08 11:24               ` Ralph Corderoy
2023-04-07 21:26           ` reformatting man pages at SIGWINCH " Alejandro Colomar
2023-04-07 22:09             ` reformatting man pages at SIGWINCH Dirk Gouders
2023-04-07 22:16               ` Alejandro Colomar
2023-04-10 19:05                 ` Dirk Gouders
2023-04-10 19:57                   ` Alejandro Colomar
2023-04-10 20:24                   ` G. Branden Robinson
2023-04-11  9:20                     ` Ralph Corderoy
2023-04-11  9:39                     ` Dirk Gouders
2023-04-17  6:23                       ` G. Branden Robinson
2023-04-08 11:40               ` Ralph Corderoy
2023-04-05 10:02     ` Playground pager lsp(1) Dirk Gouders
2023-04-05 14:19       ` Arsen Arsenović
2023-04-05 18:01         ` Dirk Gouders
2023-04-05 19:07           ` Eli Zaretskii
2023-04-05 19:56             ` Dirk Gouders
2023-04-05 20:38             ` Arsen Arsenović [this message]
2023-04-06  8:14               ` A less presumptive .info? (was: Re: Playground pager lsp(1)) Eli Zaretskii
2023-04-06  8:56                 ` Gavin Smith
2023-04-07 13:14                 ` Arsen Arsenović
2023-04-06  1:31       ` Playground pager lsp(1) Alejandro Colomar
2023-04-06  6:01         ` Dirk Gouders

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=865yaa81ru.fsf@aarsen.me \
    --to=arsen@aarsen.me \
    --cc=GavinSmith0123@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=dirk@gouders.net \
    --cc=eliz@gnu.org \
    --cc=help-texinfo@gnu.org \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).