all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#33967: [Feature Request] Use proportional fonts in Info-mode
@ 2019-01-03 20:35 Alex Griffin
       [not found] ` <mailman.6730.1546547831.1284.bug-gnu-emacs@gnu.org>
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Alex Griffin @ 2019-01-03 20:35 UTC (permalink / raw)
  To: 33967

Right now Emacs' built-in info viewer renders almost everything using the default face. I can set the default face to a proportional font and read most manuals just fine, but sometimes fixed-width fonts are assumed. Try using a proportional font on "(ledger3)Register Report" for example. It renders terribly in Emacs even though texinfo's html output successfully mixes proportional and fixed-width fonts [1].

It would be nice to improve it by using proportional fonts where appropriate, and fixed-width fonts only where necessary. This would improve readability and better match texinfo's html output.

Thanks,
-- 
Alex Griffin

[1]: https://www.ledger-cli.org/3.0/doc/ledger3.html#Register-Report





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
       [not found] ` <mailman.6730.1546547831.1284.bug-gnu-emacs@gnu.org>
@ 2019-01-03 21:23   ` Alan Mackenzie
  2019-01-03 21:41     ` Alex Griffin
  0 siblings, 1 reply; 11+ messages in thread
From: Alan Mackenzie @ 2019-01-03 21:23 UTC (permalink / raw)
  To: Alex Griffin; +Cc: 33967

Hello, Alex.

In article <mailman.6730.1546547831.1284.bug-gnu-emacs@gnu.org> you wrote:
> Right now Emacs' built-in info viewer renders almost everything using
> the default face. I can set the default face to a proportional font and
> read most manuals just fine, but sometimes fixed-width fonts are
> assumed. Try using a proportional font on "(ledger3)Register Report"
> for example. It renders terribly in Emacs even though texinfo's html
> output successfully mixes proportional and fixed-width fonts [1].

> It would be nice to improve it by using proportional fonts where
> appropriate, and fixed-width fonts only where necessary. This would
> improve readability and better match texinfo's html output.

I'm happy to do without such "improvements", taking advantage of the high
readability of my terminal's fixed width font.  I take it you really mean
"have the option of using proportional fonts".  I've nothing against
that.

I'm not sure whether proportional fonts really do improve readability.
My standard test is to use such a font to display the notional C
fragment: "Legal||Illegal" and check that what's displayed isn't just an
indistinguishable mass of vertical lines between legible characters.

However, you're probably aware that TexInfo formats text into lines, with
line breaks.  These may not display well with proportional fonts.

I'm wholly unconvinced that making Info "better match" HTML is at all
worthwhile.  Where's the advantage in such a match, even supposing it is
possible?

> Thanks,
> -- 
> Alex Griffin

> [1]: https://www.ledger-cli.org/3.0/doc/ledger3.html#Register-Report

-- 
Alan Mackenzie (Nuremberg, Germany).






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-03 21:23   ` Alan Mackenzie
@ 2019-01-03 21:41     ` Alex Griffin
  0 siblings, 0 replies; 11+ messages in thread
From: Alex Griffin @ 2019-01-03 21:41 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: 33967

On Thu, Jan 3, 2019, at 9:23 PM, Alan Mackenzie wrote:
> I'm happy to do without such "improvements", taking advantage of the high
> readability of my terminal's fixed width font.  I take it you really mean
> "have the option of using proportional fonts".  I've nothing against
> that.

Just having the option would be a nice improvement, there's no need to agree on the relative readability of each. Using more varied faces would also make it possible for you to style more elements of info manuals even in the terminal.

> I'm wholly unconvinced that making Info "better match" HTML is at all
> worthwhile.  Where's the advantage in such a match, even supposing it is
> possible?

I guess I don't care whether they match or not. I was just calling attention to the fact that texinfo already knows what needs to be formatted in fixed-width. (In contrast, most man pages don't track the semantic information that's necessary to render them in anything but fixed-width.)

-- 
Alex Griffin





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-03 20:35 bug#33967: [Feature Request] Use proportional fonts in Info-mode Alex Griffin
       [not found] ` <mailman.6730.1546547831.1284.bug-gnu-emacs@gnu.org>
@ 2019-01-04  5:58 ` Glenn Morris
  2019-01-04  6:50 ` Eli Zaretskii
  2 siblings, 0 replies; 11+ messages in thread
From: Glenn Morris @ 2019-01-04  5:58 UTC (permalink / raw)
  To: Alex Griffin; +Cc: 33967

"Alex Griffin" wrote:

> Right now Emacs' built-in info viewer renders almost everything using
> the default face. I can set the default face to a proportional font
> and read most manuals just fine, but sometimes fixed-width fonts are
> assumed. Try using a proportional font on "(ledger3)Register Report"
> for example. It renders terribly in Emacs even though texinfo's html
> output successfully mixes proportional and fixed-width fonts [1].
>
> It would be nice to improve it by using proportional fonts where
> appropriate, and fixed-width fonts only where necessary. This would
> improve readability and better match texinfo's html output.

IIUC what you are asking for, the relevant markup information simply
isn't present in .info files, so what you are asking for seems
impossible.

For example, compare
https://www.gnu.org/software/emacs/manual/html_node/elisp/Defining-Hash.html#Defining-Hash

with elisp.info. The latter contains:

   This example creates a hash table whose keys are strings that are
compared case-insensitively.

     (defun case-fold-string= (a b)
       (eq t (compare-strings a nil nil b nil nil t)))


ie, examples are not delimited in any fashion.

So you would first have to get a change in texinfo before this could work.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-03 20:35 bug#33967: [Feature Request] Use proportional fonts in Info-mode Alex Griffin
       [not found] ` <mailman.6730.1546547831.1284.bug-gnu-emacs@gnu.org>
  2019-01-04  5:58 ` Glenn Morris
@ 2019-01-04  6:50 ` Eli Zaretskii
  2019-01-05 21:51   ` Juri Linkov
  2 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-01-04  6:50 UTC (permalink / raw)
  To: Alex Griffin; +Cc: 33967

> Date: Thu, 03 Jan 2019 15:35:07 -0500
> From: "Alex Griffin" <a@ajgrf.com>
> 
> Right now Emacs' built-in info viewer renders almost everything using the default face. I can set the default face to a proportional font and read most manuals just fine, but sometimes fixed-width fonts are assumed. Try using a proportional font on "(ledger3)Register Report" for example. It renders terribly in Emacs even though texinfo's html output successfully mixes proportional and fixed-width fonts [1].
> 
> It would be nice to improve it by using proportional fonts where appropriate, and fixed-width fonts only where necessary. This would improve readability and better match texinfo's html output.

AFAIU, this is not feasible as long as we use the Info format of the
manual, because 'makeinfo' formats the manual under the assumption
that it will be read using a fixed-pitch typeface, and ends each
visual line with a hard newline.  HTML format avoids that because it
leaves it to the browser to reflow and break text into lines.

AFAIK, there's work under way to improve the HTML output so that it
could provide the features we want from a GNU manual reader, and then
switch the GNU Info readers to supporting that.  But this is a
long-term goal, and cannot be reached by changes in Emacs alone.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-04  6:50 ` Eli Zaretskii
@ 2019-01-05 21:51   ` Juri Linkov
  2019-01-06  3:35     ` Eli Zaretskii
  2019-01-06 19:41     ` Richard Stallman
  0 siblings, 2 replies; 11+ messages in thread
From: Juri Linkov @ 2019-01-05 21:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33967, Alex Griffin

> AFAIK, there's work under way to improve the HTML output so that it
> could provide the features we want from a GNU manual reader, and then
> switch the GNU Info readers to supporting that.  But this is a
> long-term goal, and cannot be reached by changes in Emacs alone.

It's easy to add HTML support to the Emacs Info reader
with the help of shr.el HTML renderer, but I guess this
should wait until the stand-alone Info reader supports HTML.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-05 21:51   ` Juri Linkov
@ 2019-01-06  3:35     ` Eli Zaretskii
  2019-01-07  0:00       ` Juri Linkov
  2019-01-06 19:41     ` Richard Stallman
  1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-01-06  3:35 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 33967, a

> From: Juri Linkov <juri@linkov.net>
> Cc: "Alex Griffin" <a@ajgrf.com>,  33967@debbugs.gnu.org
> Date: Sat, 05 Jan 2019 23:51:54 +0200
> 
> > AFAIK, there's work under way to improve the HTML output so that it
> > could provide the features we want from a GNU manual reader, and then
> > switch the GNU Info readers to supporting that.  But this is a
> > long-term goal, and cannot be reached by changes in Emacs alone.
> 
> It's easy to add HTML support to the Emacs Info reader
> with the help of shr.el HTML renderer, but I guess this
> should wait until the stand-alone Info reader supports HTML.

The problem is not to render HTML per se, the problem is to support
the Info features like index search in HTML, something I don't know
what would it take until we see what makeinfo emits.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-05 21:51   ` Juri Linkov
  2019-01-06  3:35     ` Eli Zaretskii
@ 2019-01-06 19:41     ` Richard Stallman
  1 sibling, 0 replies; 11+ messages in thread
From: Richard Stallman @ 2019-01-06 19:41 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 33967, a

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's easy to add HTML support to the Emacs Info reader
  > with the help of shr.el HTML renderer, but I guess this
  > should wait until the stand-alone Info reader supports HTML.

If we could do this now, it would be useful right away.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)







^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-06  3:35     ` Eli Zaretskii
@ 2019-01-07  0:00       ` Juri Linkov
  2019-01-07  3:36         ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Juri Linkov @ 2019-01-07  0:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33967, a

>> > AFAIK, there's work under way to improve the HTML output so that it
>> > could provide the features we want from a GNU manual reader, and then
>> > switch the GNU Info readers to supporting that.  But this is a
>> > long-term goal, and cannot be reached by changes in Emacs alone.
>> 
>> It's easy to add HTML support to the Emacs Info reader
>> with the help of shr.el HTML renderer, but I guess this
>> should wait until the stand-alone Info reader supports HTML.
>
> The problem is not to render HTML per se, the problem is to support
> the Info features like index search in HTML, something I don't know
> what would it take until we see what makeinfo emits.

We can get index entries from the links found in the Index HTML pages
that makeinfo already emits, i.e. the same way that the Info reader
already parses .info files, it can parse .html files that should be simpler
since there is less ambiguity in HTML format.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-07  0:00       ` Juri Linkov
@ 2019-01-07  3:36         ` Eli Zaretskii
  2019-01-07 21:49           ` Juri Linkov
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-01-07  3:36 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 33967, a

> From: Juri Linkov <juri@linkov.net>
> Cc: a@ajgrf.com,  33967@debbugs.gnu.org
> Date: Mon, 07 Jan 2019 02:00:42 +0200
> 
> > The problem is not to render HTML per se, the problem is to support
> > the Info features like index search in HTML, something I don't know
> > what would it take until we see what makeinfo emits.
> 
> We can get index entries from the links found in the Index HTML pages
> that makeinfo already emits, i.e. the same way that the Info reader
> already parses .info files, it can parse .html files that should be simpler
> since there is less ambiguity in HTML format.

I don't think we should invent our own HTML-Info conventions.  There's
a person actively working on that for the Texinfo project; when that
job is done, we should support whatever comes out of that.  If you
want to be part of that work, please contact the Texinfo developers.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#33967: [Feature Request] Use proportional fonts in Info-mode
  2019-01-07  3:36         ` Eli Zaretskii
@ 2019-01-07 21:49           ` Juri Linkov
  0 siblings, 0 replies; 11+ messages in thread
From: Juri Linkov @ 2019-01-07 21:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33967, a

>> > The problem is not to render HTML per se, the problem is to support
>> > the Info features like index search in HTML, something I don't know
>> > what would it take until we see what makeinfo emits.
>>
>> We can get index entries from the links found in the Index HTML pages
>> that makeinfo already emits, i.e. the same way that the Info reader
>> already parses .info files, it can parse .html files that should be simpler
>> since there is less ambiguity in HTML format.
>
> I don't think we should invent our own HTML-Info conventions.  There's
> a person actively working on that for the Texinfo project; when that
> job is done, we should support whatever comes out of that.  If you
> want to be part of that work, please contact the Texinfo developers.

Emacs could support the existing HTML-Info convention, i.e. HTML files
already emitted by the current version of makeinfo.  After modernization
of HTML output by Texinfo developers, the Emacs Info reader could also
support a new HTML-Info convention.  But since supporting both formats
would be more work, maybe better to wait for a new convention indeed.





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-01-07 21:49 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-03 20:35 bug#33967: [Feature Request] Use proportional fonts in Info-mode Alex Griffin
     [not found] ` <mailman.6730.1546547831.1284.bug-gnu-emacs@gnu.org>
2019-01-03 21:23   ` Alan Mackenzie
2019-01-03 21:41     ` Alex Griffin
2019-01-04  5:58 ` Glenn Morris
2019-01-04  6:50 ` Eli Zaretskii
2019-01-05 21:51   ` Juri Linkov
2019-01-06  3:35     ` Eli Zaretskii
2019-01-07  0:00       ` Juri Linkov
2019-01-07  3:36         ` Eli Zaretskii
2019-01-07 21:49           ` Juri Linkov
2019-01-06 19:41     ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.