On 18 July 2015 at 20:02, Per Bothner <p...@bothner.com> wrote:
> When the texinfo tool chain fails IMO is the use of the generated info
> format,
> the one you see in Emacs info mode or the standalone 'info' application.
> This format should be replaced by HTML - but now we're talking about HTML
> as a generated format, not a source format. I don't think anyone objects in
> principle, but someone needs to do the work to modify the tools and workflow
> to work with HTML. One idea is to write a new emacs 'info mode' that is
> hybrid
> between the existing info mode (for the keybindings and interface, as well
> as
> backward compatibility) and eww mode (for the parsing of HTML and the
> rendering).
>
> But unless some does the actual work, it's pointless to complain.
Let me add some pointless comments to this pointless discussion. It's
given me an excuse to bloviate.
Arthur mentioned editor support, which I assume to mean WYSIWIG ("what
you see is what you get"), like what you get with editors like
LibreOffice or OpenOffice. For this to work the editor would have to
have some understanding of Texinfo syntax. This could be achieved by
adapting parts of "makeinfo" to work as a plugin that could parse
Texinfo that is given to it and pass it back to the editor in a useful
form. I know there was a project to design a format called IXIN to
represent the information in Texinfo code; maybe that or something
similar could be used. I heard that Guile is useful for this kind of
thing: namely, facilitating manipulation of state in persistent
interactive programs when the program is made of multiple parts, e.g.
the main program and plug-ins. I don't know if there are user-friendly
word processors with an infrastructure that would allow this kind of
thing (maybe Emacs is the closest), and it's beyond me to research how
to make this possible anytime in the foreseeable future. (That's why
this email I'm writing isn't very useful.)
Presentation of documentation can certainly be more sophisticated than
Info on modern computers. Info is for character terminals. Modern
computers (or computers less than three decades old or so) have
graphical displays. PDF/TeX/dvi output is probably the prettiest,
although I'm not sure the most functional to use on a computer when
the PDF reader you use has blurry anti-aliased fonts, and there are
pointless page breaks that are meaningless for reading on a display,
and not on paper. Info is probably the most functional format at the
moment with its searching and indexing capabilities as well as manual
lookup search paths (unlike HTML which only looks for a referenced
file in a single location). HTML is somewhere in the middle, in terms
of ugliness and functionality.
It would be nice to be able to use the available display technology to
the full to be able to browse documentation that is as pretty as PDF
and as functional as Info. Since before I said a WYSIWIG editor would
be a nice thing to have, perhaps turning that editor into a
full-fledged browser wouldn't be impossible.
Although terminals are inferior to GUI interfaces they still have
their place, as a stable and well-understood programming interface,
that we can use, for example, for ssh if you don't want to waste your
time working out how X11 forwarding works or any number of remote
desktop protocols, and use when we're interested in what we're working
on and don't want to waste time fiddling with our tools. Terminal
interfaces don't have to be pretty and it doesn't matter that Info the
format doesn't even support colours or boldface. Using HTML to replace
Info wouldn't add much IMO for terminal usage, but Info is also used
by Emacs in a GUI, and for that use I can fully support enabling a
sophisticated and beautiful way to browse (and/or edit) documentation,
like what I mentioned above.
