Variable pitch mode line

Variable pitch mode line

[Lars Ingebrigtsen]

It's been almost a month since it was switched to "on", so I think it's
about time to take stock.

I think that, long term, we want to go in that direction.  But we've
uncovered some usability problems, mainly in the "how do I click those
things in "U:--" anyway?" area, and we've got a plan to fix that, but
haven't yet.

So I think the way forward is to revert the trunk back to monospaced
fonts, then fix the usability problems, and then do another test in a
few months.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 22 Dec 2021 14:14:22 +0100
> 
> So I think the way forward is to revert the trunk back to monospaced
> fonts, then fix the usability problems, and then do another test in a
> few months.

I tend to agree.

Re: Variable pitch mode line

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I think the way forward is to revert the trunk back to monospaced
> fonts, then fix the usability problems, and then do another test in a
> few months.

FWIW, I saw no issues with the new default here but the above plan
sounds good to me.

Re: Variable pitch mode line

[Juri Linkov]

> It's been almost a month since it was switched to "on", so I think it's
> about time to take stock.
>
> I think that, long term, we want to go in that direction.  But we've
> uncovered some usability problems, mainly in the "how do I click those
> things in "U:--" anyway?" area, and we've got a plan to fix that, but
> haven't yet.
>
> So I think the way forward is to revert the trunk back to monospaced
> fonts, then fix the usability problems, and then do another test in a
> few months.

Variable pitch mode line is nice, but definitely that part with "U:---"
should use monospaced fonts.  Also using variable pitch would be nice
of header lines where it has no problems.

Re: Variable pitch mode line

[Tassilo Horn]

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

Juri Linkov <juri@linkov.net> writes:

> Also using variable pitch would be nice of header lines where it has
> no problems.

The header-line face inherits from mode-line, so it's variable pitch
right now, no?  And in fact, while reading your message I became aware
that my mu4e header line is misaligned.

[-- Attachment #2: Screenshot-2021-12-22_211857.png --]
[-- Type: image/png, Size: 16038 bytes --]

[-- Attachment #3: Type: text/plain, Size: 275 bytes --]


Bye,
Tassilo

BTW: I would love to have pixel-filled, variable pitch info docs.
`variable-pitch-mode' in info has the bad effect that also code samples
or ASCII art [like the cons box&arrows in (info "(elisp) Building
Lists")] then use the variable pitch font and misalign.

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> The header-line face inherits from mode-line,

Yes.

> so it's variable pitch right now, no?

Not by default, no.  The `mode-line' face isn't variable-pitch, only the
mode-line-active and mode-line-inactive faces are.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Tassilo Horn]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> The header-line face inherits from mode-line,
>
> Yes.
>
>> so it's variable pitch right now, no?
>
> Not by default, no.  The `mode-line' face isn't variable-pitch, only
> the mode-line-active and mode-line-inactive faces are.

Oh, I haven't known the new `mode-line-active' face yet.  After your
announcement I decided to customize my (themed) mode-line with
variable-pitch fonts but used mode-line and mode-line-inactive and so
also got a variable-pitch header-line.

Bye,
Tassilo

Re: Variable pitch mode line

[Juri Linkov]

> BTW: I would love to have pixel-filled, variable pitch info docs.
> `variable-pitch-mode' in info has the bad effect that also code samples
> or ASCII art [like the cons box&arrows in (info "(elisp) Building
> Lists")] then use the variable pitch font and misalign.

The only way to reliably support variable pitch in the Info reader
is by using HTML output from Texinfo and rendering it with eww/shr.

But the problem is that most GNU/Linux distributions still don't include
Info manuals in the HTML format alongside with the Info format.
Thus we are stuck with monospaced Info manuals forever.

Re: Variable pitch mode line

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> But the problem is that most GNU/Linux distributions still don't include
> Info manuals in the HTML format alongside with the Info format.
> Thus we are stuck with monospaced Info manuals forever.

Someone (TM) should file bugs for that against the major distributions.

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 23 Dec 2021 09:52:42 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > But the problem is that most GNU/Linux distributions still don't include
> > Info manuals in the HTML format alongside with the Info format.
> > Thus we are stuck with monospaced Info manuals forever.
> 
> Someone (TM) should file bugs for that against the major distributions.

It's not a simple bug, and I'm not sure distro packagers can alone
make this happen.  The Texinfo project has no good system for
installing HTML-formatted documentation in a way that links between
manuals work reliably.

Re: Variable pitch mode line

[Juri Linkov]

>> Someone (TM) should file bugs for that against the major distributions.
>
> It's not a simple bug, and I'm not sure distro packagers can alone
> make this happen.  The Texinfo project has no good system for
> installing HTML-formatted documentation in a way that links between
> manuals work reliably.

Why HTML files couldn't be installed in the same dir where all files
in the Info format are installed?  Then it's the task of the Info reader
to handle links between manuals in the HTML format the same way as
links in the Info format are handled by the Info reader.

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  tsdh@gnu.org,  larsi@gnus.org,
>   emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 20:38:00 +0200
> 
> > It's not a simple bug, and I'm not sure distro packagers can alone
> > make this happen.  The Texinfo project has no good system for
> > installing HTML-formatted documentation in a way that links between
> > manuals work reliably.
> 
> Why HTML files couldn't be installed in the same dir where all files
> in the Info format are installed?

Because AFAIK that's not the canonical place where HTML docs are
installed, they are somewhere in /usr/share/doc/.

> Then it's the task of the Info reader to handle links between
> manuals in the HTML format the same way as links in the Info format
> are handled by the Info reader.

The additional difficulty, apart of the top-level directory, is that
HTML docs can either be produced as a single file or as separate files
per chapter/section, and then the directory structure (and
correspondingly the job of resolving links) becomes more complicated.

It isn't rocket science to fix this, but it's not something distro
maintainers can do, it's something Texinfo should do, perhaps
consulting with us.

Re: Variable pitch mode line

[Juri Linkov]

>> Why HTML files couldn't be installed in the same dir where all files
>> in the Info format are installed?
>
> Because AFAIK that's not the canonical place where HTML docs are
> installed, they are somewhere in /usr/share/doc/.

But these files are not HTML docs, they are Info docs in HTML format.

>> Then it's the task of the Info reader to handle links between
>> manuals in the HTML format the same way as links in the Info format
>> are handled by the Info reader.
>
> The additional difficulty, apart of the top-level directory, is that
> HTML docs can either be produced as a single file or as separate files
> per chapter/section, and then the directory structure (and
> correspondingly the job of resolving links) becomes more complicated.
>
> It isn't rocket science to fix this, but it's not something distro
> maintainers can do, it's something Texinfo should do, perhaps
> consulting with us.

Then distro maintainers could always generate a single file.

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: stefankangas@gmail.com,  tsdh@gnu.org,  larsi@gnus.org,
>   emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 21:39:05 +0200
> 
> >> Why HTML files couldn't be installed in the same dir where all files
> >> in the Info format are installed?
> >
> > Because AFAIK that's not the canonical place where HTML docs are
> > installed, they are somewhere in /usr/share/doc/.
> 
> But these files are not HTML docs, they are Info docs in HTML format.

What's the difference?  They are HTML files, complete with index.html
and other stuff.  Look in your /usr/share/doc directory and tell me
what significant differences are between, say, GTK docs and the HTML
formatted manuals produced by makeinfo from Texinfo sources.

> > The additional difficulty, apart of the top-level directory, is that
> > HTML docs can either be produced as a single file or as separate files
> > per chapter/section, and then the directory structure (and
> > correspondingly the job of resolving links) becomes more complicated.
> >
> > It isn't rocket science to fix this, but it's not something distro
> > maintainers can do, it's something Texinfo should do, perhaps
> > consulting with us.
> 
> Then distro maintainers could always generate a single file.

You assume they will want to.  Browsing a short HTML file is easier
than browsing a long one: for example, accurate scrolling by the
scroll-bar is much easier.  I don't think it's a good idea to assume
the distributed HTML will always be a single file.

Anyway, we are discussing this in the wrong place.  If we want to lead
the move towards using HTML docs, we need to discuss this with Texinfo
folks, because they need to do the footwork, and they also need to be
aware of the move.

Re: Variable pitch mode line

[Juri Linkov]

>> But these files are not HTML docs, they are Info docs in HTML format.
>
> What's the difference?  They are HTML files, complete with index.html
> and other stuff.  Look in your /usr/share/doc directory and tell me
> what significant differences are between, say, GTK docs and the HTML
> formatted manuals produced by makeinfo from Texinfo sources.

The main difference is in the file /usr/share/info/dir
that maintains a list of all installed manuals.

>> Then distro maintainers could always generate a single file.
>
> You assume they will want to.  Browsing a short HTML file is easier
> than browsing a long one: for example, accurate scrolling by the
> scroll-bar is much easier.  I don't think it's a good idea to assume
> the distributed HTML will always be a single file.
>
> Anyway, we are discussing this in the wrong place.  If we want to lead
> the move towards using HTML docs, we need to discuss this with Texinfo
> folks, because they need to do the footwork, and they also need to be
> aware of the move.

Even if we will support HTML in the Emacs Info reader,
distro maintainers won't be interested to include HTML files
until the standalone Info reader will be able to read HTML files.

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> The only way to reliably support variable pitch in the Info reader
> is by using HTML output from Texinfo and rendering it with eww/shr.
>
> But the problem is that most GNU/Linux distributions still don't include
> Info manuals in the HTML format alongside with the Info format.
> Thus we are stuck with monospaced Info manuals forever.

Well, not necessarily.  If we started making HTML the preferred format
for the `C-h i' etc, then they'd probably follow after a while.  And
it'd be fine for some manuals to be in HTML while other remain in INFO.

But nobody's yet to make an info-html-minor mode (or a major mode a la
eww building upon shr), so it's still academic.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Juri Linkov]

>> The only way to reliably support variable pitch in the Info reader
>> is by using HTML output from Texinfo and rendering it with eww/shr.
>>
>> But the problem is that most GNU/Linux distributions still don't include
>> Info manuals in the HTML format alongside with the Info format.
>> Thus we are stuck with monospaced Info manuals forever.
>
> Well, not necessarily.  If we started making HTML the preferred format
> for the `C-h i' etc, then they'd probably follow after a while.  And
> it'd be fine for some manuals to be in HTML while other remain in INFO.

Probably not before the standalone Info reader will support HTML.

> But nobody's yet to make an info-html-minor mode (or a major mode a la
> eww building upon shr), so it's still academic.

It can't be a mode because some Info manuals are split among several files.

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Well, not necessarily.  If we started making HTML the preferred format
>> for the `C-h i' etc, then they'd probably follow after a while.  And
>> it'd be fine for some manuals to be in HTML while other remain in INFO.
>
> Probably not before the standalone Info reader will support HTML.

Perhaps, or perhaps they'll want to have Info pages that look prettier.

>> But nobody's yet to make an info-html-minor mode (or a major mode a la
>> eww building upon shr), so it's still academic.
>
> It can't be a mode because some Info manuals are split among several files.

I don't follow the logic.  You can make a mode that covers as many
files as you wish.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Juri Linkov]

>>> Well, not necessarily.  If we started making HTML the preferred format
>>> for the `C-h i' etc, then they'd probably follow after a while.  And
>>> it'd be fine for some manuals to be in HTML while other remain in INFO.
>>
>> Probably not before the standalone Info reader will support HTML.
>
> Perhaps, or perhaps they'll want to have Info pages that look prettier.

I don't believe that distro packagers might want to include Info manuals
in the HTML format when only Emacs will display them but not the standalone
Info reader.

>>> But nobody's yet to make an info-html-minor mode (or a major mode a la
>>> eww building upon shr), so it's still academic.
>>
>> It can't be a mode because some Info manuals are split among several files.
>
> I don't follow the logic.  You can make a mode that covers as many
> files as you wish.

I meant this is not like the Emacs Info reader works.
It's not enough to enable Info-mode after visiting
an Info file.  At least, you need to use Info-on-current-buffer.
And still it works only on the first Info file in the sequence
of multiple Info files.

Re: Variable pitch mode line

[Stefan Monnier]

>> Perhaps, or perhaps they'll want to have Info pages that look prettier.
> I don't believe that distro packagers might want to include Info manuals
> in the HTML format when only Emacs will display them but not the standalone
> Info reader.

I'm not sure they include Info manuals mainly for the standalone info
viewer either.  But in any case, currently I don't think any doc viewer
has a good story for "use HTML as replacement for Info", so it's clear
that if we want it to happen, we need to start by making Emacs support
it well.  And only later, *maybe*, distros and other Info viewers will
follow suit.

>>>> But nobody's yet to make an info-html-minor mode (or a major mode a la
>>>> eww building upon shr), so it's still academic.
>>> It can't be a mode because some Info manuals are split among several files.
>> I don't follow the logic.  You can make a mode that covers as many
>> files as you wish.
> I meant this is not like the Emacs Info reader works.
> It's not enough to enable Info-mode after visiting
> an Info file.  At least, you need to use Info-on-current-buffer.
> And still it works only on the first Info file in the sequence
> of multiple Info files.

This discussion doesn't matter: he was only talking about making
Info-mode work both for Info and HTML documents, suggesting to use
a boolean var named `info-html-minor` in order to distinguish which is
currently used in the `Info-mode` buffer, which can/will change as you
navigate from one manual to another.

But, FWIW, I consider multifile Info manuals to be a thing of the past
and I'd be happy to actively discourage their use.


        Stefan

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org,  Tassilo Horn
>  <tsdh@gnu.org>
> Date: Thu, 23 Dec 2021 14:50:26 -0500
> 
> >> Perhaps, or perhaps they'll want to have Info pages that look prettier.
> > I don't believe that distro packagers might want to include Info manuals
> > in the HTML format when only Emacs will display them but not the standalone
> > Info reader.
> 
> I'm not sure they include Info manuals mainly for the standalone info
> viewer either.  But in any case, currently I don't think any doc viewer
> has a good story for "use HTML as replacement for Info", so it's clear
> that if we want it to happen, we need to start by making Emacs support
> it well.  And only later, *maybe*, distros and other Info viewers will
> follow suit.

FYI: the Texinfo folks are working on JSInfo, a Javascript-based Info
reader that displays the HTML formatted manuals.  It is already
available, on experimental basis, in the latest Texinfo 6.8.

> But, FWIW, I consider multifile Info manuals to be a thing of the past
> and I'd be happy to actively discourage their use.

You can't, because quite some GNU projects still produce multi-file
Info manuals.  Example: GDB.

Re: Variable pitch mode line

[Stefan Monnier]

>> But, FWIW, I consider multifile Info manuals to be a thing of the past
>> and I'd be happy to actively discourage their use.
> You can't, because quite some GNU projects still produce multi-file
> Info manuals.  Example: GDB.

It's technically easy to change, AFAIK.
Any reason why they insist on using multiple files?
Would these reasons be influenced by a change in Emacs such that
multi-file Info manuals can't be browsed any more?


        Stefan

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: juri@linkov.net,  larsi@gnus.org,  emacs-devel@gnu.org,  tsdh@gnu.org
> Date: Thu, 23 Dec 2021 15:12:39 -0500
> 
> >> But, FWIW, I consider multifile Info manuals to be a thing of the past
> >> and I'd be happy to actively discourage their use.
> > You can't, because quite some GNU projects still produce multi-file
> > Info manuals.  Example: GDB.
> 
> It's technically easy to change, AFAIK.

Technically, yes.

> Any reason why they insist on using multiple files?

No idea.

> Would these reasons be influenced by a change in Emacs such that
> multi-file Info manuals can't be browsed any more?

I don't know.

HTML info

[Yuan Fu]

I’m a bit confused. In order to have variable-pitch info’s. What do we need to do and what do makeinfo maintainers need to do?

Disregard of where will the HTML info files be, whether they will be in a single file, whether distributions will distribute HTML info files, what do we need to do in order to at least support reading HTML info files like .info files?

Is it a good idea that we start from a major mode Info-html-mode that can view manuals in either a single or multiple HTML files, that supports various info commands?

Yuan

Re: HTML info

[Juri Linkov]

> I’m a bit confused. In order to have variable-pitch info’s. What do we
> need to do and what do makeinfo maintainers need to do?

What we can already do is to at least display Emacs manuals from HTML
generated by `make html`.

> Disregard of where will the HTML info files be, whether they will be
> in a single file, whether distributions will distribute HTML info
> files, what do we need to do in order to at least support reading HTML
> info files like .info files?
>
> Is it a good idea that we start from a major mode Info-html-mode that
> can view manuals in either a single or multiple HTML files, that
> supports various info commands?

Most of the core package info.el deals with handling of the Info format.

Take for example Info-search.  What it mostly does is parsing the Info file's
tag table and visiting Info subfiles.  All this is not needed for HTML.
Instead of this, the HTML search function will have other problems:
how to skip text in HTML tags, e.g. searching for the word "href"
should not match it as the HTML attribute in ‘<a href="">...</a>’, etc.

OTOH, some of Info-search code should be reused in HTML Info files:
- the key ‘s’ bound in Info-mode-map should still call ‘Info-search’;
- the interactive spec should be used without changes for HTML search;
- such code (signal 'user-search-failed (list regexp "end of manual"))
  should be reused, etc. (And most isearch functions in info.el are
  already general enough that can be used for both Info and HTML formats,
  except the Info-format specific ‘Info-isearch-filter’.)

So we have at least 3 choices:

1. Intersperse the existing Info-search with such conditionals:

   (if info-html-minor
       (search-forward "<div class="contents">")
     (search-forward "\n\^_\nIndirect:"))

2. Add more hooks to every Info top command,
   so Info-html-mode could register own handlers:

   (add-hook 'Info-search-function 'Info-html-search)

3. Completely duplicate all top Info commands in a new package
   info-html.el.

Re: HTML info

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  tsdh@gnu.org,  Lars Ingebrigtsen
>  <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Fri, 24 Dec 2021 10:34:34 +0200
> 
> 1. Intersperse the existing Info-search with such conditionals:
> 
>    (if info-html-minor
>        (search-forward "<div class="contents">")
>      (search-forward "\n\^_\nIndirect:"))
> 
> 2. Add more hooks to every Info top command,
>    so Info-html-mode could register own handlers:
> 
>    (add-hook 'Info-search-function 'Info-html-search)
> 
> 3. Completely duplicate all top Info commands in a new package
>    info-html.el.

I think a new package would be cleaner.  It can always borrow ideas
and even code from info*.el, as appropriate.

In addition, I suggest to look at the Javascript code developed by
Texinfo, to maybe reuse some ideas and look-and-feel.  There's no need
for Emacs to depart from what's there where commonality makes sense.

Re: HTML info

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> 3. Completely duplicate all top Info commands in a new package
>    info-html.el.

I think that's best.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: HTML info

[Po Lu]

Juri Linkov <juri@linkov.net> writes:

>> I’m a bit confused. In order to have variable-pitch info’s. What do we
>> need to do and what do makeinfo maintainers need to do?

> What we can already do is to at least display Emacs manuals from HTML
> generated by `make html`.

Doesn't Drew Adams (copied in) maintain a package that allows displaying
Info documentation in a variable pitch face?

Thanks.

RE: [External] : Re: HTML info

[Drew Adams]

> Doesn't Drew Adams (copied in) maintain a package that allows displaying
> Info documentation in a variable pitch face?

Well, not really.  Sort of.

I tried to base guessing whether something might
be a candidate for using a fixed-width font on
indentation level.  The idea is to use that for
code, ASCII art, tables, etc.

But as Eli, and experimentation with more Info
manuals, pointed out, that heuristic isn't very
reliable.

As Eli has also said here, though Texinfo might
have some useful information about such things,
much of that gets lost in the translation to
Info output.  Just like vanilla `info.el', my
code works with the Info output.
___

However, what my code does can be useful for
some manuals, such as the Elisp manual.  Its
guesses based on indentation level do a pretty
good job there.

The code is in `info+.el'.  To try it, turn on
option `Info-fontify-indented-text-chars'.  Then
text indented at least that many chars gets face
`info-indented-text'.  If you then also turn on
minor mode `Info-variable-pitch-text-mode', the
rest of the text will be variable pitch.

In the Elisp manual this generally means blocks
of code and ASCII-art diagrams use fixed-pitch.
But in general there's no telling what might be
indented at any given level, so caveat emptor.

Option `Info-fontify-indented-text-manuals'
lets you specify which manuals fontify indented
text with a fixed-pitch face.  The default is
just the Elisp manual.

Think of this as an experimental feature.  Try
it, to see the effect.  If you like it, you can
have it turned on only in particular manuals.

Doc string of `Info-fontify-indented-text-chars':
___

A number means fontify text indented at least that many chars.
The default value is nil, which does nothing - no such fontifying.

The indented text is fontified with face `info-indented-text', which
by default uses a fixed-pitch font.

This can be useful especially if minor mode
`Info-variable-pitch-text-mode' is enabled, by keeping indented code
block, ASCII-art diagrams etc. in a fixed-pitch font.

A value of 10 works well for the Elisp manual.  But be aware that no
number works well across multiple manuals, because indented text at
any level is not necessarily something you want to fontify.

This fontification is not done for nodes named `Top', in order to
avoid fontifying continuation lines of menu-item descriptions.
___

Code:

https://www.emacswiki.org/emacs/download/info%2b.el

Re: HTML info

[Juri Linkov]

Eli Zaretskii <eliz@gnu.org> writes:

> I think a new package would be cleaner.  It can always borrow ideas
> and even code from info*.el, as appropriate.

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > 3. Completely duplicate all top Info commands in a new package
> >    info-html.el.
>
> I think that's best.

Fine.  Anyone wants to write such a package?  It would be nice to
include it in the core to be able to display Emacs manuals with
variable pitch fonts.

Re: HTML info

[Yuan Fu]

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



> On Dec 25, 2021, at 10:01 AM, Juri Linkov <juri@linkov.net> wrote:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> I think a new package would be cleaner.  It can always borrow ideas
>> and even code from info*.el, as appropriate.
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
>>> 3. Completely duplicate all top Info commands in a new package
>>>   info-html.el.
>> 
>> I think that's best.
> 
> Fine.  Anyone wants to write such a package?  It would be nice to
> include it in the core to be able to display Emacs manuals with
> variable pitch fonts.

I don’t claim to be seriously working on it, but here is a POC, I didn’t try to plug it into (dir), the only entry point right now is html-info-lispref which will open the lisp reference at /doc/lispref/elisp.html. You can click around and go next/prev/up but there is no i/[/]/r/l/etc.

One thing I noticed is that the HTML Info files lack a nice top level menu. The HTML Top only has a (very) long TOC and a short TOC. The TOC's only include the node name and leave out the short description.

I’m on a Mac which is case-insensitive, and my texinfo still have the bug where it drops index.html when merging Index.html and index.html. So I can’t test multi-file manual’s Top node (it’s in index.html). Besides that, single-file and multi-file seem to both work fine.

Yuan


[-- Attachment #2: html-info.el --]
[-- Type: application/octet-stream, Size: 16178 bytes --]

;;; html-info.el --- HTML Info  -*- lexical-binding: t; -*-

;; Author: Yuan Fu <casouri@gmail.com>

;;; This file is NOT part of GNU Emacs

;;; Commentary:

;;; Code:

(require 'pcase)
(require 'dom)
(require 'shr)

;;; Errors

(define-error 'html-info-error "Html-info generic error" 'error)
(define-error 'html-info-libxml-missing
              "Libxml library reqired but missing" 'html-info-error)
(define-error 'html-info-file-not-found
              "File not found" 'html-info-error)
(define-error 'html-info-not-full-path
              "File path not a full path" 'html-info-error)

(defvar-local html-info--current-file nil
  "The path of the currently visiting Info file.")

(defvar html-info--dom-cache nil
  "An alist of (PATH . DOM).
PATH is the path to an Info file, DOM is that file’s DOM.")

(defvar html-info--shr-override-map
  (let ((map (make-sparse-keymap )))
    (set-keymap-parent map shr-map)
    (define-key map [remap shr-browse-url]
                #'html-info--follow-link-at-point)
    map)
  "The keymap used to override the map on shr links.")

(defvar html-info--dom-classes-of-node
  '("chapter" "section" "subsection"
    "subsubsection" "subsubsubsection")
  "All possible class attributes of a node.")

(defvar html-info--navigation nil
  "A list of three anchor nodes.
Contains the next, previous and up node of the current node, in
that order.  Each anchor node is like (a ((href ...)) ...).")

(defun html-info--expand-node-name (node-name)
  "Expand NODE-NAME according to Texinfo algorithm."
  ;; See https://www.gnu.org/software/texinfo/manual/texinfo/html_node/HTML-Xref-Node-Name-Expansion.html
  (cl-labels ((need-encoding (ch)
                (not (string-match (rx (or letter digit " "))
                                   (char-to-string ch)))))
    (setq node-name
          (replace-regexp-in-string (rx (+ space)) " " node-name))
    (setq node-name (string-trim node-name))
    (setq node-name
          (mapconcat (lambda (ch)
                       (if (need-encoding ch)
                           (format "_%04x" ch)
                         (char-to-string ch)))
                     node-name))
    (setq node-name (string-replace " " "-" node-name))))

(defun html-info--check-full-path (path)
  (unless (file-name-absolute-p path)
    (signal 'html-info-not-full-path path)))

(defun html-info--dom-remove-subsections (dom)
  "Remove subsections from DOM.

A node in HTML is a div, this div contains not only the content
of that node, but also its sub-nodes.  We don’t want to display
the content of the sub-nodes, so we remove them with this
function."
  (append (list (dom-tag dom) (dom-attributes dom))
          (cl-remove-if (lambda (node)
                          (and (consp node)
                               (eq (dom-tag node) 'div)
                               (member (dom-attr node 'class)
                                       html-info--dom-classes-of-node)))
                        (dom-children dom))))

(defun html-info--dom-remove-header (dom)
  "Remove the header of DOM and return (DOM . (NEXT PREV UP)).

NEXT, PREV, UP are the anchor node (<a href=...>) of the
previous, next and up node, respectively."
  ;; We must not remove header destructively because we cache the dom
  ;; object.
  (let* ((dom (copy-tree dom))
         (header (car (dom-by-class dom "header")))
         (anchors (dom-by-tag header 'a))
         (navi
          ;; ANCHORS is either (NEXT PREV UP CONTENT INDEX)
          ;; or (NEXT UP CONTENT INDEX)
          ;; or (PREV UP CONTENT INDEX).
          (cond ((eq (length anchors) 5)
                 (cl-subseq anchors 0 3))
                ;; Prev is missing.
                ((string-match "Next" (dom-texts header))
                 (list (car anchors) nil (nth 2 anchors)))
                ;; Next is missing.
                ((string-match "Prev" (dom-texts header))
                 (cons nil (cl-subseq anchors 0 2))))))
    (dom-remove-node dom header)
    (cons dom navi)))

(defun html-info--get-dom (file)
  "Return the DOM of Info file FILE."
  (when (not (file-exists-p file))
    (signal 'html-info-file-not-found file))
  (if (fboundp 'libxml-parse-html-region)
      (or (alist-get file html-info--dom-cache nil nil #'equal)
          (setf (alist-get file html-info--dom-cache nil nil #'equal)
                (with-temp-buffer
                  (insert-file-contents file)
                  (libxml-parse-html-region (point-min) (point-max)))))
    (signal 'html-info-libxml-missing nil)))

(defun html-info--dom-bfs (dom pred)
  "Search DOM breadth-first with PRED. Return the first match.
PRED takes a single argument, the node."
  (declare (indent 1))
  (catch 'found
    (let ((queue (dom-children dom)))
      (while queue
        (let ((node (pop queue)))
          (when (consp node)
            (if (funcall pred node)
                (throw 'found node)
              (setq queue (append queue (dom-children node))))))))))

(defun html-info--find-node-1 (file id strict-case)
  "Return the DOM of the node with ID in FILE.
First search for ID case-sensitively, then case-insensitively
 (unless STRICT-CASE is t).  If ID is nil, we find the first node
 which its class is one of chapter, section, subsection, subsubsection."
  ;; We must find a chapter, section, subsection or subsubsection to
  ;; be NODE, and must not find an arbitrary node that contains the
  ;; chapter, section, etc that we actually want.  That is because we
  ;; use ‘html-info--dom-remove-subsections’ to remove any chapter etc
  ;; that’s _under_ NODE.  So if the target chapter etc is contained
  ;; in NODE rather than being NODE, it will be removed.  And that’s
  ;; bad.  If ID is non-nil, NODE must be a chapter etc.  If ID is
  ;; nil, we find the first chapter etc and use that (instead of the
  ;; top-level DOM).
  (let ((dom (html-info--get-dom file)))
    ;; If we are visiting the Top node, directly find shortcontents,
    ;; skip ‘dom-by-id’, because it traverses the whole DOM, and Top
    ;; node could be very large (contains the entire manual when the
    ;; manual is single-file).
    (if (or (equal (file-name-base file) "index")
            (equal id "Top"))
        (let* ((short-toc
                (html-info--dom-bfs dom
                  (lambda (node)
                    (equal (dom-attr node 'class) "shortcontents"))))
               (long-toc
                (html-info--dom-bfs dom
                  (lambda (node)
                    (equal (dom-attr node 'class) "contents"))))
               (links (dom-by-tag short-toc 'a))
               (real-links
                (mapcar
                 (lambda (anchor)
                   (let ((id (substring (dom-attr anchor 'href) 1)))
                     `(li nil ,@(dom-by-id long-toc id))))
                 links)))
          `(ul nil ,@real-links))
      (if id
          (if-let ((node
                    (or (let ((case-fold-search t))
                          (car (dom-by-id dom (format "^%s$" id))))
                        (if strict-case nil
                          (let ((case-fold-search nil))
                            (car (dom-by-id dom (format "^%s$" id))))))))
              (html-info--dom-remove-subsections node)
            nil)
        ;; ID is nil, find the first chapter, section, etc.  Search
        ;; breadth-first.
        (html-info--dom-remove-subsections
         (html-info--dom-bfs dom
           (lambda (node)
             (member (dom-attr node 'class)
                     html-info--dom-classes-of-node))))))))

(defun html-info--find-node (current-file node &optional strict-case)
  "Find the NODE, return its DOM and file path.

Specifically, return (DOM . PATH).

NODE can be either a string (node name) or (FILE . ID), where
FILE is the full path to the HTML Info file and ID is the node’s
ID.  CURRENT-FILE is the full path to the currently displayed HTML
Info file.

First looks for a case-sensitive match for the node part of
NODE-NAME; if none is found it then tries a case-insensitive
match \(unless STRICT-CASE is non-nil).

Return nil if no node is found."
  (if-let ((node-dom
            (if (stringp node)
                (html-info--find-node-1
                 current-file (html-info--expand-node-name node)
                 strict-case)
              nil)))
      (cons node-dom current-file)
    (pcase node
      ((pred stringp)
       (if-let ((path (expand-file-name
                       (concat (html-info--expand-node-name node) ".html")
                       (file-name-directory current-file)))
                (node-dom
                 (html-info--find-node-1 path nil strict-case)))
           (cons node-dom path)
         nil))
      (`(,file . ,id)
       (html-info--check-full-path file)
       (if-let ((node-dom (html-info--find-node-1 file id strict-case)))
           (cons node-dom file)
         nil)))))

(defun html-info-goto-node (node &optional fork strict-case)
  "Go to Info node named NODE.

TODO: (FILENAME)NODE-NAME.
TODO: Completion.
TODO: Empty NODE-NAME -> top node.
TODO: FORK as a string.

NODE can be either a string (node name) or (FILE . ID), where
FILE is the full path to the HTML Info file and ID is the node’s
HTML id.

FILE is the full path to the file in where the node resides.  If
omitted, FILE defaults to the currently visited Info file.

This function first looks for a case-sensitive match for the node part
of NODE-NAME; if none is found it then tries a case-insensitive match
\(unless STRICT-CASE is non-nil)."
  (pcase-let ((`(,node-dom . ,node-file)
               (html-info--find-node
                html-info--current-file node strict-case))
              (info-buffer (get-buffer-create
                            (if fork
                                (format "*html info-%s*"
                                        (if (stringp node)
                                            node (cdr node)))
                              "*html info*"))))
    (when (null node-dom)
      (user-error "No such node or anchor: %s" node))
    (switch-to-buffer info-buffer)
    (pcase-let*
        ((`(,final-dom . ,navi)
          (html-info--dom-remove-header node-dom))
         (inhibit-read-only t)
         (shr-map html-info--shr-override-map)
         (breadcrumb (if navi
                         (apply #'html-info--breadcrumbs navi)
                       "TODO breadcrumb for Top")))
      (erase-buffer)
      (if Info-use-header-line
          (setq header-line-format breadcrumb)
        (insert breadcrumb))
      (shr-insert-document final-dom)
      (unless (derived-mode-p 'html-info-mode)
        (html-info-mode))
      (setq html-info--current-file node-file)
      (setq html-info--navigation navi)
      (goto-char (point-min)))))

(define-button-type 'html-info-navigation-button
  'action #'html-info--button-follow-link
  'mouse-action #'html-info--button-follow-link
  'help-echo "Go to node"
  'follow-link t)

(defun html-info--breadcrumbs (next prev up)
  "Generate the breadcrumbs.
NEXT, PREV and UP are anchor nodes of the previous, next and up
node.  See ‘html-info--navigation’."
  (cl-labels ((node-name (dom)
                (if (equal (dom-attr dom 'href) "index.html")
                    "Top" (dom-text dom))))
    (with-temp-buffer
      (when next
        (insert "Next: ")
        (insert-text-button (node-name next)
                            'type 'html-info-navigation-button
                            'target (dom-attr next 'href)))
      (when (and next prev)
        (insert ", "))
      (when prev
        (insert "Prev: ")
        (insert-text-button (node-name prev)
                            'type 'html-info-navigation-button
                            'target (dom-attr prev 'href)))
      (insert ", Up: ")
      (insert-text-button (node-name up)
                          'type 'html-info-navigation-button
                          'target (dom-attr up 'href))
      (buffer-string))))

(defun html-info--follow-link (url)
  "Go to the node represented by URL.
URL could be “file”, or “file#anchor” or “#anchor.”"
  ;; The "file#anchor" case.
  (cl-labels ((expand (file)
                (expand-file-name
                 file (file-name-directory html-info--current-file))))
    (cond ((string-match (rx (seq bol (group (+ any)) "#"
                                  (group (+ any)) eol))
                         url)
           (html-info-goto-node
            (cons (expand (match-string 1 url))
                  (match-string 2 url))))
          ;; The "#anchor" case.
          ((string-match (rx (seq bol "#" (group (+ any)) eol)) url)
           (html-info-goto-node
            (cons html-info--current-file (match-string 1 url))))
          ;; The "file" case.
          (t (html-info-goto-node (cons (expand url) nil))))))

(defun html-info--button-follow-link (button)
  "Follow the link in BUTTON."
  (interactive)
  (html-info--follow-link (button-get button 'target)))

(defun html-info--follow-link-at-point ()
  "Follow the link at point."
  (interactive)
  (let ((url (get-text-property (point) 'shr-url)))
    (if (not url)
        (user-error "No link at point")
      (html-info--follow-link url))))

(defun html-info-next ()
  "Go to the “next” node, staying on the same hierarchical level.
This command doesn’t descend into sub-nodes, like
\\<html-info-mode-map>\\[html-info-forward-node] does."
  (interactive)
  (if-let ((next (nth 0 html-info--navigation)))
      (html-info--follow-link (dom-attr next 'href))
    (user-error "Node has no next")))

(defun html-info-prev ()
  "Go to the “previous” node, staying on the same hierarchical level.
This command doesn't go up to the parent node, like
\\<html-info-mode-map>\\[html-info-backward-node] does."
  (interactive)
  (if-let ((prev (nth 1 html-info--navigation)))
      (html-info--follow-link (dom-attr prev 'href))
    (user-error "Node has no previous")))

(defun html-info-up ()
  "Go to the superior node, staying on the same hierarchical level.
This command doesn’t descend into sub-nodes, like
\\<html-info-mode-map>\\[html-info-forward-node] does."
  (interactive)
  (html-info--follow-link
   (dom-attr (nth 2 html-info--navigation) 'href)))

(defvar html-info-mode-map
  (let ((map (make-sparse-keymap)))
    (define-key map "n" #'html-info-next)
    (define-key map "p" #'html-info-prev)
    (define-key map "u" #'html-info-up)
    map)
  "Keymap for ‘html-info-mode’.")

(define-derived-mode html-info-mode special-mode
  "HTML Info"
  "HTML Info mode lets you browse HTML Info files.
Documentation in Info is divided into \"nodes\", each of which
discusses one topic and contains references to other nodes which
discuss related topics.  Info has commands to follow the
references and show you other nodes."
  (setq case-fold-search t)
  (setq buffer-read-only t)
  ;; TODO: tool-bar
  ;; TODO: desktop-save-buffer
  ;; TODO: revert buffer
  ;; TODO: bookmark-make-record-function
  ;; TODO: mode-line
  (setq-local widen-automatically nil)
  (when Info-standalone
    (add-hook 'quit-window-hook 'save-buffers-kill-emacs nil t)))

(defun html-info-lispref ()
  "Open Emacs Lisp Reference Info."
  (interactive)
  (let ((lispref (expand-file-name "doc/lispref/elisp.html"
                                   source-directory)))
    (if (file-exists-p lispref)
        (let ((html-info--current-file
               (if (file-directory-p lispref)
                   (expand-file-name "index.html" lispref)
                 lispref)))
          (html-info-goto-node "Top"))
      (error "Cannot find lispref at %s" lispref))))

(provide 'html-info)

;;; html-info.el ends here

;; Local Variables:
;; sentence-end-double-space: t
;; End:

Re: HTML info

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sun, 26 Dec 2021 01:50:50 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  tsdh@gnu.org
> 
> One thing I noticed is that the HTML Info files lack a nice top level menu. The HTML Top only has a (very) long TOC and a short TOC. The TOC's only include the node name and leave out the short description.
> 
> I’m on a Mac which is case-insensitive, and my texinfo still have the bug where it drops index.html when merging Index.html and index.html. So I can’t test multi-file manual’s Top node (it’s in index.html). Besides that, single-file and multi-file seem to both work fine.

These (and some others) all are basic issues that should be addressed
by the Texinfo project, not by us.  Emacs cannot tell other GNU
projects how to produce their HTML docs, and we definitely cannot
provide the missing top-level menus and the corresponding install-info
capabilities of updating that menu when new manuals are installed.

I've written a message to the Texinfo list about this today, see

  https://lists.gnu.org/archive/html/bug-texinfo/2021-12/msg00150.html

We could work on the HTNL-doc viewing capabilities for Emacs, but we
cannot complete our work before the problems I mentioned there (and
probably others as well) are fixed, or at least we know how they will
be fixed.

Thanks.

Re: HTML info

[Juri Linkov]

> I've written a message to the Texinfo list about this today, see
>
>   https://lists.gnu.org/archive/html/bug-texinfo/2021-12/msg00150.html

Interesting, this discussion suggested to create an add-on for eww,
and this makes sense: such eww browser extension could be a mode
derived from eww-mode with additional Info keys such as ‘t’ for top-node,
‘s’ to search HTML pages, ‘i’ to look up a string in the HTML index, etc.

Re: HTML info

[Juri Linkov]

>> I've written a message to the Texinfo list about this today, see
>>
>>   https://lists.gnu.org/archive/html/bug-texinfo/2021-12/msg00150.html
>
> Interesting, this discussion suggested to create an add-on for eww,
> and this makes sense: such eww browser extension could be a mode
> derived from eww-mode with additional Info keys such as ‘t’ for top-node,
> ‘s’ to search HTML pages, ‘i’ to look up a string in the HTML index, etc.

I meant that the HTML output of makeinfo is indented to be read
in a web browser, and info.js adds more features of the Info reader.

The same way in Emacs eww displays the HTML output of makeinfo.
So the missing ingredient is a component that corresponds to info.js.
Obviously in Emacs it should be written in Lisp and enabled by eww
on visiting an HTML page produced by makeinfo.

Re: HTML info

[Lars Ingebrigtsen]

Yuan Fu <casouri@gmail.com> writes:

> I don’t claim to be seriously working on it, but here is a POC, I
> didn’t try to plug it into (dir), the only entry point right now is
> html-info-lispref which will open the lisp reference at
> /doc/lispref/elisp.html. You can click around and go next/prev/up but
> there is no i/[/]/r/l/etc.

Cool.  😀  I tested it a bit, and it's plenty fast and responsive, so it
looks like a good starting point for implementing the other bits.

> One thing I noticed is that the HTML Info files lack a nice top level
> menu. The HTML Top only has a (very) long TOC and a short TOC. The
> TOC's only include the node name and leave out the short description.

Yeah, the menus here look a lot better:

  https://www.gnu.org/software/emacs/manual/html_mono/elisp.html

Where did that conversion to HTML come from?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: HTML info

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org,  Stefan Monnier <monnier@iro.umontreal.ca>,
>   tsdh@gnu.org
> Date: Sun, 26 Dec 2021 12:48:08 +0100
> 
> Yeah, the menus here look a lot better:
> 
>   https://www.gnu.org/software/emacs/manual/html_mono/elisp.html
> 
> Where did that conversion to HTML come from?

From admin/make-manuals, which invokes a function in admin.el.

Re: HTML info

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>>From admin/make-manuals, which invokes a function in admin.el.

Thanks.  Looks like something has changed in the HTML generation,
though?

arsi@xo:~/src/emacs/trunk$ ./admin/make-manuals 
Making manuals (slow)...
Search failed: "<ul>"
make-manuals: error running make-manuals


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: HTML info

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: casouri@gmail.com,  juri@linkov.net,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  tsdh@gnu.org
> Date: Sun, 26 Dec 2021 12:57:41 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>From admin/make-manuals, which invokes a function in admin.el.
> 
> Thanks.  Looks like something has changed in the HTML generation,
> though?
> 
> arsi@xo:~/src/emacs/trunk$ ./admin/make-manuals 
> Making manuals (slow)...
> Search failed: "<ul>"
> make-manuals: error running make-manuals

Yes, see bug#49719.

Re: Variable pitch mode line

[Juri Linkov]

>> I don't believe that distro packagers might want to include Info manuals
>> in the HTML format when only Emacs will display them but not the standalone
>> Info reader.
>
> I'm not sure they include Info manuals mainly for the standalone info
> viewer either.  But in any case, currently I don't think any doc viewer
> has a good story for "use HTML as replacement for Info", so it's clear
> that if we want it to happen, we need to start by making Emacs support
> it well.  And only later, *maybe*, distros and other Info viewers will
> follow suit.

Then better to start with own dog food, and first display Emacs manuals
from HTML.  There is already a make target that produces HTML files:

  make html

Currently HTML files are generated in the source dir, that is wrong:

  doc/emacs/emacs.html

The correct place would be in the Info output dir:

  info/emacs.html

so it could reuse INFOPATH to find HTML Info manuals as well.

Then after visiting the generated HTML with eww, when proportional fonts
are enabled with `eww-toggle-fonts`, the output looks nice.
But rendering a large HTML file takes too much time.  So while
a single HTML file is still preferable over multifile Info manuals,
the Info reader should limit rendering to the currently displayed
Info node only.

Using a single HTML file will also make online reading of remote HTML
manuals easier.  For example, simply point the Emacs Info reader to
https://www.gnu.org/software/emacs/manual/html_mono/emacs.html
and it could fetch the whole HTML file, then navigate its nodes.

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Fri, 24 Dec 2021 10:21:59 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Tassilo Horn <tsdh@gnu.org>,
>  emacs-devel@gnu.org
> 
> Currently HTML files are generated in the source dir, that is wrong:
> 
>   doc/emacs/emacs.html
> 
> The correct place would be in the Info output dir:
> 
>   info/emacs.html

No, it should have its own subdirectory, probably html/.  Mixing Info
and HTML files is asking for trouble, particularly for "make install".

> so it could reuse INFOPATH to find HTML Info manuals as well.

No, INFOPATH should be reserved for Info files only.  Its rules (like
"::" at the beginning and end of the value) don't fit HTML docs.

> Then after visiting the generated HTML with eww, when proportional fonts
> are enabled with `eww-toggle-fonts`, the output looks nice.
> But rendering a large HTML file takes too much time.  So while
> a single HTML file is still preferable over multifile Info manuals,
> the Info reader should limit rendering to the currently displayed
> Info node only.

Which probably means we should produce a separate file per node or
chapter.

Re: Variable pitch mode line

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 13:42:33 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, tsdh@gnu.org
> 
> > From: Juri Linkov <juri@linkov.net>
> > Date: Fri, 24 Dec 2021 10:21:59 +0200
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Tassilo Horn <tsdh@gnu.org>,
> >  emacs-devel@gnu.org
> > 
> > Currently HTML files are generated in the source dir, that is wrong:
> > 
> >   doc/emacs/emacs.html
> > 
> > The correct place would be in the Info output dir:
> > 
> >   info/emacs.html
> 
> No, it should have its own subdirectory, probably html/.  Mixing Info
> and HTML files is asking for trouble, particularly for "make install".
> 
> > so it could reuse INFOPATH to find HTML Info manuals as well.
> 
> No, INFOPATH should be reserved for Info files only.  Its rules (like
> "::" at the beginning and end of the value) don't fit HTML docs.

And, once again, this should be coordinated with the Texinfo folks.
We should not invent our own rules, because we don't have enough
knowledge, background, and even authority to do so.  This isn't our
territory.

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Then after visiting the generated HTML with eww, when proportional fonts
>> are enabled with `eww-toggle-fonts`, the output looks nice.
>> But rendering a large HTML file takes too much time.  So while
>> a single HTML file is still preferable over multifile Info manuals,
>> the Info reader should limit rendering to the currently displayed
>> Info node only.
>
> Which probably means we should produce a separate file per node or
> chapter.

Not necessarily -- the HTML-ified info mode doesn't have to parse (and
render) the entire HTML file.  (There would have to be enough semantic
information in the HTML file to allow it to identify a node, which
shouldn't be a problem.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Not necessarily -- the HTML-ified info mode doesn't have to parse (and
> render) the entire HTML file.  (There would have to be enough semantic
> information in the HTML file to allow it to identify a node, which
> shouldn't be a problem.)

I haven't had the time to read through this thread, but can someone
assure me that the existing Info format and reader will remain, and that
Emacs documentation will continue to be generated in that format?

It doesn't have to be the only format, but it should still be present.

I also don't understand how an HTML-based Info reader will handle (for
example) I-search through an entire manual without rendering it all in
one go.

My organization has many handwritten Info files, I'm quite used to the
format and reader, and this is probably the case for many other people
as well.

Thanks.

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I haven't had the time to read through this thread, but can someone
> assure me that the existing Info format and reader will remain, and that
> Emacs documentation will continue to be generated in that format?

Yes, the Emacs documentation will continue to be available in all the
formats that Texinfo supports.

> I also don't understand how an HTML-based Info reader will handle (for
> example) I-search through an entire manual without rendering it all in
> one go.

We don't have to render the HTML to search in it -- parsing the HTML is
enough (and is quick), and then we can just search in the DOM and then
render the node we find the match in.  It's just a small matter of
programming.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I also don't understand how an HTML-based Info reader will handle (for
>> example) I-search through an entire manual without rendering it all in
>> one go.

> We don't have to render the HTML to search in it -- parsing the HTML is
> enough (and is quick), and then we can just search in the DOM and then
> render the node we find the match in.  It's just a small matter of
> programming.

It seems a bit scary to me.  For example, how would I quickly find "see
Optimize Options", if that was generated by a pxref, where the "see" and
"Optimize Options" are in different nodes?

Thanks.

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> It seems a bit scary to me.  For example, how would I quickly find "see
> Optimize Options", if that was generated by a pxref, where the "see" and
> "Optimize Options" are in different nodes?

We don't have code for that today, but it doesn't seem particularly
difficult to implement.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> We don't have code for that today, but it doesn't seem particularly
> difficult to implement.

It would have to be fast for relatively nested DOM trees in very large
documents, which is a really great feature of the regular Info reader.

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  tsdh@gnu.org
> Date: Fri, 24 Dec 2021 14:34:05 +0100
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > It seems a bit scary to me.  For example, how would I quickly find "see
> > Optimize Options", if that was generated by a pxref, where the "see" and
> > "Optimize Options" are in different nodes?
> 
> We don't have code for that today, but it doesn't seem particularly
> difficult to implement.

Btw: why doesn't shr rely on visual-line-mode to wrap the text, but
instead performs the layout in Lisp and inserts hard newlines into the
buffer?  If the reflowing was delegated to visual-line-mode, wouldn't
it be much faster?

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw: why doesn't shr rely on visual-line-mode to wrap the text, but
> instead performs the layout in Lisp and inserts hard newlines into the
> buffer?

Because many web pages have columnar layouts, and visual-line-mode
doesn't help with that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  juri@linkov.net,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  tsdh@gnu.org
> Date: Fri, 24 Dec 2021 14:48:20 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw: why doesn't shr rely on visual-line-mode to wrap the text, but
> > instead performs the layout in Lisp and inserts hard newlines into the
> > buffer?
> 
> Because many web pages have columnar layouts, and visual-line-mode
> doesn't help with that.

But for displaying HTML docs that were produced by makeinfo, that's
not a problem, right?

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But for displaying HTML docs that were produced by makeinfo, that's
> not a problem, right?

You mean something special for info-html, sure, that's possible.  But
the manual does use columns:

  https://www.gnu.org/software/emacs/manual/html_mono/elisp.html

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  juri@linkov.net,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  tsdh@gnu.org
> Date: Fri, 24 Dec 2021 15:01:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But for displaying HTML docs that were produced by makeinfo, that's
> > not a problem, right?
> 
> You mean something special for info-html, sure, that's possible.  But
> the manual does use columns:
> 
>   https://www.gnu.org/software/emacs/manual/html_mono/elisp.html

That's the TOC (or maybe other menus), where the columns are not
really important, IMO.

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> That's the TOC (or maybe other menus), where the columns are not
> really important, IMO.

But they're there.  There's also a lot of indented sections (like in
@table) where visual-line-mode is equally unhelpful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  tsdh@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  juri@linkov.net
> Date: Fri, 24 Dec 2021 16:05:42 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's the TOC (or maybe other menus), where the columns are not
> > really important, IMO.
> 
> But they're there.  There's also a lot of indented sections (like in
> @table) where visual-line-mode is equally unhelpful.

Indented text can be handled with line-prefix and wrap-prefix, can't
it?

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Indented text can be handled with line-prefix and wrap-prefix, can't
> it?

I didn't know about that text property -- looks like it'd do the trick.
But links (using the underlined link face) would have their links added
to the wrapped prefix area, I think?  (Which is ugly.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I didn't know about that text property -- looks like it'd do the trick.
> But links (using the underlined link face) would have their links added
> to the wrapped prefix area, I think?  (Which is ugly.)

Sorry, I mean -- the wrapped prefix area would have the link face
displayed, which means that you'd have some underlined spaces at the
front.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  tsdh@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  juri@linkov.net
> Date: Fri, 24 Dec 2021 16:43:12 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Indented text can be handled with line-prefix and wrap-prefix, can't
> > it?
> 
> I didn't know about that text property -- looks like it'd do the trick.
> But links (using the underlined link face) would have their links added
> to the wrapped prefix area, I think?  (Which is ugly.)

I don't think I follow: how would the link face come into play here?

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I follow: how would the link face come into play here?

If you have text with a link face that visual-display-mode displays over
two lines.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  tsdh@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  juri@linkov.net
> Date: Sat, 25 Dec 2021 12:59:00 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think I follow: how would the link face come into play here?
> 
> If you have text with a link face that visual-display-mode displays over
> two lines.

But the line-prefix/wrap-prefix's value is a string that can have its
own face.  In that case, the link face will not leak into the prefix.

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But the line-prefix/wrap-prefix's value is a string that can have its
> own face.  In that case, the link face will not leak into the prefix.

I see, then that should work.  Is there a way to make visual-line-mode
not touch parts of the buffer, like preformatted regions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  tsdh@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  juri@linkov.net
> Date: Sun, 26 Dec 2021 12:28:55 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But the line-prefix/wrap-prefix's value is a string that can have its
> > own face.  In that case, the link face will not leak into the prefix.
> 
> I see, then that should work.  Is there a way to make visual-line-mode
> not touch parts of the buffer, like preformatted regions?

Not really.  But if the preformatted regions have hard newlines, that
will happen automagically.  I believe the HTML produced by makeinfo
uses hard newlines in blocks that must not be reflowed, isn't that
right?

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Not really.  But if the preformatted regions have hard newlines, that
> will happen automagically.  I believe the HTML produced by makeinfo
> uses hard newlines in blocks that must not be reflowed, isn't that
> right?

I'm not sure what you mean by "hard newline" here?  HTML sections that
shouldn't be reflowed are in <pre> tags and the like, but there's
nothing special about the newline characters in the HTML.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  tsdh@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  juri@linkov.net
> Date: Sun, 26 Dec 2021 12:51:59 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Not really.  But if the preformatted regions have hard newlines, that
> > will happen automagically.  I believe the HTML produced by makeinfo
> > uses hard newlines in blocks that must not be reflowed, isn't that
> > right?
> 
> I'm not sure what you mean by "hard newline" here?  HTML sections that
> shouldn't be reflowed are in <pre> tags and the like, but there's
> nothing special about the newline characters in the HTML.

The text that needs to be reflowed doesn't include newlines, except at
ends of paragraphs, right?  So those are very long lines that
visual-line-mode will divide into screen line by wrapping.

By contrast, in <pre> blocks each line ends in a newline, and the lines
are supposed to be short enough to fit in a normal-size window.  So
now wrapping should be needed.

Or what did I miss?

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The text that needs to be reflowed doesn't include newlines, except at
> ends of paragraphs, right?  So those are very long lines that
> visual-line-mode will divide into screen line by wrapping.
>
> By contrast, in <pre> blocks each line ends in a newline, and the lines
> are supposed to be short enough to fit in a normal-size window.  So
> now wrapping should be needed.

In the HTML, newlines are just whitespace like anything else.  When
rendering most elements, the newlines are transformed to spaces.  (But
that's not done when rendering <pre> elements.)

<p>When a form is a macro call, it expands into a new form for Lisp to
evaluate.  We show the result of the expansion with
&lsquo;<samp>&rarr;</samp>&rsquo;.  We may or may not show the result of the
evaluation of the expanded form.
</p>
<div class="example">
<pre class="example">(third '(a b c))
     &rarr; (car (cdr (cdr '(a b c))))
     &rArr; c
</pre></div>

Nothing special about the newline characters (or the lack of them).

Anyway, your suggestion was to have shr not do the reflow, but leave
that to redisplay.  My question was whether we have a way to avoid that
on certain pre-formatted lines, like if you have:

<pre>This is a line that will be reflowed by visual-line-mode because it's too wide for the window, but it shouldn't be reflowed.</pre>

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  tsdh@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  juri@linkov.net
> Date: Sun, 26 Dec 2021 13:02:32 +0100
> 
> In the HTML, newlines are just whitespace like anything else.  When
> rendering most elements, the newlines are transformed to spaces.  (But
> that's not done when rendering <pre> elements.)
> 
> <p>When a form is a macro call, it expands into a new form for Lisp to
> evaluate.  We show the result of the expansion with
> &lsquo;<samp>&rarr;</samp>&rsquo;.  We may or may not show the result of the
> evaluation of the expanded form.
> </p>
> <div class="example">
> <pre class="example">(third '(a b c))
>      &rarr; (car (cdr (cdr '(a b c))))
>      &rArr; c
> </pre></div>
> 
> Nothing special about the newline characters (or the lack of them).

In that case, I guess we will need to convert newlines to spaces
inside "<p>..</p>", but not inside <pre>.

> Anyway, your suggestion was to have shr not do the reflow, but leave
> that to redisplay.  My question was whether we have a way to avoid that
> on certain pre-formatted lines, like if you have:
> 
> <pre>This is a line that will be reflowed by visual-line-mode because it's too wide for the window, but it shouldn't be reflowed.</pre>

We could convert spaces into NBSPs, I guess?  But if the above a
frequent situation in GNU manuals?

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> We could convert spaces into NBSPs, I guess?  But if the above a
> frequent situation in GNU manuals?

Probably not.

I'm still not sure what problem you're trying to fix with this line of
inquiry.  😀  Having shr do the line breaking or leaving it to the
display engine won't make any difference, performance wise, for the
HTML-based info mode.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  tsdh@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  juri@linkov.net
> Date: Sun, 26 Dec 2021 13:25:22 +0100
> 
> I'm still not sure what problem you're trying to fix with this line of
> inquiry.  😀  Having shr do the line breaking or leaving it to the
> display engine won't make any difference, performance wise, for the
> HTML-based info mode.

Really?  At least when I read email, HTML formatted messages take a
significant time to display, sometimes several seconds (with quite a
few GC cycles while at that).  Redisplay with word-wrap will take much
less, and will not trigger any GC.

So why do you say it won't make any difference?

Re: Variable pitch mode line

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Really?  At least when I read email, HTML formatted messages take a
> significant time to display, sometimes several seconds (with quite a
> few GC cycles while at that).  Redisplay with word-wrap will take much
> less, and will not trigger any GC.

Have you profiled shr to confirm that it's the line wrapping that takes
time?  In my experience, whenever eww is slow, it's because there's a
<table> in the page.

> So why do you say it won't make any difference?

An info node is so small that it can't possibly make any difference.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  tsdh@gnu.org,  emacs-devel@gnu.org,
>   monnier@iro.umontreal.ca,  juri@linkov.net
> Date: Mon, 27 Dec 2021 11:32:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Really?  At least when I read email, HTML formatted messages take a
> > significant time to display, sometimes several seconds (with quite a
> > few GC cycles while at that).  Redisplay with word-wrap will take much
> > less, and will not trigger any GC.
> 
> Have you profiled shr to confirm that it's the line wrapping that takes
> time?  In my experience, whenever eww is slow, it's because there's a
> <table> in the page.
> 
> > So why do you say it won't make any difference?
> 
> An info node is so small that it can't possibly make any difference.

OK, then I guess a feature whereby we can disable word-wrap in a
region of text won't be needed after all.

Re: Variable pitch mode line

[Stefan Monnier]

> I see, then that should work.  Is there a way to make visual-line-mode
> not touch parts of the buffer, like preformatted regions?

Currently no.  I'm hoping Lars or someone else will address this.


        Stefan

Re: Variable pitch mode line

[Juri Linkov]

>>> I also don't understand how an HTML-based Info reader will handle (for
>>> example) I-search through an entire manual without rendering it all in
>>> one go.
>
>> We don't have to render the HTML to search in it -- parsing the HTML is
>> enough (and is quick), and then we can just search in the DOM and then
>> render the node we find the match in.  It's just a small matter of
>> programming.
>
> It seems a bit scary to me.  For example, how would I quickly find "see
> Optimize Options", if that was generated by a pxref, where the "see" and
> "Optimize Options" are in different nodes?

Assuming no styles are used that could hide content, it would be much
simpler and fast just to strip all HTML tags from the HTML file, e.g.

  <p>For information on extending Emacs,
  see <a href="elisp/index.html#Top">Emacs Lisp</a> in <cite>The
  Emacs Lisp Reference Manual</cite>.</p>

will become

  For information on extending Emacs,
  see Emacs Lisp in The
  Emacs Lisp Reference Manual.

where you can search for "see Emacs Lisp".

Re: Variable pitch mode line

[Po Lu]

Juri Linkov <juri@linkov.net> writes:

> Assuming no styles are used that could hide content, it would be much
> simpler and fast just to strip all HTML tags from the HTML file, e.g.

>   <p>For information on extending Emacs,
>   see <a href="elisp/index.html#Top">Emacs Lisp</a> in <cite>The
>   Emacs Lisp Reference Manual</cite>.</p>

> will become

>   For information on extending Emacs,
>   see Emacs Lisp in The
>   Emacs Lisp Reference Manual.

> where you can search for "see Emacs Lisp".

What about "The Emacs Lisp Reference Manual"?

Re: Variable pitch mode line

[Juri Linkov]

>> Assuming no styles are used that could hide content, it would be much
>> simpler and fast just to strip all HTML tags from the HTML file, e.g.
>
>>   <p>For information on extending Emacs,
>>   see <a href="elisp/index.html#Top">Emacs Lisp</a> in <cite>The
>>   Emacs Lisp Reference Manual</cite>.</p>
>
>> will become
>
>>   For information on extending Emacs,
>>   see Emacs Lisp in The
>>   Emacs Lisp Reference Manual.
>
>> where you can search for "see Emacs Lisp".
>
> What about "The Emacs Lisp Reference Manual"?

The search will ignore newlines like info.el already does
with Info-search-whitespace-regexp containing newlines.

BTW, Info-search-whitespace-regexp should have the same
list of customizable choices as recently was added to
search-whitespace-regexp.

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  tsdh@gnu.org,  Eli Zaretskii
>  <eliz@gnu.org>,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sun, 26 Dec 2021 09:39:20 +0200
> 
> >> Assuming no styles are used that could hide content, it would be much
> >> simpler and fast just to strip all HTML tags from the HTML file, e.g.
> >
> >>   <p>For information on extending Emacs,
> >>   see <a href="elisp/index.html#Top">Emacs Lisp</a> in <cite>The
> >>   Emacs Lisp Reference Manual</cite>.</p>
> >
> >> will become
> >
> >>   For information on extending Emacs,
> >>   see Emacs Lisp in The
> >>   Emacs Lisp Reference Manual.
> >
> >> where you can search for "see Emacs Lisp".
> >
> > What about "The Emacs Lisp Reference Manual"?
> 
> The search will ignore newlines like info.el already does
> with Info-search-whitespace-regexp containing newlines.

Why would you need to ignore newlines, when the original HTML file has
only hard newlines in it?  We should not insert newlines into the text
when we render it, we should use visual-line-mode instead.  Then the
problem with ignoring newlines will be solved as a nice bonus.

Re: Variable pitch mode line

[Tassilo Horn]

Juri Linkov <juri@linkov.net> writes:

>> BTW: I would love to have pixel-filled, variable pitch info docs.
>> `variable-pitch-mode' in info has the bad effect that also code
>> samples or ASCII art [like the cons box&arrows in (info "(elisp)
>> Building Lists")] then use the variable pitch font and misalign.
>
> The only way to reliably support variable pitch in the Info reader is
> by using HTML output from Texinfo and rendering it with eww/shr.

What's the problem with info?  I mean, we use special environments such
as `@example ... @end example` in order to mark non-prose text in the
texi files.  Right now, they seem to only add some indentation in the
info files.  But couldn't makeinfo add some hints (like some invisible
chars) so that info readers could detect such non-prose text?

Bye,
Tassilo

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Thu, 23 Dec 2021 20:27:12 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> >> BTW: I would love to have pixel-filled, variable pitch info docs.
> >> `variable-pitch-mode' in info has the bad effect that also code
> >> samples or ASCII art [like the cons box&arrows in (info "(elisp)
> >> Building Lists")] then use the variable pitch font and misalign.
> >
> > The only way to reliably support variable pitch in the Info reader is
> > by using HTML output from Texinfo and rendering it with eww/shr.
> 
> What's the problem with info?  I mean, we use special environments such
> as `@example ... @end example` in order to mark non-prose text in the
> texi files.  Right now, they seem to only add some indentation in the
> info files.  But couldn't makeinfo add some hints (like some invisible
> chars) so that info readers could detect such non-prose text?

It could, perhaps, but then it would have to be done by the Texinfo
project, not by us.

Re: Variable pitch mode line

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> What's the problem with info?  I mean, we use special environments
>> such as `@example ... @end example` in order to mark non-prose text
>> in the texi files.  Right now, they seem to only add some indentation
>> in the info files.  But couldn't makeinfo add some hints (like some
>> invisible chars) so that info readers could detect such non-prose
>> text?
>
> It could, perhaps, but then it would have to be done by the Texinfo
> project, not by us.

Obviously.  Well, I guess their time is better spent improving the HTML
version.  Hm, but those also don't look good in eww/shr because that
doesn't support css.

Bye,
Tassilo

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: larsi@gnus.org, juri@linkov.net, emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 20:48:09 +0100
> 
> > It could, perhaps, but then it would have to be done by the Texinfo
> > project, not by us.
> 
> Obviously.  Well, I guess their time is better spent improving the HTML
> version.  Hm, but those also don't look good in eww/shr because that
> doesn't support css.

The new JSInfo reader also needs Javascript, I believe.

Re: Variable pitch mode line

[Eli Zaretskii]

> Date: Thu, 23 Dec 2021 22:02:50 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, emacs-devel@gnu.org, juri@linkov.net
> 
> > From: Tassilo Horn <tsdh@gnu.org>
> > Cc: larsi@gnus.org, juri@linkov.net, emacs-devel@gnu.org
> > Date: Thu, 23 Dec 2021 20:48:09 +0100
> > 
> > > It could, perhaps, but then it would have to be done by the Texinfo
> > > project, not by us.
> > 
> > Obviously.  Well, I guess their time is better spent improving the HTML
> > version.  Hm, but those also don't look good in eww/shr because that
> > doesn't support css.
> 
> The new JSInfo reader also needs Javascript, I believe.

Actually, let me correct that, to avoid misinterpretation.  JSInfo is
not a program, it is a way of producing HTML-formatted manuals from
Texinfo that (1) display nicer in a Web browser, and (2) solve almost
all the deficiencies of HTML manuals as compared to Info manuals: you
get the equivalent of Info-index command, regexp-search command, etc.
It does that by adding some Javascript to the manual.

Re: Variable pitch mode line

[Juri Linkov]

>>> BTW: I would love to have pixel-filled, variable pitch info docs.
>>> `variable-pitch-mode' in info has the bad effect that also code
>>> samples or ASCII art [like the cons box&arrows in (info "(elisp)
>>> Building Lists")] then use the variable pitch font and misalign.
>>
>> The only way to reliably support variable pitch in the Info reader is
>> by using HTML output from Texinfo and rendering it with eww/shr.
>
> What's the problem with info?  I mean, we use special environments such
> as `@example ... @end example` in order to mark non-prose text in the
> texi files.  Right now, they seem to only add some indentation in the
> info files.  But couldn't makeinfo add some hints (like some invisible
> chars) so that info readers could detect such non-prose text?

Texinfo already adds invisible markers to the index and images,
so it could output more invisible markup indeed.

Re: Variable pitch mode line

[Tomas Hlavaty]

>
> The only way to reliably support variable pitch in the Info reader
> is by using HTML output from Texinfo and rendering it with eww/shr.
>
> But the problem is that most GNU/Linux distributions still don't include
> Info manuals in the HTML format alongside with the Info format.
> Thus we are stuck with monospaced Info manuals forever.
iirc info files are not that complex.  How difficult would it be to
transform an info file to html in Lisp and display it with eww/shr on
the fly?  In my emacs-unoffice package, I explored this for various
office formats and it seems like a reasonably useable solution.

Re: Variable pitch mode line

[Yuan Fu]

> On Dec 23, 2021, at 12:41 PM, Tomas Hlavaty <tom@logand.com> wrote:
> 
>> 
>> The only way to reliably support variable pitch in the Info reader
>> is by using HTML output from Texinfo and rendering it with eww/shr.
>> 
>> But the problem is that most GNU/Linux distributions still don't include
>> Info manuals in the HTML format alongside with the Info format.
>> Thus we are stuck with monospaced Info manuals forever.
> iirc info files are not that complex.  How difficult would it be to
> transform an info file to html in Lisp and display it with eww/shr on
> the fly?  In my emacs-unoffice package, I explored this for various
> office formats and it seems like a reasonably useable solution.
> 

I’ve tried that. Info files are not complex, but they can’t be reliably parsed 100% of the time. My code works for like 95% of the nodes, but there are always some corner cases where it breaks. I think TRT is to use html files.

Yuan

Re: Variable pitch mode line

[Tomas Hlavaty]

On Thu 23 Dec 2021 at 12:51, Yuan Fu <casouri@gmail.com> wrote:
> I’ve tried that. Info files are not complex, but they can’t be
> reliably parsed 100% of the time. My code works for like 95% of the
> nodes, but there are always some corner cases where it breaks.

Why doesn't texinfo html output suffer from this problem?

Re: Variable pitch mode line

[Yuan Fu]

> On Dec 23, 2021, at 12:56 PM, Tomas Hlavaty <tom@logand.com> wrote:
> 
> On Thu 23 Dec 2021 at 12:51, Yuan Fu <casouri@gmail.com> wrote:
>> I’ve tried that. Info files are not complex, but they can’t be
>> reliably parsed 100% of the time. My code works for like 95% of the
>> nodes, but there are always some corner cases where it breaks.
> 
> Why doesn't texinfo html output suffer from this problem?

HTML are structured, where as Info is more like plain text. Just to give an example, in an info file, four spaces indent text could be a code block, or just an indented paragraph, there is no way telling them apart. In HTML, code is wrapped in <code> (or maybe <pre>), paragraphs are wrapped in <p>.

Yuan

Re: Variable pitch mode line

[Tomas Hlavaty]

On Thu 23 Dec 2021 at 13:00, Yuan Fu <casouri@gmail.com> wrote:
>> On Dec 23, 2021, at 12:56 PM, Tomas Hlavaty <tom@logand.com> wrote:
>> On Thu 23 Dec 2021 at 12:51, Yuan Fu <casouri@gmail.com> wrote:
>>> I’ve tried that. Info files are not complex, but they can’t be
>>> reliably parsed 100% of the time. My code works for like 95% of the
>>> nodes, but there are always some corner cases where it breaks.
>> 
>> Why doesn't texinfo html output suffer from this problem?
>
> HTML are structured, where as Info is more like plain text. Just to
> give an example, in an info file, four spaces indent text could be a
> code block, or just an indented paragraph, there is no way telling
> them apart. In HTML, code is wrapped in <code> (or maybe <pre>),
> paragraphs are wrapped in <p>.

Sorry for not being clearer.
The question is not about the difference between info and html.

The question is: why does your info to html conversion attempt work in
95% cases but textinfos info to html conversion work in 100% cases?

Re: Variable pitch mode line

[Yuan Fu]

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



> On Dec 23, 2021, at 1:24 PM, Tomas Hlavaty <tom@logand.com> wrote:
> 
> On Thu 23 Dec 2021 at 13:00, Yuan Fu <casouri@gmail.com> wrote:
>>> On Dec 23, 2021, at 12:56 PM, Tomas Hlavaty <tom@logand.com> wrote:
>>> On Thu 23 Dec 2021 at 12:51, Yuan Fu <casouri@gmail.com> wrote:
>>>> I’ve tried that. Info files are not complex, but they can’t be
>>>> reliably parsed 100% of the time. My code works for like 95% of the
>>>> nodes, but there are always some corner cases where it breaks.
>>> 
>>> Why doesn't texinfo html output suffer from this problem?
>> 
>> HTML are structured, where as Info is more like plain text. Just to
>> give an example, in an info file, four spaces indent text could be a
>> code block, or just an indented paragraph, there is no way telling
>> them apart. In HTML, code is wrapped in <code> (or maybe <pre>),
>> paragraphs are wrapped in <p>.
> 
> Sorry for not being clearer.
> The question is not about the difference between info and html.
> 
> The question is: why does your info to html conversion attempt work in
> 95% cases but textinfos info to html conversion work in 100% cases?

So I guess your question is about the difference between info and texinfo? Texinfo is also structured, makeinfo can parse a texinfo file (you probably already know that). Info files are, as I said, not structured and can’t be reliably parsed to code blocks, paragraphs, function definitions, etc. Hence my code only works 95% of the time. Also I’m not converting info files to html files, I’m just parsing info files and trying to fontify it. Here is the code, maybe that can explain better than my words. (I know it’s name conflicts with another well-know package, it’s only used by myself and not published.)


[-- Attachment #2: info+.el --]
[-- Type: application/octet-stream, Size: 11493 bytes --]

;;; info+.el --- Prettier Info      -*- lexical-binding: t; -*-

;; Author: Yuan Fu <casouri@gmail.com>

;;; This file is NOT part of GNU Emacs

;;; Commentary:
;;
;; Enable by M-x Info-pretty-mode. This mode prettifies Info buffers
;; by using word wrap and variable pitch font, among other things.
;; Since we use a very ad-hoc “parser” to parse the buffer content.
;; There are breakages where some part of the text are rendered
;; incorrectly. You have to live with it.

;;; Scratch
;;

(when nil
  (let ((reg (Info--next-block)))
    (Info--block-type (car reg) (cdr reg)))

  (defun highlight-region (reg)
    (set-mark (car reg))
    (goto-char (cdr reg))
    (transient-mark-mode))

  (highlight-region (Info--next-block))
  )
;;; Code:
;;

(require 'cl-lib)
(require 'pcase)

;; Block types:
;; | Body indent1 indent2
;; | BulletBody indent1 indent2
;; | DetailList indent1 indent2
;; | MenuHeader
;; | MenuEntry align
;; | Definition indent
;; | Code

(defface info-body `((t . (:inherit (variable-pitch default)
                                    :height 1.2)))
  "Face for body text in Info buffer."
  :group 'info)

(defface info-inline-code `((t . (:inherit widget-field)))
  "Face for inline code in Info buffer."
  :group 'info)

(defun Info--next-block ()
  "Return (BEG . END) of next text block after point.
Move point to BEG.
If search failed, return nil."
  (condition-case nil
      (let (beg end)
        ;; Non-empty line
        (re-search-forward "^[^\n]+$")
        (setq beg (match-beginning 0))
        (if (re-search-forward
             (rx (or "\n\n"
                     (seq "\n" (* " ") digit "." (+ " "))
                     (seq "\n* ")
                     (seq "\n" (* " ") "•")))
             nil t)
            (setq end (match-beginning 0))
          (setq end (point-max)))
        (cons beg end))
    (search-failed nil)))

(defsubst Info--menu-entry-detail-beg (limit)
  "Go to the beginning of the entry detail before LIMIT.
Assumes the point is at BOL.
Return nil if not found"
  (re-search-forward
   (rx (seq "*" " " (+ (not (any "\n"))) (group (>= 2 " "))))
   limit t))

(defun Info--block-type (beg end)
  "Return the type of the block between BEG and END.
Moves point."
  ;;       Code block
  (cl-labels ((indent () (- (point) (line-beginning-position)))
              (visual-indent
               () (car (window-text-pixel-size
                        nil (line-beginning-position) (point)))))
    (cond ((progn (goto-char beg)
                  (looking-at "* Menu:"))
           '(MenuHeader))
          ;; Menu (header or entry)
          ((progn (goto-char beg)
                  (looking-at "\\*"))
           (if (Info--menu-entry-detail-beg (line-end-position))
               `(MenuEntry ,(visual-indent))
             '(MenuEntry 0)))
          ;; Definition
          ((progn (goto-char beg)
                  (looking-at (rx (seq " -- "
                                       (or "Function" "Variable" "Macro"
                                           "Special Form" "Command"
                                           "User Option")
                                       ": "))))
           (re-search-forward "\n +")
           `(Definition ,(indent)))
          ;; Body
          ((let ((case-fold-search nil))
             (goto-char beg)
             (skip-chars-forward " ")
             (and (or (looking-at "[0-9]\\.")
                      (looking-at "•")
                      (looking-at "[[:upper:]]")
                      (looking-at (rx (or ?‘ ?“ (seq ?\( upper))))
                      (looking-at (rx (seq "(" (or digit letter) ")"))))
                  ;; No weird spaces.  Rules out table headers.
                  (not (re-search-forward (rx (>= 3 " "))
                                          (line-end-position) t))))
           (goto-char beg)
           (let (indent1 indent2)
             (skip-chars-forward " ")
             (setq indent1 (indent))
             (when (re-search-forward "\n" end t)
               (skip-chars-forward " ")
               (setq indent2 (indent)))
             (cond ((and indent2
                         (progn (goto-char beg)
                                (looking-at " +•")))
                    `(BulletBody ,indent1 ,(+ 2 indent1)))
                   ;; List
                   ((let ((case-fold-search nil))
                      (goto-char beg)
                      (looking-at (rx (seq (* " ")
                                           (or digit upper)
                                           ". "))))
                    `(BulletBody ,indent1 ,(+ 3 indent1)))
                   ;; Detail list
                   ((and indent2 (< indent1 indent2))
                    `(DetailList ,indent1 ,indent2))
                   ;; Body
                   (t (if indent2
                          `(Body ,indent1 ,(indent))
                        `(Body ,indent1 0))))))
          (t (goto-char beg)
             (skip-chars-forward " ")
             `(Code)))))

(defun Info--remove-indent ()
  "Remove the spaces at the beginning of this line."
  (goto-char (line-beginning-position))
  (skip-chars-forward " ")
  ;; (delete-region (line-beginning-position) (point))
  (put-text-property (line-beginning-position) (point) 'display ""))

(defun Info--remove-line-breaks (beg end)
  "Remove hard line breaks between BEG and END.
Moves point."
  (goto-char end)
  (let ((end-mark (point-marker)))
    (goto-char beg)
    (skip-chars-forward " ")
    ;; (delete-region beg (point))
    (put-text-property beg (point) 'display "")
    (while (and (< (point) end-mark)
                (search-forward "\n" end-mark t))
      (let ((p (match-beginning 0)))
        (skip-chars-forward " ")
        ;; (delete-region p (point))
        ;; (insert " ")
        (when (< (point) end-mark)
          (put-text-property p (point) 'display " "))))))

(defun Info--unfontify-quote (beg end)
  "Remove info-body face from quoted text between BEG and END."
  (goto-char beg)
  (while (re-search-forward
          (rx (or (seq "`" (+? anychar) "'")
                  (seq "‘" (+? anychar) "’")
                  (seq (not (any "doesn" "don" "didn" "can"))
                       (group "'" (+? (not (any "\n"))) "'"))))
          end t)
    ;; Only unfontify inline quote.
    (when (plist-get (text-properties-at (match-beginning 0))
                     'font-lock-face)
      (put-text-property (or (match-beginning 1) (match-beginning 0))
                         (or (match-end 1) (match-end 0))
                         'font-lock-face 'info-inline-code))))

(defun Info--fontify-block (beg end type)
  "Fontify block between BEG and END of TYPE.
Moves point."
  (goto-char beg)
  (pcase type
    (`(Body ,indent1 ,indent2)
     (put-text-property beg end 'font-lock-face 'info-body)
     (when (not (eq indent1 0))
       (put-text-property beg end 'line-prefix `(space :width ,indent1)))
     ;; We make the whole block indent the same, ignoring indent2.
     (ignore indent2)
     (put-text-property beg end 'wrap-prefix `(space :width ,indent1))
     ;; We want to include the final new line for line-height to take
     ;; effect.
     (put-text-property beg (1+ end) 'line-spacing 0.3)
     ;; This function messes positions up, has to run at the end.
     (Info--remove-line-breaks beg end))

    (`(BulletBody ,indent1 ,indent2)
     (let ((case-fold-search nil))
       (re-search-forward (rx (seq (* " ")
                                   (or "•"
                                       (seq digit ". ")
                                       (seq upper ". "))))))
     ;; We want to keep the bullet in default font.
     (put-text-property (point) end 'font-lock-face 'info-body)
     (when (not (eq indent1 0))
       (put-text-property beg end 'line-prefix `(space :width ,indent1)))
     ;; We add 2 to indent1 to align rest body with the bullet.
     (put-text-property beg end 'wrap-prefix `(space :width ,indent2))
     (put-text-property beg (1+ end) 'line-spacing 0.3)
     (Info--remove-line-breaks beg end))

    (`(MenuHeader))

    (`(MenuEntry ,align)
     ;; First, align first line’s detail.
     (when (Info--menu-entry-detail-beg end)
       ;; matched range is the white space between subject and detail.
       ;; (put-text-property
       ;;  (match-beginning 1) (match-end 1)
       ;;  'display `(space :align-to (,(* align (window-font-width)))))
       ;; We skip over the stars. Because info-menu-star is monospaced
       ;; and we want to keep the stars consistent.
       (put-text-property
        (match-end 1) end 'font-lock-face 'info-body)
       ;; Add 1 to end so the newline can get the property.
       (put-text-property beg (min (1+ end) (point-max))
                          'line-spacing 0.3)
       (put-text-property
        (match-end 1) (min (1+ end) (point-max))
        'wrap-prefix `(space :align-to (,align)))
       (Info--remove-line-breaks (match-end 1) end)))

    (`(DetailList ,indent1 ,indent2)
     (Info--remove-indent)
     (goto-char beg)
     (search-forward "\n")
     (let ((p (point)))
       (put-text-property beg (1+ end) 'line-spacing 0.3)
       (put-text-property p end 'font-lock-face 'info-body)
       (put-text-property p end 'line-prefix `(space :width ,indent2))
       (put-text-property p end 'wrap-prefix `(space :width ,indent2))
       (put-text-property beg (1- p) 'line-prefix
                          `(space :width ,indent1))
       (Info--remove-line-breaks p end)))

    (`(Definition ,indent)
     (re-search-forward "\n +")
     (let ((p (point)))
       (put-text-property beg (1+ end) 'line-spacing 0.3)
       (put-text-property p end 'font-lock-face 'info-body)
       (put-text-property p end 'line-prefix `(space :width ,indent))
       (put-text-property p end 'wrap-prefix `(space :width ,indent))
       (Info--remove-line-breaks p end)))
    (`(Code ,indent) (ignore indent))))

(defun Info--prettify-buffer ()
  "Prettify Info buffer."
  (interactive)
  (save-excursion
    (let ((buffer-read-only nil))
      (goto-char (point-min))
      (re-search-forward "[=-\\*]$")
      (let (region)
        (while (setq region (Info--next-block))
          (let ((beg (car region))
                (end (cdr region))
                end-mark)
            (setq end-mark (make-marker))
            (set-marker end-mark end)
            (condition-case nil
                (progn
                  (Info--fontify-block
                   beg end (Info--block-type beg end))
                  (Info--unfontify-quote beg end-mark))
              ((debug search-failed)
               (message "Failed to fontify block %d %d" beg end)))
            (goto-char end-mark))))
      (Info-fontify-node)
      (visual-line-mode)
      (face-remap-add-relative 'link '(:inherit info-body)))))

(define-minor-mode info-pretty-mode
  "Prettified Info."
  :global t
  :lighter ""
  (if info-pretty-mode
      (add-hook 'Info-selection-hook #'Info--prettify-buffer)
    (remove-hook 'Info-selection-hook #'Info--prettify-buffer))
  (when (derived-mode-p 'Info-mode)
    (revert-buffer nil t)))



(provide 'info+)

;;; info+.el ends here

[-- Attachment #3: Type: text/plain, Size: 8 bytes --]



Yuan

Re: Variable pitch mode line

[Tomas Hlavaty]

On Thu 23 Dec 2021 at 13:41, Yuan Fu <casouri@gmail.com> wrote:
>> On Dec 23, 2021, at 1:24 PM, Tomas Hlavaty <tom@logand.com> wrote:
>> On Thu 23 Dec 2021 at 13:00, Yuan Fu <casouri@gmail.com> wrote:
>>>> On Dec 23, 2021, at 12:56 PM, Tomas Hlavaty <tom@logand.com> wrote:
>>>> On Thu 23 Dec 2021 at 12:51, Yuan Fu <casouri@gmail.com> wrote:
>>>>> I’ve tried that. Info files are not complex, but they can’t be
>>>>> reliably parsed 100% of the time. My code works for like 95% of the
>>>>> nodes, but there are always some corner cases where it breaks.
>>>> 
>>>> Why doesn't texinfo html output suffer from this problem?
>>> 
>>> HTML are structured, where as Info is more like plain text. Just to
>>> give an example, in an info file, four spaces indent text could be a
>>> code block, or just an indented paragraph, there is no way telling
>>> them apart. In HTML, code is wrapped in <code> (or maybe <pre>),
>>> paragraphs are wrapped in <p>.
>> 
>> Sorry for not being clearer.
>> The question is not about the difference between info and html.
>> 
>> The question is: why does your info to html conversion attempt work in
>> 95% cases but textinfos info to html conversion work in 100% cases?
>
> So I guess your question is about the difference between info and
> texinfo? Texinfo is also structured, makeinfo can parse a texinfo file
> (you probably already know that). Info files are, as I said, not
> structured and can’t be reliably parsed to code blocks, paragraphs,
> function definitions, etc. Hence my code only works 95% of the
> time. Also I’m not converting info files to html files, I’m just
> parsing info files and trying to fontify it. Here is the code, maybe
> that can explain better than my words. (I know it’s name conflicts
> with another well-know package, it’s only used by myself and not
> published.)

I see, textinfo does not use info files for html conversion (it uses
texi files) and the conversion from texi to info looses important
information, is that right?

btw, for example in slime.info, I see paragraphs delimited with empty
line.  Also 3 spaces for indenting paragraphs and 5 spaces for code.  Is
that not always the case?

Re: Variable pitch mode line

[Yuan Fu]

> On Dec 23, 2021, at 3:00 PM, Tomas Hlavaty <tom@logand.com> wrote:
> 
> On Thu 23 Dec 2021 at 13:41, Yuan Fu <casouri@gmail.com> wrote:
>>> On Dec 23, 2021, at 1:24 PM, Tomas Hlavaty <tom@logand.com> wrote:
>>> On Thu 23 Dec 2021 at 13:00, Yuan Fu <casouri@gmail.com> wrote:
>>>>> On Dec 23, 2021, at 12:56 PM, Tomas Hlavaty <tom@logand.com> wrote:
>>>>> On Thu 23 Dec 2021 at 12:51, Yuan Fu <casouri@gmail.com> wrote:
>>>>>> I’ve tried that. Info files are not complex, but they can’t be
>>>>>> reliably parsed 100% of the time. My code works for like 95% of the
>>>>>> nodes, but there are always some corner cases where it breaks.
>>>>> 
>>>>> Why doesn't texinfo html output suffer from this problem?
>>>> 
>>>> HTML are structured, where as Info is more like plain text. Just to
>>>> give an example, in an info file, four spaces indent text could be a
>>>> code block, or just an indented paragraph, there is no way telling
>>>> them apart. In HTML, code is wrapped in <code> (or maybe <pre>),
>>>> paragraphs are wrapped in <p>.
>>> 
>>> Sorry for not being clearer.
>>> The question is not about the difference between info and html.
>>> 
>>> The question is: why does your info to html conversion attempt work in
>>> 95% cases but textinfos info to html conversion work in 100% cases?
>> 
>> So I guess your question is about the difference between info and
>> texinfo? Texinfo is also structured, makeinfo can parse a texinfo file
>> (you probably already know that). Info files are, as I said, not
>> structured and can’t be reliably parsed to code blocks, paragraphs,
>> function definitions, etc. Hence my code only works 95% of the
>> time. Also I’m not converting info files to html files, I’m just
>> parsing info files and trying to fontify it. Here is the code, maybe
>> that can explain better than my words. (I know it’s name conflicts
>> with another well-know package, it’s only used by myself and not
>> published.)
> 
> I see, textinfo does not use info files for html conversion (it uses
> texi files) and the conversion from texi to info looses important
> information, is that right?

Yes.

> 
> btw, for example in slime.info, I see paragraphs delimited with empty
> line.  Also 3 spaces for indenting paragraphs and 5 spaces for code.  Is
> that not always the case?

Yes. But sometimes paragraphs are indented to 5 spaces, and we can’t tell if its code or paragraph. I don’t remember concert cases, but maybe a list in a paragraph, which indents more than the paragraph it is in. There are other breakages, of course. If you enable info-pretty-mode in info+.el and try to use it for a while, eventually you will encounter some breakage. In my case, I encountered some breakages and have no way to fix them. There is just not enough information.

Yuan

Re: Variable pitch mode line

[Tomas Hlavaty]

On Thu 23 Dec 2021 at 15:28, Yuan Fu <casouri@gmail.com> wrote:
>> On Dec 23, 2021, at 3:00 PM, Tomas Hlavaty <tom@logand.com> wrote:
>> I see, textinfo does not use info files for html conversion (it uses
>> texi files) and the conversion from texi to info looses important
>> information, is that right?
>
> Yes.

thanks for explanation

> In my case, I encountered some breakages and have no way to fix
> them. There is just not enough information.

that is a shame

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Fri, 24 Dec 2021 00:00:57 +0100
> Cc: Tassilo Horn <tsdh@gnu.org>, Lars Ingebrigtsen <larsi@gnus.org>,
>  Emacs developers <emacs-devel@gnu.org>, Juri Linkov <juri@linkov.net>
> 
> btw, for example in slime.info, I see paragraphs delimited with empty
> line.  Also 3 spaces for indenting paragraphs and 5 spaces for code.  Is
> that not always the case?

It's something that can be changed via an appropriate Texinfo setting.

Again, I suggest a good reading of the Texinfo manual.  It is a very
good manual, and will teach you some surprising and even awesome
stuff.

RE: [External] : Re: Variable pitch mode line

[Drew Adams]

> Here is the code, maybe that can explain better
> than my words. (I know it’s name conflicts with
> another well-know package, it’s only used by
> myself and not published.)

Well, you're distributing it now (here).  Please
consider using a different file name, to avoid
confusing anyone.

There are zillions of names you can use.  My
`info+.el' library has been around since 1996,
at least - and likely longer.

Thx.

Re: [External] : Re: Variable pitch mode line

[Yuan Fu]

> On Dec 23, 2021, at 4:50 PM, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> Here is the code, maybe that can explain better
>> than my words. (I know it’s name conflicts with
>> another well-know package, it’s only used by
>> myself and not published.)
> 
> Well, you're distributing it now (here).  Please
> consider using a different file name, to avoid
> confusing anyone.

That’s true. I’ll change its name before posting that code next time. Sorry.

> 
> There are zillions of names you can use.  My
> `info+.el' library has been around since 1996,
> at least - and likely longer.

I agree.

Yuan

RE: [External] : Re: Variable pitch mode line

[Drew Adams]

> That’s true. I’ll change its name before posting
> that code next time. Sorry.

Thank you!

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Thu, 23 Dec 2021 21:56:21 +0100
> Cc: Juri Linkov <juri@linkov.net>, Lars Ingebrigtsen <larsi@gnus.org>,
>  emacs-devel@gnu.org, Tassilo Horn <tsdh@gnu.org>
> 
> On Thu 23 Dec 2021 at 12:51, Yuan Fu <casouri@gmail.com> wrote:
> > I’ve tried that. Info files are not complex, but they can’t be
> > reliably parsed 100% of the time. My code works for like 95% of the
> > nodes, but there are always some corner cases where it breaks.
> 
> Why doesn't texinfo html output suffer from this problem?

Because it starts from Texinfo's original markup, not from Info, where
most of it is either lost or translated to something else.

For example, @var{..} should be converted to italics in HTML, but Info
has it in CAPS.  OTOH, acronyms, like GNU, are also in CAPS.  So how
would you distinguish between acronyms, which should be left alone in
HTML, and what was in @var{..}?

Re: Variable pitch mode line

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Thu, 23 Dec 2021 21:41:32 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> iirc info files are not that complex.  How difficult would it be to
> transform an info file to html in Lisp and display it with eww/shr on
> the fly?  In my emacs-unoffice package, I explored this for various
> office formats and it seems like a reasonably useable solution.

That doesn't work well enough because many of the Texinfo directives
get lost in the Info format, and the way Texinfo markup is expressed
in Info doesn't allow mapping back to the original markup.

This has been tried before, and turned out to be unworkable.

If you are not convinced, I suggest a careful reading of the Texinfo
manual, which describes for each directive and markup how it is
translated into Info.  Then try to see how you would produce the
reverse translation.  You will quickly see that the translation is not
reversible.

Re: Variable pitch mode line

[Tomas Hlavaty]

On Fri 24 Dec 2021 at 08:50, Eli Zaretskii <eliz@gnu.org> wrote:
> This has been tried before, and turned out to be unworkable.

ok