Tick Reduction

Tick Reduction

[Lars Ingebrigtsen]

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

I'm wondering whether we should reduce the number of ‘’ marks in the
*Help* buffer.  Here's what it looks like today:


[-- Attachment #2: Type: image/png, Size: 108503 bytes --]

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


The variable/function symbols are links and stand out on their own, and
the keys also have their own distinct faces.  Without them, this would
look like:


[-- Attachment #4: Type: image/png, Size: 108017 bytes --]

[-- Attachment #5: Type: text/plain, Size: 235 bytes --]


I dunno.  We could skip the tick removal on displays that don't support
the relevant faces, of course.

It looks calmer without the ticks.

And, of course, we could also consider using proportional fonts for the
non-code prose bits:


[-- Attachment #6: Type: image/png, Size: 111515 bytes --]

[-- Attachment #7: Type: text/plain, Size: 172 bytes --]


This makes the keys and the symbols stand out more clearly again.

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

Re: Tick Reduction

[Perry E. Metzger]

On 11/18/21 15:37, Lars Ingebrigtsen wrote:
> We could skip the tick removal on displays that don't support the 
> relevant faces, of course. 

Perhaps the right thing to start with would be to provide a 
customization that does this (i.e. turns on tick removal for displays 
with relevant faces), see how it looks for a while, and then, if 
everyone agrees it is better, switch the default?

Perry

Re: Tick Reduction

[Lars Ingebrigtsen]

"Perry E. Metzger" <perry@piermont.com> writes:

> Perhaps the right thing to start with would be to provide a
> customization that does this (i.e. turns on tick removal for displays
> with relevant faces), see how it looks for a while, and then, if
> everyone agrees it is better, switch the default?

Sure, that's a plan.

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

Re: Tick Reduction

[Dmitry Gutov]

On 18.11.2021 23:37, Lars Ingebrigtsen wrote:
> It looks calmer without the ticks.

Looks better to me too.

> And, of course, we could also consider using proportional fonts for the
> non-code prose bits:

Might be worth trying, although I don't find examples of using 
proportional fonts in Emacs that I like often.

Re: Tick Reduction

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> And, of course, we could also consider using proportional fonts for the
>> non-code prose bits:
>
> Might be worth trying, although I don't find examples of using
> proportional fonts in Emacs that I like often.

Hm...  where do we do that?  The only instances I can think of is on the
splash screen, and in eww and shortdoc.

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

Re: Tick Reduction

[Michael Welsh Duggan]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>>> And, of course, we could also consider using proportional fonts for the
>>> non-code prose bits:
>>
>> Might be worth trying, although I don't find examples of using
>> proportional fonts in Emacs that I like often.
>
> Hm...  where do we do that?  The only instances I can think of is on the
> splash screen, and in eww and shortdoc.

Titles in Info docs?  That's the only other place I remember seeing
them.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Tick Reduction

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>>> And, of course, we could also consider using proportional fonts for the
>>> non-code prose bits:
>>
>> Might be worth trying, although I don't find examples of using
>> proportional fonts in Emacs that I like often.

Could it be that you are using a suboptimal font?  In my experience,
finding a really good one makes a big difference.

> Hm...  where do we do that?  The only instances I can think of is on the
> splash screen, and in eww and shortdoc.

The ones that come to mind are headers in `C-h C-h' (where it looks
great IMO, but that might be author's bias ;-) and headers in info.

FWIW, I think we could and should use proportional fonts in more places.
For example, the modus themes uses it in the `header-line-format' in
info and it just looks better with no fuzz (though it would work even
better if we added an :align-to text property).

As you Lars pointed out in your thread about proportional fonts in the
mode line, doing that will also help Emacs look more contemporary.
There are of course many cases where it just won't work, but in other
cases it absolutely will.

Re: Tick Reduction

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> The ones that come to mind are headers in `C-h C-h' (where it looks
> great IMO, but that might be author's bias ;-) and headers in info.

😀

Perhaps the rest of the text in `C-h C-h' should also use a proportional
font?  I.e., everything but the keys.

> FWIW, I think we could and should use proportional fonts in more places.
> For example, the modus themes uses it in the `header-line-format' in
> info and it just looks better with no fuzz (though it would work even
> better if we added an :align-to text property).
>
> As you Lars pointed out in your thread about proportional fonts in the
> mode line, doing that will also help Emacs look more contemporary.
> There are of course many cases where it just won't work, but in other
> cases it absolutely will.

Yes, I think we should work towards using proportional fonts throughout
Emacs (where it makes sense) in the Emacs 29 cycle to get a more
consistent and modern look.  For instance, "emacs -Q" uses proportional
fonts in the menus and the toolbars (on most systems), but not in the
mode line or the header lines.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Nov 2021 08:05:39 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> Yes, I think we should work towards using proportional fonts throughout
> Emacs (where it makes sense) in the Emacs 29 cycle to get a more
> consistent and modern look.  For instance, "emacs -Q" uses proportional
> fonts in the menus and the toolbars (on most systems), but not in the
> mode line or the header lines.

Using proportional fonts on the mode line will cause annoying
horizontal shifts when, say, "--" is replaced with "**" or ""%%" is
replaced with "%*", or when the line number changes or the time shown
in the mode line changes.  So if we want to use such fonts there and
avoid such shifts, we will need to treat the mode line as a kind of
table, where each part starts at a horizontal position that is aligned
at pixelwise resolution.  We'll probably need to see what this means
for the current implementation of mode-line display, especially with
those :eval parts.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Using proportional fonts on the mode line will cause annoying
> horizontal shifts when, say, "--" is replaced with "**" or ""%%" is
> replaced with "%*", or when the line number changes or the time shown
> in the mode line changes.  So if we want to use such fonts there and
> avoid such shifts, we will need to treat the mode line as a kind of
> table, where each part starts at a horizontal position that is aligned
> at pixelwise resolution.  We'll probably need to see what this means
> for the current implementation of mode-line display, especially with
> those :eval parts.

Yes, we've previously discussed adding a new type of mode line spec, but
I don't think we got all the way there in how it's supposed to work, so
perhaps we could just continue that discussion here?  😀

So, to recap: We'd like to be able to ensure that the mode line elements
don't change width all the time, because that'd be annoying.  Some fonts
have digits that are of uneven width -- this is very rare, but they do
exist, and that would make column number mode change the width all the
time.

I think my suggestion was to add a spec that says "this bit of the mode
line should take at least x pixels" (or "y times the width of the x
character").  This would fix the issue with the column indicator.

And...  I think that also fixes the issue with "--" changing to "**"?
That is, we'd have something like:

(defvar-local mode-line-mule-info
  `(""
    (:min-space 5
     (current-input-method
      (:propertize ("" current-input-method-title)

For instance.  That is, I don't think we have to go full table on
this -- the number of affected mode line elements isn't large.  (And I
don't think we can go to a table based lineup, because the mode line
format is just too variable.)

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Nov 2021 09:30:07 +0100
> Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> I think my suggestion was to add a spec that says "this bit of the mode
> line should take at least x pixels" (or "y times the width of the x
> character").  This would fix the issue with the column indicator.
> 
> And...  I think that also fixes the issue with "--" changing to "**"?
> That is, we'd have something like:
> 
> (defvar-local mode-line-mule-info
>   `(""
>     (:min-space 5
>      (current-input-method
>       (:propertize ("" current-input-method-title)
> 
> For instance.  That is, I don't think we have to go full table on
> this -- the number of affected mode line elements isn't large.  (And I
> don't think we can go to a table based lineup, because the mode line
> format is just too variable.)

The problem is how to select the appropriate "x character" to use as
the unit of width.  Different fonts will have different characters
suitable for this role, so how to have a default spec that will DTRT
with whatever fonts are selected on different platforms for the
relevant faces?

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The problem is how to select the appropriate "x character" to use as
> the unit of width.  Different fonts will have different characters
> suitable for this role, so how to have a default spec that will DTRT
> with whatever fonts are selected on different platforms for the
> relevant faces?

I don't think that's an insurmountable task, and we could leave it as a
customisation option for the times we guess wrong.  In practice, in the
mode line the problem is that a - character typically takes less space
than the rest of the characters, and using just about any "normal"
letter as the model character will fix the issue.

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

Re: Tick Reduction

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And...  I think that also fixes the issue with "--" changing to "**"?
> That is, we'd have something like:
>
> (defvar-local mode-line-mule-info
>   `(""
>     (:min-space 5
>      (current-input-method
>       (:propertize ("" current-input-method-title)

Or rather -- what we want here is really to make each glyph behave as it
came from a monospaced font?  That is it, should (at least) have the
"normal character width".  Which is kinda also what was discussed in the
thread about CJK characters: That there should be a way to specify that
glyphs should have a width that's an integer multiple of the normal
character width.  (So it's not the same, but if we introduce this, we
might keep that in mind.)

But in this context, it might mean that we introduce a mode line
construct like:

(defvar-local mode-line-mule-info
  `(""
    (:monospace
     (current-input-method
      (:propertize ("" current-input-method-title)

or a text property like

(defvar-local mode-line-mule-info
  `(""
    (current-input-method
     (:propertize ("" current-input-method-title)
                  :monospace t/1

and the display machinery would then add some empty pixels after the
glyph if it's narrower than the normal character width.  I think the
text property makes more sense, because then we could use it generally
in Emacs, not just the mode line.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 21 Nov 2021 16:11:47 +0100
> 
> Or rather -- what we want here is really to make each glyph behave as it
> came from a monospaced font?  That is it, should (at least) have the
> "normal character width".

You want to make a proportional font look like a monospaced one?
Wouldn't that basically throw away all the advantages of using a
proportional font?  I though we want proportional fonts there because
they look nicer and more natural?

You can try this by adding SPC characters with (space :align-to)
display specs on them after each character in text that uses a
variable-pitch face.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> You want to make a proportional font look like a monospaced one?
> Wouldn't that basically throw away all the advantages of using a
> proportional font?  I though we want proportional fonts there because
> they look nicer and more natural?

This would only be used for the U:-- bit at the front and for the
line/column specs.  For the latter, there should be no visual
difference for virtually all fonts, but for the former, it'll typically
add some space after the - characters.

> You can try this by adding SPC characters with (space :align-to)
> display specs on them after each character in text that uses a
> variable-pitch face.

In the mode line we don't know what to align to.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 21 Nov 2021 18:24:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You want to make a proportional font look like a monospaced one?
> > Wouldn't that basically throw away all the advantages of using a
> > proportional font?  I though we want proportional fonts there because
> > they look nicer and more natural?
> 
> This would only be used for the U:-- bit at the front and for the
> line/column specs.  For the latter, there should be no visual
> difference for virtually all fonts, but for the former, it'll typically
> add some space after the - characters.

Won't a line number like L1234 look worse with this
"monospace-ization" than it looks when displayed "normally"?  AFAIK,
proportional fonts are designed to look well when each glyph is
displayed with its advance width in the font.  Overriding the advance
width in many cases looks like some extra spaces added between
characters, which is annoying, looks like a bug in display, and gets
in the way of reading, IME.

> > You can try this by adding SPC characters with (space :align-to)
> > display specs on them after each character in text that uses a
> > variable-pitch face.
> 
> In the mode line we don't know what to align to.

I only meant that as a means to try and see what will such display
look like, without changing anything in the display code.  Just to see
what we will get before we implement it, and decide whether it's worth
the trouble.

Re: Tick Reduction

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> Won't a line number like L1234 look worse with this
> "monospace-ization" than it looks when displayed "normally"?  AFAIK,
> proportional fonts are designed to look well when each glyph is
> displayed with its advance width in the font.  Overriding the advance
> width in many cases looks like some extra spaces added between
> characters, which is annoying, looks like a bug in display, and gets
> in the way of reading, IME.

The "L" wouldn't be monospacified here -- only the digits.  And in the
vast majority of fonts, the digits are the width we're aiming for, at
least as far as I can see, so it will visually be no change.

(Monospeciation of the numbers is basically not necessary unless you
have a very odd font -- virtually all proportional fonts do not have
proportional widths for the digits.)

> I only meant that as a means to try and see what will such display
> look like, without changing anything in the display code.  Just to see
> what we will get before we implement it, and decide whether it's worth
> the trouble.

First line without monospacification, second line with:


[-- Attachment #2: Type: image/png, Size: 1158 bytes --]

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


First two lines without monospacification, last two lines with:


[-- Attachment #4: Type: image/png, Size: 17425 bytes --]

[-- Attachment #5: Type: text/plain, Size: 105 bytes --]



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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 21 Nov 2021 19:00:18 +0100
> 
> The "L" wouldn't be monospacified here -- only the digits.  And in the
> vast majority of fonts, the digits are the width we're aiming for, at
> least as far as I can see, so it will visually be no change.
> 
> (Monospeciation of the numbers is basically not necessary unless you
> have a very odd font -- virtually all proportional fonts do not have
> proportional widths for the digits.)

Sorry, I'm now confused.  You say the width of "L" will not be changed
and the width of digits doesn't need to be changed?  Then why are we
doing all this, if there will be no change?

(And btw, displaying "L" normally while "1234" not normally is quite a
lot more difficult than handling all characters the same, because the
display code generally doesn't distinguish between characters.  Unless
you make "L" that "default character" whose advance width is used for
all the other characters, that is.  But if you do that, then what
about "C" in the column number?)

> First line without monospacification, second line with:

For the "U:---" part, each dash character is a separate field, so what
are the benefits of using proportional fonts there?  For the
line/column number, I don't see any significant difference, barely a
pixel here and there.  So I wonder what is this all about.  I'm
probably missing something important.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I'm now confused.  You say the width of "L" will not be changed
> and the width of digits doesn't need to be changed?  Then why are we
> doing all this, if there will be no change?

The column/line specs use spaces to fill out (I think it defaults to
three char positions for the L spec?), and it's really only these that
will be affected by the monospaciation (in that spec).

> (And btw, displaying "L" normally while "1234" not normally is quite a
> lot more difficult than handling all characters the same, because the
> display code generally doesn't distinguish between characters.  Unless
> you make "L" that "default character" whose advance width is used for
> all the other characters, that is.  But if you do that, then what
> about "C" in the column number?)

The L won't be displayed normally either, but like the numbers, the L
won't be affected, because it's also as wide or wider than the "normal
font width" (i.e., font->average_width).

>> First line without monospacification, second line with:
>
> For the "U:---" part, each dash character is a separate field, so what
> are the benefits of using proportional fonts there?

Because mixing fonts here makes things look weird.

> For the line/column number, I don't see any significant difference,
> barely a pixel here and there.  So I wonder what is this all about.

With this font (as with most fonts), the displays of the line/column
numbers should be identical.  (Except for the spaces.)

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

Re: Tick Reduction

[Lars Ingebrigtsen]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The column/line specs use spaces to fill out (I think it defaults to
> three char positions for the L spec?), and it's really only these that
> will be affected by the monospaciation (in that spec).

I.e., the first two lines have the L/C fields (including space padding)
monospacialized, and the last two lines are without.


[-- Attachment #2: Type: image/png, Size: 37325 bytes --]

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




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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 21 Nov 2021 19:25:38 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sorry, I'm now confused.  You say the width of "L" will not be changed
> > and the width of digits doesn't need to be changed?  Then why are we
> > doing all this, if there will be no change?
> 
> The column/line specs use spaces to fill out (I think it defaults to
> three char positions for the L spec?), and it's really only these that
> will be affected by the monospaciation (in that spec).
> 
> > (And btw, displaying "L" normally while "1234" not normally is quite a
> > lot more difficult than handling all characters the same, because the
> > display code generally doesn't distinguish between characters.  Unless
> > you make "L" that "default character" whose advance width is used for
> > all the other characters, that is.  But if you do that, then what
> > about "C" in the column number?)
> 
> The L won't be displayed normally either, but like the numbers, the L
> won't be affected, because it's also as wide or wider than the "normal
> font width" (i.e., font->average_width).

Beware: with proportional fonts, the value of font->average_width is
sometimes surprising.

> >> First line without monospacification, second line with:
> >
> > For the "U:---" part, each dash character is a separate field, so what
> > are the benefits of using proportional fonts there?
> 
> Because mixing fonts here makes things look weird.
> 
> > For the line/column number, I don't see any significant difference,
> > barely a pixel here and there.  So I wonder what is this all about.
> 
> With this font (as with most fonts), the displays of the line/column
> numbers should be identical.  (Except for the spaces.)

I think we may be mis-communicating.  Can you take an example of a
full mode line and tell which part(s) of it will use proportional
fonts "as usual", which will use glyphs from proportional fonts with
monospaced advance width, and which will use monospaced fonts?
Because currently I'm utterly confused regarding what you'd like to
change there and how.  And consequently, I don't understand what are
the benefits of making such changes.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think we may be mis-communicating.  Can you take an example of a
> full mode line and tell which part(s) of it will use proportional
> fonts "as usual", which will use glyphs from proportional fonts with
> monospaced advance width, and which will use monospaced fonts?
> Because currently I'm utterly confused regarding what you'd like to
> change there and how.  And consequently, I don't understand what are
> the benefits of making such changes.

The entire mode line should use the same proportional font.  Bits that
are liable to shift around should be monospacialised, and the only parts
that shift around are the "U:---" bit at the start and the line/column
bits (including spacers at the end).

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

Re: Tick Reduction

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The entire mode line should use the same proportional font.  Bits that
> are liable to shift around should be monospacialised, and the only parts
> that shift around are the "U:---" bit at the start and the line/column
> bits (including spacers at the end).

Oh, and the "Top/45%/Bot" thing, I guess.

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

Re: Tick Reduction

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, and the "Top/45%/Bot" thing, I guess.

Hm, and that one doesn't really fit with this scheme, since the % is
usually quite big.  So perhaps my first suggestion (of setting a min
width for an entire group of glyphs) would be less fragile.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 21 Nov 2021 20:34:32 +0100
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru
> 
> The entire mode line should use the same proportional font.  Bits that
> are liable to shift around should be monospacialised, and the only parts
> that shift around are the "U:---" bit at the start and the line/column
> bits (including spacers at the end).

My mode line where I type this looks like this:

 -\**-  *mail*         Bot L30    (Mail Fly/en Abbrev Fill) 9:41PM 0.08 [100%]

So the "-\**" part, the Top/nn%/Bot part, the L30 part, the 9:41PM
part, the 0.08 part, and the [100%] part will have to use the fixed
advance width?

And do you know which character's width should we take as the
"standard" width for this purpose?

Btw, I still don't think I understand why aligning each field to a
certain pixel value would not look better (and be easier to
implement).

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> My mode line where I type this looks like this:
>
>  -\**-  *mail*         Bot L30    (Mail Fly/en Abbrev Fill) 9:41PM 0.08 [100%]
>
> So the "-\**" part, the Top/nn%/Bot part, the L30 part, the 9:41PM
> part, the 0.08 part, and the [100%] part will have to use the fixed
> advance width?

No, the last three parts change widths today?  So we wouldn't make them
not change widths in the future.  (The digits are, as I said, not an
issue -- it's just exchanging digits with other characters, like
spaces.)

> And do you know which character's width should we take as the
> "standard" width for this purpose?

"0", for instance.

> Btw, I still don't think I understand why aligning each field to a
> certain pixel value would not look better (and be easier to
> implement).

I don't understand what you mean by that.  Could you explain and give an
example?

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org,  stefankangas@gmail.com,  dgutov@yandex.ru
> Date: Sun, 21 Nov 2021 20:53:13 +0100
> 
> >  -\**-  *mail*         Bot L30    (Mail Fly/en Abbrev Fill) 9:41PM 0.08 [100%]
> >
> > So the "-\**" part, the Top/nn%/Bot part, the L30 part, the 9:41PM
> > part, the 0.08 part, and the [100%] part will have to use the fixed
> > advance width?
> 
> No, the last three parts change widths today?

They are numbers, so they can change the width because different
digits have different width.

> (The digits are, as I said, not an issue -- it's just exchanging
> digits with other characters, like spaces.)

I'm not sure this assumption is always true.  I've seen fonts where
"1" is much narrower than other digits.  And the [100%] part is
produced in my case with the [%b%p%%] format, so it can change the
width, AFAIU.

> > Btw, I still don't think I understand why aligning each field to a
> > certain pixel value would not look better (and be easier to
> > implement).
> 
> I don't understand what you mean by that.  Could you explain and give an
> example?

I've shown different fields for the mode line below:

 -\**-  *mail*         Bot L30    (Mail Fly/en Abbrev Fill) 9:41PM 0.08 [100%]
 +++++  +----------+   +-+ +-+    +-----------------------+ +----+ +--+ +----+

A single + means a field of 1 character cell; a +---+ means a field
that starts and ends at the +.  The idea is that each field always
starts at a predefined pixel offset from the beginning of the mode
line.  The each field can change its width, but it will not affect the
following fields.

Re: Tick Reduction

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> They are numbers, so they can change the width because different
> digits have different width.

No, they don't (in the vast majority of proportional fonts).

>> I don't understand what you mean by that.  Could you explain and give an
>> example?
>
> I've shown different fields for the mode line below:
>
>  -\**-  *mail*         Bot L30    (Mail Fly/en Abbrev Fill) 9:41PM 0.08 [100%]
>  +++++  +----------+   +-+ +-+    +-----------------------+ +----+ +--+ +----+
>
> A single + means a field of 1 character cell; a +---+ means a field
> that starts and ends at the +.  The idea is that each field always
> starts at a predefined pixel offset from the beginning of the mode
> line.  The each field can change its width, but it will not affect the
> following fields.

Here's two random mode lines:


[-- Attachment #2: Type: image/png, Size: 20238 bytes --]

[-- Attachment #3: Type: image/png, Size: 18241 bytes --]

[-- Attachment #4: Type: text/plain, Size: 486 bytes --]


The absolute positions of the fields are extremely different from mode
to mode -- in the first one, the name takes half the space, and in the
other one, everything starts a lot nearer to the left.

So I don't see how we could practically define a fixed-width field mode
line: The mode line formats are pretty different between modes and users
and how you combine different things.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org,  stefankangas@gmail.com,  dgutov@yandex.ru
> Date: Sun, 21 Nov 2021 21:17:07 +0100
> 
> > They are numbers, so they can change the width because different
> > digits have different width.
> 
> No, they don't (in the vast majority of proportional fonts).

"Vast majority" is not "all".

> The absolute positions of the fields are extremely different from mode
> to mode -- in the first one, the name takes half the space, and in the
> other one, everything starts a lot nearer to the left.

Yes, and I suggest to change that.  Each field will start at the same
horizontal position.  A field that doesn't fit in its allotted cell
will be truncated.

> So I don't see how we could practically define a fixed-width field mode
> line: The mode line formats are pretty different between modes and users
> and how you combine different things.

Let's consider the standard mode line before we consider extensions.
We can talk about extensions later.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, and I suggest to change that.  Each field will start at the same
> horizontal position.  A field that doesn't fit in its allotted cell
> will be truncated.

That'd be a massive change in how mode lines are displayed, and how
people can customise them.

>> So I don't see how we could practically define a fixed-width field mode
>> line: The mode line formats are pretty different between modes and users
>> and how you combine different things.
>
> Let's consider the standard mode line before we consider extensions.
> We can talk about extensions later.

I don't consider normal mode line customisations to be extensions.  The
mode line formatting is a basic thing that's gone back to when Emacs was
created, and we can't ditch that.

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

Re: Tick Reduction

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Let's consider the standard mode line before we consider extensions.
>> We can talk about extensions later.
>
> I don't consider normal mode line customisations to be extensions.  The
> mode line formatting is a basic thing that's gone back to when Emacs was
> created, and we can't ditch that.

(And my two examples were two standard Emacs mode lines, as specified by
their respective major modes.)

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

Re: Tick Reduction

[Lars Ingebrigtsen]

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

I wondered whether it'd be much work to implement a min-width thing for
a sequence of characters.  So with this

(insert "||" (propertize "foo" 'min-width '(10.0)) "||")

and the proof of concept patch (it needs some more sanity checking)
below I get:


[-- Attachment #2: Type: image/png, Size: 13213 bytes --]

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


which seems promising.  However, point movement over the stretch glyph
is very wonky -- Emacs basically refuses to put point after that
stretch glyph.

Anybody got any tips on what I need to do to get point movement working
here?

diff --git a/src/dispextern.h b/src/dispextern.h
index a698f6546b..a78be900db 100644
--- a/src/dispextern.h
+++ b/src/dispextern.h
@@ -2185,6 +2185,8 @@ #define MAX_FRINGE_BITMAPS (1<<FRINGE_ID_BITS)
   /* Not a property.  Used to indicate changes in overlays.  */
   OVERLAY_PROP_IDX,
 
+  MIN_WIDTH_PROP_IDX,
+
   /* Sentinel.  */
   LAST_PROP_IDX
 };
@@ -2746,6 +2748,12 @@ #define OVERLAY_STRING_CHUNK_SIZE 16
   /* For iterating over bidirectional text.  */
   struct bidi_it bidi_it;
   bidi_dir_t paragraph_embedding;
+
+  /* For handling the :min-width property.  The object is the text
+     property we're testing the `eq' of (nil if none), and the integer
+     is the x position of the start of the run of glyphs. */
+  Lisp_Object min_width_property;
+  int min_width_start;
 };
 
 
diff --git a/src/xdisp.c b/src/xdisp.c
index 8d34b7c4c3..83f1f64fec 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -822,6 +822,10 @@ #define RESTORE_IT(pITORIG, pITCOPY, CACHE)	\
 /* Functions to mark elements as needing redisplay.  */
 enum { REDISPLAY_SOME = 2};	/* Arbitrary choice.  */
 
+static bool
+calc_pixel_width_or_height (double *, struct it *, Lisp_Object,
+			    struct font *, bool, int *);
+
 void
 redisplay_other_windows (void)
 {
@@ -969,6 +973,7 @@ move_trace (char const *fmt, ...)
 static enum prop_handled handle_composition_prop (struct it *);
 static enum prop_handled handle_overlay_change (struct it *);
 static enum prop_handled handle_fontified_prop (struct it *);
+static enum prop_handled handle_min_width_prop (struct it *);
 
 /* Properties handled by iterators.  */
 
@@ -981,6 +986,7 @@ move_trace (char const *fmt, ...)
   {SYMBOL_INDEX (Qdisplay),	DISPLAY_PROP_IDX,	handle_display_prop},
   {SYMBOL_INDEX (Qinvisible),	INVISIBLE_PROP_IDX,	handle_invisible_prop},
   {SYMBOL_INDEX (Qcomposition),	COMPOSITION_PROP_IDX, handle_composition_prop},
+  {SYMBOL_INDEX (Qmin_width),	MIN_WIDTH_PROP_IDX,     handle_min_width_prop},
   {0,				0,			NULL}
 };
 
@@ -5141,6 +5147,81 @@ setup_for_ellipsis (struct it *it, int len)
   it->ellipsis_p = true;
 }
 
+\f
+/***********************************************************************
+			    `min-width' property
+ ***********************************************************************/
+
+/* Set up iterator IT from `min-width' property at its current position.
+   Called from handle_stop.  */
+
+static enum prop_handled
+handle_min_width_prop (struct it *it)
+{
+  if (STRINGP (it->string) || !it->glyph_row)
+    return HANDLED_NORMALLY;
+
+  Lisp_Object buffer = it->w->contents;
+  struct text_pos *position = &it->current.pos;
+  ptrdiff_t bufpos = CHARPOS (*position);
+
+  Lisp_Object propval = Fget_text_property (make_fixnum (bufpos),
+					    Qmin_width, buffer);
+  /* We're being called at the end of the `min-width' sequence,
+     probably. */
+  if (NILP (propval))
+    {
+      /* Check that we're really right after the sequence of
+	 characters covered by this `min-width'.  */
+      if (!NILP (it->min_width_property)
+	  && bufpos > BEGV
+	  && EQ (it->min_width_property,
+		 Fget_text_property (make_fixnum (bufpos - 1),
+				     Qmin_width, buffer)))
+	{
+	  struct font *font = NULL;
+	  double width;
+	  if (FRAME_WINDOW_P (it->f))
+	    {
+#ifdef HAVE_WINDOW_SYSTEM
+	      struct face *face = FACE_FROM_ID (it->f, it->face_id);
+	      font = face->font ? face->font : FRAME_FONT (it->f);
+	      const int stretch_ascent =
+		(((it->ascent + it->descent)
+		  * FONT_BASE (font)) / FONT_HEIGHT (font));
+	      prepare_face_for_display (it->f, face);
+#else
+	      struct face *face = NULL;
+#endif
+	      calc_pixel_width_or_height (&width, it,
+					  XCAR (it->min_width_property),
+					  font, true, NULL);
+	      width -= it->current_x - it->min_width_start;
+	      append_stretch_glyph (it, Qnil,
+				    (int)width,
+				    it->ascent + it->descent,
+				    stretch_ascent);
+	      it->min_width_property = Qnil;
+	    }
+	}
+    }
+  /* We're at the start of a `min-width' sequence -- record the
+     position and the property, so that we can later see if we're at
+     the end.  */
+  else if (CONSP (propval) && NUMBERP (XCAR (propval)))
+    {
+      if (bufpos == BEGV
+	  || (bufpos > BEGV
+	      && !EQ (propval, Fget_text_property (make_fixnum (bufpos - 1),
+						   Qmin_width, buffer))))
+	{
+	  it->min_width_property = propval;
+	  it->min_width_start = it->current_x;
+	}
+    }
+  return HANDLED_NORMALLY;
+}
+
 
 \f
 /***********************************************************************
@@ -7186,6 +7267,7 @@ reseat_1 (struct it *it, struct text_pos pos, bool set_stop_p)
     }
   /* This make the information stored in it->cmp_it invalidate.  */
   it->cmp_it.id = -1;
+  it->min_width_property = Qnil;
 }
 
 

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 22 Nov 2021 09:19:59 +0100
> 
> I wondered whether it'd be much work to implement a min-width thing for
> a sequence of characters.  So with this
> 
> (insert "||" (propertize "foo" 'min-width '(10.0)) "||")
> 
> and the proof of concept patch (it needs some more sanity checking)
> below I get:
> 
> which seems promising.  However, point movement over the stretch glyph
> is very wonky -- Emacs basically refuses to put point after that
> stretch glyph.
> 
> Anybody got any tips on what I need to do to get point movement working
> here?

Do you intend to install something like this when the problems are
fixed?  Or is this just a prototype to get the impression of what the
results could look like?  If the latter, we just need to fix the
immediate issue with the cursor (if it is at all relevant, since this
is for mode line AFAIU?).  If it's the former, we need to talk about
the design, because the way you wrote the code, it violates several
protocols of the display engine, and that needs to be fixed first (and
will probably also fix the problems you have with the cursor).

Thanks.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Do you intend to install something like this when the problems are
> fixed?  Or is this just a prototype to get the impression of what the
> results could look like?

It's just exploratory hacking to see whether this is the way to do it.

> If the latter, we just need to fix the immediate issue with the cursor
> (if it is at all relevant, since this is for mode line AFAIU?).

I think it's generally useful.

> If it's the former, we need to talk about the design, because the way
> you wrote the code, it violates several protocols of the display
> engine, and that needs to be fixed first (and will probably also fix
> the problems you have with the cursor).

Sure, talk away.  😀  This is my first attempt at implementing something
in the display engine (as opposed to tweaking bits), so as much advice
as possible will be helpful.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 22 Nov 2021 15:50:20 +0100
> 
> I think it's generally useful.
> 
> > If it's the former, we need to talk about the design, because the way
> > you wrote the code, it violates several protocols of the display
> > engine, and that needs to be fixed first (and will probably also fix
> > the problems you have with the cursor).
> 
> Sure, talk away.  😀  This is my first attempt at implementing something
> in the display engine (as opposed to tweaking bits), so as much advice
> as possible will be helpful.

For starters, here's a thought: why not make this feature a variant of
the 'display' property, rather than inventing a new kind of property?
We already have similar variants of 'display': (height HEIGHT) and
(raise FACTOR), and this one sounds similar enough.  The advantage of
doing that is that you will then have much of the infrastructure and
the framework into which to drop your additional code: the
handle_display_prop function, the handle_single_display_spec function,
and the code there which shows how this stuff is done.  You will also
have display_prop_end function, which will help you know where the
text with this property ends (so you know where to produce the stretch
glyph).  In short: the processing of 'display' properties is already
well integrated into the overall design of the display engine, so
adding there one more variety should be relatively easy.

And one other important thing: never call append_FOO_glyph directly.
Instead, call produce_FOO_glyph.  That's because produce_FOO_glyph
already takes care of many things that you otherwise will have to do
manually (and make mistakes).  For example, this:

> +static enum prop_handled
> +handle_min_width_prop (struct it *it)
> +{
> +  if (STRINGP (it->string) || !it->glyph_row)
> +    return HANDLED_NORMALLY;

is unacceptable: when it->glyph_row is NULL, it usually means we are
emulating redisplay without producing glyphs, but the data in 'it'
still needs to be maintained as if we did, because otherwise stuff
like vertical-motion and its callers will stop working.  You will see
in produce_stretch_glyph that it does get this case correctly.

Re: Tick Reduction

[Stefan Monnier]

> For starters, here's a thought: why not make this feature a variant of
> the 'display' property, rather than inventing a new kind of property?

Side note: the reason why Gerd stuffed all those things into the one
`display` property, IIRC, is that having to check N different properties
all the time ended up slowing down redisplay measurably.


        Stefan

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> For starters, here's a thought: why not make this feature a variant of
> the 'display' property, rather than inventing a new kind of property?
> We already have similar variants of 'display': (height HEIGHT) and
> (raise FACTOR), and this one sounds similar enough.

Sure, that makes sense.  (Perhaps we should add a convenience function a
la `add-face-text-property', but for `display', because `min-width' is
something you'd typically want to slap on arbitrary things, like a text
that contains a small image mixed in with letters.)

> In short: the processing of 'display' properties is already well
> integrated into the overall design of the display engine, so adding
> there one more variety should be relatively easy.

Sounds good; I'll have a try at implementing it that way (but probably
not today).

> And one other important thing: never call append_FOO_glyph directly.
> Instead, call produce_FOO_glyph.  That's because produce_FOO_glyph
> already takes care of many things that you otherwise will have to do
> manually (and make mistakes).  For example, this:
>
>> +static enum prop_handled
>> +handle_min_width_prop (struct it *it)
>> +{
>> +  if (STRINGP (it->string) || !it->glyph_row)
>> +    return HANDLED_NORMALLY;
>
> is unacceptable: when it->glyph_row is NULL, it usually means we are
> emulating redisplay without producing glyphs, but the data in 'it'
> still needs to be maintained as if we did, because otherwise stuff
> like vertical-motion and its callers will stop working.  You will see
> in produce_stretch_glyph that it does get this case correctly.

Ah, I see.  Thanks for the tips.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 23 Nov 2021 11:15:07 +0100
> 
> Perhaps we should add a convenience function a
> la `add-face-text-property', but for `display', because `min-width' is
> something you'd typically want to slap on arbitrary things, like a text
> that contains a small image mixed in with letters.

The value of 'display' property can be either a single spec, or a list
or vector of specs.  Thus, adding should be trivial: either add
another list member or produce a new vector with one more element.  Do
you think this justifies a dedicated API?

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The value of 'display' property can be either a single spec, or a list
> or vector of specs.  Thus, adding should be trivial: either add
> another list member or produce a new vector with one more element.  Do
> you think this justifies a dedicated API?

To add a `max-width' to a series of characters, it first has to see
whether there's any other bits with a `display' property.  Then if it
finds sequences of characters like that, it has to see whether there's
only one spec, and then to transform it to a list, and if not, it just
has to append.  And do this efficiently, so that we don't get a bunch of
short lists when there's different overlapping regions with `display'.

So, yes, I think this deserves a function.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 23 Nov 2021 14:49:38 +0100
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The value of 'display' property can be either a single spec, or a list
> > or vector of specs.  Thus, adding should be trivial: either add
> > another list member or produce a new vector with one more element.  Do
> > you think this justifies a dedicated API?
> 
> To add a `max-width' to a series of characters, it first has to see
> whether there's any other bits with a `display' property.

It does? why is that?

> Then if it finds sequences of characters like that, it has to see
> whether there's only one spec, and then to transform it to a list,
> and if not, it just has to append.

We do that every day in Lisp programs.

> And do this efficiently, so that we don't get a bunch of short lists
> when there's different overlapping regions with `display'.

You cannot have overlapping regions with different values of the
'display' property (or of any other text property), so I'm not sure
what are you alluding to here.

> So, yes, I think this deserves a function.

I'm still not convinced.  But if we will do this all over the place,
maybe we should have a function.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> To add a `max-width' to a series of characters, it first has to see
>> whether there's any other bits with a `display' property.
>
> It does? why is that?

If you're (put-text-property foo bar 'display '(max-width ...)) and
there's bits in the region with an image or a height display property,
they'll go missing.

>> And do this efficiently, so that we don't get a bunch of short lists
>> when there's different overlapping regions with `display'.
>
> You cannot have overlapping regions with different values of the
> 'display' property (or of any other text property), so I'm not sure
> what are you alluding to here.

Exactly -- if you want to have a region with max-width from 1 to 10, and
height from 5 to 15, you have to create three different intervals.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org,  stefankangas@gmail.com,  dgutov@yandex.ru
> Date: Tue, 23 Nov 2021 15:32:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> To add a `max-width' to a series of characters, it first has to see
> >> whether there's any other bits with a `display' property.
> >
> > It does? why is that?
> 
> If you're (put-text-property foo bar 'display '(max-width ...)) and
> there's bits in the region with an image or a height display property,
> they'll go missing.

Whether or not they go missing depends on how you apply the property.

> >> And do this efficiently, so that we don't get a bunch of short lists
> >> when there's different overlapping regions with `display'.
> >
> > You cannot have overlapping regions with different values of the
> > 'display' property (or of any other text property), so I'm not sure
> > what are you alluding to here.
> 
> Exactly -- if you want to have a region with max-width from 1 to 10, and
> height from 5 to 15, you have to create three different intervals.

That's not special to 'display' property.

Re: Tick Reduction

[Lars Ingebrigtsen]

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

I've now pushed the new min-width thing, but there's things here that
could be tweaked.

Basically, you can now say

(insert "|" (propertize "foo" 'display '(min-width (8.0)) 'face 'match) "|")

and then this will occupy eight normal character widths:


[-- Attachment #2: Type: image/png, Size: 16377 bytes --]

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


Things to ponder:

1) Should the stretch have been inserted "before the foo ended", i.e.,
with that face extending to the end of the range?

1a) Perhaps :extend of the face should control that?

2) To identify a range, we need an identity, so I used `eq' on the list
containing the width spec itself.  Other identities that are possible,
for instance:

(propertize "foo" 'display '(min-width 8.0 :the-identity))

But...  what if somebody then does:

(insert (propertize "foo" 'display '(min-width 5.0 :the-identity))
        (propertize "foo" 'display '(min-width 10.0 :the-identity)))

Using the `eq' of the list is awkward, but at least it's not ambiguous.
And we need an identity, because otherwise this won't be possible:

(insert (propertize "foo" 'display '(min-width 5.0))
        (propertize "bar" 'display '(min-width 5.0)))

3) Should this stuff nest?  We could have a stack of these, but meh.

4) Probably other things.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 12:07:08 +0100
> 
> I've now pushed the new min-width thing, but there's things here that
> could be tweaked.
> 
> Basically, you can now say
> 
> (insert "|" (propertize "foo" 'display '(min-width (8.0)) 'face 'match) "|")
> 
> and then this will occupy eight normal character widths:

Thanks.  A couple of comments/questions:

Is it possible to use an integer value instead of a float, and if so,
what is the semantics of that?

> 1) Should the stretch have been inserted "before the foo ended", i.e.,
> with that face extending to the end of the range?

You are saying that the stretch doesn't use the same face as the
characters "covered" by this property?  If so, why not use the same
face ID?  If that's not what you are saying, then what are you saying?

> 2) To identify a range, we need an identity

You are saying "a range", here and in the documentation you installed,
but you never explain what that means in this context.  Can you
explain what you mean by that, and why do you need to identify that
range?

And finally, I don't understand this recent addition:

      /* When called form display_string (i.e., the mode line),
	 we're being called with a string as the object, and we
	 may be called with many sub-strings belonging to the same
	 :propertize run. */
      if ((bufpos == 0
	   && !EQ (it->min_width_property,
		   get_display_property (0, Qmin_width, object)))
	  /* In a buffer -- check that we're really right after the
	     sequence of characters covered by this `min-width'.  */
	  || (bufpos > BEGV
	      && EQ (it->min_width_property,
		     get_display_property (bufpos - 1, Qmin_width, object))))

To support a Lisp string as OBJECT, you need first to test for that:

  if (STRINGP (object))
     ....

Then, if it _is_ a string, I don't understand the test for bufpos == 0
vs bufpos > BEGV in the case of a buffer, and I also don't understand
the reverse condition of the property equality.  Can you explain what
is going on here and why?

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> (insert "|" (propertize "foo" 'display '(min-width (8.0)) 'face 'match) "|")
>> 
>> and then this will occupy eight normal character widths:
>
> Thanks.  A couple of comments/questions:
>
> Is it possible to use an integer value instead of a float, and if so,
> what is the semantics of that?

It's the same as in all the width things -- a floating point number is a
normal-character ratio, while an integer is a number of pixels.  (Etc.)

>> 1) Should the stretch have been inserted "before the foo ended", i.e.,
>> with that face extending to the end of the range?
>
> You are saying that the stretch doesn't use the same face as the
> characters "covered" by this property?  If so, why not use the same
> face ID?  If that's not what you are saying, then what are you saying?

I'm asking, I'm not saying.

>> 2) To identify a range, we need an identity
>
> You are saying "a range", here and in the documentation you installed,
> but you never explain what that means in this context.  Can you
> explain what you mean by that, and why do you need to identify that
> range?

"A group of consecutive characters".  And it needs to be identified,
because that's the thing that has a minimum width.

> Then, if it _is_ a string, I don't understand the test for bufpos == 0
> vs bufpos > BEGV in the case of a buffer, and I also don't understand
> the reverse condition of the property equality.  Can you explain what
> is going on here and why?

This doesn't deal with strings at all.  It's display_string (i.e., the
mode line) or a buffer.  Adding support for strings, too, might be nice.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 17:28:17 +0100
> 
> >> 1) Should the stretch have been inserted "before the foo ended", i.e.,
> >> with that face extending to the end of the range?
> >
> > You are saying that the stretch doesn't use the same face as the
> > characters "covered" by this property?  If so, why not use the same
> > face ID?  If that's not what you are saying, then what are you saying?
> 
> I'm asking, I'm not saying.

OK, but then I don't think I see a problem.  The display code will
keep using the same face until something changes it.  So if you don't
touch it->face_id in your code, the stretch will be displayed in the
same face as the text covered by this property.

Is that what you wanted to ask?  Does that answer your question?

> >> 2) To identify a range, we need an identity
> >
> > You are saying "a range", here and in the documentation you installed,
> > but you never explain what that means in this context.  Can you
> > explain what you mean by that, and why do you need to identify that
> > range?
> 
> "A group of consecutive characters".  And it needs to be identified,
> because that's the thing that has a minimum width.

You mean, the text "covered" by this property?

Btw, why don't you just record in the iterator the position where it
ends when you first see the property, instead of trying to identify
that by comparing property values?  The iterator structure has a
member called 'position' for this purpose.

> > Then, if it _is_ a string, I don't understand the test for bufpos == 0
> > vs bufpos > BEGV in the case of a buffer, and I also don't understand
> > the reverse condition of the property equality.  Can you explain what
> > is going on here and why?
> 
> This doesn't deal with strings at all.  It's display_string (i.e., the
> mode line) or a buffer.  Adding support for strings, too, might be nice.

Sorry, I don't understand: the functions which call display_min_width
are general-purpose display code, they are used for displaying both
buffer text and Lisp strings.  In fact, displaying the mode line
already means that strings are supported, because the mode line is
constructed from Lisp strings, not from buffer text.

In any case, can you please explain what the test bufpos == 0 tries to
test?  I'd like to understand the logic there.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is that what you wanted to ask?  Does that answer your question?

I wondered whether people had any opinion on whether the stretch should
or shouldn't use the face from the preceding text.  😀

> You mean, the text "covered" by this property?

Yes.

> Btw, why don't you just record in the iterator the position where it
> ends when you first see the property, instead of trying to identify
> that by comparing property values?  The iterator structure has a
> member called 'position' for this purpose.

Hm...  how do I know where it ends when I see the start? 

> Sorry, I don't understand: the functions which call display_min_width
> are general-purpose display code, they are used for displaying both
> buffer text and Lisp strings.  In fact, displaying the mode line
> already means that strings are supported, because the mode line is
> constructed from Lisp strings, not from buffer text.
>
> In any case, can you please explain what the test bufpos == 0 tries to
> test?  I'd like to understand the logic there.

I may well have misunderstood something, but my bufpos == 0 test is
testing whether I'm really being called from display_string.  If it not
0, I'm assuming I'm being called while displaying a buffer.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 18:10:06 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, why don't you just record in the iterator the position where it
> > ends when you first see the property, instead of trying to identify
> > that by comparing property values?  The iterator structure has a
> > member called 'position' for this purpose.
> 
> Hm...  how do I know where it ends when I see the start? 

There's the display_prop_end function we normally use for that.

> > In any case, can you please explain what the test bufpos == 0 tries to
> > test?  I'd like to understand the logic there.
> 
> I may well have misunderstood something, but my bufpos == 0 test is
> testing whether I'm really being called from display_string.  If it not
> 0, I'm assuming I'm being called while displaying a buffer.

I guessed that much, but again: if you just want to test that you are
called from display_string, the test STRINGP (object) should be
enough.

And I'm confused by the fact that for buffers you test

   if (bufpos > BEGV && EQ (FOO, BAR))

whereas for a string you test

   if (bufpos == 0 && !EQ (FOO, BAR))

The equivalent of BEGV in strings is zero, so I'd expect

   if (bufpos > 0

and also why is the first case tests equality, whereas the second one
tests INequality?

IOW, the issue here AFAIU is that you might be called to display
buffer text with this property or to display a Lisp string with this
property, so the tests should be equivalent, and the only difference
between strings and buffers is that text starts at BEGV in buffers but
at zero in strings.  So why there are more differences that that?
What am I missing?

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> There's the display_prop_end function we normally use for that.

I don't quite understand.  If I have a max-width going from 5 to 15,
and a height going from 10 to 12, I think this function is going to be
called at 5, 10, 12 and 15?  I need to know that this consecutive series
of characters ends at 15.

It's the same issue when called from display_string -- the mode line
machinery will call the function several times, even if the :propertize
is around all the specs.

> I guessed that much, but again: if you just want to test that you are
> called from display_string, the test STRINGP (object) should be
> enough.

Ah, I see.

> And I'm confused by the fact that for buffers you test
>
>    if (bufpos > BEGV && EQ (FOO, BAR))
>
> whereas for a string you test
>
>    if (bufpos == 0 && !EQ (FOO, BAR))

The bufpos == 0 is just testing that we're being called from the mode
line (where it's always 0).

> The equivalent of BEGV in strings is zero, so I'd expect
>
>    if (bufpos > 0
>
> and also why is the first case tests equality, whereas the second one
> tests INequality?

Looks correct to me -- one is testing the start of the range and one is
testing whether we're at the end.

> IOW, the issue here AFAIU is that you might be called to display
> buffer text with this property or to display a Lisp string with this
> property, so the tests should be equivalent, and the only difference
> between strings and buffers is that text starts at BEGV in buffers but
> at zero in strings.  So why there are more differences that that?
> What am I missing?

Like I said, there's no strings -- only buffers and mode lines.  I.e.,
this doesn't work:

(string-pixel-width (propertize "foo" 'display '(min-width (1000))))

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 18:50:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There's the display_prop_end function we normally use for that.
> 
> I don't quite understand.  If I have a max-width going from 5 to 15,
> and a height going from 10 to 12, I think this function is going to be
> called at 5, 10, 12 and 15?  I need to know that this consecutive series
> of characters ends at 15.

You cannot usefully have two display properties with different values
(one min-width, the other height) which overlap.  But yes,
display_prop_end will fund the next position where the display
property changes its value.  Why is that a problem?  The idea is that
whatever tests you need to do to with the position it finds, you do
them at the beginning of the property, then you record the result in
it->position, and use that to know when you are at the end of the
property.

> It's the same issue when called from display_string -- the mode line
> machinery will call the function several times, even if the :propertize
> is around all the specs.

I don't think so, but maybe I misunderstand something.

> > And I'm confused by the fact that for buffers you test
> >
> >    if (bufpos > BEGV && EQ (FOO, BAR))
> >
> > whereas for a string you test
> >
> >    if (bufpos == 0 && !EQ (FOO, BAR))
> 
> The bufpos == 0 is just testing that we're being called from the mode
> line (where it's always 0).

But that isn't guaranteed.  This display property can be on some part
of the string, and doesn't have to start at position zero.

> > and also why is the first case tests equality, whereas the second one
> > tests INequality?
> 
> Looks correct to me -- one is testing the start of the range and one is
> testing whether we're at the end.

??? But the code under the test does the processing that's appropriate
for the end of the property, doesn't it?  Namely, it computes the
width of the stretch that needs to be appended for padding.  And both
conditions, when fulfilled, trigger the same code:

      if ((bufpos == 0
	   && !EQ (it->min_width_property,
		   get_display_property (0, Qmin_width, object)))
	  /* In a buffer -- check that we're really right after the
	     sequence of characters covered by this `min-width'.  */
	  || (bufpos > BEGV
	      && EQ (it->min_width_property,
		     get_display_property (bufpos - 1, Qmin_width, object))))
	{
	  Lisp_Object w = Qnil;
	  double width;
#ifdef HAVE_WINDOW_SYSTEM
	  if (FRAME_WINDOW_P (it->f))
	    {
	      struct font *font = NULL;
	      struct face *face = FACE_FROM_ID (it->f, it->face_id);
	      font = face->font ? face->font : FRAME_FONT (it->f);
	      calc_pixel_width_or_height (&width, it,
					  XCAR (it->min_width_property),
					  font, true, NULL);
	      width -= it->current_x - it->min_width_start;
	      w = list1 (make_int (width));
	    }

I'm afraid that I'm missing something important here.

> > IOW, the issue here AFAIU is that you might be called to display
> > buffer text with this property or to display a Lisp string with this
> > property, so the tests should be equivalent, and the only difference
> > between strings and buffers is that text starts at BEGV in buffers but
> > at zero in strings.  So why there are more differences that that?
> > What am I missing?
> 
> Like I said, there's no strings -- only buffers and mode lines.

Once again: displaying the mode line _is_ displaying a string.  The
mode line is constructed from Lisp strings.

> I.e., this doesn't work:
> 
> (string-pixel-width (propertize "foo" 'display '(min-width (1000))))

I don't think this is related.  First, as you well know,
string-pixel-width inserts the string into a temporary buffer, and
then measures the dimensions there, so this has nothing to do with
display properties on strings, as the implementation eventually walks
text of some buffer.  And second, the current implementation seems to
have bugs, because this trivial variation of your original test case:

  (insert "|" (propertize "foo" 'display '(min-width (8.0)) 'face 'match))

doesn't work, either.  (All I did was remove the final "|" from the
inserted string.)

So I think it's too early to use the code behavior as the evidence of
anything ;-)

Re: Tick Reduction

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> You cannot usefully have two display properties with different values
> (one min-width, the other height) which overlap.

Sure you can:


[-- Attachment #2: Type: image/png, Size: 32380 bytes --]

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


But like I said, I won't have time to poke more at this tonight, but
I'll be back at it tomorrow.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 19:44:17 +0100
> 
> > You cannot usefully have two display properties with different values
> > (one min-width, the other height) which overlap.
> 
> Sure you can:

There's no min-width in this counter-example, so how does it
contradict what I said?  'height and 'raise make sense when combined
in the way you did (i.e. one completely nested inside the other), but
what would be the sense of 'min-width and 'height that partially
overlap?

But let me be more precise: you cannot usefully have overlapping
display properties for any arbitrary combination of property values.
It can work for some combination, but won't work for most of them.

Re: Tick Reduction

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> There's no min-width in this counter-example, so how does it
> contradict what I said?  'height and 'raise make sense when combined
> in the way you did (i.e. one completely nested inside the other), but
> what would be the sense of 'min-width and 'height that partially
> overlap?

It's the same with any min-width -- I just thought raise/height was
easier to see.

(progn
  (goto-char (point-min))
  (insert "Foo bar zot gazonk\n")
  (add-display-text-property 4 8 'height 2.0) 
  (add-display-text-property 2 12 'min-width '(40.0)))

yields


[-- Attachment #2: Type: image/png, Size: 8045 bytes --]

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


> But let me be more precise: you cannot usefully have overlapping
> display properties for any arbitrary combination of property values.
> It can work for some combination, but won't work for most of them.

Well, min-width is one of those you can overlap meaningfully.

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

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The idea is that whatever tests you need to do to with the position it
> finds, you do them at the beginning of the property, then you record
> the result in it->position, and use that to know when you are at the
> end of the property.

Oh, you mean keep adding when the min_width eq-ness doesn't change?  I
guess that could work, but I don't see how that'd simplify anything.

>> It's the same issue when called from display_string -- the mode line
>> machinery will call the function several times, even if the :propertize
>> is around all the specs.
>
> I don't think so, but maybe I misunderstand something.

I've tested, and it does.  It's only apparently in specs like
" (%l,%c)", though.

> I'm afraid that I'm missing something important here.

Yes, when called from the mode line we're postponing the stretch
computation until the :propertize run is actually over (in the
multiple-% case).

>   (insert "|" (propertize "foo" 'display '(min-width (8.0)) 'face 'match))
>
> doesn't work, either.  (All I did was remove the final "|" from the
> inserted string.)

Well, the stretch isn't realised until there's something to stretch too.
So at the end of the buffer it's a NOOP, which seems natural to me.

But we could change that, of course.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 13:58:08 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The idea is that whatever tests you need to do to with the position it
> > finds, you do them at the beginning of the property, then you record
> > the result in it->position, and use that to know when you are at the
> > end of the property.
> 
> Oh, you mean keep adding when the min_width eq-ness doesn't change?  I
> guess that could work, but I don't see how that'd simplify anything.

It might simplify things because you won't need display_min_width to
be called the second time by property (in)equality, but just based on
position.  Also, you don't need to keep the form in the iterator,
which could help GC.

> >> It's the same issue when called from display_string -- the mode line
> >> machinery will call the function several times, even if the :propertize
> >> is around all the specs.
> >
> > I don't think so, but maybe I misunderstand something.
> 
> I've tested, and it does.  It's only apparently in specs like
> " (%l,%c)", though.

Well, that's expected: you are formatting two strings.

> > I'm afraid that I'm missing something important here.
> 
> Yes, when called from the mode line we're postponing the stretch
> computation until the :propertize run is actually over (in the
> multiple-% case).

But "is over" seems to mean "we are in the next string", not "we are
at the end of the string that needs to be stretched".  that's what the
bufpos == 0 test does.  Right?  If so, this is too late: what if
there's no "next string"?

> >   (insert "|" (propertize "foo" 'display '(min-width (8.0)) 'face 'match))
> >
> > doesn't work, either.  (All I did was remove the final "|" from the
> > inserted string.)
> 
> Well, the stretch isn't realised until there's something to stretch too.

??? The "foo" part has the display property, so it is that something
which needs to be stretched.  That there's some more text after it
shouldn't affect how "foo" is displayed, right?  Or what am I missing?

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It might simplify things because you won't need display_min_width to
> be called the second time by property (in)equality, but just based on
> position.  Also, you don't need to keep the form in the iterator,
> which could help GC.

I don't understand how I can ditch the form -- I'll be called several
times, and I need to see whether the new interval has a min-width that's
`eq' the one in the previous interval.

But it does sound like it might make the end case simpler, yes.  Hm...
I think.

>> I've tested, and it does.  It's only apparently in specs like
>> " (%l,%c)", though.
>
> Well, that's expected: you are formatting two strings.

Yes, like I said.

>> Yes, when called from the mode line we're postponing the stretch
>> computation until the :propertize run is actually over (in the
>> multiple-% case).
>
> But "is over" seems to mean "we are in the next string", not "we are
> at the end of the string that needs to be stretched".  that's what the
> bufpos == 0 test does.  Right?  If so, this is too late: what if
> there's no "next string"?

If there's no "next string" we have nothing to stretch for, so that's
fine.

(If we want to extend the face over the stretch, then this has to be
done differently.)

> ??? The "foo" part has the display property, so it is that something
> which needs to be stretched.  That there's some more text after it
> shouldn't affect how "foo" is displayed, right?  Or what am I missing?

The stretch comes after "foo", so I'm not sure what you're asking.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 15:29:04 +0100
> 
> > But "is over" seems to mean "we are in the next string", not "we are
> > at the end of the string that needs to be stretched".  that's what the
> > bufpos == 0 test does.  Right?  If so, this is too late: what if
> > there's no "next string"?
> 
> If there's no "next string" we have nothing to stretch for, so that's
> fine.

Yes, we do: the last string.

The padding of a string should not depend on whether there's another
string after it.  The padding is a display feature: if some Lisp puts
the property on a string, that string should look the same, with the
same padding, regardless of where on the screen it is located, and
regardless of whether there's some text after it.

> (If we want to extend the face over the stretch, then this has to be
> done differently.)

Which face?  This feature is not about faces, it is about padding text
so that it takes at least X pixels on display.

> > ??? The "foo" part has the display property, so it is that something
> > which needs to be stretched.  That there's some more text after it
> > shouldn't affect how "foo" is displayed, right?  Or what am I missing?
> 
> The stretch comes after "foo", so I'm not sure what you're asking.

I'm asking why the stretch isn't produced when there's nothing but EOB
after "foo".  I expect to see the stretch between the end of "foo" and
EOB.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The padding of a string should not depend on whether there's another
> string after it.  The padding is a display feature: if some Lisp puts
> the property on a string, that string should look the same, with the
> same padding, regardless of where on the screen it is located, and
> regardless of whether there's some text after it.

It does look the same, I think?  That is, nothingness that comes from a
stretch looks like the same like the nothingness that was there before.

(But you can tell the difference in buffers if you put the point after
it.)

>> (If we want to extend the face over the stretch, then this has to be
>> done differently.)
>
> Which face?  This feature is not about faces, it is about padding text
> so that it takes at least X pixels on display.

If there's a face with a background (or the like), you can see the
difference between a stretch and no stretch -- you can't otherwise.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 13:12:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The padding of a string should not depend on whether there's another
> > string after it.  The padding is a display feature: if some Lisp puts
> > the property on a string, that string should look the same, with the
> > same padding, regardless of where on the screen it is located, and
> > regardless of whether there's some text after it.
> 
> It does look the same, I think?  That is, nothingness that comes from a
> stretch looks like the same like the nothingness that was there before.
> 
> (But you can tell the difference in buffers if you put the point after
> it.)

Exactly.  So no, it does NOT look the same.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> And I'm confused by the fact that for buffers you test
>
>    if (bufpos > BEGV && EQ (FOO, BAR))

There might be a bug somewhere.  I've now added the previously discussed
`add-display-text-property' function, so now it's easier to test these
things, and it looks like there's something not quite working as it's
supposed to, but I haven't debugged yet.  (It only seems to affect
"overlapping" regions.)

I'll have a new look at this tomorrow.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Nov 2021 19:41:49 +0100
> 
> There might be a bug somewhere.  I've now added the previously discussed
> `add-display-text-property' function, so now it's easier to test these
> things, and it looks like there's something not quite working as it's
> supposed to, but I haven't debugged yet.  (It only seems to affect
> "overlapping" regions.)

One thing that seems wrong is that you expect handle_stop to be called
at the end of the property.  But that is only true if there's some
text after the property, because handle_stop is called when text
properties _change_, and there's no such change at EOB.  So you need
special handling for EOB and for end-of-string (for the mode-line
case, when the padded field is the last one).

In general, handle_stop and the other functions involved here are used
both when displaying strings and when displaying buffer text, so if
implemented correctly, this feature should automagically work for both
cases.  That's the main reason for implementing the feature at this
level, the level which produces glyphs from some text, regardless of
the origin of that text.

Re: Tick Reduction

[Yuan Fu]

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

BTW, I pulled the master today and noticed something: it is used to be that you can insert a line that stretches across the window by

(insert (propertize "-" 'display '(space :width text)
                    'face '(:strike-through t)))

Which look like this:



Now the strike through is gone. Could it be related to changes made in this thread?

Yuan

[-- Attachment #2.1: Type: text/html, Size: 933 bytes --]

[-- Attachment #2.2: Screen Shot 2021-11-24 at 2.30.48 PM.png --]
[-- Type: image/png, Size: 9874 bytes --]

Re: Tick Reduction

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Wed, 24 Nov 2021 14:32:19 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  Emacs developers <emacs-devel@gnu.org>,
>  Stefan Kangas <stefankangas@gmail.com>,
>  dgutov@yandex.ru
> 
> BTW, I pulled the master today and noticed something: it is used to be that you can insert a line that stretches across the window by
> 
> (insert (propertize "-" 'display '(space :width text)
>                     'face '(:strike-through t)))
> 
> Which look like this:
> 
> 
> 
> Now the strike through is gone. Could it be related to changes made in this thread?

This still works for me with the current master.  Did you forget to
turn off font-lock-mode, per chance?  When font-lock-mode is ON, you
cannot usefully add any 'face' properties to the text; you need to use
'font-lock-face' instead.

Re: Tick Reduction

[Yuan Fu]

> 
> This still works for me with the current master.  Did you forget to
> turn off font-lock-mode, per chance?  When font-lock-mode is ON, you
> cannot usefully add any 'face' properties to the text; you need to use
> 'font-lock-face' instead.

Strange. I pulled the latest master and tried again and the problem persists. I’m sure font-lock-mode is disabled. (And I used emacs -Q, of course.) The code snippet doesn’t have any problem, it works in an earlier Emacs. Maybe I’m missing some dumb things, but I don’t know what they are.

Yuan

Re: Tick Reduction

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 26 Nov 2021 09:03:57 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  emacs-devel@gnu.org,
>  stefankangas@gmail.com,
>  dgutov@yandex.ru
> 
> > 
> > This still works for me with the current master.  Did you forget to
> > turn off font-lock-mode, per chance?  When font-lock-mode is ON, you
> > cannot usefully add any 'face' properties to the text; you need to use
> > 'font-lock-face' instead.
> 
> Strange. I pulled the latest master and tried again and the problem persists. I’m sure font-lock-mode is disabled. (And I used emacs -Q, of course.) The code snippet doesn’t have any problem, it works in an earlier Emacs. Maybe I’m missing some dumb things, but I don’t know what they are.

Maybe try to describe step by step what exactly did you do.  For
example, font-lock-mode is turned ON by default, so if you turned it
OFF, at least one step is missing.  What else is missing?

Re: Tick Reduction

[Yuan Fu]

> On Nov 26, 2021, at 10:41 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Fri, 26 Nov 2021 09:03:57 -0800
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>> emacs-devel@gnu.org,
>> stefankangas@gmail.com,
>> dgutov@yandex.ru
>> 
>>> 
>>> This still works for me with the current master.  Did you forget to
>>> turn off font-lock-mode, per chance?  When font-lock-mode is ON, you
>>> cannot usefully add any 'face' properties to the text; you need to use
>>> 'font-lock-face' instead.
>> 
>> Strange. I pulled the latest master and tried again and the problem persists. I’m sure font-lock-mode is disabled. (And I used emacs -Q, of course.) The code snippet doesn’t have any problem, it works in an earlier Emacs. Maybe I’m missing some dumb things, but I don’t know what they are.
> 
> Maybe try to describe step by step what exactly did you do.  For
> example, font-lock-mode is turned ON by default, so if you turned it
> OFF, at least one step is missing.  What else is missing?

What does the following produce for you?

(progn
  (switch-to-buffer (get-buffer-create "test"))
  (font-lock-mode -1)
  (insert (propertize "-" 'display '(space :width text)
                      'face '(:strike-through t))))

Here it works (produces a line) on an older Emacs (a couple month ago) but not on the latest master.

Yuan

Re: Tick Reduction

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 26 Nov 2021 10:54:49 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  Emacs developers <emacs-devel@gnu.org>,
>  Stefan Kangas <stefankangas@gmail.com>,
>  dgutov@yandex.ru
> 
> What does the following produce for you?
> 
> (progn
>   (switch-to-buffer (get-buffer-create "test"))
>   (font-lock-mode -1)
>   (insert (propertize "-" 'display '(space :width text)
>                       'face '(:strike-through t))))
> 
> Here it works (produces a line) on an older Emacs (a couple month ago) but not on the latest master.

Here it produces a thin line, as expected.

Is your repository clean of changes that are not on the master branch?
If so, please show the information collected about your build by
report-emacs-bug.

Re: Tick Reduction

[Lars Ingebrigtsen]

The one remaining problem I have now is with the mode line -- the
display handlers aren't called in all circumstances, and I don't quite
understand why.

With this:

(defvar mode-line-position
  `((:propertize
     (" " mode-line-percent-position)
     display (min-width (6.0))

handle_display_prop is called (via next_element_from_string) as you'd
expect, and everything works fine.  However, if you just have:

(defvar mode-line-position
  `((:propertize
     mode-line-percent-position
     display (min-width (6.0))

handle_display_prop is never called.  I don't quite understand the
calling sequence -- I've been trying to trace it via gdb for half an
hour now, and I'm not able to pin-point the exact code flow here (it's
via some indirection that I'm not sure about).  Do you have any tips
about where I should be looking?

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 14:06:45 +0100
> 
> The one remaining problem I have now is with the mode line -- the
> display handlers aren't called in all circumstances, and I don't quite
> understand why.
> 
> With this:
> 
> (defvar mode-line-position
>   `((:propertize
>      (" " mode-line-percent-position)
>      display (min-width (6.0))
> 
> handle_display_prop is called (via next_element_from_string) as you'd
> expect, and everything works fine.  However, if you just have:
> 
> (defvar mode-line-position
>   `((:propertize
>      mode-line-percent-position
>      display (min-width (6.0))
> 
> handle_display_prop is never called.

The value of mode-line-percent-position is '(-3 "%p").  So in the
second example you propertize the thing which Emacs produces from the
%p mode-line format.  But %p produces a C string, and C strings cannot
have text properties.  That's why handle_display_prop isn't called: it
is never called for C strings we display.

Bottom line: to put text properties on stuff we display on the mode
line, you need to make sure that stuff is a Lisp string.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The value of mode-line-percent-position is '(-3 "%p").  So in the
> second example you propertize the thing which Emacs produces from the
> %p mode-line format.  But %p produces a C string, and C strings cannot
> have text properties.  That's why handle_display_prop isn't called: it
> is never called for C strings we display.

But...  the displayed string does end up with a text property --
help-echo etc.  So text properties work fine, I think?  It's just that
we don't call the `display' handler.

I think.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 15:07:44 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The value of mode-line-percent-position is '(-3 "%p").  So in the
> > second example you propertize the thing which Emacs produces from the
> > %p mode-line format.  But %p produces a C string, and C strings cannot
> > have text properties.  That's why handle_display_prop isn't called: it
> > is never called for C strings we display.
> 
> But...  the displayed string does end up with a text property --
> help-echo etc.  So text properties work fine, I think?  It's just that
> we don't call the `display' handler.

I didn't say text properties on the mode line didn't work, I just
explained why we disregard text properties that are put on C strings.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> But...  the displayed string does end up with a text property --
>> help-echo etc.  So text properties work fine, I think?  It's just that
>> we don't call the `display' handler.
>
> I didn't say text properties on the mode line didn't work, I just
> explained why we disregard text properties that are put on C strings.

Right, but I still don't understand how the display (resulting from
those C strings) does have text properties, while we're not heeding the
`display' property.  Is this a bug?

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 15:16:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But...  the displayed string does end up with a text property --
> >> help-echo etc.  So text properties work fine, I think?  It's just that
> >> we don't call the `display' handler.
> >
> > I didn't say text properties on the mode line didn't work, I just
> > explained why we disregard text properties that are put on C strings.
> 
> Right, but I still don't understand how the display (resulting from
> those C strings) does have text properties, while we're not heeding the
> `display' property.  Is this a bug?

The properties are put on the mode-line elements that are Lisp
strings, in display_mode_element.  "%p" starts as a Lisp string (it
comes from bindings.el), so we do put all those text properties,
including min-width, on the Lisp string whose contents is "%p".  But
when we come to _displaying_ the result of evaluating %p, we disregard
the 'display' property on the result, because the result is a C
string.

Given this description, what exactly do you mean when you say you
don't understand "how the display (resulting from those C strings)
does have text properties"?  How do you see that "the display does
have text properties"?

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Given this description, what exactly do you mean when you say you
> don't understand "how the display (resulting from those C strings)
> does have text properties"?  How do you see that "the display does
> have text properties"?

When hovering over "10%", Emacs displays the `help-echo' text property.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 13:09:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Given this description, what exactly do you mean when you say you
> > don't understand "how the display (resulting from those C strings)
> > does have text properties"?  How do you see that "the display does
> > have text properties"?
> 
> When hovering over "10%", Emacs displays the `help-echo' text property.

Ah, that.  It's an illusion which we create in this fragment from
display_mode_element:

		      case MODE_LINE_DISPLAY:
			{
			  int nglyphs_before, nwritten;

			  nglyphs_before = it->glyph_row->used[TEXT_AREA];
			  nwritten = display_string (spec, string, elt,
						     charpos, 0, it,
						     field, prec, 0,
						     multibyte);

			  /* Assign to the glyphs written above the
			     string where the `%x' came from, position
			     of the `%'.  */
			  if (nwritten > 0)
			    {
			      struct glyph *glyph
				= (it->glyph_row->glyphs[TEXT_AREA]
				   + nglyphs_before);
			      int i;

			      for (i = 0; i < nwritten; ++i)
				{
				  glyph[i].object = elt;
				  glyph[i].charpos = charpos;
				}

			      n += nwritten;
			    }

As you see, after display_string (where any 'display' properties can
be consulted and acted upon) does its job and produces some glyphs for
display on the mode line, we manually assign to each produced glyph
the original object from which those glyphs came.  In this case, that
object is the Lisp string whose text is "%p" and whose text properties
include help-echo etc.  Then, when the mouse hovers over that part of
the mode line, the code in note_mode_line_or_margin_highlight examines
the object recorded in the glyph below the mouse pointer, and extracts
the help-echo stuff.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Ah, that.  It's an illusion which we create in this fragment from
> display_mode_element:
>
> 		      case MODE_LINE_DISPLAY:
> 			{
> 			  int nglyphs_before, nwritten;
>
> 			  nglyphs_before = it->glyph_row->used[TEXT_AREA];
> 			  nwritten = display_string (spec, string, elt,
> 						     charpos, 0, it,
> 						     field, prec, 0,
> 						     multibyte);
>
> 			  /* Assign to the glyphs written above the
> 			     string where the `%x' came from, position
> 			     of the `%'.  */

Ah, I see.  Then perhaps the solution here is to call handle_stop at a
strategic place in the C string case.  I'll poke at the problem some
more, but probably not this weekend.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 15:15:53 +0100
> 
> > 			  /* Assign to the glyphs written above the
> > 			     string where the `%x' came from, position
> > 			     of the `%'.  */
> 
> Ah, I see.  Then perhaps the solution here is to call handle_stop at a
> strategic place in the C string case.

How would you know where to call it?  When display_string produces the
glyphs for the result of "%p", all it sees is a C string like "26%".
I don't see how it could reach out to the original mode-line spec.
the above code runs only _after_ display_string returns.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> How would you know where to call it?  When display_string produces the
> glyphs for the result of "%p", all it sees is a C string like "26%".
> I don't see how it could reach out to the original mode-line spec.
> the above code runs only _after_ display_string returns.

Yes, it'd have to call the `display' machinery before doing the C
string, I think?  I haven't poked at the code yet, so I'm not sure.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 14:40:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How would you know where to call it?  When display_string produces the
> > glyphs for the result of "%p", all it sees is a C string like "26%".
> > I don't see how it could reach out to the original mode-line spec.
> > the above code runs only _after_ display_string returns.
> 
> Yes, it'd have to call the `display' machinery before doing the C
> string, I think?

That's crazy (forgive my French).  It is much cleaner to produce a
Lisp string with the result of %p (or whatever), with the 'display'
property on it, and use that in the mode line instead.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> That's crazy (forgive my French).  It is much cleaner to produce a
> Lisp string with the result of %p (or whatever), with the 'display'
> property on it, and use that in the mode line instead.

Instead of that hack that copies over the display properties afterwards?
Sounds good to me.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 15:00:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's crazy (forgive my French).  It is much cleaner to produce a
> > Lisp string with the result of %p (or whatever), with the 'display'
> > property on it, and use that in the mode line instead.
> 
> Instead of that hack that copies over the display properties afterwards?
> Sounds good to me.

That hack will need to stay, because we cannot unsupport the old
mode-line code.  It just won't be used with the new mode-line faces.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> That hack will need to stay, because we cannot unsupport the old
> mode-line code.  It just won't be used with the new mode-line faces.

Hm...  I don't quite follow you.  What are you proposing to do here in
practice?  (Or perhaps it'd be faster if you just adjusted the code
yourself instead of splainin.  😀)

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

Re: Tick Reduction

[Eli Zaretskii]

> Date: Mon, 29 Nov 2021 16:06:31 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru
> 
> That hack will need to stay, because we cannot unsupport the old
> mode-line code.  It just won't be used with the new mode-line faces.

There's one other alternative: extend display_string to accept
FIELD_WIDTH in pixel units (or add another argument to that effect).
This could be set by examining the 'display' property before calling
display_string.  The disadvantage is that only the min-width spec
could be supported this way for mode-line constructs that are produced
from C strings.

Re: Tick Reduction

[Eli Zaretskii]

> Date: Mon, 29 Nov 2021 16:17:12 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> There's one other alternative: extend display_string to accept
> FIELD_WIDTH in pixel units (or add another argument to that effect).
> This could be set by examining the 'display' property before calling
> display_string.  The disadvantage is that only the min-width spec
> could be supported this way for mode-line constructs that are produced
> from C strings.

Are you okay with this idea?  If so, I can work on it.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> There's one other alternative: extend display_string to accept
>> FIELD_WIDTH in pixel units (or add another argument to that effect).
>> This could be set by examining the 'display' property before calling
>> display_string.  The disadvantage is that only the min-width spec
>> could be supported this way for mode-line constructs that are produced
>> from C strings.
>
> Are you okay with this idea?  If so, I can work on it.

Yes, great!

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

Re: Tick Reduction

[Feng Shu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>
> (insert "||" (propertize "foo" 'min-width '(10.0)) "||")
>

I have try the below test in newest code, and seem to get different result,
any different?

这是测试

;; test1
(progn
  (add-display-text-property 1 2 'min-width '(10.0))
  (add-display-text-property 2 3 'min-width '(10.0))
  (add-display-text-property 3 4 'min-width '(10.0)))

;; test2
(dolist (i '(1 2 3))
  (add-display-text-property i (+ i 1) 'min-width '(10.0)))

Re: Tick Reduction

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,
>   stefankangas@gmail.com,  dgutov@yandex.ru
> Date: Thu, 25 Nov 2021 07:10:49 +0800
> 
> I have try the below test in newest code, and seem to get different result,
> any different?
> 
> 这是测试
> 
> ;; test1
> (progn
>   (add-display-text-property 1 2 'min-width '(10.0))
>   (add-display-text-property 2 3 'min-width '(10.0))
>   (add-display-text-property 3 4 'min-width '(10.0)))
> 
> ;; test2
> (dolist (i '(1 2 3))
>   (add-display-text-property i (+ i 1) 'min-width '(10.0)))

I think it's a bug related to the way the current implementation
identifies where the property ends.  (The second example uses the same
list as the value, whereas the first example uses 3 different lists,
although they have the same contents.)

The current code is not yet ready for prime time IMO, and Lars
intended to work on it soon.  Stay tuned.

Re: Tick Reduction

[Lars Ingebrigtsen]

"Feng Shu" <tumashu@163.com> writes:

> I have try the below test in newest code, and seem to get different result,
> any different?
>
> 这是测试
>
> ;; test1
> (progn
>   (add-display-text-property 1 2 'min-width '(10.0))
>   (add-display-text-property 2 3 'min-width '(10.0))
>   (add-display-text-property 3 4 'min-width '(10.0)))
>
> ;; test2
> (dolist (i '(1 2 3))
>   (add-display-text-property i (+ i 1) 'min-width '(10.0)))

Yes, that's working as designed.  It identifies a range of characters by
using `eq' on the list containing the width, and in the first example
you have three different lists, and in the last example you have the
same list applied three times, so it's `eq' all the way.

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

Re: Tick Reduction

[chad]

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

On Sun, Nov 21, 2021 at 12:18 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> > They are numbers, so they can change the width because different
> > digits have different width.
>
> No, they don't (in the vast majority of proportional fonts).
>

You're both right.

More specifically, the details are more complicated than it might appear.
When typesetting numbers, there's a feature called "tabular figures" that
uses alternative glyphs to make everything line up in columns. This applies
to proportion fonts even if the "normal" numerals aren't the same width (or
the same size), and can be extended to include number-related glyphs that
are likely to appear in tabular layouts, such as making things like
"12345", "(234)", "-2345", "$2345", "1234%", etc. always be the same width.
A similar feature makes tabular figures the same size in bold, italic, and
roman scripts.

Wikipedia has some details here:
https://en.wikipedia.org/wiki/Typeface#Typesetting_numbers
Another potentially useful reference:
https://www.fonts.com/content/learning/fontology/level-3/numbers/proportional-vs-tabular-figures

I can certainly imagine situations where emacs might want each of these
options. I think that this conversation is suggesting that the mode-line
mostly wants tabular figures, and I can imagine something similar in, as an
example, dired buffers.

Hope that helps,
~Chad

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

Re: Tick Reduction

[Lars Ingebrigtsen]

By the way, reading the manual on the `space' display thing, I don't
quite understand this bit:

@item :relative-width @var{factor}
Specifies that the width of the stretch should be computed from the
first character in the group of consecutive characters that have the
same @code{display} property.  The space width is the pixel width of
that character, multiplied by @var{factor}.  (On text-mode terminals,
the ``pixel width'' of a character is usually 1, but it could be more
for TABs and double-width CJK characters.)

:relative-width is used only one place in our code base, and I'm not
quite sure what it's trying to achieve there, either.

The doc string here seems to be saying something about a series of
characters, but the one usage we have only puts it on a single
character, apparently?

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org,  stefankangas@gmail.com,  dgutov@yandex.ru
> Date: Sun, 21 Nov 2021 21:10:29 +0100
> 
> @item :relative-width @var{factor}
> Specifies that the width of the stretch should be computed from the
> first character in the group of consecutive characters that have the
> same @code{display} property.  The space width is the pixel width of
> that character, multiplied by @var{factor}.  (On text-mode terminals,
> the ``pixel width'' of a character is usually 1, but it could be more
> for TABs and double-width CJK characters.)
> 
> :relative-width is used only one place in our code base, and I'm not
> quite sure what it's trying to achieve there, either.
> 
> The doc string here seems to be saying something about a series of
> characters, but the one usage we have only puts it on a single
> character, apparently?

This is a 'display' text property, right?  It is placed on text;
instead of that text Emacs will display a stretch glyph (white space)
whose width is calculated as the pixel width of the first character
"covered" by the property multiplied by FACTOR.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This is a 'display' text property, right?  It is placed on text;
> instead of that text Emacs will display a stretch glyph (white space)
> whose width is calculated as the pixel width of the first character
> "covered" by the property multiplied by FACTOR.

(shr-string-pixel-width
 (propertize "칹a" 'display '(space :relative-width 1)))
=> 22

(shr-string-pixel-width
 (propertize "a칹" 'display '(space :relative-width 1)))
=> 22

The first one should be a lot wider than the second, but I seem to be
getting the exact same width no matter what I do?

The only in-tree usage is this:

(defconst org-table-separator-space
  (propertize " " 'display '(space :relative-width 1))

And that's concat-ed with other bits.

(let ((start (point)))
  (insert "칹a")
  (put-text-property start (point) 'display '(space :relative-width 1)))

seems to give the same results...

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

Re: Tick Reduction

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (defconst org-table-separator-space
>   (propertize " " 'display '(space :relative-width 1))

This is apparently the code?  It talks about a `glyph' property?  But...
only in the comments?  

  else if (prop = Fplist_get (plist, QCrelative_width), NUMVAL (prop) > 0)
    {
      /* Relative width `:relative-width FACTOR' specified and valid.
	 Compute the width of the characters having the `glyph'
	 property.  */
      struct it it2;
      unsigned char *p = BYTE_POS_ADDR (IT_BYTEPOS (*it));

      it2 = *it;
      if (it->multibyte_p)
	it2.c = it2.char_to_display = string_char_and_length (p, &it2.len);
      else
	{
	  it2.c = it2.char_to_display = *p, it2.len = 1;
	  if (! ASCII_CHAR_P (it2.c))
	    it2.char_to_display = BYTE8_TO_CHAR (it2.c);
	}

      it2.glyph_row = NULL;
      it2.what = IT_CHARACTER;
      PRODUCE_GLYPHS (&it2);
      width = NUMVAL (prop) * it2.pixel_width;
    }

and

   2. `:relative-width FACTOR' specifies that the width of the stretch
   should be computed from the width of the first character having the
   `glyph' property, and should be FACTOR times that width.

Hm...

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 21 Nov 2021 21:41:30 +0100
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > (defconst org-table-separator-space
> >   (propertize " " 'display '(space :relative-width 1))
> 
> This is apparently the code?  It talks about a `glyph' property?  But...
> only in the comments?  
> 
>   else if (prop = Fplist_get (plist, QCrelative_width), NUMVAL (prop) > 0)
>     {
>       /* Relative width `:relative-width FACTOR' specified and valid.
> 	 Compute the width of the characters having the `glyph'
> 	 property.  */

Ignore that comment, it makes no sense.

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org,  stefankangas@gmail.com,  dgutov@yandex.ru
> Date: Sun, 21 Nov 2021 21:28:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is a 'display' text property, right?  It is placed on text;
> > instead of that text Emacs will display a stretch glyph (white space)
> > whose width is calculated as the pixel width of the first character
> > "covered" by the property multiplied by FACTOR.
> 
> (shr-string-pixel-width
>  (propertize "칹a" 'display '(space :relative-width 1)))
> => 22
> 
> (shr-string-pixel-width
>  (propertize "a칹" 'display '(space :relative-width 1)))
> => 22

A bug?

Re: Tick Reduction

[Eli Zaretskii]

> Date: Sun, 21 Nov 2021 22:42:30 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: emacs-devel@gnu.org,  stefankangas@gmail.com,  dgutov@yandex.ru
> > Date: Sun, 21 Nov 2021 21:28:27 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > This is a 'display' text property, right?  It is placed on text;
> > > instead of that text Emacs will display a stretch glyph (white space)
> > > whose width is calculated as the pixel width of the first character
> > > "covered" by the property multiplied by FACTOR.
> > 
> > (shr-string-pixel-width
> >  (propertize "칹a" 'display '(space :relative-width 1)))
> > => 22
> > 
> > (shr-string-pixel-width
> >  (propertize "a칹" 'display '(space :relative-width 1)))
> > => 22
> 
> A bug?

Definitely a bug.  I have a provisional fix, and will install
tomorrow, together with a fix for another bug: the current code
doesn't support this property on a string (as opposed to on buffer
text).

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Definitely a bug.  I have a provisional fix, and will install
> tomorrow, together with a fix for another bug: the current code
> doesn't support this property on a string (as opposed to on buffer
> text).

Ah, I see.

I'm still not quite sure what the use case is, which perhaps explains
why it's not used.  (Well, along with it not working.  😀)

If you say (propertize "😀foo" '(space :relative-width 1)) then it's
supposed to make a space that's two normal characters wide?  (Since 😀
has a char-width of 2.)  Hm...  Well, OK, I can vaguely see how that
might be useful, but it seems like it would be as easy to just say

(propertize "😀foo" `(space :width ,(char-width ?😀)))

wouldn't it?

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 22 Nov 2021 12:22:37 +0100
> 
> If you say (propertize "😀foo" '(space :relative-width 1)) then it's
> supposed to make a space that's two normal characters wide?  (Since 😀
> has a char-width of 2.)

No, not on GUI frames.  On GUI frames this works at pixel resolution,
so it produces (or should, but currently fails to produce) a stretch
of whitespace whose pixel width is exactly like that of the glyph for
😀 produced by your font.  char-width is only for TTY frames and for
crude approximations on GUI frames.

> Well, OK, I can vaguely see how that
> might be useful, but it seems like it would be as easy to just say
> 
> (propertize "😀foo" `(space :width ,(char-width ?😀)))
> 
> wouldn't it?

As easy, yes.  But it's supposed to be much more accurate than
char-width.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> No, not on GUI frames.  On GUI frames this works at pixel resolution,
> so it produces (or should, but currently fails to produce) a stretch
> of whitespace whose pixel width is exactly like that of the glyph for
> 😀 produced by your font.  char-width is only for TTY frames and for
> crude approximations on GUI frames.

Ah, I see.  And we didn't have `string-pixel-width' in the olden days,
so this would be a way to line stuff up without knowing that.  And it's
dynamic, so if you change the font (or instantiate on a different
display/frame type), then things will still line up.

OK, I can see how it could be useful now.

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

Re: Tick Reduction

[Eli Zaretskii]

> Date: Sun, 21 Nov 2021 23:12:24 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru
> 
> > > (shr-string-pixel-width
> > >  (propertize "칹a" 'display '(space :relative-width 1)))
> > > => 22
> > > 
> > > (shr-string-pixel-width
> > >  (propertize "a칹" 'display '(space :relative-width 1)))
> > > => 22
> > 
> > A bug?
> 
> Definitely a bug.  I have a provisional fix, and will install
> tomorrow, together with a fix for another bug: the current code
> doesn't support this property on a string (as opposed to on buffer
> text).

Fixed on the release branch.  I figured out that, given only one
caller and the localized fix, we might as well fix this embarrassing
bug in Emacs 28.

Re: Tick Reduction

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps the rest of the text in `C-h C-h' should also use a proportional
> font?  I.e., everything but the keys.

It looks like this before:

[-- Attachment #2: Type: text/plain, Size: 13 bytes --]


And after:


[-- Attachment #3: h-h-fixed-pitch.png --]
[-- Type: image/png, Size: 86167 bytes --]

[-- Attachment #4: h-h-variable-pitch.png --]
[-- Type: image/png, Size: 85516 bytes --]

[-- Attachment #5: Type: text/plain, Size: 1936 bytes --]


To my eyes, it looks really good.  A marked improvement.

Here is the diff (make sure to rm lisp/help.elc before testing):

diff --git a/lisp/faces.el b/lisp/faces.el
index 9ec20c4298..ee805ede8a 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2883,13 +2883,17 @@ help-key-binding
      ;; making the characters wider, which then would cause unpleasant
      ;; horizontal shifts of the cursor during C-n/C-p movement
      ;; through a line with this face.
-     :box (:line-width (-1 . -1) :color "grey80"))
+     :box (:line-width (-1 . -1) :color "grey80")
+     :inherit fixed-pitch)
     (((class color) (min-colors 88) (background dark))
      :background "grey19" :foreground "LightBlue"
-     :box (:line-width (-1 . -1) :color "grey35"))
-    (((class color grayscale) (background light)) :background "grey90")
-    (((class color grayscale) (background dark)) :background "grey25")
-    (t :background "grey90"))
+     :box (:line-width (-1 . -1) :color "grey35")
+     :inherit fixed-pitch)
+    (((class color grayscale) (background light)) :background "grey90"
+     :inherit fixed-pitch)
+    (((class color grayscale) (background dark)) :background "grey25"
+     :inherit fixed-pitch)
+    (t :background "grey90" :inherit fixed-pitch))
   "Face for keybindings in *Help* buffers.
 
 This face is added by `substitute-command-keys', which see.
diff --git a/lisp/help-macro.el b/lisp/help-macro.el
index 1fa9d82afd..8eba7b7cda 100644
--- a/lisp/help-macro.el
+++ b/lisp/help-macro.el
@@ -140,6 +140,7 @@ make-help-screen
                    (insert (substitute-command-keys help-screen)))
                  (let ((minor-mode-map-alist new-minor-mode-map-alist))
                    (help-mode)
+                   (variable-pitch-mode)
                    (setq new-minor-mode-map-alist minor-mode-map-alist))
                  (goto-char (point-min))
                  (while (or (memq char (append help-event-list

Re: Tick Reduction

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> To my eyes, it looks really good.  A marked improvement.

Looks good to me too, but this reminded me of one thing: Emacs (by
default) chooses a variable-pitch font that is markedly smaller than the
monospaced font, in my experience, and you can see the same in your
screenshot.  So I have this in my .emacs:

(set-face-attribute 'variable-pitch nil :height 130)

I think we should look into that, because the height discrepancy between
those two fonts is disturbing -- see the "(see also M-x apropos)" line
in your screenshot.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Nov 2021 09:39:28 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > To my eyes, it looks really good.  A marked improvement.
> 
> Looks good to me too, but this reminded me of one thing: Emacs (by
> default) chooses a variable-pitch font that is markedly smaller than the
> monospaced font, in my experience, and you can see the same in your
> screenshot.

Here the font of variable-pitch face is actually larger by a pixel or
two, but this is MS-Windows.

> I think we should look into that

It probably has something to do with how we choose fonts, and also
with which fonts are available.

Re: Tick Reduction

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Looks good to me too, but this reminded me of one thing: Emacs (by
>> default) chooses a variable-pitch font that is markedly smaller than the
>> monospaced font, in my experience, and you can see the same in your
>> screenshot.
>
> Here the font of variable-pitch face is actually larger by a pixel or
> two, but this is MS-Windows.
>
>> I think we should look into that
>
> It probably has something to do with how we choose fonts, and also
> with which fonts are available.

Hm -- I wonder whether things have changed, because if I try it in
"emacs -Q" now, it doesn't look as bad as I think I remember it being:


[-- Attachment #2: Type: image/png, Size: 11243 bytes --]

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


It's just a pixel or two shorter now.  But that's probably because I'm
using a different font these days.

But, yes, we should have a look at how we choose this font and see
whether we can get a more precise height match.  It's going to be more
important if we're starting to use variable pitch faces more.

To return to the subject of filling -- I don't think we have enough
regularity in the doc strings to do that.  We've previously discussed (a
few years back) how to do paragraphs in doc strings, and we decided to
do that with an empty line -- but there's still tons of doc strings that
are formatted like:

----
This is the first paragraphs, and here's
the second line.
This is obviously the second paragraph, and
you can tell because of how that second line
was shorter, can't you?  Absolutely, you can.
And this is the third paragraph, and now
things get complicated.
----

So if we're going to fill, we'd have to audit the doc strings.  And
that's a huge job.  So I don't think we can do filling.

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

Re: Tick Reduction

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Here the font of variable-pitch face is actually larger by a pixel or
> two, but this is MS-Windows.

I suspect that the fonts used are from two different font families, and
thus have different x-heights.  Could you check which fonts are being
used for both variable-pitch and fixed-pitch, and which font sizes are
reported by Emacs when one looks larger than the other?

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 19 Nov 2021 11:28:52 +0100
> Cc: emacs-devel@gnu.org, dgutov@yandex.ru
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Here the font of variable-pitch face is actually larger by a pixel or
> > two, but this is MS-Windows.
> 
> I suspect that the fonts used are from two different font families, and
> thus have different x-heights.

Of course they are from different families, otherwise how can one be
fixed-pitch and the other variable-pitch.  It is rare for the same
family to provide both.

> Could you check which fonts are being used for both variable-pitch
> and fixed-pitch, and which font sizes are reported by Emacs when one
> looks larger than the other?

Both have the height of 13, according to "C-u C-x =".  And in a
debugger I see that both faces have the height attribute of 98 (in
units of 1/10 point).  So it sounds like Emacs thinks these have the
same height, and still the line height changes by about 1 pixel
depending on whether I do or don't use the variable-pitch face on that
line.  Maybe I'm missing something.

Re: Tick Reduction

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Of course they are from different families, otherwise how can one be
> fixed-pitch and the other variable-pitch.  It is rare for the same
> family to provide both.

On GNU/Linux, or at least on my machine, they are the same family in
"emacs -Q" (Bitstream Vera Sans / Bitstream Vera Sans Mono).

> Both have the height of 13, according to "C-u C-x =".  And in a
> debugger I see that both faces have the height attribute of 98 (in
> units of 1/10 point).  So it sounds like Emacs thinks these have the
> same height, and still the line height changes by about 1 pixel
> depending on whether I do or don't use the variable-pitch face on that
> line.  Maybe I'm missing something.

Oh, I was so focussed on the x-height that I missed that you were discussing a
difference in the line height.

Do you observe this using the `C-h C-h' example?  If yes, could the
explanation be some difference in how the :box attribute we set in
`help-key-binding' works on MS-Windows vs. on GNU/Linux?  Just a guess.

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 19 Nov 2021 14:04:09 +0100
> Cc: larsi@gnus.org, emacs-devel@gnu.org, dgutov@yandex.ru
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Of course they are from different families, otherwise how can one be
> > fixed-pitch and the other variable-pitch.  It is rare for the same
> > family to provide both.
> 
> On GNU/Linux, or at least on my machine, they are the same family in
> "emacs -Q" (Bitstream Vera Sans / Bitstream Vera Sans Mono).

Is that the default that corresponds to standard-fontset-spec in
fontset.el, or did you tweak your system or Emacs to use that family?

> > Both have the height of 13, according to "C-u C-x =".  And in a
> > debugger I see that both faces have the height attribute of 98 (in
> > units of 1/10 point).  So it sounds like Emacs thinks these have the
> > same height, and still the line height changes by about 1 pixel
> > depending on whether I do or don't use the variable-pitch face on that
> > line.  Maybe I'm missing something.
> 
> Oh, I was so focussed on the x-height that I missed that you were discussing a
> difference in the line height.
> 
> Do you observe this using the `C-h C-h' example?  If yes, could the
> explanation be some difference in how the :box attribute we set in
> `help-key-binding' works on MS-Windows vs. on GNU/Linux?  Just a guess.

I don't think I follow: there's no variable-pitch face, or any face
that inherits from it, in the "C-h C-h" display, AFAICT.  What am I
missing?

Re: Tick Reduction

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Is that the default that corresponds to standard-fontset-spec in
> fontset.el, or did you tweak your system or Emacs to use that family?

They come automatically if you install emacs-gtk (gtk depends on pango,
pango depends on fontconfig, fontconfig depends on ttf-bitstream-vera
that has these two fonts).  With emacs-lucid, you have a direct
dependency on fontconfig so its the same thing there.

> I don't think I follow: there's no variable-pitch face, or any face
> that inherits from it, in the "C-h C-h" display, AFAICT.  What am I
> missing?

Oh, I didn't install that patch yet, did I?  I forgot about that little
detail...  So my guess was not a winner.

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 19 Nov 2021 14:41:11 +0100
> Cc: larsi@gnus.org, emacs-devel@gnu.org, dgutov@yandex.ru
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is that the default that corresponds to standard-fontset-spec in
> > fontset.el, or did you tweak your system or Emacs to use that family?
> 
> They come automatically if you install emacs-gtk (gtk depends on pango,
> pango depends on fontconfig, fontconfig depends on ttf-bitstream-vera
> that has these two fonts).  With emacs-lucid, you have a direct
> dependency on fontconfig so its the same thing there.

Does emacs-gtk install some site-init files, or does it work via
fontconfig settings or other GTK settings?

If any of the above is true, then it confirms my mental model of this:
Emacs by default doesn't ensure the fixed-pitch and variable-pitch
faces use fonts from the same family.

Re: Tick Reduction

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Does emacs-gtk install some site-init files, or does it work via
> fontconfig settings or other GTK settings?

If I'm not mistaken this happens via fontconfig or similar.  I don't
remember seeing any fonts being set the last time I read Debian's
site-init files.

Re: Tick Reduction

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Looks good to me too, but this reminded me of one thing: Emacs (by
> default) chooses a variable-pitch font that is markedly smaller than the
> monospaced font, in my experience, and you can see the same in your
> screenshot.  So I have this in my .emacs:
>
> (set-face-attribute 'variable-pitch nil :height 130)
>
> I think we should look into that, because the height discrepancy between
> those two fonts is disturbing -- see the "(see also M-x apropos)" line
> in your screenshot.

Here is my analysis.

First, take a look at the below screenshot.  The monospace text uses
Bitstream Vera Sans Mono, and the variable width "M" and "s" on the
sides use Bitstream Vera Sans.  Both are the same size as reported by
`C-u C-x ='.

[-- Attachment #2: Type: text/plain, Size: 301 bytes --]


Both the upper-case and lower-case characters have the same x-height.
Yet they look as if they have different sizes when on the same line
together (and are not immediately next to each other).

I also took these screenshots of the first line, one with an added red
line to make things even clearer:


[-- Attachment #3: mono-vs-prop.png --]
[-- Type: image/png, Size: 4397 bytes --]

[-- Attachment #4: first-line.png --]
[-- Type: image/png, Size: 9947 bytes --]

[-- Attachment #5: first-line-red.png --]
[-- Type: image/png, Size: 12614 bytes --]

[-- Attachment #6: Type: text/plain, Size: 1221 bytes --]


I believe the reason why we get the visual impression that the monospace
font is larger than the proportional, even though they take up as many
vertical pixels, is because it takes up more horizontal space.

Such visual illusions are not entirely uncommon in typography, and the
normal solution is to forget about aligning things "mathematically" or
with a ruler.  (Doing that would be counter-productive when the key
thing is what it looks like to a human reader and not to a machine.)
Instead, you simply eye-ball it.  There's no way around it.

So my conclusion is that Emacs does things "right" here, in the sense
that it doesn't do any adjustments: it just presents the font at the
specified font size.

We probably should make some adjustments to be more appealing to a human
reader, but the tricky part is what exactly to do.  Making the variable
width font slightly larger would work on my machine, but it won't work
if the chosen fonts have different x-heights.  (Eli's report was
illuminating: he seems to have the exact opposite problem from what we
have both observed.)

What, if anything, does TeX do about this?

Does harfbuzz, or something else, provide us with a way to know the
x-height of a character?

Re: Tick Reduction

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I believe the reason why we get the visual impression that the monospace
> font is larger than the proportional, even though they take up as many
> vertical pixels, is because it takes up more horizontal space.

Yes, that does seem like the explanation here.

> Such visual illusions are not entirely uncommon in typography, and the
> normal solution is to forget about aligning things "mathematically" or
> with a ruler.  (Doing that would be counter-productive when the key
> thing is what it looks like to a human reader and not to a machine.)
> Instead, you simply eye-ball it.  There's no way around it.
>
> So my conclusion is that Emacs does things "right" here, in the sense
> that it doesn't do any adjustments: it just presents the font at the
> specified font size.

Yup.

> Does harfbuzz, or something else, provide us with a way to know the
> x-height of a character?

I've poked around briefly, and I don't see anything likely.  fc-query
doesn't say anything about x-height either.  Anybody else know?

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 20 Nov 2021 09:43:34 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > Does harfbuzz, or something else, provide us with a way to know the
> > x-height of a character?
> 
> I've poked around briefly, and I don't see anything likely.  fc-query
> doesn't say anything about x-height either.  Anybody else know?

Emacs knows that for each character it displays.  (Assuming I
understand what "x-height of a character" means in this context.)  We
get the full metrics of the character from the font, and use that for
layout.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Emacs knows that for each character it displays.  (Assuming I
> understand what "x-height of a character" means in this context.)  We
> get the full metrics of the character from the font, and use that for
> layout.

The x-height is literally the height of the lower-case x character.  😀
But it's used as a shorthand to say something about the characteristics
of a font -- the x-height is what matters most for legibility, and the
ascenders (in characters like "b") and descenders (in characters like
"g") are separate things.

Fonts with equal heights but different x-heights mix badly visually.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Sat, 20 Nov 2021 10:26:38 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Emacs knows that for each character it displays.  (Assuming I
> > understand what "x-height of a character" means in this context.)  We
> > get the full metrics of the character from the font, and use that for
> > layout.
> 
> The x-height is literally the height of the lower-case x character.  😀
> But it's used as a shorthand to say something about the characteristics
> of a font -- the x-height is what matters most for legibility, and the
> ascenders (in characters like "b") and descenders (in characters like
> "g") are separate things.

We can easily get the info from the font.  But how do you propose to
use that info?

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> The x-height is literally the height of the lower-case x character.  😀
>> But it's used as a shorthand to say something about the characteristics
>> of a font -- the x-height is what matters most for legibility, and the
>> ascenders (in characters like "b") and descenders (in characters like
>> "g") are separate things.
>
> We can easily get the info from the font.  But how do you propose to
> use that info?

I'm not quite sure.  But picking a variable-pitch font that has the same
x-height as the monospace font we've picked might be nice.  Of course,
that has its drawbacks -- we don't want the total height to be taller,
either.

But perhaps it can go into the mix when searching for an appropriate
font -- if we have several candidates with the correct total height,
preferring the one(s) with the same x-height would be nice, I think?

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Sat, 20 Nov 2021 10:56:41 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The x-height is literally the height of the lower-case x character.  😀
> >> But it's used as a shorthand to say something about the characteristics
> >> of a font -- the x-height is what matters most for legibility, and the
> >> ascenders (in characters like "b") and descenders (in characters like
> >> "g") are separate things.
> >
> > We can easily get the info from the font.  But how do you propose to
> > use that info?
> 
> I'm not quite sure.  But picking a variable-pitch font that has the same
> x-height as the monospace font we've picked might be nice.  Of course,
> that has its drawbacks -- we don't want the total height to be taller,
> either.
>
> But perhaps it can go into the mix when searching for an appropriate
> font -- if we have several candidates with the correct total height,
> preferring the one(s) with the same x-height would be nice, I think?

You want to know this when selecting fonts?  That'd be expensive,
since it requires to open a font,l an expensive operation.  Currently
we avoid opening fonts we consider as candidates, and only open the
one we select.

And of course, no one guarantees we can even find a font with the same
"x-height" as the monospaced font we are using.  It might not exist on
the system.

Re: Tick Reduction

[Lars Ingebrigtsen]

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

I wondered how a browser renders a mix of proportional an monospace
text.  So here's Emacs (with eww):


[-- Attachment #2: Type: image/png, Size: 20068 bytes --]

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


The heights are the same, but visually the monospace text looks a bit on
the big side?

Here's Firefox:


[-- Attachment #4: Type: image/png, Size: 30044 bytes --]

[-- Attachment #5: Type: text/plain, Size: 147 bytes --]


They seem to be going way in the opposite direction -- the monospace
text is significantly smaller than the proportional text.

Here's Chromium:


[-- Attachment #6: Type: image/png, Size: 29585 bytes --]

[-- Attachment #7: Type: text/plain, Size: 582 bytes --]


Same thing as in Firefox.  (HTML test file included below.)

I think that mixture of fonts looks better than the Emacs one -- but the
choice is easier in a browser -- the primary font will definitely be a
proportional one, and the monospace font is secondary.  And in Emacs
it's the opposite -- we can't choose a proportional font that's bigger
than the primary font, because that'll make lines with wonky heights.

OK, here's an idea: What about we don't use the default face for
monospace text in buffers with "primarily" proportional text, but use a
smaller one?  Let's see...


[-- Attachment #8: Type: image/png, Size: 19213 bytes --]

[-- Attachment #9: Type: text/plain, Size: 436 bytes --]


That's with a :height 0.9.  I think that looks visually less messy?

So we'd introduce a new face like this:

(defface fixed-pitch-for-proportional-buffers-but-a-better-name
  '((t :inherit fixed-pitch :height 0.9))
  "The basic fixed-pitch face."
  :group 'basic-faces)

And then use that in these primarily-proportional buffers.

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

[-- Attachment #10: foo.html --]
[-- Type: text/html, Size: 88 bytes --]

Re: Tick Reduction

[Lars Ingebrigtsen]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Here's Chromium:

No, that was just another Firefox window.  :-/

Here's Chromium:


[-- Attachment #2: Type: image/png, Size: 20254 bytes --]

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


So that's halfway between Firefox and Emacs -- the monospace font has
the same x-height as the proportional font, but lower overall height, I
think.

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

Re: Tick Reduction

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So that's halfway between Firefox and Emacs -- the monospace font has
> the same x-height as the proportional font, but lower overall height, I
> think.

Hmm, it's hard to say why they do that.  Either they have consciously
gone in a different direction, or Chrome (being the newer browser) just
never bothered to clean this up as Firefox has.

The considerations will perhaps be slightly different for a text editor
though, where we are concerned not just with display but also effective
editing (i.e. an even greater need to pick things out to avoid
mistakes).

The Firefox way seems more in line with what you would see in a printed
manual, and has the benefit that the monospace text stands out more
clearly.  I prefer it for that reason.  However, it would also mean
doing more work.

One idea is to just keep what we have now, and get more experience with
it as we introduce a proportional font in more places.  Once we have
more examples to look at and consider, we could decide if we want to
invest more work in making any improvements in one direction or another.

Re: Tick Reduction

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> The Firefox way seems more in line with what you would see in a printed
> manual, and has the benefit that the monospace text stands out more
> clearly.  I prefer it for that reason.  However, it would also mean
> doing more work.

Well...  it's not a lot more work.  We just define a fixed-pitch face
that's 0.9 of the normal fixed-pitch face, and that'll hopefully be the
right thing in most cases.  (And then use it in primarily-proportional
buffers.)

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

Re: Tick Reduction

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> To my eyes, it looks really good.  A marked improvement.
>
> Looks good to me too,

I installed the patch for now, under the assumption that the issues
raised in this subthread will be easier to work on if it is installed
first.  (More people can test and report their findings, etc.)

Re: Tick Reduction

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I installed the patch for now, under the assumption that the issues
> raised in this subthread will be easier to work on if it is installed
> first.  (More people can test and report their findings, etc.)

Hm, I'm still getting monospaced faces in `C-h C-h' (with "emacs -Q").

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

Re: Tick Reduction

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> I installed the patch for now, under the assumption that the issues
>> raised in this subthread will be easier to work on if it is installed
>> first.  (More people can test and report their findings, etc.)
>
> Hm, I'm still getting monospaced faces in `C-h C-h' (with "emacs -Q").

Did you say "rm lisp/help.elc"?

Re: Tick Reduction

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Did you say "rm lisp/help.elc"?

Nope.  But I did it now, and it is indeed not monospaced any more.
Looks nice.    😀

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

Use variable-pitch face in more places

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, I think we should work towards using proportional fonts throughout
> Emacs (where it makes sense) in the Emacs 29 cycle to get a more
> consistent and modern look.  For instance, "emacs -Q" uses proportional
> fonts in the menus and the toolbars (on most systems), but not in the
> mode line or the header lines.

So here's some low-hanging fruit: the header-line and breadcrumb in info.

I'm not sure if the header-line should perhaps just default to use a
proportional font though?  In tabulated-list-mode, we use :align-to so
there is nothing there that would immediately break.  And any place
where we don't use :align-to, we should perhaps just fix in any case.
I'm not sure, which is why I am asking.

[-- Attachment #2: 0001-Use-variable-pitch-in-Info-header-line-and-breadcrum.patch --]
[-- Type: application/octet-stream, Size: 1497 bytes --]

From ce967f91792920426f8fcc1335dd01c5b0935abc Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Mon, 22 Nov 2021 15:41:35 +0100
Subject: [PATCH] Use variable-pitch in Info header-line and breadcrumb

* lisp/info.el (Info-fontify-node): Use 'variable-pitch' face in
'header-line' and breadcrumb.
---
 lisp/info.el | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lisp/info.el b/lisp/info.el
index cd4c867f4e..6e393fa0ee 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -4827,14 +4827,17 @@ Info-fontify-node
 			       (replace-regexp-in-string
 				"%"
 				;; Preserve text properties on duplicated `%'.
-				(lambda (s) (concat s s)) header))
+                                (lambda (s) (concat s s))
+                                (propertize header
+                                            'face 'variable-pitch)))
             ;; Hide the part of the first line
             ;; that is in the header, if it is just part.
             (cond
              ((> Info-breadcrumbs-depth 0)
 	      (let ((ov (make-overlay (point-min) (1+ header-end))))
-		(overlay-put ov 'display (Info-breadcrumbs))
-		(overlay-put ov 'evaporate t)))
+                (overlay-put ov 'display (Info-breadcrumbs))
+                (overlay-put ov 'evaporate t)
+                (overlay-put ov 'face 'variable-pitch)))
              ((not (bobp))
               ;; Hide the punctuation at the end, too.
               (skip-chars-backward " \t,")
-- 
2.33.0

Re: Use variable-pitch face in more places

[Stefan Kangas]

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

Stefan Kangas <stefankangas@gmail.com> writes:

> So here's some low-hanging fruit: the header-line and breadcrumb in info.

Please find attached a screenshot.

[-- Attachment #2: info-variable-pitch.png --]
[-- Type: image/png, Size: 43394 bytes --]

Re: Use variable-pitch face in more places

[Juri Linkov]

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

> So here's some low-hanging fruit: the header-line and breadcrumb in info.

Thanks, it looks much nicer with variable-pitch.  But the problem is that
before this change the links on the header line were highlighted as links
with blue color, but the patch overwrites all faces with variable-pitch face.
I guess the faces should be merged here, maybe with add-face-text-property?


[-- Attachment #2: info-header-line.png --]
[-- Type: image/png, Size: 55539 bytes --]

Re: Use variable-pitch face in more places

[Stefan Kangas]

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

Juri Linkov <juri@linkov.net> writes:

> Thanks, it looks much nicer with variable-pitch.  But the problem is that
> before this change the links on the header line were highlighted as links
> with blue color, but the patch overwrites all faces with variable-pitch face.
> I guess the faces should be merged here, maybe with add-face-text-property?

Thanks for noticing this.  Fixed patch attached, as well as a new screenshot.

[-- Attachment #2: 0001-Use-variable-pitch-in-Info-header-line-and-breadcrum.patch --]
[-- Type: application/x-patch, Size: 1262 bytes --]

[-- Attachment #3: variable-pitch-info-2.png --]
[-- Type: image/png, Size: 26630 bytes --]

Re: Use variable-pitch face in more places

[Juri Linkov]

>> Thanks, it looks much nicer with variable-pitch.  But the problem is that
>> before this change the links on the header line were highlighted as links
>> with blue color, but the patch overwrites all faces with variable-pitch face.
>> I guess the faces should be merged here, maybe with add-face-text-property?
>
> Thanks for noticing this.  Fixed patch attached, as well as a new screenshot.
>
> +            (add-face-text-property 0 (length header)
> +                                    'variable-pitch nil header)

Sorry, I don't know why add-face-text-property has no effect,
and doesn't add variable-pitch 🤔

Re: Use variable-pitch face in more places

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Thanks for noticing this.  Fixed patch attached, as well as a new screenshot.

I think that looks really nice.

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

Re: Use variable-pitch face in more places

[Juri Linkov]

>> Thanks for noticing this.  Fixed patch attached, as well as a new screenshot.
>
> I think that looks really nice.

I tried really hard, but can't see variable-pitch on the header line 🤓
And indeed, my suggestion to use add-face-text-property was wrong, sorry.
The correct function name can be found in these commented out
lines in Info-breadcrumbs:

    ;; (font-lock-append-text-property 0 (length line)
    ;; 				    'font-lock-face 'header-line line)

Only then the header-line shows variable-pitch on the header line:

diff --git a/lisp/info.el b/lisp/info.el
index cd4c867f4e..43be21c570 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -4822,6 +4822,8 @@ Info-fontify-node
                         (concat "No next, prev or up links  --  "
                                 (buffer-substring (point) header-end))
                       (buffer-substring (point) header-end)))))
+            (font-lock-append-text-property
+             0 (length header) 'font-lock-face 'variable-pitch header)
             (put-text-property (point-min) (1+ (point-min))
                                'header-line
 			       (replace-regexp-in-string
-- 

Re: Use variable-pitch face in more places

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I tried really hard, but can't see variable-pitch on the header line 🤓
> And indeed, my suggestion to use add-face-text-property was wrong, sorry.
> The correct function name can be found in these commented out
> lines in Info-breadcrumbs:

Hm.  When I do an "emacs -Q" and then `C-h i', I get the header line in
a proportional font (on the current trunk).  Did you fix this already?

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

Re: Use variable-pitch face in more places

[Juri Linkov]

> Hm.  When I do an "emacs -Q" and then `C-h i', I get the header line in
> a proportional font (on the current trunk).  Did you fix this already?

  (defface header-line
    '((default
       :inherit mode-line) 😋

But proportional fonts in the header line looks great.
I tested with different modes that use the header line:
Info, proced, tabulated-list, even ruler-mode, and everywhere
the header line with proportional fonts is really nice.
Also there is no problems in the mode line: I tested that
there is no shift jumping left and right while scrolling
adds digits to the column/line indicator, etc.

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 19 Nov 2021 07:50:18 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> >> Might be worth trying, although I don't find examples of using
> >> proportional fonts in Emacs that I like often.
> 
> Could it be that you are using a suboptimal font?  In my experience,
> finding a really good one makes a big difference.

If finding such good fonts is a significant effort, we could have
users complain about ugly display because they didn't invest that
effort.  This stuff should work OOTB as much as possible, or else we
should make it opt-in.

> As you Lars pointed out in your thread about proportional fonts in the
> mode line, doing that will also help Emacs look more contemporary.
> There are of course many cases where it just won't work, but in other
> cases it absolutely will.

I think we should indeed improve the alignment and filling
infrastructure as a prerequisite for wider use of variable-pitch fonts
and faces.  I think we have everything we need in the display engine,
it's just a question of making better use of it in Lisp.

Re: Tick Reduction

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Could it be that you are using a suboptimal font?  In my experience,
>> finding a really good one makes a big difference.
>
> If finding such good fonts is a significant effort, we could have
> users complain about ugly display because they didn't invest that
> effort.  This stuff should work OOTB as much as possible, or else we
> should make it opt-in.

That's a solid point, and definitely something worth thinking about.

The effort involved is a) picking a suitable candidate, b) installing it
if it's not already, and c) customizing Emacs to use it.

Step a) can take however much time you want to, I suppose.  Some people
enjoy searching for fonts more than others.

In my experience from Debian, step b) can be slightly tedious given that
distributions might package fonts in various bundles such that the font
name you find online doesn't necessarily correspond 1:1 with the name of
the package.  YMMV.

Step c) is a bit fiddly, but not too bad (you need to type the name of
the font manually, as opposed to just selecting it from a list, so you
better get the spelling right).

If we want to simplify this, these are the first ideas that come to
mind:

- We could provide a curated list of variable-width fonts to
  prefer, where available.  Perhaps depending on system.

- We could somehow encourage distributions to add this or that font as
  an optional dependency ("recommends", as Debian/apt would call it),
  and then use it if available.

- If we want to recommend one or more particular `variable-pitch' font,
  it would make sense to recommend also one or more `fixed-pitch' fonts
  that would go well with it.  Fonts generally harmonize better or worse
  with each other, also on a technical level (a font with thick glyphs
  might look rather bad next to one with very thin glyphs, for example).

Re: Tick Reduction

[Dmitry Gutov]

On 19.11.2021 08:27, Lars Ingebrigtsen wrote:
> Hm...  where do we do that?  The only instances I can think of is on the
> splash screen, and in eww and shortdoc.

Nothing specific I can point a finger at, but FWIW proportional fonts 
have featured in a number of bug reports to company-mode.

Where the default popup rendering method can't support them, of course. 
But if we're talking about read-only buffers only, I suppose that's not 
pertinent.

RE: [External] : Tick Reduction

[Drew Adams]

> I'm wondering whether we should reduce the number of ‘’ marks in the
> *Help* buffer.

(This proposal seems like a rehash of earlier
ones about Info presentation.)

FWIW, I'm against it, in particular for the
same reasons I'm against the use of curly
quotes, including search & recognition.

At most, it should be optional (and opt-in).

It ain't broke; please don't "fix" it.  And
real Emacs improvements are still possible...

RE: [External] : Tick Reduction

[Phil Sainty]

On 2021-11-19 11:18, Drew Adams wrote:
> FWIW, I'm against it, in particular for the
> same reasons I'm against the use of curly
> quotes, including search & recognition.
> 
> At most, it should be optional (and opt-in).
> 
> It ain't broke; please don't "fix" it.  And
> real Emacs improvements are still possible...

Having just read this thread and the significant collection of
complications being discussed, I can only agree with Drew --
let's not default to introducing issues for users where none
previously existed.

(Tangentially I also think curly quotes cause more problems
than they do improvements.)

Most users will already have a good monospace font configured
for Emacs, and the things being discussed will not be problems
for them, so I'm in favour of any such changes being opt-in,
rather than risk their existing proportional font configuration
making Emacs look bad all of a sudden.

At minimum these changes should be options.


-Phil

Re: Tick Reduction

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And, of course, we could also consider using proportional fonts for the
> non-code prose bits:

I forgot to mention how that'd work: It's pretty easy to identify Lisp
snippets in doc strings -- they're either in `' pairs or they're
paragraphs of texts that start with ; or (, so we can identify them
pretty reliably automatically.  So I think we'd get 93% there without
altering any doc strings.

We'd need to add a directive (like we did with literal ticks with \\='
etc) to mark out sections that should not have a proportional font for
bits where the automatic algo mis-guesses, like when you have non-Lisp
tables in the doc strings.  Those are pretty rare, though.

The most challenging bits are doc strings that are written in a
semi-columnar fashion, like

--------
Generate a PostScript syntactic chart image of the region in an EPS file.

Generate an EPS file for each production in the region.
The EPS file name has the following form:

   <PREFIX><PRODUCTION>.eps

<PREFIX>     is given by variable ‘ebnf-eps-prefix’.
	     The default value is "ebnf--".

<PRODUCTION> is the production name.
	     Some characters in the production file name are replaced to
	     produce a valid file name.  For example, the production name
	     "A/B + C" is modified to produce "A_B_+_C", and the EPS
	     file name used in this case will be "ebnf--A_B_+_C.eps".

WARNING: This function does *NOT* ask any confirmation to override existing
	 files.
--------

Fortunately, we have some pretty good guesses in the filling machinery
for these cases, and we could reuse that code here to identify these
bits and then use `align-to' to align this stuff up.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 19 Nov 2021 06:48:36 +0100
> 
> Fortunately, we have some pretty good guesses in the filling machinery
> for these cases, and we could reuse that code here to identify these
> bits and then use `align-to' to align this stuff up.

If we want to have good filling with variable-pitch fonts, we should
teach fill.el to put (space :width N) display specs on whitespace
characters, with N calculated to produce the correct pixel-resolution
filling.  This is in etc/TODO.

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Fortunately, we have some pretty good guesses in the filling machinery
>> for these cases, and we could reuse that code here to identify these
>> bits and then use `align-to' to align this stuff up.
>
> If we want to have good filling with variable-pitch fonts, we should
> teach fill.el to put (space :width N) display specs on whitespace
> characters, with N calculated to produce the correct pixel-resolution
> filling.  This is in etc/TODO.

Yes.  But I'm not suggesting we should auto-fill the doc strings,
because I think that would lead to too much mis-formatted text.

I think.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 19 Nov 2021 08:28:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If we want to have good filling with variable-pitch fonts, we should
> > teach fill.el to put (space :width N) display specs on whitespace
> > characters, with N calculated to produce the correct pixel-resolution
> > filling.  This is in etc/TODO.
> 
> Yes.  But I'm not suggesting we should auto-fill the doc strings,
> because I think that would lead to too much mis-formatted text.

If we don't fill them, it will also look mis-formatted, no?

Re: Tick Reduction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If we don't fill them, it will also look mis-formatted, no?

Not significantly more than today -- the doc strings rarely look like
blocks of text.  (And it usually evens out in normal text.  You can
construct extreme examples with lines that are only "W"s compared with
lines that are only "i"s, but they don't exist in nature.)

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

Re: Tick Reduction

[Eric S Fraga]

On Thursday, 18 Nov 2021 at 21:37, Lars Ingebrigtsen wrote:
> And, of course, we could also consider using proportional fonts for the
> non-code prose bits:

Would the text be re-flowed/wrapped/filled (choice of terms) as
otherwise it will end up looking rather ugly?

-- 
Eric S Fraga with org 9.5 in Emacs 29.0.50 on Debian 11.1

Re: Tick Reduction

[Lars Ingebrigtsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Would the text be re-flowed/wrapped/filled (choice of terms) as
> otherwise it will end up looking rather ugly?

It would look even prettier if filled, but doc strings don't usually
have very uniformly filled blocks of text as is, so I don't think we
have to fill the text if we move to proportional fonts.

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

Re: Tick Reduction

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The variable/function symbols are links and stand out on their own, and
> the keys also have their own distinct faces.  Without them, this would
> look like:

This is better.

> And, of course, we could also consider using proportional fonts for the
> non-code prose bits:

This would be even better still.

However, if we want to start using proportional fonts, I think we will
run into issues with:

- Code fragments
- Tables
- Lists

My vote would be for expanding the docstring syntax to also handle these
things, and I think it'd be natural to base it on Org-mode.  We might
also want some other way to mark things as monospace that is not `foo'
(in which case it will be linked if there is such a Lisp symbol, which
is not correct e.g. when referring to the executables "man" or "whois").

So, for example:

1. A table would look like:

    | foo | bar |
    | baz | bzz |

2. Monospace would look like:

    =this=

3. A code fragment would look like:

    #+begin_src
    (defun foo () ...)
    #+end_src

4. Lists would look like:

    - Foo
    - Bar
    - Baz

   Lists could be rendered with "•" on capable displays.

We could make adjustments or even base it on something else like
Markdown.  I think Org-mode is closer to home, but that's me.

While we are at it, we could also introduce /italic/, and maybe even
*bold* (but we would need clear guidelines to avoid people going
overboard, i.e. I would not use *bold* for anything but "WARNING:" or
similar).

Re: Tick Reduction

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> My vote would be for expanding the docstring syntax to also handle these
> things, and I think it'd be natural to base it on Org-mode.  We might
> also want some other way to mark things as monospace that is not `foo'
> (in which case it will be linked if there is such a Lisp symbol, which
> is not correct e.g. when referring to the executables "man" or "whois").

I think it would be natural to do all "strings" in doc strings as
monospace, though.

> 3. A code fragment would look like:
>
>     #+begin_src
>     (defun foo () ...)
>     #+end_src

I think going full Org in the doc strings would be excessive -- it's
pretty easy to detect Emacs Lisp.

But, sure, moving towards a more Org-like syntax might make sense.

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

Re: Tick Reduction

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think it would be natural to do all "strings" in doc strings as
> monospace, though.

Except for when you want to say things like:

    This "frobnicates" the turbo encabulator.

IOW, where the thing in quotes are just regular words.  I'm positive we
have such cases, but I can't remember where.

> I think going full Org in the doc strings would be excessive -- it's
> pretty easy to detect Emacs Lisp.

Yes, it must be slimmed down to its absolute bare essentials.  IOW, we
should consider only those parts that we see a need for.

BTW, Markdown has a nice way to mark monospace blocks, if we want to
avoid relying on heuristics or simply provide a fire-escape if it fails:

```
like this
```

Although it is far less powerful than what Org-mode does, it is also
much simpler and less noisy.

Re: Tick Reduction

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Except for when you want to say things like:
>
>     This "frobnicates" the turbo encabulator.
>
> IOW, where the thing in quotes are just regular words.  I'm positive we
> have such cases, but I can't remember where.

We probably have, but it's pretty rare.  (Mostly because people don't
like typing \" all over the place, I think.)

>> I think going full Org in the doc strings would be excessive -- it's
>> pretty easy to detect Emacs Lisp.
>
> Yes, it must be slimmed down to its absolute bare essentials.  IOW, we
> should consider only those parts that we see a need for.
>
> BTW, Markdown has a nice way to mark monospace blocks, if we want to
> avoid relying on heuristics or simply provide a fire-escape if it fails:
>
> ```
> like this
> ```
>
> Although it is far less powerful than what Org-mode does, it is also
> much simpler and less noisy.

Yup.  We currently use \ as the escape character (with \\< and \\[ and
\\=), so we could continue to use that:

\\*
like this
\\*

Or something.  On the other hand, \\ is really kinda ugly.

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

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 19 Nov 2021 07:52:36 +0100
> 
> My vote would be for expanding the docstring syntax to also handle these
> things, and I think it'd be natural to base it on Org-mode.

You mean, actually load Org for displaying those, including the doc
strings?  That's a non-starter, since Org is a very large (to put it
mildly) package, and even just loading it takes a long time.  We
should be able to display doc strings with bare-bones Emacs.

Re: Tick Reduction

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> My vote would be for expanding the docstring syntax to also handle these
>> things, and I think it'd be natural to base it on Org-mode.
>
> You mean, actually load Org for displaying those, including the doc
> strings?  That's a non-starter, since Org is a very large (to put it
> mildly) package, and even just loading it takes a long time.  We
> should be able to display doc strings with bare-bones Emacs.

No, I mean only the syntax.  I see now that what I wrote was ambiguous
on this point.

Re: Tick Reduction

[Stefan Monnier]

> And, of course, we could also consider using proportional fonts for the
> non-code prose bits:

On a docstring like that of `pcase` the result is a bit poor.

Also, it makes line lengths vary even more; as a result, it ends up
crying for re-filling the text.  Especially since, while most lines end
up shorter when displayed with proportional fonts, occasionally some
lines end up longer, causing line-wrapping.

Clearly, we would benefit from a formal markup language (and one which
includes some way to align text into columns).  Note that for the column
display, I think we actually need an extension to the current `space`
thingy on the `display` property which is able to align columns even
without the buffer's data telling the redisplay at which precise pixel
position it should be aligned (instead it should just add space until
the columns are visually aligned).


        Stefan "happy user of proportional font for the mode-line,
                and not so happy user of proportional fonts for docstrings"

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Fri, 19 Nov 2021 08:58:11 -0500
> 
> Clearly, we would benefit from a formal markup language (and one which
> includes some way to align text into columns).

AFAIU, markup is generally separate from layout, so aligning text is
not part of what markup is supposed to solve.

> Note that for the column display, I think we actually need an
> extension to the current `space` thingy on the `display` property
> which is able to align columns even without the buffer's data
> telling the redisplay at which precise pixel position it should be
> aligned (instead it should just add space until the columns are
> visually aligned).

This goes against the very basics of how our display engine is
designed: it examines text one character at a time and makes layout
decisions as part of that examination.  What you want would AFAIU
require the display engine perform layout of the entire window above
the line currently being laid out, before the layout of the current
line can be performed.

Re: Tick Reduction

[Stefan Monnier]

>> Clearly, we would benefit from a formal markup language (and one which
>> includes some way to align text into columns).
>
> AFAIU, markup is generally separate from layout, so aligning text is
> not part of what markup is supposed to solve.

Not sure what you mean: in order to know that the columns need to be
aligned, the code that does the layout will need to be told about it by
some markup.

>> Note that for the column display, I think we actually need an
>> extension to the current `space` thingy on the `display` property
>> which is able to align columns even without the buffer's data
>> telling the redisplay at which precise pixel position it should be
>> aligned (instead it should just add space until the columns are
>> visually aligned).
> This goes against the very basics of how our display engine is
> designed:

Yup, I know :-(

> it examines text one character at a time and makes layout
> decisions as part of that examination.  What you want would AFAIU
> require the display engine perform layout of the entire window above
> the line currently being laid out, before the layout of the current
> line can be performed.

AFAIK, the way the display engine works currently, when we process
a given char at POS, we have already processed all the chars between
`window-start` and POS, so I think we could handle the case of "align
with some previous line" (with some non-trivial caveats since it means
that future changes in that previous line would need to cause POS to be
re-processed, which may require disabling some optimizations).

Of course, to really auto-align columns, we can't just "align
with some previous line", but we'd also need to align with some
subsequent line, which means it can't be done in a single pass.


        Stefan

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 19 Nov 2021 13:22:16 -0500
> 
> >> Clearly, we would benefit from a formal markup language (and one which
> >> includes some way to align text into columns).
> >
> > AFAIU, markup is generally separate from layout, so aligning text is
> > not part of what markup is supposed to solve.
> 
> Not sure what you mean: in order to know that the columns need to be
> aligned, the code that does the layout will need to be told about it by
> some markup.

What I mean is that markup generally tells nothing about layout, and
alignment is part of layout.

> > it examines text one character at a time and makes layout
> > decisions as part of that examination.  What you want would AFAIU
> > require the display engine perform layout of the entire window above
> > the line currently being laid out, before the layout of the current
> > line can be performed.
> 
> AFAIK, the way the display engine works currently, when we process
> a given char at POS, we have already processed all the chars between
> `window-start` and POS

That is only true when the window is redisplayed in its entirety, top
to bottom.  This happens relatively rarely, because the display engine
tries very hard not to redisplay much more than absolutely necessary.
These redisplay optimizations are generally structure as follows:

 . find the beginning and the end of the part of the buffer that needs
   to be redisplayed
 . redisplay that part starting at its beginning and going to its end

This could result in redisplaying just one line, for example, or all
lines between N and M.  Which means that redisplay of a window can
start at some arbitrary point in the middle of the window, without
knowing anything about the preceding lines, except that they weren't
changed on the glass.

Basically any display engine algorithm is required to support a
redisplay that begins at an arbitrary point in the buffer, and not
rely on the glyph matrices to be up-to-date.

> so I think we could handle the case of "align
> with some previous line" (with some non-trivial caveats since it means
> that future changes in that previous line would need to cause POS to be
> re-processed, which may require disabling some optimizations).

What you want would require every redisplay to always redraw the
entire window.  IOW, disable _all_ redisplay optimizations.

> Of course, to really auto-align columns, we can't just "align
> with some previous line", but we'd also need to align with some
> subsequent line, which means it can't be done in a single pass.

Ouch!

Re: Tick Reduction

[Stefan Monnier]

> That is only true when the window is redisplayed in its entirety, top
> to bottom.  This happens relatively rarely, because the display engine
> tries very hard not to redisplay much more than absolutely necessary.
> These redisplay optimizations are generally structure as follows:
>
>  . find the beginning and the end of the part of the buffer that needs
>    to be redisplayed
>  . redisplay that part starting at its beginning and going to its end
>
> This could result in redisplaying just one line, for example, or all
> lines between N and M.  Which means that redisplay of a window can
> start at some arbitrary point in the middle of the window, without
> knowing anything about the preceding lines, except that they weren't
> changed on the glass.

IIUC this isn't quite true: the "old" glyph matrix still contains the
rendering result of the previous lines and while it's old, it's still
up-to-date, so we might be able to extract the alignment info we need
from that.

>> so I think we could handle the case of "align
>> with some previous line" (with some non-trivial caveats since it means
>> that future changes in that previous line would need to cause POS to be
>> re-processed, which may require disabling some optimizations).
> What you want would require every redisplay to always redraw the
> entire window.  IOW, disable _all_ redisplay optimizations.

Not necessarily always: we could record dependencies between lines of
the glyph matrix such that we only grow the set of redisplayed lines
when it's actually needed (i.e. when the corresponding text does use
such cross-line alignment).


        Stefan

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 19 Nov 2021 14:24:46 -0500
> 
> > That is only true when the window is redisplayed in its entirety, top
> > to bottom.  This happens relatively rarely, because the display engine
> > tries very hard not to redisplay much more than absolutely necessary.
> > These redisplay optimizations are generally structure as follows:
> >
> >  . find the beginning and the end of the part of the buffer that needs
> >    to be redisplayed
> >  . redisplay that part starting at its beginning and going to its end
> >
> > This could result in redisplaying just one line, for example, or all
> > lines between N and M.  Which means that redisplay of a window can
> > start at some arbitrary point in the middle of the window, without
> > knowing anything about the preceding lines, except that they weren't
> > changed on the glass.
> 
> IIUC this isn't quite true: the "old" glyph matrix still contains the
> rendering result of the previous lines and while it's old, it's still
> up-to-date, so we might be able to extract the alignment info we need
> from that.

The display code only assumes the current glyph matrix is up-to-date
if a set of very conservative tests succeeds.  In the other cases, it
doesn't use the contents of the current glyph matrix.

And if this is not enough, let me remind you that the display engine
also includes a set of functions that "emulate" redisplay, and those
cannot use the glyph matrices at all, because they many times are used
for text that is not displayed at all.

> >> so I think we could handle the case of "align
> >> with some previous line" (with some non-trivial caveats since it means
> >> that future changes in that previous line would need to cause POS to be
> >> re-processed, which may require disabling some optimizations).
> > What you want would require every redisplay to always redraw the
> > entire window.  IOW, disable _all_ redisplay optimizations.
> 
> Not necessarily always: we could record dependencies between lines of
> the glyph matrix such that we only grow the set of redisplayed lines
> when it's actually needed (i.e. when the corresponding text does use
> such cross-line alignment).

Anything can be implemented: this is software, after all.  All I'm
saying is that it won't be easy, not at all.  And once again, the
display code tries very hard not to use the current glyph matrix
because there's no good way of knowing when it's up to date,
especially when you are in the middle of some Lisp code.

Re: Tick Reduction

[Stefan Monnier]

>> IIUC this isn't quite true: the "old" glyph matrix still contains the
>> rendering result of the previous lines and while it's old, it's still
>> up-to-date, so we might be able to extract the alignment info we need
>> from that.
>
> The display code only assumes the current glyph matrix is up-to-date
> if a set of very conservative tests succeeds.  In the other cases, it
> doesn't use the contents of the current glyph matrix.

So far it indeed doesn't use the old glyph matrix, but that matrix is
still around and (for the lines that preceded the currently processed
text) should still be up-to-date.
So we could conceivably use that.

> And if this is not enough, let me remind you that the display engine
> also includes a set of functions that "emulate" redisplay, and those
> cannot use the glyph matrices at all, because they many times are used
> for text that is not displayed at all.

Yes, we may have to declare that for functions that "emulate" the
redisplay internally, the resulting horizontal position info might not
always be quite right (might not reflect what you'll see on the glass)
for text tat uses the new alignment functionality :-(

>> Not necessarily always: we could record dependencies between lines of
>> the glyph matrix such that we only grow the set of redisplayed lines
>> when it's actually needed (i.e. when the corresponding text does use
>> such cross-line alignment).
> Anything can be implemented: this is software, after all.  All I'm
> saying is that it won't be easy, not at all.

No doubt.  I'm just trying to separate "hard" from "fundamentally incompatible".

AFAICT it could be made to work without having to rewrite all the code,
so I consider it as "not fundamentally incompatible".
But I agree it wouldn't be easy.

> And once again, the display code tries very hard not to use the
> current glyph matrix because there's no good way of knowing when it's
> up to date, especially when you are in the middle of some Lisp code.

Indeed, it might imply a rethink of how we manage the
old/current/desired glyph matrices.


        Stefan

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 19 Nov 2021 16:09:44 -0500
> 
> > The display code only assumes the current glyph matrix is up-to-date
> > if a set of very conservative tests succeeds.  In the other cases, it
> > doesn't use the contents of the current glyph matrix.
> 
> So far it indeed doesn't use the old glyph matrix, but that matrix is
> still around and (for the lines that preceded the currently processed
> text) should still be up-to-date.
> So we could conceivably use that.

IME, that road is full of pitfalls and mines.  The current display
code stays away of that for a good reason.

> > And if this is not enough, let me remind you that the display engine
> > also includes a set of functions that "emulate" redisplay, and those
> > cannot use the glyph matrices at all, because they many times are used
> > for text that is not displayed at all.
> 
> Yes, we may have to declare that for functions that "emulate" the
> redisplay internally, the resulting horizontal position info might not
> always be quite right (might not reflect what you'll see on the glass)
> for text tat uses the new alignment functionality :-(

That will break quite a few features, I'm afraid.  Including redisplay
cycles themselves, which sometimes use this emulation to decide how to
proceed or which buffer position to use as window-start.  But also
vertical-motion, for example, and stuff that depends on it, like
line-move-visual.

Re: Tick Reduction

[Stefan Monnier]

>> Yes, we may have to declare that for functions that "emulate" the
>> redisplay internally, the resulting horizontal position info might not
>> always be quite right (might not reflect what you'll see on the glass)
>> for text tat uses the new alignment functionality :-(
> That will break quite a few features, I'm afraid.

This will completely depend on the specifics of when/how the answer
isn't quite right, of course.


        Stefan

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Sat, 20 Nov 2021 08:11:06 -0500
> 
> >> Yes, we may have to declare that for functions that "emulate" the
> >> redisplay internally, the resulting horizontal position info might not
> >> always be quite right (might not reflect what you'll see on the glass)
> >> for text tat uses the new alignment functionality :-(
> > That will break quite a few features, I'm afraid.
> 
> This will completely depend on the specifics of when/how the answer
> isn't quite right, of course.

AFAIU, it will never be right, as long as this kind of alignment is
used on display.

Re: Tick Reduction

[Stefan Monnier]

Eli Zaretskii [2021-11-20 15:32:04] wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Sat, 20 Nov 2021 08:11:06 -0500
>> >> Yes, we may have to declare that for functions that "emulate" the
>> >> redisplay internally, the resulting horizontal position info might not
>> >> always be quite right (might not reflect what you'll see on the glass)
>> >> for text tat uses the new alignment functionality :-(
>> > That will break quite a few features, I'm afraid.
>> This will completely depend on the specifics of when/how the answer
>> isn't quite right, of course.
> AFAIU, it will never be right, as long as this kind of alignment is
> used on display.

That completely depends on what the "redisplay emulation" code does.
It could opt to use the old (unreliable) glyph matrix to compute its
(documented as unreliable 🙍) info, in which case it could end up
breaking less often (but more spectacularly when it does)?


        Stefan

Re: Tick Reduction

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Sat, 20 Nov 2021 09:06:45 -0500
> 
> Eli Zaretskii [2021-11-20 15:32:04] wrote:
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> >> Date: Sat, 20 Nov 2021 08:11:06 -0500
> >> >> Yes, we may have to declare that for functions that "emulate" the
> >> >> redisplay internally, the resulting horizontal position info might not
> >> >> always be quite right (might not reflect what you'll see on the glass)
> >> >> for text tat uses the new alignment functionality :-(
> >> > That will break quite a few features, I'm afraid.
> >> This will completely depend on the specifics of when/how the answer
> >> isn't quite right, of course.
> > AFAIU, it will never be right, as long as this kind of alignment is
> > used on display.
> 
> That completely depends on what the "redisplay emulation" code does.
> It could opt to use the old (unreliable) glyph matrix to compute its
> (documented as unreliable 🙍) info, in which case it could end up
> breaking less often (but more spectacularly when it does)?

As I explained earlier, that code cannot use the glyph matrix, because
it is required to work with text that is not displayed at all.

Re: Tick Reduction

[Stefan Monnier]

>> That completely depends on what the "redisplay emulation" code does.
>> It could opt to use the old (unreliable) glyph matrix to compute its
>> (documented as unreliable 🙍) info, in which case it could end up
>> breaking less often (but more spectacularly when it does)?
>
> As I explained earlier, that code cannot use the glyph matrix, because
> it is required to work with text that is not displayed at all.

It could use it opportunistically when it's available.


        Stefan

Re: Tick Reduction

[Lars Ingebrigtsen]

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

>> And, of course, we could also consider using proportional fonts for the
>> non-code prose bits:
>
> On a docstring like that of `pcase` the result is a bit poor.

This bit?

---
Each PATTERN expands, in essence, to a predicate to call
on EXPVAL.  When the return value of that call is non-nil,
PATTERN matches.  PATTERN can take one of the forms:

  _                matches anything.
  \\='VAL             matches if EXPVAL is `equal' to VAL.
  KEYWORD          shorthand for \\='KEYWORD
  INTEGER          shorthand for \\='INTEGER
...
---

Yes, we have to develop some syntax to mark up tabular data, and Stefan
K suggested using the Org syntax, i.e.,

|  _               | matches anything.
|  \\='VAL         |    matches if EXPVAL is `equal' to VAL.
|  KEYWORD         | shorthand for \\='KEYWORD
|  INTEGER         | shorthand for \\='INTEGER

which seems like a good idea to me.

I think the number of doc strings that need this isn't huge, though.

> Also, it makes line lengths vary even more; as a result, it ends up
> crying for re-filling the text.  Especially since, while most lines end
> up shorter when displayed with proportional fonts, occasionally some
> lines end up longer, causing line-wrapping.

(I think we've already covered this bit, but to recap: In practice, it's
not a big problem, and to re-fill doc strings, we'd have to rewrite a
large number of them, so it's not practical.)

> Clearly, we would benefit from a formal markup language (and one which
> includes some way to align text into columns).  Note that for the column
> display, I think we actually need an extension to the current `space`
> thingy on the `display` property which is able to align columns even
> without the buffer's data telling the redisplay at which precise pixel
> position it should be aligned (instead it should just add space until
> the columns are visually aligned).

Hm...  I don't think we need anything new here?  The thing that displays
the doc string can figure out the pixel positions -- it's what shr does
with tables.

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