Re: How to make Emacs popular again: Use monospaced fonts less

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

One of the reasons Emacs looks kinda old-fashioned is that we use
monospaced fonts all over the place.  Now, when programming and stuff, a
monospaced font is preferred, but in other contexts, it looks pretty
old-fashioned.

So here's my most controversial suggestion ever:

diff --git a/lisp/faces.el b/lisp/faces.el
index 5b7e0a5aee..e6f65a5901 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2553,6 +2553,7 @@ mode-line-faces
 (defface mode-line
   '((((class color) (min-colors 88))
      :box (:line-width -1 :style released-button)
+     :inherit variable-pitch
      :background "grey75" :foreground "black")
     (t
      :inverse-video t))

In addition to looking nicer, it means we can fit more data into the
mode line.

Other obvious candidates for variable-pitching are basically any mode
that displays data in tabular form.  And, of course, the manuals, but
that'll happen by itself once we move from .info to .html.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

On October 11, 2020 8:37:45 AM GMT+03:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> One of the reasons Emacs looks kinda old-fashioned is that we use
> monospaced fonts all over the place.  Now, when programming and stuff,
> a
> monospaced font is preferred, but in other contexts, it looks pretty
> old-fashioned.
> 
> So here's my most controversial suggestion ever:
> 
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
> 
> In addition to looking nicer, it means we can fit more data into the
> mode line.
> 
> Other obvious candidates for variable-pitching are basically any mode
> that displays data in tabular form.  And, of course, the manuals, but
> that'll happen by itself once we move from .info to .html.

We cannot just switch to variable-pitch font and leave the rest unchanged.  Using a variable-pitch font will cause an annoying horizontal movement of the mode-line stuff when some parts change.  For example, moving in the buffer will change the column and line numbers, and everything to the right of that will as result shift slightly in the horizontal direction.

So to use variable pitch fonts here (and in any other tabjlar display), we'd need to use 'align-to' display properties to keep the other parts from moving.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> We cannot just switch to variable-pitch font and leave the rest
> unchanged.  Using a variable-pitch font will cause an annoying
> horizontal movement of the mode-line stuff when some parts change.
> For example, moving in the buffer will change the column and line
> numbers, and everything to the right of that will as result shift
> slightly in the horizontal direction.

The line numbers aren't that big a problem -- the number of digits
rarely change, and all the numbers are the same size in most variable
pitch fonts that are in use for this stuff.

I don't use column number mode, but I switched it on now, and that seems
fine to me, too.

> So to use variable pitch fonts here (and in any other tabjlar
> display), we'd need to use 'align-to' display properties to keep the
> other parts from moving.

After playing with this stuff for half an hour, the only thing that
seemed vaguely disturbing was the U:** stuff at the start.  Adding an
align-to after that would get us most of the way there, I think.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

On October 11, 2020 9:35:39 AM GMT+03:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We cannot just switch to variable-pitch font and leave the rest
> > unchanged.  Using a variable-pitch font will cause an annoying
> > horizontal movement of the mode-line stuff when some parts change.
> > For example, moving in the buffer will change the column and line
> > numbers, and everything to the right of that will as result shift
> > slightly in the horizontal direction.
> 
> The line numbers aren't that big a problem -- the number of digits
> rarely change, and all the numbers are the same size in most variable
> pitch fonts that are in use for this stuff.
> 
> I don't use column number mode, but I switched it on now, and that
> seems
> fine to me, too.

The number of digits in the line number can change a lot if you jump to another place with M-g g or C-x C-x or some other similar command.

And what about the "All/Top/Bot/NN%" part?

And then there are optional displays, like display-time-mode etc.

In any case, I wouldn't rely on what you see with some subset of fonts, this is a general feature we are talking about.

> > So to use variable pitch fonts here (and in any other tabjlar
> > display), we'd need to use 'align-to' display properties to keep the
> > other parts from moving.
> 
> After playing with this stuff for half an hour, the only thing that
> seemed vaguely disturbing was the U:** stuff at the start.  Adding an
> align-to after that would get us most of the way there, I think.

I rather think we should use align-to for all the fields.  Half-measures will come back to bite us down the road.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The number of digits in the line number can change a lot if you jump
> to another place with M-g g or C-x C-x or some other similar command.

That's true, but is also the case today (in huge files).  I think the
only way to see whether it's annoying or not is to try it out on people
and see what they say.

> And what about the "All/Top/Bot/NN%" part?

Ditto.

> And then there are optional displays, like display-time-mode etc.

All the ones that display numbers (and don't change between numbers and
non-numerical data) aren't affected in any reasonable font.

> I rather think we should use align-to for all the fields.
> Half-measures will come back to bite us down the road.

I think we should just gather some feedback first and see what's
annoying and what isn't.  I've now used this for hours :-), and the only
thing I've noticed being even remotely odd is the U:** switching to
U:--, which takes much less space and draws the eye.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

This reminds me, by the way...  I forget if this has been discussed
before or not, but in these cases it'd be handy to have a text property
like, say, (propertize "foo" :min-width 5) (or :min-width (50)), and
have the display engine compute how much space to add to the end.

Would that be much work to add?

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>>  (defface mode-line
>>    '((((class color) (min-colors 88))
>>       :box (:line-width -1 :style released-button)
>> +     :inherit variable-pitch
>>       :background "grey75" :foreground "black")

FWIW, I've been using pretty much exactly that for quite a few years now.
I did it mostly to save space, and the main downside for me was that the
`*`s "don't look right" (they're shifted up compared to my monospace
fonts), but I overcame this trauma without too much trouble.

> We cannot just switch to variable-pitch font and leave the rest unchanged.
> Using a variable-pitch font will cause an annoying horizontal movement of
> the mode-line stuff when some parts change.

Never bothered me even a tiny bit.  It's the kind of thing that annoys
me when it happens right where I'm editing, but apparently the modeline
is far enough.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 11 Oct 2020 12:54:06 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The number of digits in the line number can change a lot if you jump
> > to another place with M-g g or C-x C-x or some other similar command.
> 
> That's true, but is also the case today (in huge files).

Yes, but with variable-pitch fonts, it will happen more frequently,
because the width of a space is typically different in these fonts
from the width of digit characters.

> I think the only way to see whether it's annoying or not is to try
> it out on people and see what they say.

I've seen complaints about similar behavior in other contexts, that's
why I raised the issue.

> > And what about the "All/Top/Bot/NN%" part?
> 
> Ditto.

No: these are all 3-character wide, so they take a fixed-width space
with fixed-pitch fonts.  Now it won't.

> > And then there are optional displays, like display-time-mode etc.
> 
> All the ones that display numbers (and don't change between numbers and
> non-numerical data) aren't affected in any reasonable font.

display-time-mode shows AM and PM, though.

> I think we should just gather some feedback first and see what's
> annoying and what isn't.

We _are_ getting feedback: you've got mine ;-)

And others are encouraged to express their views as well.

> I've now used this for hours :-), and the only thing I've noticed
> being even remotely odd is the U:** switching to U:--, which takes
> much less space and draws the eye.

Using :align-to is simple, and could even simplify the mode-line
construction: instead of carefully counting spaces, you will need just
one space with a suitable :align-to.  So I'm not really sure why this
needs an argument.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 11 Oct 2020 13:28:06 +0200
> 
> This reminds me, by the way...  I forget if this has been discussed
> before or not, but in these cases it'd be handy to have a text property
> like, say, (propertize "foo" :min-width 5) (or :min-width (50)), and
> have the display engine compute how much space to add to the end.
> 
> Would that be much work to add?

Let's put it this way: if there's a simple way of adding this, I
cannot think of it.

Btw, if there were such a property, how would you calculate the value
to put there?

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 11 Oct 2020 09:21:46 -0400
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> > We cannot just switch to variable-pitch font and leave the rest unchanged.
> > Using a variable-pitch font will cause an annoying horizontal movement of
> > the mode-line stuff when some parts change.
> 
> Never bothered me even a tiny bit.

So I guess you won't be sending bug reports about it.  But someone
else would, and the measures to avoid that up front are so easy I
don't see why we are arguing.

Re: How to make Emacs popular again: Use monospaced fonts less

[Teemu Likonen]

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

* 2020-10-11 07:37:45+02, Lars Ingebrigtsen wrote:

> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))

Thanks. I think this is a good idea. I included it to my own Emacs
theme.

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> > > We cannot just switch to variable-pitch font and leave the rest
> > > unchanged.
> > > Using a variable-pitch font will cause an annoying horizontal movement of
> > > the mode-line stuff when some parts change.
> >
> > Never bothered me even a tiny bit.
> 
> So I guess you won't be sending bug reports about it.  But someone
> else would, and the measures to avoid that up front are so easy I
> don't see why we are arguing.

My 2 cents about this -

1. I don't think we should use `align-to' etc., at all.
   That would be even more disruptive, e.g., it might
   interfere with user mode-line customizations.

   Whereas it's easy for a user to add, change, or
   remove attributes of face `mode-line', it's not so
   easy for a user to try to second-guess or make
   adjustments for whatever you might do wrt ensuring
   alignment.

2. Having tried Lars's suggestion, I find the effect
   good overall.

3. Should it really be on by default?  Dunno.  Typically
   to make something like this the default we'd have lots
   of people already using it by their own customizations.

   Though the mode-line is not easy to customize in
   general, it's trivial to change its face.  Do we have
   lots of users who use a variable-pitch font for it now?

I'm going to start using this, myself.  Dunno whether
I'll stick with it, but so far it seems good.

How bothersome it might be for some parts of the line
content to move left or right is personal, I think.

Personally, I'm not bothered by it.  And the mode-line
parts don't have to be aligned with anything else in
Emacs, AFAIK.

Re: How to make Emacs popular again: Use monospaced fonts less

[Andreas Schwab]

On Okt 11 2020, Lars Ingebrigtsen wrote:

> So here's my most controversial suggestion ever:
>
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
>
> In addition to looking nicer, it means we can fit more data into the
> mode line.

Make sure that the header-line face does *not* inherit the
variable-pitch face.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> > Never bothered me even a tiny bit.
> 
> So I guess you won't be sending bug reports about it.  But someone
> else would, and the measures to avoid that up front are so easy I
> don't see why we are arguing.

True, but the measures to remove the annoyance
are also simple.  It's a matter of one attribute
of one face (since `mode-line-inactive' inherits
from `mode-line').

Dunno whether we should change the default
immediately - I don't see a crying need to do
that.  But I'm going to try using it, myself.

Many users already use some library/package or
theme that provides a customized mode-line.
If they haven't already, perhaps some such will
use variable-pitch fonts.  It many users start
using variable-pitch in the mode-line then it
would be especially reasonable to consider
switching the default to variable-pitch.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> Make sure that the header-line face does *not* inherit the
> variable-pitch face.

My header-line face uses the same variable pitch face as my mode line,
so I'm not sure why you say the above.

There are indeed several uses of the header-line that need/want to be
aligned with the buffer's content (typically for tabular formats), which
I bumped into back when I started using a variable pitch face for the
mode/header-lines, but these should be fixed in any case (for those
people like me who use a variable pitch face), and I have indeed fixed
those cases that I saw (e.g. `list-buffers`, `list-packages`,
`csv-mode`, `ses-mode`, ...).


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Andreas Schwab]

On Okt 11 2020, Stefan Monnier wrote:

>> Make sure that the header-line face does *not* inherit the
>> variable-pitch face.
>
> My header-line face uses the same variable pitch face as my mode line,
> so I'm not sure why you say the above.

Try hexl-mode.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>>> Make sure that the header-line face does *not* inherit the
>>> variable-pitch face.
>> My header-line face uses the same variable pitch face as my mode line,
>> so I'm not sure why you say the above.
> Try hexl-mode.

I use `nhexl-mode` ;-)

It should be pretty easy to fix `hexl-mode` to do something like what
`nhexl-mode` does (based on my experience with the various other
packages I fixed over the years).

But at least in `nhexl-mode` I still get a slightly incorrect result in
the "right hand side ASCII area" because the digits of my variable-pitch
font take up a bit more horizontal space than the chars of my monospaced
font, so the "0123456789abcdef" string in the header-line ends up wider
(by ~2 chars) than the 16 monospaced chars below.  Luckily, it's the
last field of the line, so it's not too bothersome, but admittedly
it's unsatisfactory.

I actually played with another approach which was to impose the same
font in `nhexl-mode`s header-line as in the buffer's text, but after
playing with it I decided that I preferred the variable pitch font,
despite its downsides.


        Stefan

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> There are indeed several uses of the header-line that need/want to be
> aligned with the buffer's content (typically for tabular formats), 

Ah, good point.  In this respect a header-line isn't
similar to a mode-line.

(Well, I suppose a mode-line could also have column
"footers" that repeat the column headers or provide
some alternative identification.)

> but these should be fixed in any case

Agreed.  And the fix is (should always be, AFAICT)
pretty simple.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stephen Berman]

On Sun, 11 Oct 2020 14:29:14 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Make sure that the header-line face does *not* inherit the
>> variable-pitch face.
>
> My header-line face uses the same variable pitch face as my mode line,
> so I'm not sure why you say the above.
>
> There are indeed several uses of the header-line that need/want to be
> aligned with the buffer's content (typically for tabular formats), which
> I bumped into back when I started using a variable pitch face for the
> mode/header-lines, but these should be fixed in any case (for those
> people like me who use a variable pitch face), and I have indeed fixed
> those cases that I saw (e.g. `list-buffers`, `list-packages`,
> `csv-mode`, `ses-mode`, ...).

Could you try to make proced work with a variable pitch header-line?  I
tried and failed (bug#1779).

Steve Berman

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> Could you try to make proced work with a variable pitch header-line?
> I tried and failed (bug#1779).

Haven't looked at it yet, but I just pushed an attempt to fix it for
`hexl-mode` (which already had some of the work done).


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> display-time-mode shows AM and PM, though.

I don't think the shift in pixels twice a day will annoy anyone.  :-)

>> I've now used this for hours :-), and the only thing I've noticed
>> being even remotely odd is the U:** switching to U:--, which takes
>> much less space and draws the eye.
>
> Using :align-to is simple, and could even simplify the mode-line
> construction: instead of carefully counting spaces, you will need just
> one space with a suitable :align-to.  So I'm not really sure why this
> needs an argument.

I just didn't want to add any premature complexity here if none is
needed.

But...  Now that you mention it, I don't quite see how to use :align-to
in the mode line (in general).  It takes as a parameter the target
column number (or pixels), so if we want to say "this element should be
at least 80 pixels wide", then we need to know what column/pixel we're
on already, don't we?  Or am I missing something obvious here?

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> This reminds me, by the way...  I forget if this has been discussed
>> before or not, but in these cases it'd be handy to have a text property
>> like, say, (propertize "foo" :min-width 5) (or :min-width (50)), and
>> have the display engine compute how much space to add to the end.
>> 
>> Would that be much work to add?
>
> Let's put it this way: if there's a simple way of adding this, I
> cannot think of it.

Yeah, the semantics of text properties aren't very well-defined,
either.  I mean, if you have "foo" in the buffer with a :min-width (50)
text property, and then you insert a space in the middle (without any
properties), then both "fo" and "o" would have a separate :min-width
(50) stretch, so presumably would both be that wide.

So that's kinda a mess.

> Btw, if there were such a property, how would you calculate the value
> to put there?

It depends -- for instance, when calculating tabular layouts, I'd know
the number of pixels already.  In the mode line, I'd take 5x
typical-character-width if I wanted to display something that should
typically not take more than 5 characters.

Which is what we do in the mode line already for some of the things that
change lengths, like the line numbers.

OK, here's another random idea for padding variable-pitch elements in
the mode lines in particular:

        (setq mode-line-thing
              `(:propertize
                "some-string"
                :min-width 15))

which could have well-defined semantics, like "this element should have
the width of at least 15 typical characters", and be pretty easy to use?

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> Could you try to make proced work with a variable pitch header-line?  I
> tried and failed (bug#1779).

Done.  The right-alignment is still fairly ugly, of course.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Stephen Berman]

On Sun, 11 Oct 2020 18:23:36 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Could you try to make proced work with a variable pitch header-line?  I
>> tried and failed (bug#1779).
>
> Done.  The right-alignment is still fairly ugly, of course.

Thanks!

Steve Berman

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> > display-time-mode shows AM and PM, though.
> 
> I don't think the shift in pixels twice a day will annoy anyone.  :-)

Emacs is already too popular.  Surely it will annoy someone. ;-)

Re: How to make Emacs popular again: Use monospaced fonts less

[Richard Stallman]

[[[ 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. ]]]

I like this idea, in principle.  Partly because once we use
variable-width fonts, to get good visual results we will need to solve
the problems of getting good alignment.  We will need to develop
solutions that are easy to use and look good.

That will be an important step forward.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: How to make Emacs popular again: Use monospaced fonts less

[Andreas Schwab]

On Okt 11 2020, Stefan Monnier wrote:

>> Make sure that the header-line face does *not* inherit the
>> variable-pitch face.
>
> My header-line face uses the same variable pitch face as my mode line,
> so I'm not sure why you say the above.

header-line overrides all attributes of mode-line anyway.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: How to make Emacs popular again: Use monospaced fonts less

[Ricardo Wurmus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Make sure that the header-line face does *not* inherit the
>> variable-pitch face.
>
> My header-line face uses the same variable pitch face as my mode line,
> so I'm not sure why you say the above.
>
> There are indeed several uses of the header-line that need/want to be
> aligned with the buffer's content (typically for tabular formats), which
> I bumped into back when I started using a variable pitch face for the
> mode/header-lines, but these should be fixed in any case (for those
> people like me who use a variable pitch face), and I have indeed fixed
> those cases that I saw (e.g. `list-buffers`, `list-packages`,
> `csv-mode`, `ses-mode`, ...).

mu4e’s *mu4e-headers* buffer has a header line (“Date”, “Flgs”, “List”,
“From”, “Subject”), which no longer lines up with the contents of the
buffer when the mode-line face inherits from variable-pitch.

I suspect that other packages would suffer from the same problem (and we
can’t fix this for them all), so perhaps it would be a good idea to
override the inheritance of header-line by default.

-- 
Ricardo

Re: How to make Emacs popular again: Use monospaced fonts less

[Ricardo Wurmus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> One of the reasons Emacs looks kinda old-fashioned is that we use
> monospaced fonts all over the place.  Now, when programming and stuff, a
> monospaced font is preferred, but in other contexts, it looks pretty
> old-fashioned.
>
> So here's my most controversial suggestion ever:
>
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
>
> In addition to looking nicer, it means we can fit more data into the
> mode line.

I use variable-pitch for EWW, Info, and Org buffers, so I’m generally
happy to see more uses of variable-pitch where monospace isn’t
necessary.  That said, I think it looks a bit out of place to me,
perhaps because I use a serif font for the variable-pitch face.
Variable pitch looks fine in text buffers to me, but on a single line
surrounded by monospaced text it looks a bit odd.

The modeline would benefit from prettification, of course, such as using
icons instead of the more cryptic “U:-*” indicators etc.  But perhaps
variable pitch isn’t the best way to accomplish prettification here.

Another thing I noticed is that only the active modeline has variable
pitch; perhaps all mode line faces (including mode-line-inactive) need
adjustment?

> Other obvious candidates for variable-pitching are basically any mode
> that displays data in tabular form.  And, of course, the manuals, but
> that'll happen by itself once we move from .info to .html.

Will this move only affect Emacs?  Emacs is still the best Info reader
out there and most GNU packages have manuals in Info format.  Reading
other GNU packages’ Info documentation in Emacs would still look odd,
even if the Emacs manual(s) were to be converted to HTML.

Perhaps it would make sense to augment the Info format with extra
information, so that all Info documentation would look better in all
Info readers.

-- 
Ricardo

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> Another thing I noticed is that only the active modeline has variable
> pitch; perhaps all mode line faces (including mode-line-inactive) need
> adjustment?

I think you must be doing something special.
Face `mode-line-inactive' inherits from face
`mode-line'.  After I changed `mode-line' to
use variable-pitch, `mode-line-inactive' had
it also.

> > Other obvious candidates for variable-pitching are basically any mode
> > that displays data in tabular form.

Perhaps NON-variable was meant there?

> > And, of course, the manuals, but
> > that'll happen by itself once we move from .info to .html.

Variable pitch for header-line and mode-line
work fine for me in Info (FWIW).

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 12 Oct 2020 00:14:18 +0200
> 
> But...  Now that you mention it, I don't quite see how to use :align-to
> in the mode line (in general).  It takes as a parameter the target
> column number (or pixels), so if we want to say "this element should be
> at least 80 pixels wide", then we need to know what column/pixel we're
> on already, don't we?

Yes.  But that's how you design tabulated display, don't you?  You
select the coordinate where each column will end, and set tab stops
there, right?

If you are saying that you are used to start with column widths
instead, then just adding them up will give you the goal coordinates
for :align-to.  Am I missing something?

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 12 Oct 2020 00:21:10 +0200
> 
> > Btw, if there were such a property, how would you calculate the value
> > to put there?
> 
> It depends -- for instance, when calculating tabular layouts, I'd know
> the number of pixels already.  In the mode line, I'd take 5x
> typical-character-width if I wanted to display something that should
> typically not take more than 5 characters.

If this is what you already know, then calculating the goal
coordinates for :align-to should be a simple matter of adding up the
column widths.  Right?

> OK, here's another random idea for padding variable-pitch elements in
> the mode lines in particular:
> 
>         (setq mode-line-thing
>               `(:propertize
>                 "some-string"
>                 :min-width 15))
> 
> which could have well-defined semantics, like "this element should have
> the width of at least 15 typical characters", and be pretty easy to use?

This stuff is basically unworkable without having a window in whose
context the string will be shown.  That's because we need metrics of
each character glyph, and that presumes fonts, and that presumes faces
and other stuff.

This is why we use 'display' property: when the text is displayed, we
have this data by definition.  But not when we just have a string.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> mu4e’s *mu4e-headers* buffer has a header line (“Date”, “Flgs”, “List”,
> “From”, “Subject”), which no longer lines up with the contents of the
> buffer when the mode-line face inherits from variable-pitch.
>
> I suspect that other packages would suffer from the same problem (and we

No need to use the conditional: this already affects all users who have
changed their `header-line` (such as yours truly).

The best course of action is to file bug reports for every such case.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Tim Cross]

Just as another data point ....

I'm using spacemacs with the default spacemacs mode-line theme. I added
the following to my .spacemacs config file (I'm using the 'gotham'
theme).

(setq theming-modifications '((gotham (mode-line :inherit variable-pitch))))

This appears to be working well despite the fact spacemacs has a heavily
customised mode-line definition. The spacemacs environment supports a
number of different mode-line themes. I have only tried variable pitch
with the default theme. It looks good. 

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Ricardo Wurmus <rekado@elephly.net> writes:

> Another thing I noticed is that only the active modeline has variable
> pitch; perhaps all mode line faces (including mode-line-inactive) need
> adjustment?

I don't see this -- perhaps you've altered that face yourself?

>> Other obvious candidates for variable-pitching are basically any mode
>> that displays data in tabular form.  And, of course, the manuals, but
>> that'll happen by itself once we move from .info to .html.
>
> Will this move only affect Emacs?

Yes.

> Perhaps it would make sense to augment the Info format with extra
> information, so that all Info documentation would look better in all
> Info readers.

That would require changing all those other Info readers, which isn't
feasible.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> But...  Now that you mention it, I don't quite see how to use :align-to
>> in the mode line (in general).  It takes as a parameter the target
>> column number (or pixels), so if we want to say "this element should be
>> at least 80 pixels wide", then we need to know what column/pixel we're
>> on already, don't we?
>
> Yes.  But that's how you design tabulated display, don't you?  You
> select the coordinate where each column will end, and set tab stops
> there, right?

More or less.  But how would this work for mode lines?  There's nothing
tabular about those, and they move around a lot.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> OK, here's another random idea for padding variable-pitch elements in
>> the mode lines in particular:
>> 
>>         (setq mode-line-thing
>>               `(:propertize
>>                 "some-string"
>>                 :min-width 15))
>> 
>> which could have well-defined semantics, like "this element should have
>> the width of at least 15 typical characters", and be pretty easy to use?
>
> This stuff is basically unworkable without having a window in whose
> context the string will be shown.  That's because we need metrics of
> each character glyph, and that presumes fonts, and that presumes faces
> and other stuff.
>
> This is why we use 'display' property: when the text is displayed, we
> have this data by definition.  But not when we just have a string.

I'm not sure I understand you.  The mode line elements are only used
when we display them, so we know all that stuff, and can apply some
padding after the element if we have a :min-width thing here.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Ricardo Wurmus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Another thing I noticed is that only the active modeline has variable
>> pitch; perhaps all mode line faces (including mode-line-inactive) need
>> adjustment?
>
> I don't see this -- perhaps you've altered that face yourself?

Perhaps smart-mode-line did it.  Sorry for the noise.

>>> Other obvious candidates for variable-pitching are basically any mode
>>> that displays data in tabular form.  And, of course, the manuals, but
>>> that'll happen by itself once we move from .info to .html.
>>
>> Will this move only affect Emacs?
>
> Yes.
>
>> Perhaps it would make sense to augment the Info format with extra
>> information, so that all Info documentation would look better in all
>> Info readers.
>
> That would require changing all those other Info readers, which isn't
> feasible.

There aren’t many Info readers, but there are countless .info documents
across GNU and beyond.  Changing the Info format (and Info readers with
it) seems the better choice.

-- 
Ricardo

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 13 Oct 2020 02:35:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But...  Now that you mention it, I don't quite see how to use :align-to
> >> in the mode line (in general).  It takes as a parameter the target
> >> column number (or pixels), so if we want to say "this element should be
> >> at least 80 pixels wide", then we need to know what column/pixel we're
> >> on already, don't we?
> >
> > Yes.  But that's how you design tabulated display, don't you?  You
> > select the coordinate where each column will end, and set tab stops
> > there, right?
> 
> More or less.  But how would this work for mode lines?  There's nothing
> tabular about those, and they move around a lot.

I think if we want to keep the fields in their places, we should
consider the mode line to be tabular.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 13 Oct 2020 02:38:03 +0200
> 
> >>         (setq mode-line-thing
> >>               `(:propertize
> >>                 "some-string"
> >>                 :min-width 15))
> >> 
> >> which could have well-defined semantics, like "this element should have
> >> the width of at least 15 typical characters", and be pretty easy to use?
> >
> > This stuff is basically unworkable without having a window in whose
> > context the string will be shown.  That's because we need metrics of
> > each character glyph, and that presumes fonts, and that presumes faces
> > and other stuff.
> >
> > This is why we use 'display' property: when the text is displayed, we
> > have this data by definition.  But not when we just have a string.
> 
> I'm not sure I understand you.  The mode line elements are only used
> when we display them, so we know all that stuff, and can apply some
> padding after the element if we have a :min-width thing here.

Then perhaps I didn't understand your suggestion: how would the above
be different from what you originally had in mind about :min-width?

Re: How to make Emacs popular again: Use monospaced fonts less

[Juri Linkov]

> So here's my most controversial suggestion ever:
>
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
>
> In addition to looking nicer, it means we can fit more data into the
> mode line.

I tried this, and the mode-line looks much nicer indeed,
but this improvement is unusable because the mode-line jumps
left and right when the buffer is saved, the cursor is moved, etc.

Is it possible to leave monospaced fonts on parts of the mode-line
that change often (mode-line-modified, mode-line-position),
and put variable-pitch only on parts of the mode-line that don't
change often (mode-line-buffer-identification, mode-line-modes…)

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> I tried this, and the mode-line looks much nicer indeed,
> but this improvement is unusable because the mode-line jumps
> left and right when the buffer is saved, the cursor is moved, etc.

FWIW, I don't find it unusable.  (Just one user.)

(So far, my vote would be for face `mode-line' to
inherit from face `variable-pitch'.)

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think if we want to keep the fields in their places, we should
> consider the mode line to be tabular.

I don't think a tabular mode line is something that would be practical.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> >>         (setq mode-line-thing
>> >>               `(:propertize
>> >>                 "some-string"
>> >>                 :min-width 15))

[...]

> Then perhaps I didn't understand your suggestion: how would the above
> be different from what you originally had in mind about :min-width?

When rendering the mode line, Emacs knows what pixel it started the
first glyph of each mode line element on, and it knows where it ends, so
it sounds conceptually sound to add a :min-width spec here (since it can
just insert some space of the required length at the end).

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I tried this, and the mode-line looks much nicer indeed,
> but this improvement is unusable because the mode-line jumps
> left and right when the buffer is saved, the cursor is moved, etc.

Do you use a variable-pitch font that has different widths for the
digits?  I didn't think that would be an issue in practice.  What font
do you use?

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Protesilaos Stavrou]

On 2020-10-14, 06:05 +0200, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Juri Linkov <juri@linkov.net> writes:
>
>> I tried this, and the mode-line looks much nicer indeed,
>> but this improvement is unusable because the mode-line jumps
>> left and right when the buffer is saved, the cursor is moved, etc.
>
> Do you use a variable-pitch font that has different widths for the
> digits?  I didn't think that would be an issue in practice.  What font
> do you use?

To add to Juri's comment, many typefaces I tested exhibit this
jumpiness: Roboto, FiraGO, Inter, Noto Sans, Open Sans, DejaVu Sans…

I have column-number-mode enabled.  Typing this makes the modeline's
text shift slightly to the left and right, as if it were pulsing.  It is
due to the column count changing.  The effect may be fairly minor, but
is noticeable enough for me not to be able to tolerate it in its current
state.

The effect would be more pronounced (to my eyes, anyway), whenever I
would work towards the bottom of the window, where the text I type is
closer to the modeline.

Perhaps some modeline fields that change often can have a fixed length?

-- 
Protesilaos Stavrou
protesilaos.com

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Protesilaos Stavrou <info@protesilaos.com> writes:

> To add to Juri's comment, many typefaces I tested exhibit this
> jumpiness: Roboto, FiraGO, Inter, Noto Sans, Open Sans, DejaVu Sans…

I'm using DejaVu Sans, and all the digits are the same width here.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Protesilaos Stavrou]

On 2020-10-14, 09:09 +0200, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Protesilaos Stavrou <info@protesilaos.com> writes:
>
>> To add to Juri's comment, many typefaces I tested exhibit this
>> jumpiness: Roboto, FiraGO, Inter, Noto Sans, Open Sans, DejaVu Sans…
>
> I'm using DejaVu Sans, and all the digits are the same width here.

True for DejaVu Sans.  Though it is the difference between the width of
a space and a character/digit that causes the issue for me.  Again, this
is minor and subjective.

Note that some typefaces default to proportional spacing for digits.
Some fonts have a "tabular figures" configuration to enable fixed-space
digits.[1] It can be controlled by fontconfig, but that is outside
Emacs' control, as far as I can tell.[2]

[1]: https://en.wikipedia.org/wiki/OpenType_feature_tag_list
[2]: https://www.freedesktop.org/software/fontconfig/fontconfig-user.html

-- 
Protesilaos Stavrou
protesilaos.com

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Protesilaos Stavrou <info@protesilaos.com> writes:

>> I'm using DejaVu Sans, and all the digits are the same width here.
>
> True for DejaVu Sans.  Though it is the difference between the width of
> a space and a character/digit that causes the issue for me.  Again, this
> is minor and subjective.

Yes, with variable width fonts, different characters take up various
amount of space -- that's the point, and will have to be dealt with.

There seemed to be some claims that even totally numerical elements
(that doesn't change the number of digits) also leads to shifts that'll
have to be handled (like display-time-mode), and that just isn't lining
up with my experiences.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Juri Linkov]

>> I tried this, and the mode-line looks much nicer indeed,
>> but this improvement is unusable because the mode-line jumps
>> left and right when the buffer is saved, the cursor is moved, etc.
>
> Do you use a variable-pitch font that has different widths for the
> digits?  I didn't think that would be an issue in practice.  What font
> do you use?

I'm using DejaVu Sans, where all the digits have the same width,
but still with column-number-mode enabled, the mode-line exhibits
jumpiness when the length of the column number changes.

But maybe using monospaced fonts only on these parts of the mode-line
will fix the problem when the rest of the mode-line will use variable-pitch?

Re: How to make Emacs popular again: Use monospaced fonts less

[James Cloos]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

LI> There seemed to be some claims that even totally numerical elements
LI> (that doesn't change the number of digits) also leads to shifts that'll
LI> have to be handled (like display-time-mode), and that just isn't lining
LI> up with my experiences.

Opentype offers both fixed width and proportional digits (not to mention
oldstyle).

Some fonts default to proportinal.  Most to fixed.

DOCCIS is down now so I cannot remind myself how to ensure fixed width digits...

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: How to make Emacs popular again: Use monospaced fonts less

[tomas]

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

On Wed, Oct 14, 2020 at 04:30:48AM -0400, James Cloos wrote:
> >>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> LI> There seemed to be some claims that even totally numerical elements
> LI> (that doesn't change the number of digits) also leads to shifts that'll
> LI> have to be handled (like display-time-mode), and that just isn't lining
> LI> up with my experiences.
> 
> Opentype offers both fixed width and proportional digits (not to mention
> oldstyle).

Fixed width digits do make sense: often you want more than just aligning
a numerical "field" -- you'd like the individual digits to align. This
is an issue at least as old as Metafont (at least whithin our digital
bubble, I'm sure the lead-and-ink typesetters were well aware of that!).

Let's call those fonts the "normal" fonts (with a tip off the hat to
Russel's paradox ;-)

The question here is whether there is a space the width of a digit (for
"normal fonts", that is).

It seems Unicode has a place for that:  U+2007 aka FIGURE SPACE. Whether
those fonts implement that is left as an exercise...

Me? I use fixed fonts on-screen. Actually my eyes very much prefer them.
This might be the result of acclimatisation.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>> I tried this, and the mode-line looks much nicer indeed,
>> but this improvement is unusable because the mode-line jumps
>> left and right when the buffer is saved, the cursor is moved, etc.
> Do you use a variable-pitch font that has different widths for the digits?

The jumps come from the difference of width between the numbers and the
SPC char.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 06:01:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think if we want to keep the fields in their places, we should
> > consider the mode line to be tabular.
> 
> I don't think a tabular mode line is something that would be practical.

All the "other" apps that provide such a "status bar" do treat its
display as tabular: the positions of its parts never move.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 06:03:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >>         (setq mode-line-thing
> >> >>               `(:propertize
> >> >>                 "some-string"
> >> >>                 :min-width 15))
> 
> [...]
> 
> > Then perhaps I didn't understand your suggestion: how would the above
> > be different from what you originally had in mind about :min-width?
> 
> When rendering the mode line, Emacs knows what pixel it started the
> first glyph of each mode line element on, and it knows where it ends, so
> it sounds conceptually sound to add a :min-width spec here (since it can
> just insert some space of the required length at the end).

Yes, this can be done.  But we'd need fort to decide what is the
semantics of this:

  (setq mode-line-thing `(:propertize "%12b" :min-width 10))

IOW, when the format and :min-width contradict, who "wins"?

Or maybe we should re-purpose the WIDTH parameter of such formats to
mean "min-width"?

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 14 Oct 2020 09:53:12 +0200
> Cc: emacs-devel@gnu.org, Juri Linkov <juri@linkov.net>
> 
> Protesilaos Stavrou <info@protesilaos.com> writes:
> 
> >> I'm using DejaVu Sans, and all the digits are the same width here.
> >
> > True for DejaVu Sans.  Though it is the difference between the width of
> > a space and a character/digit that causes the issue for me.  Again, this
> > is minor and subjective.
> 
> Yes, with variable width fonts, different characters take up various
> amount of space -- that's the point, and will have to be dealt with.

I think Protesilaos means SPC the character, not "space" the screen
estate.

RE: How to make Emacs popular again: Use monospaced fonts less

[Drew Adams]

> But maybe using monospaced fonts only on these parts of the mode-line
> will fix the problem when the rest of the mode-line will use variable-
> pitch?

I'd suggest that rather than trying to do something like
that automatically (especially if done in a hard-to-disable
way), we should just try to make it easier for users to apply
a given face to specific parts of the mode-line.

Finding a good way to make that easier would also let users
do other things more easily to parts of the mode-line.

We have mode-line variables, but maybe we need another level,
that takes the string results they provide and lets you
easily apply a function to them.  We have `eval', and you
can pretty much do anything you need to do with the mode-line,
but it's not simple to do things, for most users.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> Yes, this can be done.  But we'd need fort to decide what is the
> semantics of this:
>
>   (setq mode-line-thing `(:propertize "%12b" :min-width 10))

One solution is to not use text-properties, e.g.

    (setq mode-line-format
          '(...
            (:control-width mode-line-buffer-identification
                            :min-width 10 :max-width 30)
            ...
            (:control-width mode-line-position
                            :min-width 10
                            :align 'center)
            ...))

The downside is that this will only work for <foo>-line-format, whereas
this kind of functionality would also be handy within buffer text for
tabular modes like `proced`.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 13:07:42 -0400
> 
> > Yes, this can be done.  But we'd need fort to decide what is the
> > semantics of this:
> >
> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
> 
> One solution is to not use text-properties, e.g.

That's what I suggested: to use the "12" part for that.

> The downside is that this will only work for <foo>-line-format, whereas
> this kind of functionality would also be handy within buffer text for
> tabular modes like `proced`.

Outside of the mode line, I don't know how to implement that easily,
because that would need some kind of looking-back to find where the
text property started.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>> > Yes, this can be done.  But we'd need fort to decide what is the
>> > semantics of this:
>> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>> One solution is to not use text-properties, e.g.
> That's what I suggested: to use the "12" part for that.

That would limit its applicability to to the few % escape sequences
(and would make it more difficult to provide things like centering,
min-width, max-width, ...).

>> The downside is that this will only work for <foo>-line-format, whereas
>> this kind of functionality would also be handy within buffer text for
>> tabular modes like `proced`.
> Outside of the mode line, I don't know how to implement that easily,
> because that would need some kind of looking-back to find where the
> text property started.

Indeed.  Maybe the text-property's value should include the information
of what is the "starting position".


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>> I tried this, and the mode-line looks much nicer indeed,
>>> but this improvement is unusable because the mode-line jumps
>>> left and right when the buffer is saved, the cursor is moved, etc.
>>
>> Do you use a variable-pitch font that has different widths for the
>> digits?  I didn't think that would be an issue in practice.  What font
>> do you use?
>
> I'm using DejaVu Sans, where all the digits have the same width,
> but still with column-number-mode enabled, the mode-line exhibits
> jumpiness when the length of the column number changes.

OK, so you exaggerated a bit.  :-)  Then we're on the same page. 

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, this can be done.  But we'd need fort to decide what is the
> semantics of this:
>
>   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>
> IOW, when the format and :min-width contradict, who "wins"?

I'd say %12b should win -- :min-width should be used only to add extra
padding if needed.  I think that would be pretty clear semantics...

> Or maybe we should re-purpose the WIDTH parameter of such formats to
> mean "min-width"?

Hm...  *ponder*  I think that perhaps sounds like a complicating
factor.  I mean, semantics-wise.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Yes, this can be done.  But we'd need fort to decide what is the
>> semantics of this:
>>
>>   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>
> One solution is to not use text-properties, e.g.

I wasn't really thinking that the :min-width would be translated into
text properties at all here -- it's just an instruction to the mode line
rendering machinery.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>>> Yes, this can be done.  But we'd need fort to decide what is the
>>> semantics of this:
>>>
>>>   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>>
>> One solution is to not use text-properties, e.g.
>
> I wasn't really thinking that the :min-width would be translated into
> text properties at all here -- it's just an instruction to the mode line
> rendering machinery.

I sorry, I guess I read the `:propertize` too literally.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 18:53:31 -0400
> 
> >> > Yes, this can be done.  But we'd need fort to decide what is the
> >> > semantics of this:
> >> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
> >> One solution is to not use text-properties, e.g.
> > That's what I suggested: to use the "12" part for that.
> 
> That would limit its applicability to to the few % escape sequences
> (and would make it more difficult to provide things like centering,
> min-width, max-width, ...).

We'll need to change the mode-line spec anyway, if we decide to go
this way, no matter if it's by a property or by some change in the
format specs.

The advantage of %12b and its ilk is that it solves 2 problems at the
same time: removes the potential contradiction between the width
specification in mode-line-format and this new property; and allows to
get rid of the text property, which is a certain complication.

> >> The downside is that this will only work for <foo>-line-format, whereas
> >> this kind of functionality would also be handy within buffer text for
> >> tabular modes like `proced`.
> > Outside of the mode line, I don't know how to implement that easily,
> > because that would need some kind of looking-back to find where the
> > text property started.
> 
> Indeed.  Maybe the text-property's value should include the information
> of what is the "starting position".

??? How can Lisp know that?  The starting position is needed at pixel
accuracy to be useful.  Mode-line display knows that because it keeps
the string iterator object as it goes from one mode-line element to
the next one, and the iterator object needs to keep track of the
current X coordinate.  So we can record the X coordinate we started
from when we begin to lay out each mode-line element.  But that
doesn't happen in normal text layout.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 08:48:55 +0200
> 
> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
> >
> > IOW, when the format and :min-width contradict, who "wins"?
> 
> I'd say %12b should win -- :min-width should be used only to add extra
> padding if needed.

But so is %12b, no?

> > Or maybe we should re-purpose the WIDTH parameter of such formats to
> > mean "min-width"?
> 
> Hm...  *ponder*  I think that perhaps sounds like a complicating
> factor.  I mean, semantics-wise.

I don't think I see the complications.  Can you elaborate?

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> >   (setq mode-line-thing `(:propertize "%12b" :min-width 10))
>> >
>> > IOW, when the format and :min-width contradict, who "wins"?
>> 
>> I'd say %12b should win -- :min-width should be used only to add extra
>> padding if needed.
>
> But so is %12b, no?
>
>> > Or maybe we should re-purpose the WIDTH parameter of such formats to
>> > mean "min-width"?
>> 
>> Hm...  *ponder*  I think that perhaps sounds like a complicating
>> factor.  I mean, semantics-wise.
>
> I don't think I see the complications.  Can you elaborate?

I mean, it would be complicated if we did both.  If we just extend
"%12b" to effectively be :min-width, then that'd be fine, I think.
Unless we want to do pixel-based :min-widths, but that's perhaps not so
useful...

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> The advantage of %12b and its ilk is that it solves 2 problems at the
> same time: removes the potential contradiction between the width
> specification in mode-line-format and this new property; and allows to
> get rid of the text property, which is a certain complication.

But the %12b approach doesn't let you specify a max/min width for other
elements such as `mode-line-process`, `major-mode, `minor-mode-alist`, ...

>> > Outside of the mode line, I don't know how to implement that easily,
>> > because that would need some kind of looking-back to find where the
>> > text property started.
>> Indeed.  Maybe the text-property's value should include the information
>> of what is the "starting position".
> ??? How can Lisp know that?

Oh, I see we were not talking about the same thing.
Yes, we'd need somehow to walk back the glyph structure to find the
pixel position of the start position of the element.

What I was trying to address is the issue of text properties being
potentially split, so you can't really rely on

    (put-text-property START END 'width 50)

so I was thinking of instead doing something like

    (put-text-property (1- END) END 'relative-end-position (list START 50))

so when the redisplay sees this position, it would walk back the glyphs
to find the nearest one corresponding to START, and then either truncate
the last few glyphs to fit in a width of 50, or add some space to reach
a width of 50.

Of course, on the next day someone would come along and want to use it
with START on another line with the intention to do relative
indentation ;-)

At which point we may prefer to use something like:

    (put-text-property START (1+ START) 'glyph-mark 'my-glyph-mark)
    (put-text-property (1- END) END 'relative-end-position (list 'my-glyph-mark 50))

with the redisplay keeping track somehow(!) of a set of "glyph-marks" seen
in the current window.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 16:07:36 +0200
> 
> >> > Or maybe we should re-purpose the WIDTH parameter of such formats to
> >> > mean "min-width"?
> >> 
> >> Hm...  *ponder*  I think that perhaps sounds like a complicating
> >> factor.  I mean, semantics-wise.
> >
> > I don't think I see the complications.  Can you elaborate?
> 
> I mean, it would be complicated if we did both.  If we just extend
> "%12b" to effectively be :min-width, then that'd be fine, I think.

That is what I intended to propose.

> Unless we want to do pixel-based :min-widths, but that's perhaps not so
> useful...

The idea is to interpret "12" in units of the canonical frame's
character width, and do the calculations in pixels.  I think this is
good enough, as I don't envision a need for Lisp programs to fine-tune
the position at pixel granularity.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 10:21:39 -0400
> 
> Yes, we'd need somehow to walk back the glyph structure to find the
> pixel position of the start position of the element.
> 
> What I was trying to address is the issue of text properties being
> potentially split, so you can't really rely on
> 
>     (put-text-property START END 'width 50)
> 
> so I was thinking of instead doing something like
> 
>     (put-text-property (1- END) END 'relative-end-position (list START 50))
> 
> so when the redisplay sees this position, it would walk back the glyphs
> to find the nearest one corresponding to START, and then either truncate
> the last few glyphs to fit in a width of 50, or add some space to reach
> a width of 50.

I don't think this will be much simpler than just the first method
above: the way to find where the property started is just one
previous-single-property-change call away, right?

Or we could add some new field to the iterator to keep track of the
beginning, and be done with that.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> I don't think this will be much simpler than just the first method
> above: the way to find where the property started is just one
> previous-single-property-change call away, right?

Not necessarily if the property ends up split into two (or
more) sections.

Or rather, yes that's what it would boil down to in the redisplay, but
in terms of resulting behavior we'd have bugs whenever the property span
gets split into several spans.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Or rather, yes that's what it would boil down to in the redisplay, but
> in terms of resulting behavior we'd have bugs whenever the property span
> gets split into several spans.

Yeah, :min-width as a text property thing is fraught with all kinds of
issues.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 10:48:32 -0400
> 
> > I don't think this will be much simpler than just the first method
> > above: the way to find where the property started is just one
> > previous-single-property-change call away, right?
> 
> Not necessarily if the property ends up split into two (or
> more) sections.

The function has the LIMIT argument.

> Or rather, yes that's what it would boil down to in the redisplay, but
> in terms of resulting behavior we'd have bugs whenever the property span
> gets split into several spans.

If this is a danger, then this feature is not workable at all for
buffer text.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

>> Or rather, yes that's what it would boil down to in the redisplay, but
>> in terms of resulting behavior we'd have bugs whenever the property span
>> gets split into several spans.
>
> If this is a danger, then this feature is not workable at all for
> buffer text.

That's why I was suggesting a representation where you don't put
a property on the whole span but only at the beginning and at the end.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 12:25:15 -0400
> 
> >> Or rather, yes that's what it would boil down to in the redisplay, but
> >> in terms of resulting behavior we'd have bugs whenever the property span
> >> gets split into several spans.
> >
> > If this is a danger, then this feature is not workable at all for
> > buffer text.
> 
> That's why I was suggesting a representation where you don't put
> a property on the whole span but only at the beginning and at the end.

That's not the difficulty I had in mind, so your suggestion doesn't
clear the path towards a solution.

The problem is that if the run of text which needs to be "padded" this
way can be split between lines, the problem becomes undefined.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Monnier]

> The problem is that if the run of text which needs to be "padded" this
> way can be split between lines, the problem becomes undefined.

I think we could give it a well-defined meaning.  E.g.

    (put-text-property (1- END) END 'relative-end-position (list START 50))

could mean something like "make sure that END ends up exactly 50 pixels
more to the right than the horizontal pixel position of START".

This way, it could be used for indentation relative to some position
START in some previous line.

Sadly, this email format does not include any notion of margin, so
I can't include the simple&elegant implementation of that feature here.


        Stefan

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 15 Oct 2020 14:31:43 -0400
> 
>     (put-text-property (1- END) END 'relative-end-position (list START 50))
> 
> could mean something like "make sure that END ends up exactly 50 pixels
> more to the right than the horizontal pixel position of START".
> 
> This way, it could be used for indentation relative to some position
> START in some previous line.

So you now expect the display engine to look back at previous lines,
not just previous glyphs on the same screen line?  That's against the
heart of the design of the display code: it is required to be able to
start at any point in the buffer text, and go from there forward one
buffer position at a time.  The need to go back sometimes is one
reason why displaying long lines brings Emacs to its knees.

> Sadly, this email format does not include any notion of margin, so
> I can't include the simple&elegant implementation of that feature here.

Looking forward to seeing that implementation soon in a Git repository
near me.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The idea is to interpret "12" in units of the canonical frame's
> character width, and do the calculations in pixels.  I think this is
> good enough, as I don't envision a need for Lisp programs to fine-tune
> the position at pixel granularity.

Yeah, that probably wouldn't be very useful.  So the %12b thing sound
good to me.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Juri Linkov]

>> Could you try to make proced work with a variable pitch header-line?  I
>> tried and failed (bug#1779).
>
> Done.  The right-alignment is still fairly ugly, of course.

Trying to click on the proced header line sometimes sorts a wrong column.

Comparing 'proced-sort-header' with 'tabulated-list-col-sort' shows
that the latter uses '(cdr posn-object)' to get the clicked column,
whereas 'proced' uses more complex logic with 'posn-actual-col-row'
that fails to get the correct aligned column.

This begs the question why proced doesn't use 'tabulated-list-mode'?
Maybe there are some features in proced that are not yet supported
by tabulated-list?

Re: How to make Emacs popular again: Use monospaced fonts less

[Stephen Berman]

On Wed, 02 Dec 2020 23:06:37 +0200 Juri Linkov <juri@linkov.net> wrote:

>>> Could you try to make proced work with a variable pitch header-line?  I
>>> tried and failed (bug#1779).
>>
>> Done.  The right-alignment is still fairly ugly, of course.
>
> Trying to click on the proced header line sometimes sorts a wrong column.
>
> Comparing 'proced-sort-header' with 'tabulated-list-col-sort' shows
> that the latter uses '(cdr posn-object)' to get the clicked column,
> whereas 'proced' uses more complex logic with 'posn-actual-col-row'
> that fails to get the correct aligned column.
>
> This begs the question why proced doesn't use 'tabulated-list-mode'?
> Maybe there are some features in proced that are not yet supported
> by tabulated-list?

This question came up in bug#1779
<20008.59545.186131.208473@gargle.gargle.HOWL>:

From: "Roland Winkler" <winkler@gnu.org>
Subject: Re: bug#1779: 23.0.60; proced with variable-pitch header line
  To: Chong Yidong <cyd@stupidchicken.com>
  Cc: Stephen Berman <stephen.berman@gmx.net>, 1779@debbugs.gnu.org
  Date: Thu, 21 Jul 2011 22:03:53 -0500

  On Thu Jul 21 2011 Chong Yidong wrote:
  > AFAICT, the alignment issue does not occur in Tabulated List mode, which
  > uses :align-to.  In the short run, you might be able to get a clue about
  > the correct fix from there.  In the long run, I think proced.el should
  > be reworked to use Tabulated List mode.

  Thanks, I'll have to find out what Tabulated List mode is doing.
  I am just wondering: In general, proced was much inspired by dired.
  Would you suggest that dired should likewise use Tabulated List mode?

Maybe Roland (added to CC) can weigh in again.

Steve Berman

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 02 Dec 2020 23:06:37 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Stephen Berman <stephen.berman@gmx.net>,
>  Andreas Schwab <schwab@linux-m68k.org>, emacs-devel@gnu.org
> 
> >> Could you try to make proced work with a variable pitch header-line?  I
> >> tried and failed (bug#1779).
> >
> > Done.  The right-alignment is still fairly ugly, of course.
> 
> Trying to click on the proced header line sometimes sorts a wrong column.
> 
> Comparing 'proced-sort-header' with 'tabulated-list-col-sort' shows
> that the latter uses '(cdr posn-object)' to get the clicked column,
> whereas 'proced' uses more complex logic with 'posn-actual-col-row'
> that fails to get the correct aligned column.

Then it's a bug that needs to be fixed, IMO.

Re: How to make Emacs popular again: Use monospaced fonts less

[Juri Linkov]

>> This begs the question why proced doesn't use 'tabulated-list-mode'?
>> Maybe there are some features in proced that are not yet supported
>> by tabulated-list?
>
> This question came up in bug#1779
> <20008.59545.186131.208473@gargle.gargle.HOWL>:
>
> From: "Roland Winkler" <winkler@gnu.org>
> Subject: Re: bug#1779: 23.0.60; proced with variable-pitch header line
>   To: Chong Yidong <cyd@stupidchicken.com>
>   Cc: Stephen Berman <stephen.berman@gmx.net>, 1779@debbugs.gnu.org
>   Date: Thu, 21 Jul 2011 22:03:53 -0500
>
>   On Thu Jul 21 2011 Chong Yidong wrote:
>   > AFAICT, the alignment issue does not occur in Tabulated List mode, which
>   > uses :align-to.  In the short run, you might be able to get a clue about
>   > the correct fix from there.  In the long run, I think proced.el should
>   > be reworked to use Tabulated List mode.
>
>   Thanks, I'll have to find out what Tabulated List mode is doing.
>   I am just wondering: In general, proced was much inspired by dired.
>   Would you suggest that dired should likewise use Tabulated List mode?

IMHO, the difference is that dired is based on the output from external
programs inserted to the buffer as is, whereas proced has an internal
list data that can be provided to tabulated-list.

Re: How to make Emacs popular again: Use monospaced fonts less

[Roland Winkler]

On Wed Dec 2 2020 Stephen Berman wrote:
>   On Thu Jul 21 2011 Chong Yidong wrote:
>   > AFAICT, the alignment issue does not occur in Tabulated List mode, which
>   > uses :align-to.  In the short run, you might be able to get a clue about
>   > the correct fix from there.  In the long run, I think proced.el should
>   > be reworked to use Tabulated List mode.
> 
>   Thanks, I'll have to find out what Tabulated List mode is doing.
>   I am just wondering: In general, proced was much inspired by dired.
>   Would you suggest that dired should likewise use Tabulated List mode?
> 
> Maybe Roland (added to CC) can weigh in again.

I am sorry, there is not much I can contribute to this discussion.
I developed proced in 2008 when, I believe, tabulated list mode did
not yet exist.  In general, I am much in favor of not re-inventing
the wheel.  So even if tabulated list mode cannot yet provide all
the functionality that is useful for proced, it is probably better
if this is provided only once in tabulated list mode, and packages
like proced use it.  I will not miss the handcrafted solutions in
proced.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> One of the reasons Emacs looks kinda old-fashioned is that we use
> monospaced fonts all over the place.  Now, when programming and stuff, a
> monospaced font is preferred, but in other contexts, it looks pretty
> old-fashioned.
>
> So here's my most controversial suggestion ever:
>
> diff --git a/lisp/faces.el b/lisp/faces.el
> index 5b7e0a5aee..e6f65a5901 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2553,6 +2553,7 @@ mode-line-faces
>  (defface mode-line
>    '((((class color) (min-colors 88))
>       :box (:line-width -1 :style released-button)
> +     :inherit variable-pitch
>       :background "grey75" :foreground "black")
>      (t
>       :inverse-video t))
>
> In addition to looking nicer, it means we can fit more data into the
> mode line.

What happened to this?

I have noticed that the modus themes has the option
`modus-themes-variable-pitch-ui':

    Use proportional fonts (variable-pitch) in UI elements.
    This includes the mode line, header line, tab bar, and tab line.

It is useful if one wants to experiment with how this works in
practice.  Just set it to t and `M-x load-theme RET modus-operandi RET'.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> What happened to this?

I think we wanted to introduce mode line constructs to ensure a minimum
width to elements (like "L13") for those that want that, and somehow
have variable pitch fonts that have numbers of unequal width (uncommon
as those fonts are).

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think we wanted to introduce mode line constructs to ensure a minimum
> width to elements (like "L13") for those that want that, and somehow
> have variable pitch fonts that have numbers of unequal width (uncommon
> as those fonts are).

How about installing the attached for the `header-line' face while we
work on sorting out all that?

AFAICT, tabulation already works there (e.g. `tabulated-list-mode'), and
it would allow us to give this some testing before Emacs 28.

[-- Attachment #2: 0001-lisp-faces.el-header-line-Inherit-variable-pitch.patch --]
[-- Type: text/x-diff, Size: 864 bytes --]

From b0a6eb47a30843d66012ee99a2449b935a732ba7 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Mon, 12 Apr 2021 15:08:45 +0200
Subject: [PATCH] * lisp/faces.el (header-line): Inherit variable-pitch.

---
 lisp/faces.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/faces.el b/lisp/faces.el
index 42f4cddfb1..d120852418 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2613,7 +2613,9 @@ mode-line-buffer-id
 
 (defface header-line
   '((default
-     :inherit mode-line)
+      ;; FIXME: This can be changed to inherit only `mode-line' once
+      ;;        that face inherits variable-pitch.
+      :inherit (variable-pitch mode-line))
     (((type tty))
      ;; This used to be `:inverse-video t', but that doesn't look very
      ;; good when combined with inverse-video mode-lines and multiple
-- 
2.30.2

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 12 Apr 2021 08:23:19 -0500
> Cc: emacs-devel@gnu.org
> 
> How about installing the attached for the `header-line' face while we
> work on sorting out all that?

That's an incompatible change, in that it will cause header-line not
necessarily follow mode-line.  Right?

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> That's an incompatible change, in that it will cause header-line not
> necessarily follow mode-line.  Right?

We could do this instead; the effect is the same in emacs -Q:

diff --git a/lisp/faces.el b/lisp/faces.el
index d120852418..c7d9b48d2d 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2615,7 +2615,7 @@ header-line
   '((default
       ;; FIXME: This can be changed to inherit only `mode-line' once
       ;;        that face inherits variable-pitch.
-      :inherit (variable-pitch mode-line))
+      :inherit (mode-line variable-pitch))
     (((type tty))
      ;; This used to be `:inverse-video t', but that doesn't look very
      ;; good when combined with inverse-video mode-lines and multiple

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 12 Apr 2021 10:27:23 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's an incompatible change, in that it will cause header-line not
> > necessarily follow mode-line.  Right?
> 
> We could do this instead; the effect is the same in emacs -Q:
> 
> diff --git a/lisp/faces.el b/lisp/faces.el
> index d120852418..c7d9b48d2d 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2615,7 +2615,7 @@ header-line
>    '((default
>        ;; FIXME: This can be changed to inherit only `mode-line' once
>        ;;        that face inherits variable-pitch.
> -      :inherit (variable-pitch mode-line))
> +      :inherit (mode-line variable-pitch))

I don't see how that is different.

My problem is that this change makes header-line different from
mode-line, which I think is undesirable.

Re: How to make Emacs popular again: Use monospaced fonts less

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> diff --git a/lisp/faces.el b/lisp/faces.el
>> index d120852418..c7d9b48d2d 100644
>> --- a/lisp/faces.el
>> +++ b/lisp/faces.el
>> @@ -2615,7 +2615,7 @@ header-line
>>    '((default
>>        ;; FIXME: This can be changed to inherit only `mode-line' once
>>        ;;        that face inherits variable-pitch.
>> -      :inherit (variable-pitch mode-line))
>> +      :inherit (mode-line variable-pitch))
>
> I don't see how that is different.

If a list of faces is used, attributes from faces earlier in the list
override those from later faces.

> My problem is that this change makes header-line different from
> mode-line, which I think is undesirable.

Oh, okay.  Yes, that would be the drawback.

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 12 Apr 2021 12:29:40 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> > My problem is that this change makes header-line different from
> > mode-line, which I think is undesirable.
> 
> Oh, okay.  Yes, that would be the drawback.

Which is why I prefer that we change the mode-line face (if we thing
using variable-pitch there is a good move), and leave header-line
inheriting from mode-line as before.  Then (a) mode line and header
line will look the same by default, and (b) if someone wants a
different face for both, they just need to change a single face, not 2
of them.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Which is why I prefer that we change the mode-line face (if we thing
> using variable-pitch there is a good move), and leave header-line
> inheriting from mode-line as before.  Then (a) mode line and header
> line will look the same by default, and (b) if someone wants a
> different face for both, they just need to change a single face, not 2
> of them.

Yup; I agree.

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Robert Weiner]

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

On Sun, Oct 11, 2020 at 1:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Other obvious candidates for variable-pitching are basically any mode
> that displays data in tabular form.  And, of course, the manuals, but
> that'll happen by itself once we move from .info to .html.
>

Is this a serious statement?  Please don't do that.  I can browse an entire
Info manual easily inside Emacs nicely by pressing the spacebar and delete
only.  I can search entire manuals quickly and move across manuals easily.

Of course, it would be fine to additionally output html format for web
viewing since the Texinfo/Makeinfo package already supports that.

Old fashioned sometimes is better.  If only Scribe had survived, millions
of hours would not have been lost in Word and LaTeX formatting and now the
minimalist Markdown to get worse results.

-- Bob

[-- Attachment #2: Type: text/html, Size: 1781 bytes --]

Re: How to make Emacs popular again: Use monospaced fonts less

[tomas]

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

On Sun, Apr 18, 2021 at 11:13:49PM -0400, Robert Weiner wrote:
> On Sun, Oct 11, 2020 at 1:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> > Other obvious candidates for variable-pitching are basically any mode
> > that displays data in tabular form.  And, of course, the manuals, but
> > that'll happen by itself once we move from .info to .html.
> >
> 
> Is this a serious statement?  Please don't do that.  I can browse an entire
> Info manual easily inside Emacs nicely by pressing the spacebar and delete
> only.  I can search entire manuals quickly and move across manuals easily.
> 
> Of course, it would be fine to additionally output html format for web
> viewing since the Texinfo/Makeinfo package already supports that.

Seconded. HTML is (more of) a rendering format. Info is more of a
document structure format. Rendering info to HTML would make sense
for display (for those who enjoy viewing things in the browser).
The other way around... not so much.

I know that this taxonomy is fluid (what is "more" rendering: PS or
PDF? What about SVG?), but I think that most would agree that HTML
is more on the "rendering" side than info.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: How to make Emacs popular again: Use monospaced fonts less

[Kévin Le Gouguec]

Robert Weiner <rsw@gnu.org> writes:

> On Sun, Oct 11, 2020 at 1:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>  Other obvious candidates for variable-pitching are basically any mode
>  that displays data in tabular form.  And, of course, the manuals, but
>  that'll happen by itself once we move from .info to .html.
>
> Is this a serious statement?  Please don't do that.  I can browse an entire Info manual easily inside Emacs nicely by pressing the spacebar and delete only.  I can
> search entire manuals quickly and move across manuals easily.

(Jumping in without having read the whole thread; my apologies if my
reply misses the mark)

FWIW, Emacs's web browser (M-x eww), just like most read-only modes,
supports SPC and DEL for forward and backward page navigation.

Whatever this hypothetical move from .info to .html entails (I don't
think we have seen patches for that yet), I expect the maintainers'
vision is to keep feature parity with the current Info browser, with all
its indexing and searching convenience; I don't think there should be
cause for alarm.

Re: How to make Emacs popular again: Use monospaced fonts less

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Whatever this hypothetical move from .info to .html entails (I don't
> think we have seen patches for that yet), I expect the maintainers'
> vision is to keep feature parity with the current Info browser, with all
> its indexing and searching convenience; I don't think there should be
> cause for alarm.

Indeed.  I don't think casual users will notice the change from .info to
.html much at all (except getting better rendering).

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

Re: How to make Emacs popular again: Use monospaced fonts less

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Mon, 19 Apr 2021 09:55:29 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, rswgnu@gmail.com,
>  emacs-devel <emacs-devel@gnu.org>
> 
> Robert Weiner <rsw@gnu.org> writes:
> 
> > On Sun, Oct 11, 2020 at 1:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> >
> >  Other obvious candidates for variable-pitching are basically any mode
> >  that displays data in tabular form.  And, of course, the manuals, but
> >  that'll happen by itself once we move from .info to .html.
> >
> > Is this a serious statement?  Please don't do that.  I can browse an entire Info manual easily inside Emacs nicely by pressing the spacebar and delete only.  I can
> > search entire manuals quickly and move across manuals easily.
> 
> (Jumping in without having read the whole thread; my apologies if my
> reply misses the mark)
> 
> FWIW, Emacs's web browser (M-x eww), just like most read-only modes,
> supports SPC and DEL for forward and backward page navigation.
> 
> Whatever this hypothetical move from .info to .html entails (I don't
> think we have seen patches for that yet), I expect the maintainers'
> vision is to keep feature parity with the current Info browser, with all
> its indexing and searching convenience; I don't think there should be
> cause for alarm.

I think this sub-thread is based on a misunderstanding.  I think Lars
alluded to the on-going development in the Texinfo quarters, whereby
the goal is to have HTML-based format "on steroids", which will allow
to browse GNU manuals with capable browsers without losing any
functionality we have now in the text-based Info readers.  No one
intends to lose any useful Info features; when the Texinfo developers
are done designing and implementing this, Emacs should examine the
results and see how best to support that.

People who are interested in details should go and read the archives
of bug-texinfo@gnu.org for the past year or so.