* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 5:37 ` How to make Emacs popular again: Use monospaced fonts less Lars Ingebrigtsen
@ 2020-10-11 6:28 ` Eli Zaretskii
2020-10-11 6:35 ` Lars Ingebrigtsen
2020-10-11 13:21 ` Stefan Monnier
2020-10-11 14:35 ` Teemu Likonen
` (5 subsequent siblings)
6 siblings, 2 replies; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-11 6:28 UTC (permalink / raw)
To: emacs-devel, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 6:28 ` Eli Zaretskii
@ 2020-10-11 6:35 ` Lars Ingebrigtsen
2020-10-11 7:00 ` Eli Zaretskii
2020-10-11 13:21 ` Stefan Monnier
1 sibling, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-11 6:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 6:35 ` Lars Ingebrigtsen
@ 2020-10-11 7:00 ` Eli Zaretskii
2020-10-11 10:54 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-11 7:00 UTC (permalink / raw)
To: emacs-devel, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 7:00 ` Eli Zaretskii
@ 2020-10-11 10:54 ` Lars Ingebrigtsen
2020-10-11 11:28 ` Lars Ingebrigtsen
2020-10-11 13:56 ` Eli Zaretskii
0 siblings, 2 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-11 10:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 10:54 ` Lars Ingebrigtsen
@ 2020-10-11 11:28 ` Lars Ingebrigtsen
2020-10-11 13:58 ` Eli Zaretskii
2020-10-11 13:56 ` Eli Zaretskii
1 sibling, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-11 11:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 11:28 ` Lars Ingebrigtsen
@ 2020-10-11 13:58 ` Eli Zaretskii
2020-10-11 22:21 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-11 13:58 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 13:58 ` Eli Zaretskii
@ 2020-10-11 22:21 ` Lars Ingebrigtsen
2020-10-12 16:49 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-11 22:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 22:21 ` Lars Ingebrigtsen
@ 2020-10-12 16:49 ` Eli Zaretskii
2020-10-13 0:38 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-12 16:49 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-12 16:49 ` Eli Zaretskii
@ 2020-10-13 0:38 ` Lars Ingebrigtsen
2020-10-13 14:40 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-13 0:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-13 0:38 ` Lars Ingebrigtsen
@ 2020-10-13 14:40 ` Eli Zaretskii
2020-10-14 4:03 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-13 14:40 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-13 14:40 ` Eli Zaretskii
@ 2020-10-14 4:03 ` Lars Ingebrigtsen
2020-10-14 14:54 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-14 4:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 4:03 ` Lars Ingebrigtsen
@ 2020-10-14 14:54 ` Eli Zaretskii
2020-10-14 17:07 ` Stefan Monnier
2020-10-15 6:48 ` Lars Ingebrigtsen
0 siblings, 2 replies; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-14 14:54 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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"?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 14:54 ` Eli Zaretskii
@ 2020-10-14 17:07 ` Stefan Monnier
2020-10-14 17:39 ` Eli Zaretskii
2020-10-15 6:51 ` Lars Ingebrigtsen
2020-10-15 6:48 ` Lars Ingebrigtsen
1 sibling, 2 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-14 17:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, emacs-devel
> 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 17:07 ` Stefan Monnier
@ 2020-10-14 17:39 ` Eli Zaretskii
2020-10-14 22:53 ` Stefan Monnier
2020-10-15 6:51 ` Lars Ingebrigtsen
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-14 17:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 17:39 ` Eli Zaretskii
@ 2020-10-14 22:53 ` Stefan Monnier
2020-10-15 13:57 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Stefan Monnier @ 2020-10-14 22:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, emacs-devel
>> > 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 22:53 ` Stefan Monnier
@ 2020-10-15 13:57 ` Eli Zaretskii
2020-10-15 14:21 ` Stefan Monnier
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-15 13:57 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 13:57 ` Eli Zaretskii
@ 2020-10-15 14:21 ` Stefan Monnier
2020-10-15 14:28 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Stefan Monnier @ 2020-10-15 14:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, emacs-devel
> 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 14:21 ` Stefan Monnier
@ 2020-10-15 14:28 ` Eli Zaretskii
2020-10-15 14:48 ` Stefan Monnier
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-15 14:28 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 14:28 ` Eli Zaretskii
@ 2020-10-15 14:48 ` Stefan Monnier
2020-10-15 14:52 ` Lars Ingebrigtsen
2020-10-15 15:00 ` Eli Zaretskii
0 siblings, 2 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-15 14:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, emacs-devel
> 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 14:48 ` Stefan Monnier
@ 2020-10-15 14:52 ` Lars Ingebrigtsen
2020-10-15 15:00 ` Eli Zaretskii
1 sibling, 0 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-15 14:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 14:48 ` Stefan Monnier
2020-10-15 14:52 ` Lars Ingebrigtsen
@ 2020-10-15 15:00 ` Eli Zaretskii
2020-10-15 16:25 ` Stefan Monnier
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-15 15:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 15:00 ` Eli Zaretskii
@ 2020-10-15 16:25 ` Stefan Monnier
2020-10-15 16:50 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Stefan Monnier @ 2020-10-15 16:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 16:25 ` Stefan Monnier
@ 2020-10-15 16:50 ` Eli Zaretskii
2020-10-15 18:31 ` Stefan Monnier
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-15 16:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 16:50 ` Eli Zaretskii
@ 2020-10-15 18:31 ` Stefan Monnier
2020-10-15 18:49 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Stefan Monnier @ 2020-10-15 18:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, emacs-devel
> 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 18:31 ` Stefan Monnier
@ 2020-10-15 18:49 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-15 18:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 17:07 ` Stefan Monnier
2020-10-14 17:39 ` Eli Zaretskii
@ 2020-10-15 6:51 ` Lars Ingebrigtsen
2020-10-15 12:26 ` Stefan Monnier
1 sibling, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-15 6:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 6:51 ` Lars Ingebrigtsen
@ 2020-10-15 12:26 ` Stefan Monnier
0 siblings, 0 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-15 12:26 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 14:54 ` Eli Zaretskii
2020-10-14 17:07 ` Stefan Monnier
@ 2020-10-15 6:48 ` Lars Ingebrigtsen
2020-10-15 14:02 ` Eli Zaretskii
1 sibling, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-15 6:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 6:48 ` Lars Ingebrigtsen
@ 2020-10-15 14:02 ` Eli Zaretskii
2020-10-15 14:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-15 14:02 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 14:02 ` Eli Zaretskii
@ 2020-10-15 14:07 ` Lars Ingebrigtsen
2020-10-15 14:24 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-15 14:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 14:07 ` Lars Ingebrigtsen
@ 2020-10-15 14:24 ` Eli Zaretskii
2020-10-16 5:06 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-15 14:24 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-15 14:24 ` Eli Zaretskii
@ 2020-10-16 5:06 ` Lars Ingebrigtsen
0 siblings, 0 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-16 5:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 10:54 ` Lars Ingebrigtsen
2020-10-11 11:28 ` Lars Ingebrigtsen
@ 2020-10-11 13:56 ` Eli Zaretskii
2020-10-11 22:14 ` Lars Ingebrigtsen
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-11 13:56 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 13:56 ` Eli Zaretskii
@ 2020-10-11 22:14 ` Lars Ingebrigtsen
2020-10-11 23:39 ` Drew Adams
2020-10-12 16:46 ` Eli Zaretskii
0 siblings, 2 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-11 22:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* RE: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 22:14 ` Lars Ingebrigtsen
@ 2020-10-11 23:39 ` Drew Adams
2020-10-12 16:46 ` Eli Zaretskii
1 sibling, 0 replies; 97+ messages in thread
From: Drew Adams @ 2020-10-11 23:39 UTC (permalink / raw)
To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: emacs-devel
> > 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. ;-)
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 22:14 ` Lars Ingebrigtsen
2020-10-11 23:39 ` Drew Adams
@ 2020-10-12 16:46 ` Eli Zaretskii
2020-10-13 0:35 ` Lars Ingebrigtsen
1 sibling, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-12 16:46 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-12 16:46 ` Eli Zaretskii
@ 2020-10-13 0:35 ` Lars Ingebrigtsen
2020-10-13 14:39 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-13 0:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-13 0:35 ` Lars Ingebrigtsen
@ 2020-10-13 14:39 ` Eli Zaretskii
2020-10-14 4:01 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-13 14:39 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 6:28 ` Eli Zaretskii
2020-10-11 6:35 ` Lars Ingebrigtsen
@ 2020-10-11 13:21 ` Stefan Monnier
2020-10-11 14:02 ` Eli Zaretskii
1 sibling, 1 reply; 97+ messages in thread
From: Stefan Monnier @ 2020-10-11 13:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, emacs-devel
>> (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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 13:21 ` Stefan Monnier
@ 2020-10-11 14:02 ` Eli Zaretskii
0 siblings, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-11 14:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 5:37 ` How to make Emacs popular again: Use monospaced fonts less Lars Ingebrigtsen
2020-10-11 6:28 ` Eli Zaretskii
@ 2020-10-11 14:35 ` Teemu Likonen
2020-10-11 15:21 ` Andreas Schwab
` (4 subsequent siblings)
6 siblings, 0 replies; 97+ messages in thread
From: Teemu Likonen @ 2020-10-11 14:35 UTC (permalink / raw)
To: Lars Ingebrigtsen, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 5:37 ` How to make Emacs popular again: Use monospaced fonts less Lars Ingebrigtsen
2020-10-11 6:28 ` Eli Zaretskii
2020-10-11 14:35 ` Teemu Likonen
@ 2020-10-11 15:21 ` Andreas Schwab
2020-10-11 18:29 ` Stefan Monnier
2020-10-12 11:24 ` Ricardo Wurmus
` (3 subsequent siblings)
6 siblings, 1 reply; 97+ messages in thread
From: Andreas Schwab @ 2020-10-11 15:21 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 15:21 ` Andreas Schwab
@ 2020-10-11 18:29 ` Stefan Monnier
2020-10-11 18:58 ` Andreas Schwab
` (4 more replies)
0 siblings, 5 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-11 18:29 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Lars Ingebrigtsen, emacs-devel
> 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 18:29 ` Stefan Monnier
@ 2020-10-11 18:58 ` Andreas Schwab
2020-10-11 19:41 ` Stefan Monnier
2020-10-11 19:42 ` Drew Adams
` (3 subsequent siblings)
4 siblings, 1 reply; 97+ messages in thread
From: Andreas Schwab @ 2020-10-11 18:58 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel
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."
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 18:58 ` Andreas Schwab
@ 2020-10-11 19:41 ` Stefan Monnier
0 siblings, 0 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-11 19:41 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Lars Ingebrigtsen, emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 97+ messages in thread
* RE: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 18:29 ` Stefan Monnier
2020-10-11 18:58 ` Andreas Schwab
@ 2020-10-11 19:42 ` Drew Adams
2020-10-11 19:56 ` Stephen Berman
` (2 subsequent siblings)
4 siblings, 0 replies; 97+ messages in thread
From: Drew Adams @ 2020-10-11 19:42 UTC (permalink / raw)
To: Stefan Monnier, Andreas Schwab; +Cc: Lars Ingebrigtsen, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 18:29 ` Stefan Monnier
2020-10-11 18:58 ` Andreas Schwab
2020-10-11 19:42 ` Drew Adams
@ 2020-10-11 19:56 ` Stephen Berman
2020-10-11 21:09 ` Stefan Monnier
2020-10-11 22:23 ` Stefan Monnier
2020-10-12 9:47 ` Andreas Schwab
2020-10-12 11:17 ` Ricardo Wurmus
4 siblings, 2 replies; 97+ messages in thread
From: Stephen Berman @ 2020-10-11 19:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, Andreas Schwab, emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 19:56 ` Stephen Berman
@ 2020-10-11 21:09 ` Stefan Monnier
2020-10-11 22:23 ` Stefan Monnier
1 sibling, 0 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-11 21:09 UTC (permalink / raw)
To: Stephen Berman; +Cc: Lars Ingebrigtsen, Andreas Schwab, emacs-devel
> 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 19:56 ` Stephen Berman
2020-10-11 21:09 ` Stefan Monnier
@ 2020-10-11 22:23 ` Stefan Monnier
2020-10-11 22:50 ` Stephen Berman
2020-12-02 21:06 ` Juri Linkov
1 sibling, 2 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-11 22:23 UTC (permalink / raw)
To: Stephen Berman; +Cc: Lars Ingebrigtsen, Andreas Schwab, emacs-devel
> 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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 22:23 ` Stefan Monnier
@ 2020-10-11 22:50 ` Stephen Berman
2020-12-02 21:06 ` Juri Linkov
1 sibling, 0 replies; 97+ messages in thread
From: Stephen Berman @ 2020-10-11 22:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, Andreas Schwab, emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 22:23 ` Stefan Monnier
2020-10-11 22:50 ` Stephen Berman
@ 2020-12-02 21:06 ` Juri Linkov
2020-12-02 22:33 ` Stephen Berman
2020-12-03 14:48 ` Eli Zaretskii
1 sibling, 2 replies; 97+ messages in thread
From: Juri Linkov @ 2020-12-02 21:06 UTC (permalink / raw)
To: Stefan Monnier
Cc: Lars Ingebrigtsen, Stephen Berman, Andreas Schwab, emacs-devel
>> 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?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-12-02 21:06 ` Juri Linkov
@ 2020-12-02 22:33 ` Stephen Berman
2020-12-03 21:05 ` Juri Linkov
2020-12-03 21:06 ` Roland Winkler
2020-12-03 14:48 ` Eli Zaretskii
1 sibling, 2 replies; 97+ messages in thread
From: Stephen Berman @ 2020-12-02 22:33 UTC (permalink / raw)
To: Juri Linkov
Cc: Roland Winkler, emacs-devel, Andreas Schwab, Stefan Monnier,
Lars Ingebrigtsen, 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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-12-02 22:33 ` Stephen Berman
@ 2020-12-03 21:05 ` Juri Linkov
2020-12-03 21:06 ` Roland Winkler
1 sibling, 0 replies; 97+ messages in thread
From: Juri Linkov @ 2020-12-03 21:05 UTC (permalink / raw)
To: Stephen Berman
Cc: Lars Ingebrigtsen, Roland Winkler, Andreas Schwab, Stefan Monnier,
emacs-devel
>> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-12-02 22:33 ` Stephen Berman
2020-12-03 21:05 ` Juri Linkov
@ 2020-12-03 21:06 ` Roland Winkler
1 sibling, 0 replies; 97+ messages in thread
From: Roland Winkler @ 2020-12-03 21:06 UTC (permalink / raw)
To: Stephen Berman
Cc: Lars Ingebrigtsen, emacs-devel, Andreas Schwab, Stefan Monnier,
Juri Linkov
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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-12-02 21:06 ` Juri Linkov
2020-12-02 22:33 ` Stephen Berman
@ 2020-12-03 14:48 ` Eli Zaretskii
1 sibling, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2020-12-03 14:48 UTC (permalink / raw)
To: Juri Linkov; +Cc: larsi, stephen.berman, schwab, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 18:29 ` Stefan Monnier
` (2 preceding siblings ...)
2020-10-11 19:56 ` Stephen Berman
@ 2020-10-12 9:47 ` Andreas Schwab
2020-10-12 11:17 ` Ricardo Wurmus
4 siblings, 0 replies; 97+ messages in thread
From: Andreas Schwab @ 2020-10-12 9:47 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel
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."
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 18:29 ` Stefan Monnier
` (3 preceding siblings ...)
2020-10-12 9:47 ` Andreas Schwab
@ 2020-10-12 11:17 ` Ricardo Wurmus
2020-10-12 17:24 ` Stefan Monnier
4 siblings, 1 reply; 97+ messages in thread
From: Ricardo Wurmus @ 2020-10-12 11:17 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, Andreas Schwab, emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-12 11:17 ` Ricardo Wurmus
@ 2020-10-12 17:24 ` Stefan Monnier
0 siblings, 0 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-12 17:24 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Lars Ingebrigtsen, Andreas Schwab, emacs-devel
> 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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 5:37 ` How to make Emacs popular again: Use monospaced fonts less Lars Ingebrigtsen
` (2 preceding siblings ...)
2020-10-11 15:21 ` Andreas Schwab
@ 2020-10-12 11:24 ` Ricardo Wurmus
2020-10-12 16:30 ` Drew Adams
2020-10-13 0:34 ` Lars Ingebrigtsen
2020-10-13 20:00 ` Juri Linkov
` (2 subsequent siblings)
6 siblings, 2 replies; 97+ messages in thread
From: Ricardo Wurmus @ 2020-10-12 11:24 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread* RE: How to make Emacs popular again: Use monospaced fonts less
2020-10-12 11:24 ` Ricardo Wurmus
@ 2020-10-12 16:30 ` Drew Adams
2020-10-12 23:02 ` Tim Cross
2020-10-13 0:34 ` Lars Ingebrigtsen
1 sibling, 1 reply; 97+ messages in thread
From: Drew Adams @ 2020-10-12 16:30 UTC (permalink / raw)
To: Ricardo Wurmus, Lars Ingebrigtsen; +Cc: emacs-devel
> 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).
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-12 16:30 ` Drew Adams
@ 2020-10-12 23:02 ` Tim Cross
0 siblings, 0 replies; 97+ messages in thread
From: Tim Cross @ 2020-10-12 23:02 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-12 11:24 ` Ricardo Wurmus
2020-10-12 16:30 ` Drew Adams
@ 2020-10-13 0:34 ` Lars Ingebrigtsen
2020-10-13 6:02 ` Ricardo Wurmus
1 sibling, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-13 0:34 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-13 0:34 ` Lars Ingebrigtsen
@ 2020-10-13 6:02 ` Ricardo Wurmus
0 siblings, 0 replies; 97+ messages in thread
From: Ricardo Wurmus @ 2020-10-13 6:02 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 5:37 ` How to make Emacs popular again: Use monospaced fonts less Lars Ingebrigtsen
` (3 preceding siblings ...)
2020-10-12 11:24 ` Ricardo Wurmus
@ 2020-10-13 20:00 ` Juri Linkov
2020-10-13 20:36 ` Drew Adams
2020-10-14 4:05 ` Lars Ingebrigtsen
2021-04-12 2:19 ` Stefan Kangas
2021-04-19 3:13 ` Robert Weiner
6 siblings, 2 replies; 97+ messages in thread
From: Juri Linkov @ 2020-10-13 20:00 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
> 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…)
^ permalink raw reply [flat|nested] 97+ messages in thread* RE: How to make Emacs popular again: Use monospaced fonts less
2020-10-13 20:00 ` Juri Linkov
@ 2020-10-13 20:36 ` Drew Adams
2020-10-14 4:05 ` Lars Ingebrigtsen
1 sibling, 0 replies; 97+ messages in thread
From: Drew Adams @ 2020-10-13 20:36 UTC (permalink / raw)
To: Juri Linkov, Lars Ingebrigtsen; +Cc: emacs-devel
> 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'.)
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-13 20:00 ` Juri Linkov
2020-10-13 20:36 ` Drew Adams
@ 2020-10-14 4:05 ` Lars Ingebrigtsen
2020-10-14 7:06 ` Protesilaos Stavrou
` (2 more replies)
1 sibling, 3 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-14 4:05 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 4:05 ` Lars Ingebrigtsen
@ 2020-10-14 7:06 ` Protesilaos Stavrou
2020-10-14 7:09 ` Lars Ingebrigtsen
2020-10-14 8:03 ` Juri Linkov
2020-10-14 13:21 ` Stefan Monnier
2 siblings, 1 reply; 97+ messages in thread
From: Protesilaos Stavrou @ 2020-10-14 7:06 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel, Juri Linkov
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 7:06 ` Protesilaos Stavrou
@ 2020-10-14 7:09 ` Lars Ingebrigtsen
2020-10-14 7:46 ` Protesilaos Stavrou
0 siblings, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-14 7:09 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: emacs-devel, Juri Linkov
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 7:09 ` Lars Ingebrigtsen
@ 2020-10-14 7:46 ` Protesilaos Stavrou
2020-10-14 7:53 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Protesilaos Stavrou @ 2020-10-14 7:46 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel, Juri Linkov
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 7:46 ` Protesilaos Stavrou
@ 2020-10-14 7:53 ` Lars Ingebrigtsen
2020-10-14 8:30 ` James Cloos
2020-10-14 15:03 ` Eli Zaretskii
0 siblings, 2 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-14 7:53 UTC (permalink / raw)
To: Protesilaos Stavrou; +Cc: emacs-devel, Juri Linkov
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 7:53 ` Lars Ingebrigtsen
@ 2020-10-14 8:30 ` James Cloos
2020-10-14 9:14 ` tomas
2020-10-14 15:03 ` Eli Zaretskii
1 sibling, 1 reply; 97+ messages in thread
From: James Cloos @ 2020-10-14 8:30 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Protesilaos Stavrou, Juri Linkov, emacs-devel
>>>>> "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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 8:30 ` James Cloos
@ 2020-10-14 9:14 ` tomas
0 siblings, 0 replies; 97+ messages in thread
From: tomas @ 2020-10-14 9:14 UTC (permalink / raw)
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 7:53 ` Lars Ingebrigtsen
2020-10-14 8:30 ` James Cloos
@ 2020-10-14 15:03 ` Eli Zaretskii
1 sibling, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2020-10-14 15:03 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: info, juri, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 4:05 ` Lars Ingebrigtsen
2020-10-14 7:06 ` Protesilaos Stavrou
@ 2020-10-14 8:03 ` Juri Linkov
2020-10-14 16:38 ` Drew Adams
2020-10-15 6:45 ` Lars Ingebrigtsen
2020-10-14 13:21 ` Stefan Monnier
2 siblings, 2 replies; 97+ messages in thread
From: Juri Linkov @ 2020-10-14 8:03 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
>> 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?
^ permalink raw reply [flat|nested] 97+ messages in thread
* RE: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 8:03 ` Juri Linkov
@ 2020-10-14 16:38 ` Drew Adams
2020-10-15 6:45 ` Lars Ingebrigtsen
1 sibling, 0 replies; 97+ messages in thread
From: Drew Adams @ 2020-10-14 16:38 UTC (permalink / raw)
To: Juri Linkov, Lars Ingebrigtsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 8:03 ` Juri Linkov
2020-10-14 16:38 ` Drew Adams
@ 2020-10-15 6:45 ` Lars Ingebrigtsen
1 sibling, 0 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-15 6:45 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-14 4:05 ` Lars Ingebrigtsen
2020-10-14 7:06 ` Protesilaos Stavrou
2020-10-14 8:03 ` Juri Linkov
@ 2020-10-14 13:21 ` Stefan Monnier
2 siblings, 0 replies; 97+ messages in thread
From: Stefan Monnier @ 2020-10-14 13:21 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel, 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?
The jumps come from the difference of width between the numbers and the
SPC char.
Stefan
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 5:37 ` How to make Emacs popular again: Use monospaced fonts less Lars Ingebrigtsen
` (4 preceding siblings ...)
2020-10-13 20:00 ` Juri Linkov
@ 2021-04-12 2:19 ` Stefan Kangas
2021-04-12 7:58 ` Lars Ingebrigtsen
2021-04-19 3:13 ` Robert Weiner
6 siblings, 1 reply; 97+ messages in thread
From: Stefan Kangas @ 2021-04-12 2:19 UTC (permalink / raw)
To: Lars Ingebrigtsen, emacs-devel
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'.
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-12 2:19 ` Stefan Kangas
@ 2021-04-12 7:58 ` Lars Ingebrigtsen
2021-04-12 13:23 ` Stefan Kangas
0 siblings, 1 reply; 97+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-12 7:58 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-12 7:58 ` Lars Ingebrigtsen
@ 2021-04-12 13:23 ` Stefan Kangas
2021-04-12 13:39 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Stefan Kangas @ 2021-04-12 13:23 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
[-- 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
^ permalink raw reply related [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-12 13:23 ` Stefan Kangas
@ 2021-04-12 13:39 ` Eli Zaretskii
2021-04-12 15:27 ` Stefan Kangas
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2021-04-12 13:39 UTC (permalink / raw)
To: Stefan Kangas; +Cc: larsi, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-12 13:39 ` Eli Zaretskii
@ 2021-04-12 15:27 ` Stefan Kangas
2021-04-12 16:40 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Stefan Kangas @ 2021-04-12 15:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, emacs-devel
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
^ permalink raw reply related [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-12 15:27 ` Stefan Kangas
@ 2021-04-12 16:40 ` Eli Zaretskii
2021-04-12 17:29 ` Stefan Kangas
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2021-04-12 16:40 UTC (permalink / raw)
To: Stefan Kangas; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-12 16:40 ` Eli Zaretskii
@ 2021-04-12 17:29 ` Stefan Kangas
2021-04-12 17:51 ` Eli Zaretskii
0 siblings, 1 reply; 97+ messages in thread
From: Stefan Kangas @ 2021-04-12 17:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, emacs-devel
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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-12 17:29 ` Stefan Kangas
@ 2021-04-12 17:51 ` Eli Zaretskii
2021-04-13 7:34 ` Lars Ingebrigtsen
0 siblings, 1 reply; 97+ messages in thread
From: Eli Zaretskii @ 2021-04-12 17:51 UTC (permalink / raw)
To: Stefan Kangas; +Cc: larsi, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-12 17:51 ` Eli Zaretskii
@ 2021-04-13 7:34 ` Lars Ingebrigtsen
0 siblings, 0 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-13 7:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stefan Kangas, emacs-devel
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2020-10-11 5:37 ` How to make Emacs popular again: Use monospaced fonts less Lars Ingebrigtsen
` (5 preceding siblings ...)
2021-04-12 2:19 ` Stefan Kangas
@ 2021-04-19 3:13 ` Robert Weiner
2021-04-19 7:12 ` tomas
2021-04-19 7:55 ` Kévin Le Gouguec
6 siblings, 2 replies; 97+ messages in thread
From: Robert Weiner @ 2021-04-19 3:13 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 97+ messages in thread* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-19 3:13 ` Robert Weiner
@ 2021-04-19 7:12 ` tomas
2021-04-19 7:55 ` Kévin Le Gouguec
1 sibling, 0 replies; 97+ messages in thread
From: tomas @ 2021-04-19 7:12 UTC (permalink / raw)
To: rswgnu; +Cc: Lars Ingebrigtsen, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-19 3:13 ` Robert Weiner
2021-04-19 7:12 ` tomas
@ 2021-04-19 7:55 ` Kévin Le Gouguec
2021-04-19 12:31 ` Lars Ingebrigtsen
2021-04-19 12:48 ` Eli Zaretskii
1 sibling, 2 replies; 97+ messages in thread
From: Kévin Le Gouguec @ 2021-04-19 7:55 UTC (permalink / raw)
To: Robert Weiner; +Cc: Lars Ingebrigtsen, rswgnu, emacs-devel
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.
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-19 7:55 ` Kévin Le Gouguec
@ 2021-04-19 12:31 ` Lars Ingebrigtsen
2021-04-19 12:48 ` Eli Zaretskii
1 sibling, 0 replies; 97+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-19 12:31 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: rswgnu, emacs-devel, Robert Weiner
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
^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: How to make Emacs popular again: Use monospaced fonts less
2021-04-19 7:55 ` Kévin Le Gouguec
2021-04-19 12:31 ` Lars Ingebrigtsen
@ 2021-04-19 12:48 ` Eli Zaretskii
1 sibling, 0 replies; 97+ messages in thread
From: Eli Zaretskii @ 2021-04-19 12:48 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: larsi, rswgnu, emacs-devel, rsw
> 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.
^ permalink raw reply [flat|nested] 97+ messages in thread