Variable pitch text filling

Variable pitch text filling

[Lars Ingebrigtsen]

I've we're going to grow variable pitch usage, we should probably have a
little library for doing variable pitch filling.

This is already implemented in shr.el, so it's mostly just a matter of
extracting it from there -- if that's all we want.  (It just does simple
filling -- i.e., breaking the lines after a given pixel width.)

But I'm wondering to what degree (if any) we'd want to support the more
advanced (and seldom used) features from our normal filling machinery.
For instance -- justification (i.e., having straight borders on both
sides).

To do this with a variable pitch text, you'd have to first fill a line
normally, and then go over the line and distribute some space pixels
everywhere (or just on spaces in the line).  (This can (conveniently
enough) probably be done with the new `min-width' spec (if we're
distributing the extra pixels on all characters and not just the
spaces).)

But...  is that too niche?  Perhaps?  Perhaps not?  I mean, if you have
a HiDPI screen, then having a straight right margin might be cool?  (Or
left, in an r2l language.)

Our normal filling machinery also has a bunch of support for various
modes, with auto-filling and paragraphs etc, and my feeling is that this
library doesn't have to -- it'll only be used for displaying
natural-language text.  So that should simplify things quite a bit.

I.e., it might only have a single entry point and not a lot of knobs to
twiddle:

  (fill-region-to-pixel-width start end (- (window-pixel-width) 100) 'justify)

Has anybody pondered these deep and eternal questions before?  If so,
please chime in before I start typing away at this library.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 26 Nov 2021 15:45:46 +0100
> 
> But I'm wondering to what degree (if any) we'd want to support the more
> advanced (and seldom used) features from our normal filling machinery.
> For instance -- justification (i.e., having straight borders on both
> sides).

I think this would be a welcome feature.

> To do this with a variable pitch text, you'd have to first fill a line
> normally, and then go over the line and distribute some space pixels
> everywhere (or just on spaces in the line).  (This can (conveniently
> enough) probably be done with the new `min-width' spec (if we're
> distributing the extra pixels on all characters and not just the
> spaces).)

Since we will have spaces in the text from the filling, we could use
the :width display spec on those space characters.  There should be no
need for min-width.

Re: Variable pitch text filling

[Ihor Radchenko]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Has anybody pondered these deep and eternal questions before?  If so,
> please chime in before I start typing away at this library.

I am not sure if it is 100% relevant, but it would be useful to have
native pixel-precise justification support for things like
tabulated-list-mode and Org mode tables.

In tabulated special modes, we often need to adjust and justify text to
span over predefined width and alignt to left/right/center. The standard
Emacs approach using column numbers/character count often looks ugly on
variable pitch fonts.

Things get even worse on window resize. Truncated/filled fields can only
be defined in absolute units and cannot just be a fraction of total
window width.
 
Best,
Ihor

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> To do this with a variable pitch text, you'd have to first fill a line
>> normally, and then go over the line and distribute some space pixels
>> everywhere (or just on spaces in the line).  (This can (conveniently
>> enough) probably be done with the new `min-width' spec (if we're
>> distributing the extra pixels on all characters and not just the
>> spaces).)
>
> Since we will have spaces in the text from the filling, we could use
> the :width display spec on those space characters.  There should be no
> need for min-width.

Yes, if we're distributing the extra space on the space characters only,
we can use space specs.  But usually typesetters don't do that -- they
also distribute some of the space between other characters, too, to get
a more even "greyness".  (Or whatever they call it -- it's been a few
years since I read up on typography last time.)

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

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Ihor Radchenko <yantar92@gmail.com> writes:

> I am not sure if it is 100% relevant, but it would be useful to have
> native pixel-precise justification support for things like
> tabulated-list-mode and Org mode tables.

Yes, there's a different package for that in the works.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 16:10:00 +0100
> 
> > Since we will have spaces in the text from the filling, we could use
> > the :width display spec on those space characters.  There should be no
> > need for min-width.
> 
> Yes, if we're distributing the extra space on the space characters only,
> we can use space specs.  But usually typesetters don't do that -- they
> also distribute some of the space between other characters, too, to get
> a more even "greyness".  (Or whatever they call it -- it's been a few
> years since I read up on typography last time.)

You mean, add space inside of a word?  That could at first be avoided,
because doing that isn't trivial.  I'm not sure min-width is the right
implementation for that, because we don't really want to put a
separate property on each character.  This should probably be
implemented by tweaking the advance width the glyphs or something.

Re: Variable pitch text filling

[Yuan Fu]

> Yes, if we're distributing the extra space on the space characters only,
> we can use space specs.  But usually typesetters don't do that -- they
> also distribute some of the space between other characters, too, to get
> a more even "greyness".  (Or whatever they call it -- it's been a few
> years since I read up on typography last time.)

I think they call it “color”. Typography people surely know how to name things. And what you described seems to be tracking, ie, altering the space between individual characters.

Yuan

Re: Variable pitch text filling

[Stefan Monnier]

> You mean, add space inside of a word?  That could at first be avoided,
> because doing that isn't trivial.  I'm not sure min-width is the right
> implementation for that, because we don't really want to put a
> separate property on each character.  This should probably be
> implemented by tweaking the advance width the glyphs or something.

And whole-pixels are probably too coarse a granularity for that in most
cases (especially with non-HiDPI screens).


        Stefan "who can't remember wanting/needing justified text in Emacs"

Re: Variable pitch text filling

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, add space inside of a word?  That could at first be avoided,
> because doing that isn't trivial.

Not trivial in what way?

> I'm not sure min-width is the right implementation for that, because
> we don't really want to put a separate property on each character.
> This should probably be implemented by tweaking the advance width the
> glyphs or something.

That'd probably be more efficient, but some cursory testing seems to
indicate that putting a min-width on every char in a pretty big buffer
works fine.

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

> And whole-pixels are probably too coarse a granularity for that in most
> cases (especially with non-HiDPI screens).

It depends on the resolution.  Here's the same sentence without and with
a min-width on each char that's one pixel wider than the natural width:


[-- Attachment #2: width2.png --]
[-- Type: image/png, Size: 27664 bytes --]

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


Looks fine here, but this is a 320PPI display.  For low resolutions,
doing this sort of thing is probably not recommended.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 08:12:48 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You mean, add space inside of a word?  That could at first be avoided,
> > because doing that isn't trivial.
> 
> Not trivial in what way?

The Lisp code would be unnecessarily complicated.  And having a
display property on each character will slow down redisplay, because
handle_stop will be called for each character.  Having too many
intervals on buffer text is also best avoided for other reasons
(memory etc.).

> > I'm not sure min-width is the right implementation for that, because
> > we don't really want to put a separate property on each character.
> > This should probably be implemented by tweaking the advance width the
> > glyphs or something.
> 
> That'd probably be more efficient, but some cursory testing seems to
> indicate that putting a min-width on every char in a pretty big buffer
> works fine.

I don't like such an implementation.  It's a kludge at best, IMO.
Please let's not go that way.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> That'd probably be more efficient, but some cursory testing seems to
>> indicate that putting a min-width on every char in a pretty big buffer
>> works fine.
>
> I don't like such an implementation.  It's a kludge at best, IMO.
> Please let's not go that way.

Yes, I was pondering other solutions for several different, but somewhat
related, use cases.

1) We want to display the "-" wider in the variable-pitch mode line
2) In the justification case, we want to add some blank pixels more free-form
3) A much-requested feature is to be able to "snap" characters to an
integer multiple of the standard font (in a fixed-width buffer).
(Mostly relevant for people that mix fonts, like CJK and roman.)

All three of these are essentially the same: Add some pixels to the
glyphs in a region.

So we could do just that.  I.e., not a complex display spec, but a
simpler char-based one, for instance `char-spacing', that could have
values:

1) 1.0, to be at least 1 normal character wide
2) 3, to add three blank pixels to the end
3) `grid', to add enough blank pixels to have a width that's an
   integer multiple of the normal character width

So standard-mode-line-format would have

             (list
              :propertize
              (list ""
	            'mode-line-mule-info
	            'mode-line-client
	            'mode-line-modified
	            'mode-line-remote)
              'display '(min-width (5.0))
              'char-spacing 1.0)

while inter-character justification would use 'char-spacing 1 to add an
extra pixel after all the chars on the line, for instance. 

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 09:04:53 +0100
> 
> 1) We want to display the "-" wider in the variable-pitch mode line
> 2) In the justification case, we want to add some blank pixels more free-form
> 3) A much-requested feature is to be able to "snap" characters to an
> integer multiple of the standard font (in a fixed-width buffer).
> (Mostly relevant for people that mix fonts, like CJK and roman.)
> 
> All three of these are essentially the same: Add some pixels to the
> glyphs in a region.
> 
> So we could do just that.  I.e., not a complex display spec, but a
> simpler char-based one, for instance `char-spacing', that could have
> values:
> 
> 1) 1.0, to be at least 1 normal character wide
> 2) 3, to add three blank pixels to the end
> 3) `grid', to add enough blank pixels to have a width that's an
>    integer multiple of the normal character width

It is trivial to add some pixels to the width of a glyph we produce
for a character: it just involves enlarging the it->pixel_width and/or
the glyph->pixel_width when we produce the glyph for that character.
Then the display backends (xterm.c etc.) will draw the background
color for those pixels automatically, thus creating an illusion of
"blank pixels".

The problem is how to determine which characters to "widen", and how
to calculate the number of the "widening" pixels.  The answer could be
different for each kind of situations you mention.

> So standard-mode-line-format would have
> 
>              (list
>               :propertize
>               (list ""
> 	            'mode-line-mule-info
> 	            'mode-line-client
> 	            'mode-line-modified
> 	            'mode-line-remote)
>               'display '(min-width (5.0))
>               'char-spacing 1.0)

What would be the exact meaning of "char-spacing 1.0" here?  IOW, how
would we compute the number of pixels to add to each glyph's width in
this case? what is a "normal character" for this purpose?

> while inter-character justification would use 'char-spacing 1 to add an
> extra pixel after all the chars on the line, for instance. 

With the value 1 computed by Lisp?  Because it cannot be a fixed
value: it should at least depend on the size of the font, and I think
it should be possible to add more pixels without making the display
unpleasant.

Also, in the case of CJK fonts, we should be able to do that without
any text property put on the text, so we need some (optional)
variable as well.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It is trivial to add some pixels to the width of a glyph we produce
> for a character: it just involves enlarging the it->pixel_width and/or
> the glyph->pixel_width when we produce the glyph for that character.

Right.  This reminds me -- perhaps we'd want to distribute the extra
space both before and after the glyph, to centre it within its allotted
width?  I haven't looked at the code yet, but I assume that's not going
to make this significantly more difficult.

> The problem is how to determine which characters to "widen", and how
> to calculate the number of the "widening" pixels.  The answer could be
> different for each kind of situations you mention.

Yup.

> What would be the exact meaning of "char-spacing 1.0" here?  IOW, how
> would we compute the number of pixels to add to each glyph's width in
> this case? what is a "normal character" for this purpose?

It's the same as for all these width specs -- it's FRAME_COLUMN_WIDTH.
The lengthy commentary before calc_pixel_width_or_height has all the
grisly details, and I see that I misremembered the specs when doing the
documentation.  Floating point numbers aren't special:

   SPEC ::=
     NUM      - a (fractional) multiple of the default font width/height
     (NUM)    - specifies exactly NUM pixels

So both 1 and 1.0 is one "normal character width", and it's (10)
that's the pixel spec.  (But I did it correctly in the code. 😀)

>> while inter-character justification would use 'char-spacing 1 to add an
>> extra pixel after all the chars on the line, for instance. 
>
> With the value 1 computed by Lisp?  Because it cannot be a fixed
> value: it should at least depend on the size of the font, and I think
> it should be possible to add more pixels without making the display
> unpleasant.

Yes, for the justification case, the algo would have to do all the
computation, and I'm guessing getting at a pleasing result will depend
on a lot of things.  For instance, if the display is low res, we
wouldn't want to do inter-character spacing at all -- unless there
aren't any spaces, and then we'd have to do it after all.  Etc.  I think
we'll just have to implement it, see what it looks like and tweak it
until it's OK.

> Also, in the case of CJK fonts, we should be able to do that without
> any text property put on the text, so we need some (optional)
> variable as well.

Yup.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 15:28:08 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is trivial to add some pixels to the width of a glyph we produce
> > for a character: it just involves enlarging the it->pixel_width and/or
> > the glyph->pixel_width when we produce the glyph for that character.
> 
> Right.  This reminds me -- perhaps we'd want to distribute the extra
> space both before and after the glyph, to centre it within its allotted
> width?

I don't think so, because that would move the leftmost character away
from the window-edge.

> > What would be the exact meaning of "char-spacing 1.0" here?  IOW, how
> > would we compute the number of pixels to add to each glyph's width in
> > this case? what is a "normal character" for this purpose?
> 
> It's the same as for all these width specs -- it's FRAME_COLUMN_WIDTH.

That's not the best possibility, because if some part of the affected
text uses a smaller font, you'd see glyphs that are too-widely spaced?

Re: Variable pitch text filling

[Eli Zaretskii]

> Date: Sat, 27 Nov 2021 16:55:47 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > > What would be the exact meaning of "char-spacing 1.0" here?  IOW, how
> > > would we compute the number of pixels to add to each glyph's width in
> > > this case? what is a "normal character" for this purpose?
> > 
> > It's the same as for all these width specs -- it's FRAME_COLUMN_WIDTH.
> 
> That's not the best possibility, because if some part of the affected
> text uses a smaller font, you'd see glyphs that are too-widely spaced?

I think a better idea is to use the width of the face's ASCII font (or
its average width, if that's a variable-pitch face).  Then everything
will scale as expected with the face's height.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Right.  This reminds me -- perhaps we'd want to distribute the extra
>> space both before and after the glyph, to centre it within its allotted
>> width?
>
> I don't think so, because that would move the leftmost character away
> from the window-edge.

Yes...  but it that necessarily bad?  I'm not sure what CJK users (which
is who this would be relevant for) would prefer here -- please do chime
up if you're such a user.

>> It's the same as for all these width specs -- it's FRAME_COLUMN_WIDTH.
>
> That's not the best possibility, because if some part of the affected
> text uses a smaller font, you'd see glyphs that are too-widely spaced?

All these specs (`space' and whatnot) refer to FRAME_COLUMN_WIDTH in
their logic.  (I mean, for those parts that aren't actual pixels.)

And I'm not quite sure what you mean here -- we're talking about
allowing people to "quantise" the widths to some common multiple, which
means that that is indeed what you'd see.  But that's what the user
asked for.

So mixing in smaller fonts in such a display wouldn't really be part of
the remit...

We could add a fourth spec to quantise to the font's "typical width",
but I don't see the use case for that.

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

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think a better idea is to use the width of the face's ASCII font (or
> its average width, if that's a variable-pitch face).  Then everything
> will scale as expected with the face's height.

Hm...  Oh, OK, I see what you mean now.  Yes, I think that would work
fine, but it's semantically slightly odd to have these width spec work
differently than the other width specs.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 14:46:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Right.  This reminds me -- perhaps we'd want to distribute the extra
> >> space both before and after the glyph, to centre it within its allotted
> >> width?
> >
> > I don't think so, because that would move the leftmost character away
> > from the window-edge.
> 
> Yes...  but it that necessarily bad?

Yes, IMO, because the text will seem to shift.

It is also unnecessary, because having 2 pixels to the right of each
character is practically indistinguishable from having one pixel on
the left and 1 pixel on the right: you still end up with 2 pixels
between any two characters.

> > That's not the best possibility, because if some part of the affected
> > text uses a smaller font, you'd see glyphs that are too-widely spaced?
> 
> All these specs (`space' and whatnot) refer to FRAME_COLUMN_WIDTH in
> their logic.  (I mean, for those parts that aren't actual pixels.)

Yes, but FRAME_COLUMN_WIDTH only reflects the dimensions of the
frame's default face's font.  If you use another face with a different
(smaller) font, FRAME_COLUMN_WIDTH won't change.  Think about a
feature where footnotes are shown in a smaller font.

> And I'm not quite sure what you mean here -- we're talking about
> allowing people to "quantise" the widths to some common multiple, which
> means that that is indeed what you'd see.  But that's what the user
> asked for.
> 
> So mixing in smaller fonts in such a display wouldn't really be part of
> the remit...

I think it should be.  Each face in Emacs has what I call "ASCII
font": that's the face's font used for the ASCII (and usually also
Latin) characters.  My idea is to take the "standard" width from that
ASCII font of the face.  Then we can provide this feature for every
possible face, and the result will be visually reasonable, since
smaller faces will have smaller "standard" width, and will have fewer
added pixels to the double-width characters displayed in that face.

It's the same idea as I used for the enlarged height (which was
rejected, but not because of this aspect), just for the width and not
for the height.

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 14:50:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think a better idea is to use the width of the face's ASCII font (or
> > its average width, if that's a variable-pitch face).  Then everything
> > will scale as expected with the face's height.
> 
> Hm...  Oh, OK, I see what you mean now.  Yes, I think that would work
> fine, but it's semantically slightly odd to have these width spec work
> differently than the other width specs.

Well, the spec will have a different name, and the documentation will
explain what that means.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It is also unnecessary, because having 2 pixels to the right of each
> character is practically indistinguishable from having one pixel on
> the left and 1 pixel on the right: you still end up with 2 pixels
> between any two characters.

The difference is with the characters above and below.  When doing a
monospaced "grid" display, the Roman characters will form a reliable
grid while the CJK will be put to the left in their allotted space.

Having them in the middle of that space might be more pleasing, but
again, I think we need some input from CJK users here to see what they
expect.

And we could perhaps leave this as an option to be specified by the user
(somehow).  I.e., flush left, flush right and middle.  But perhaps this
is over-engineering again.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 15:09:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is also unnecessary, because having 2 pixels to the right of each
> > character is practically indistinguishable from having one pixel on
> > the left and 1 pixel on the right: you still end up with 2 pixels
> > between any two characters.
> 
> The difference is with the characters above and below.  When doing a
> monospaced "grid" display, the Roman characters will form a reliable
> grid while the CJK will be put to the left in their allotted space.

But the same happens on TTY frames, so how can this be a problem on
GUI frames?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But the same happens on TTY frames, so how can this be a problem on
> GUI frames?

We're aiming to do better on GUI frames in general, so I don't think
taking pointers from inherent TUI limitations is a good argument here.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 15:19:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But the same happens on TTY frames, so how can this be a problem on
> > GUI frames?
> 
> We're aiming to do better on GUI frames in general

We do?  I thought we wanted to produce the same effect as on TTY
frames in this case: make double-width characters take exactly 2
columns of ASCII characters, like they do on TTY frames.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> We're aiming to do better on GUI frames in general
>
> We do?

In general, yes.

> I thought we wanted to produce the same effect as on TTY
> frames in this case: make double-width characters take exactly 2
> columns of ASCII characters, like they do on TTY frames.

Yes, that's the main point.  But if we can do it better, then we should
do it better.

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

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Hm...  Oh, OK, I see what you mean now.  Yes, I think that would work
>> fine, but it's semantically slightly odd to have these width spec work
>> differently than the other width specs.
>
> Well, the spec will have a different name, and the documentation will
> explain what that means.

Consistency is also a plus...

Your definition of "normal character width" is clearly superior to what
we have in Emacs today, though, so I wonder whether we could change
that.  That is, today if you say `display (space 2)' you get a multiple
of the frame column width.  We could change that to be the ASCII font
width of the current face instead, like what you suggested for this new
feature.

This would be incompatible, but I doubt it'd break anything much in
practice.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 16:09:31 +0100
> 
> Your definition of "normal character width" is clearly superior to what
> we have in Emacs today, though, so I wonder whether we could change
> that.  That is, today if you say `display (space 2)' you get a multiple
> of the frame column width.  We could change that to be the ASCII font
> width of the current face instead, like what you suggested for this new
> feature.
> 
> This would be incompatible, but I doubt it'd break anything much in
> practice.

Perhaps we could eat the cake and also have it: the 'space' spec
already supports a notion of "units".  Currently, we have:

       UNIT ::= in | mm | cm | width | height

where "width" and "height" are for the default face's font.  So we
could add a new "unit", say, "face-width" or "font-width" (and
similarly with height), to mean dimensions of the character of the
font used by the underlying face.

Re: Variable pitch text filling

[Yuan Fu]

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



> On Nov 29, 2021, at 6:09 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> It is also unnecessary, because having 2 pixels to the right of each
>> character is practically indistinguishable from having one pixel on
>> the left and 1 pixel on the right: you still end up with 2 pixels
>> between any two characters.
> 
> The difference is with the characters above and below.  When doing a
> monospaced "grid" display, the Roman characters will form a reliable
> grid while the CJK will be put to the left in their allotted space.
> 
> Having them in the middle of that space might be more pleasing, but
> again, I think we need some input from CJK users here to see what they
> expect.

I think aligning to middle is better, see the image below. I manually inserted spaces between CJK characters to align them to ASCII characters. The second line is flushed left, the third flushed right, and the fourth aligned to middle. If we flush the CJK to left, CJK characters are closer to the text before and further from the text after, and vice versa for flushing right. The middle-aligned line looks better. 


> 
> And we could perhaps leave this as an option to be specified by the user
> (somehow).  I.e., flush left, flush right and middle.  But perhaps this
> is over-engineering again.

I can’t think of useful use-cases for flushing left and right right now.

Yuan

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

[-- Attachment #2.2: Screen Shot 2021-11-29 at 10.37.38 AM.png --]
[-- Type: image/png, Size: 26000 bytes --]

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Perhaps we could eat the cake and also have it: the 'space' spec
> already supports a notion of "units".  Currently, we have:
>
>        UNIT ::= in | mm | cm | width | height
>
> where "width" and "height" are for the default face's font.  So we
> could add a new "unit", say, "face-width" or "font-width" (and
> similarly with height), to mean dimensions of the character of the
> font used by the underlying face.

Yes, that makes sense.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Mon, 29 Nov 2021 10:44:32 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> 
> I think aligning to middle is better, see the image below.

Please also try a line that begins with CJK characters below a line
that begins with English characters.  In that case, flushed left
should look the best, because it will be aligned with the beginnings
of the other lines.

> I manually inserted spaces between CJK characters to align them to ASCII characters. The second line is flushed left, the third flushed right, and the fourth aligned to middle. If we flush the CJK to left, CJK characters are closer to the text before and further from the text after, and vice versa for flushing right. The middle-aligned line looks better. 

In real-life use, there will usually be a space character between
English and CJK, right?  If so, the minor pixel differences you
mention will not be usually perceptible.  By contrast, the problem
with the leftmost characters not being aligned will _always_ be
visible, and will make the display ugly if not downright buggy by its
looks.

Re: Variable pitch text filling

[Yuan Fu]

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



> On Nov 29, 2021, at 11:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Mon, 29 Nov 2021 10:44:32 -0800
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> emacs-devel@gnu.org
>> 
>> I think aligning to middle is better, see the image below.
> 
> Please also try a line that begins with CJK characters below a line
> that begins with English characters.  In that case, flushed left
> should look the best, because it will be aligned with the beginnings
> of the other lines.
> 
>> I manually inserted spaces between CJK characters to align them to ASCII characters. The second line is flushed left, the third flushed right, and the fourth aligned to middle. If we flush the CJK to left, CJK characters are closer to the text before and further from the text after, and vice versa for flushing right. The middle-aligned line looks better. 
> 
> In real-life use, there will usually be a space character between
> English and CJK, right?  If so, the minor pixel differences you
> mention will not be usually perceptible.  By contrast, the problem
> with the leftmost characters not being aligned will _always_ be
> visible, and will make the display ugly if not downright buggy by its
> looks.

You are right :-)



Yuan


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

[-- Attachment #2.2: Screen Shot 2021-11-29 at 12.13.37 PM.png --]
[-- Type: image/png, Size: 79735 bytes --]

Re: Variable pitch text filling

[Lars Ingebrigtsen]

I've now added a pixel-fill.el package (that's basically the relevant
bits from the shr filling code).

The justification support discussed has not been added yet, because
we're still discussing just how the redisplay-level support for this is
supposed to look, so that bit will be added later.

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

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Perhaps we could eat the cake and also have it: the 'space' spec
>> already supports a notion of "units".  Currently, we have:
>>
>>        UNIT ::= in | mm | cm | width | height
>>
>> where "width" and "height" are for the default face's font.  So we
>> could add a new "unit", say, "face-width" or "font-width" (and
>> similarly with height), to mean dimensions of the character of the
>> font used by the underlying face.
>
> Yes, that makes sense.

So I think we're in agreement concerning the feature set here.  Do you
want to implement this, or should I take a crack at it?

Uhm...  did we decide on a name?  I think I suggested calling the text
property `char-spacing'...

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

Re: Variable pitch text filling

[Eli Zaretskii]

On December 1, 2021 6:35:02 AM GMT+02:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> >> Perhaps we could eat the cake and also have it: the 'space' spec
> >> already supports a notion of "units".  Currently, we have:
> >>
> >>        UNIT ::= in | mm | cm | width | height
> >>
> >> where "width" and "height" are for the default face's font.  So we
> >> could add a new "unit", say, "face-width" or "font-width" (and
> >> similarly with height), to mean dimensions of the character of the
> >> font used by the underlying face.
> >
> > Yes, that makes sense.
> 
> So I think we're in agreement concerning the feature set here.  Do you
> want to implement this, or should I take a crack at it?
> 
> Uhm...  did we decide on a name?  I think I suggested calling the text
> property `char-spacing'...
> 

I was under the impression that you asked me to do this.  But don't let this stop you from doing that yourself, if you want.

AFAIU, we need 2 separate features: (a) a variable to force all characters to have width that is an integral multiple of some "standard" pixel width; and (b) a display spec that would enlarge the pixel width of every character with that display property by some number of pixels.  The display spec can be called char-width.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I was under the impression that you asked me to do this.  But don't
> let this stop you from doing that yourself, if you want.

You said you were going to work on the display_string min-width/C string
thing, but I don't recall discussing who was going to do this thing
(which is totally separate).

> AFAIU, we need 2 separate features: (a) a variable to force all
> characters to have width that is an integral multiple of some
> "standard" pixel width; and (b) a display spec that would enlarge the
> pixel width of every character with that display property by some
> number of pixels.  The display spec can be called char-width.

Well, there were three features that should all be text properties.  To
recap:

1) Be able to specify a min width based on a "standard" char width (for
"-" in the mode line, for instance)

2) A specific pixel width (for justification, for instance)

3) The integral multiple (i.e., "grid")

The third thing should be a buffer-local variable in addition to a text
property.

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

Re: Variable pitch text filling

[chad]

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

On Tue, Nov 30, 2021 at 9:32 PM Eli Zaretskii <eliz@gnu.org> wrote:

> [...] a display spec that would enlarge the pixel width of every character
> with that display property by some number of pixels.  The display spec can
> be called char-width.
>

I know that the two great problems are naming, cache invalidation, and
off-by-one errors, but in case it helps: if I understand the concept
correctly, it's very close to what typesetting calls "tracking".

Hope that helps,
~Chad

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

Re: Variable pitch text filling

[Eli Zaretskii]

On December 1, 2021 7:39:42 AM GMT+02:00, chad <yandros@gmail.com> wrote:
> On Tue, Nov 30, 2021 at 9:32 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > [...] a display spec that would enlarge the pixel width of every character
> > with that display property by some number of pixels.  The display spec can
> > be called char-width.
> >
> 
> I know that the two great problems are naming, cache invalidation, and
> off-by-one errors, but in case it helps: if I understand the concept
> correctly, it's very close to what typesetting calls "tracking".

Emacs users are not professional typographers, so something like "tracking" will confuse rather than help.  We should use "spacing" or somesuch.

Re: Variable pitch text filling

[Yuri Khan]

On Wed, 1 Dec 2021 at 13:54, Eli Zaretskii <eliz@gnu.org> wrote:

> Emacs users are not professional typographers, so something like "tracking" will confuse rather than help.  We should use "spacing" or somesuch.

More specifically, “letter spacing”. There is also line spacing aka leading.

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 06:38:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I was under the impression that you asked me to do this.  But don't
> > let this stop you from doing that yourself, if you want.
> 
> You said you were going to work on the display_string min-width/C string
> thing, but I don't recall discussing who was going to do this thing
> (which is totally separate).

I thought you asked me (separately ;-) to work on both.

> > AFAIU, we need 2 separate features: (a) a variable to force all
> > characters to have width that is an integral multiple of some
> > "standard" pixel width; and (b) a display spec that would enlarge the
> > pixel width of every character with that display property by some
> > number of pixels.  The display spec can be called char-width.
> 
> Well, there were three features that should all be text properties.  To
> recap:
> 
> 1) Be able to specify a min width based on a "standard" char width (for
> "-" in the mode line, for instance)
> 
> 2) A specific pixel width (for justification, for instance)
> 
> 3) The integral multiple (i.e., "grid")
> 
> The third thing should be a buffer-local variable in addition to a text
> property.

We already have 1), it just needs some loving care, AFAIU?  What is
missing in min-width to provide 1) ?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I thought you asked me (separately ;-) to work on both.

Less work for me is less work for me.  😀

>> 1) Be able to specify a min width based on a "standard" char width (for
>> "-" in the mode line, for instance)
>> 
>> 2) A specific pixel width (for justification, for instance)
>> 
>> 3) The integral multiple (i.e., "grid")
>> 
>> The third thing should be a buffer-local variable in addition to a text
>> property.
>
> We already have 1), it just needs some loving care, AFAIU?  What is
> missing in min-width to provide 1) ?

For min-width provides both 1) and 2), but it's inefficient for both, so
I think it makes sense to allow both these things in the char-spacing
(or whatever we're calling it) thing.

As a practical matter, `min-width' doesn't support nesting now, and we'd
have to make it recursive to allow having both a `min-width' on a series
of characters and on separate characters (as we need in the U:--- thing
in the mode line), which would further make `min-width' more inefficient.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 15:33:47 +0100
> 
> > We already have 1), it just needs some loving care, AFAIU?  What is
> > missing in min-width to provide 1) ?
> 
> For min-width provides both 1) and 2), but it's inefficient for both, so
> I think it makes sense to allow both these things in the char-spacing
> (or whatever we're calling it) thing.
> 
> As a practical matter, `min-width' doesn't support nesting now, and we'd
> have to make it recursive to allow having both a `min-width' on a series
> of characters and on separate characters (as we need in the U:--- thing
> in the mode line), which would further make `min-width' more inefficient.

In what way is min-width inefficient?

I'm not sure I understand the "recursive" part: if some string has a
certain value of some text property, then every character of that
string has that same value of that property, and thus you cannot have
some of those characters have the same property with a different
value.  So how can the "recursive" part work in practice?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> In what way is min-width inefficient?

I'm not sure -- you're the one who said it was?  But it does to a lot of
work, dropping into the start/stop machinery and doing computations.
This new property is purely on a char by char basis, so it doesn't have
to do any of that stuff.

> I'm not sure I understand the "recursive" part: if some string has a
> certain value of some text property, then every character of that
> string has that same value of that property, and thus you cannot have
> some of those characters have the same property with a different
> value.  So how can the "recursive" part work in practice?

You'd have to maintain a stack in the `min-width' machinery to handle
"overlapping" (or rather, nesting) min-width display properties.  I'd
rather not.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 16:10:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In what way is min-width inefficient?
> 
> I'm not sure -- you're the one who said it was?  But it does to a lot of
> work, dropping into the start/stop machinery and doing computations.
> This new property is purely on a char by char basis, so it doesn't have
> to do any of that stuff.

OK, I will have a look.  I don't think what we have is expensive, but
maybe I'm missing something.

> > I'm not sure I understand the "recursive" part: if some string has a
> > certain value of some text property, then every character of that
> > string has that same value of that property, and thus you cannot have
> > some of those characters have the same property with a different
> > value.  So how can the "recursive" part work in practice?
> 
> You'd have to maintain a stack in the `min-width' machinery to handle
> "overlapping" (or rather, nesting) min-width display properties.  I'd
> rather not.

So what are the requirements for the replacement feature here?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So what are the requirements for the replacement feature here?

I think it's basically to be able to specify the widths that the `space'
display ting takes -- pixels and "normal characters" (and the latter
should be extended to the "normal character" of the face, as you pointed
out).

But the wrinkle is that these spaces should only be used if the
character is narrower than the space we computed.

In addition, there should be a way to specify that the space should be
an integer multiple of the "normal character" width.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 17:49:05 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So what are the requirements for the replacement feature here?
> 
> I think it's basically to be able to specify the widths that the `space'
> display ting takes -- pixels and "normal characters" (and the latter
> should be extended to the "normal character" of the face, as you pointed
> out).
> 
> But the wrinkle is that these spaces should only be used if the
> character is narrower than the space we computed.
> 
> In addition, there should be a way to specify that the space should be
> an integer multiple of the "normal character" width.

Is this per character or per string?

And what happened to the "recursive" part of what you described
earlier -- is that no longer needed?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > So what are the requirements for the replacement feature here?
>> 
>> I think it's basically to be able to specify the widths that the `space'
>> display ting takes -- pixels and "normal characters" (and the latter
>> should be extended to the "normal character" of the face, as you pointed
>> out).
>> 
>> But the wrinkle is that these spaces should only be used if the
>> character is narrower than the space we computed.
>> 
>> In addition, there should be a way to specify that the space should be
>> an integer multiple of the "normal character" width.
>
> Is this per character or per string?

I was describing the char-spacing thing, not the min-width thing.  :-/
So, per character.

> And what happened to the "recursive" part of what you described
> earlier -- is that no longer needed?

If we implement the char-spacing thing as above, then we don't need to
touch the min-width thing, yes.

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

Re: Variable pitch text filling

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, if we're distributing the extra space on the space characters only,
> we can use space specs.  But usually typesetters don't do that -- they
> also distribute some of the space between other characters, too, to get
> a more even "greyness".  (Or whatever they call it -- it's been a few
> years since I read up on typography last time.)

Graphical design software also hyphenate and use other non-trivial
tactics to get justified text right.

The main problem I see is that unless you go down that road seriously
it's easy to find a solution that'll look rather bad in many cases.
For example, IMHO most web browsers fail pretty badly at this, as does
many word processors.  For starters, they don't hyphenate, but just
add more space between words, which is exactly the thing you'd want to
avoid: you end up with "rivers" of whitespace in the text.

Try this in Firefox or some other web browser to see what I mean:
    https://developer.mozilla.org/en-US/docs/Web/CSS/text-justify

IMHO, I think we'd at the very least need a hyphenation feature to do
a somewhat proper job.  This is unfortunately hard to get right, as
hyphenation rules differ depending on languages, and there are even
different preferences within the same language (we have two main
methods for hyphenation in Swedish, both equally accepted).
Anecdotally, I have used Adobe InDesign extensively (proprietary
software, sorry) for book and magazine production, and over the years
I have amassed hundreds of custom rules for words where the default
hyphenation engine did a suboptimal job in my eyes.

That said, maybe we don't care to do better than, say, Firefox.  In
that case, the job is of course much simpler.

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 18:02:08 +0100
> 
> >> In addition, there should be a way to specify that the space should be
> >> an integer multiple of the "normal character" width.
> >
> > Is this per character or per string?
> 
> I was describing the char-spacing thing, not the min-width thing.  :-/
> So, per character.
> 
> > And what happened to the "recursive" part of what you described
> > earlier -- is that no longer needed?
> 
> If we implement the char-spacing thing as above, then we don't need to
> touch the min-width thing, yes.

I'm sorry, I'm confused now.  Let's go to your original 3 requests:

> 1) Be able to specify a min width based on a "standard" char width (for
> "-" in the mode line, for instance)
> 
> 2) A specific pixel width (for justification, for instance)
> 
> 3) The integral multiple (i.e., "grid")

1) is for mode line, and is satisfied with min-width display spec
(which needs to be fixed, perhaps, see bug#52183).
2) is for pixel-resolution justification, and will be satisfied by a
new kind of display spec.
3) will should be per-buffer (or globally), and will be satisfied by a new
buffer-local variable.

Is something missing?

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 1 Dec 2021 18:07:33 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> IMHO, I think we'd at the very least need a hyphenation feature to do
> a somewhat proper job.

I think hyphenation is a separate feature, and a major job at that.
We _can_ have justification without it, since most real-life
situations are nowhere near the extreme cases you show.

> This is unfortunately hard to get right, as
> hyphenation rules differ depending on languages, and there are even
> different preferences within the same language (we have two main
> methods for hyphenation in Swedish, both equally accepted).

Exactly.  So let's not let the perfect block the good, okay?  We are
(still) not pretending to be a WYSIWYG word processor, so we can be
excused for occasionally doing a less than perfect job (which still is
better than not supporting justification at all).

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> 1) Be able to specify a min width based on a "standard" char width (for
>> "-" in the mode line, for instance)
>> 
>> 2) A specific pixel width (for justification, for instance)
>> 
>> 3) The integral multiple (i.e., "grid")
>
> 1) is for mode line, and is satisfied with min-width display spec
> (which needs to be fixed, perhaps, see bug#52183).
> 2) is for pixel-resolution justification, and will be satisfied by a
> new kind of display spec.
> 3) will should be per-buffer (or globally), and will be satisfied by a new
> buffer-local variable.
>
> Is something missing?

Yes.

1) is difficult to achieve, because we haven't implemented a recursive
`min-width'.  To do so it possible, but finicky, since we have to look
far ahead in the buffer to see whether a new min-width spec ends the
current one, or starts a new recursive one.  I'd rather not do that,
because it'd be ugly and weird. 

So all three of these should be a new kind of text property.  In
addition, 3) should also be a buffer-local variable in addition to being
a text property.  (The text property is useful if you have a monospace
table in a buffer, but there may be other text in the buffer that you
don't want to quantise.)

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 18:35:31 +0100
> 
> 1) is difficult to achieve, because we haven't implemented a recursive
> `min-width'.

In what situations you'd need such a "recursive" min-width?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> 1) is difficult to achieve, because we haven't implemented a recursive
>> `min-width'.
>
> In what situations you'd need such a "recursive" min-width?

In the "U:--" in the mode line, where the "-" should be wider, and there
should be an overall min-width for the entire thing.

But to reiterate -- I don't think we should do that, and instead use
char-spacing for "-".

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 18:52:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 1) is difficult to achieve, because we haven't implemented a recursive
> >> `min-width'.
> >
> > In what situations you'd need such a "recursive" min-width?
> 
> In the "U:--" in the mode line, where the "-" should be wider, and there
> should be an overall min-width for the entire thing.

Why would you need the overall min-width, if each one of the "-" is as
wide as "*" or "%" (whichever is wider)?

IOW, why also have a condition on a whole when you already have
conditions on each one of its parts?

Re: Variable pitch text filling

[john muhl]

On Wed, 2021-12-01 at 08:52 +0200, Eli Zaretskii wrote:
> On December 1, 2021 7:39:42 AM GMT+02:00, chad <yandros@gmail.com>
> wrote:
> > On Tue, Nov 30, 2021 at 9:32 PM Eli Zaretskii <eliz@gnu.org>
> > wrote:
> > 
> > > [...] a display spec that would enlarge the pixel width of every
> > > character
> > > with that display property by some number of pixels.  The
> > > display spec can
> > > be called char-width.
> > > 
> > 
> > I know that the two great problems are naming, cache invalidation,
> > and
> > off-by-one errors, but in case it helps: if I understand the
> > concept
> > correctly, it's very close to what typesetting calls "tracking".
> 
> Emacs users are not professional typographers, so something like
> "tracking" will confuse rather than help.  We should use "spacing"
> or somesuch.
> 

Some of us are (of course we don't use Emacs for our jobs but for all
the other stuff it is good at).

Eli is right that Emacs using terms like tracking (etc) would be more
confusing than inventing something; even (maybe especially) to those
with a background in typography since the likelihood of it doing what
we expect is probably slim.

"char-spacing" lines up well with "line-spacing".

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why would you need the overall min-width, if each one of the "-" is as
> wide as "*" or "%" (whichever is wider)?

That's not what we're going for, I think?  The "-" should be made as
wide as a "normal character", but "%" is often wider.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 19:19:16 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why would you need the overall min-width, if each one of the "-" is as
> > wide as "*" or "%" (whichever is wider)?
> 
> That's not what we're going for, I think?  The "-" should be made as
> wide as a "normal character", but "%" is often wider.

That's not the important part in my question, the important part is
this:

> IOW, why also have a condition on a whole when you already have
> conditions on each one of its parts?

Since the overall width is a sum of the widths of the individual
characters, placing min-width on each character would also yield
min-width on all of them together.  Right?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Since the overall width is a sum of the widths of the individual
> characters, placing min-width on each character would also yield
> min-width on all of them together.  Right?

The overall min-width here will be larger than the sum of the individual
min-widths.  I think we're going for 6 typical characters for the
"U:--", which is four separate typical character widths.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 19:52:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Since the overall width is a sum of the widths of the individual
> > characters, placing min-width on each character would also yield
> > min-width on all of them together.  Right?
> 
> The overall min-width here will be larger than the sum of the individual
> min-widths.

Then all you need to do is to make the min-width of the last character
larger than those of the preceding ones

> I think we're going for 6 typical characters for the "U:--", which
> is four separate typical character widths.

So the last one should have a larger min-width.  Doesn't that solve
the problem?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think we're going for 6 typical characters for the "U:--", which
>> is four separate typical character widths.
>
> So the last one should have a larger min-width.  Doesn't that solve
> the problem?

No?  If the ":" becomes twice as wide, that won't affect the min-width
of the last "-".  And so the bits after the last "-" will shift to the
right.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 20:23:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I think we're going for 6 typical characters for the "U:--", which
> >> is four separate typical character widths.
> >
> > So the last one should have a larger min-width.  Doesn't that solve
> > the problem?
> 
> No?  If the ":" becomes twice as wide, that won't affect the min-width
> of the last "-".  And so the bits after the last "-" will shift to the
> right.

But the same will happen in your case if ":" becomes 10 times as wide!
there's no end to this if we are going to consider hypothetical cases
which will never happen.  min-width is about handling too-narrow
strings, not too wide strings.

Re: Variable pitch text filling

[Jim Porter]

On 12/1/2021 10:19 AM, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> Why would you need the overall min-width, if each one of the "-" is as
>> wide as "*" or "%" (whichever is wider)?
> 
> That's not what we're going for, I think?  The "-" should be made as
> wide as a "normal character", but "%" is often wider.
I hope that whatever the implementation of the U:--- thing, the width of 
each element doesn't change when you click on it. That would make it 
harder to click multiple times on the same element (e.g. if you 
mistakenly clicked and want to undo the change by clicking again). In 
the case of "%", I mentioned this in the other thread about it[1]:

> This points to a similar problem I mentioned, but in reverse: If a buffer is currently read-only and I click the first "%", it will change to "-" and thus become narrower. Depending on where my mouse pointer is, that could mean it's now hovering over the "modified" indicator, so if I click again, I end up changing the "modified" state, not the "read-only" state.

Currently, the "-" is much narrower, so the change in size is pretty 
significant. However, even a small change in size could cause this issue 
depending on where exactly the mouse pointer is. (Personally, I prefer 
the U:--- thing to be monospace since it doesn't have these issues and 
Just Works today, but I wouldn't necessarily oppose an implementation 
that worked just as well for variable-width fonts.)

- Jim

[1] https://lists.gnu.org/archive/html/emacs-devel/2021-11/msg01996.html

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> No?  If the ":" becomes twice as wide, that won't affect the min-width
>> of the last "-".  And so the bits after the last "-" will shift to the
>> right.
>
> But the same will happen in your case if ":" becomes 10 times as wide!
> there's no end to this if we are going to consider hypothetical cases
> which will never happen.  min-width is about handling too-narrow
> strings, not too wide strings.

I'm not considering any hypothetical cases -- I'm just describing the
bog-standard way this works.

Adding a wide min-width to the last "-" is not affected by any of the
previous bits.  We're putting a too-wide min-width over all these four
characters to allow them to stretch individually outside their allotted
spaces, but without affecting the part afterwards.

I'm not quibbling or trying to be difficult here -- this is extremely
basic, and I don't think you've thought this through.

Trust me.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 20:34:52 +0100
> 
> I'm not considering any hypothetical cases -- I'm just describing the
> bog-standard way this works.

Then please explain how a ":" character can become twice wider.

> Adding a wide min-width to the last "-" is not affected by any of the
> previous bits.  We're putting a too-wide min-width over all these four
> characters to allow them to stretch individually outside their allotted
> spaces, but without affecting the part afterwards.

Characters don't stretch, they stay the same width.  If "-" is
replaced by "*", then the width could change, but if each of them has
a min-width that accommodates all the possibilities, that won't give
us any trouble.

> I'm not quibbling or trying to be difficult here -- this is extremely
> basic, and I don't think you've thought this through.
> 
> Trust me.

Sorry, I cannot write code out of trust alone.  I need, for some
strange reason, to understand the goal.

So if I'm too stupid to understand and think through your intentions,
then I'm afraid you'll have to do this yourself.  At least I tried,
and tried very hard.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm not considering any hypothetical cases -- I'm just describing the
>> bog-standard way this works.
>
> Then please explain how a ":" character can become twice wider.

By changing to a "%", for instance (which is twice as wide in some fonts).

> Characters don't stretch, they stay the same width.  If "-" is
> replaced by "*", then the width could change, but if each of them has
> a min-width that accommodates all the possibilities, that won't give
> us any trouble.

But they don't.  They shouldn't be shorter than a normal character here,
because that makes them difficult to click, but they will change size
individually.  I.e., when "-" changes to "%", the other chars later in
"U:--" will move, but the things later in the mode line won't.

> So if I'm too stupid to understand and think through your intentions,
> then I'm afraid you'll have to do this yourself.  At least I tried,
> and tried very hard.

OK, I'll implement this, then.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 02 Dec 2021 09:15:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'm not considering any hypothetical cases -- I'm just describing the
> >> bog-standard way this works.
> >
> > Then please explain how a ":" character can become twice wider.
> 
> By changing to a "%", for instance (which is twice as wide in some fonts).

Which is why I said:

> > Characters don't stretch, they stay the same width.  If "-" is
> > replaced by "*", then the width could change, but if each of them has
> > a min-width that accommodates all the possibilities, that won't give
> > us any trouble.
> 
> But they don't.  They shouldn't be shorter than a normal character here,
> because that makes them difficult to click, but they will change size
> individually.

Putting a min-width property on each of them will achieve that goal,
right?

> I.e., when "-" changes to "%", the other chars later in
> "U:--" will move, but the things later in the mode line won't.

If each of these, "U", ":", "-", and "-", has min-width defined for
it, none of them will move, and things later on the mode line won't
move, either.

> > So if I'm too stupid to understand and think through your intentions,
> > then I'm afraid you'll have to do this yourself.  At least I tried,
> > and tried very hard.
> 
> OK, I'll implement this, then.

On which of the 3 features you intend to work?  I'd hate to have us
step on each other's toes.

Or maybe what I say above settles the disagreement?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> But they don't.  They shouldn't be shorter than a normal character here,
>> because that makes them difficult to click, but they will change size
>> individually.
>
> Putting a min-width property on each of them will achieve that goal,
> right?

The goal is not to make the individual characters in U:-- not change
displayed width.  To do that, you'd have to make each character as wide
as the widest glyph in the font, and that will be really ugly.  The goal
is to make the "-" wide enough that you can click it, which is why they
should have a char-spacing property of "one normal character".

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 02 Dec 2021 09:56:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But they don't.  They shouldn't be shorter than a normal character here,
> >> because that makes them difficult to click, but they will change size
> >> individually.
> >
> > Putting a min-width property on each of them will achieve that goal,
> > right?
> 
> The goal is not to make the individual characters in U:-- not change
> displayed width.  To do that, you'd have to make each character as wide
> as the widest glyph in the font, and that will be really ugly.

Not the widest glyph in the font, only the widest of the characters
that can be displayed in that place on the mode line.  Which is a
small set, so there's no problem finding the widest one, even
statically and in advance.

> The goal is to make the "-" wide enough that you can click it, which
> is why they should have a char-spacing property of "one normal
> character".

But it is also ugly to have those characters move when we display a
different character in one of those places.  Someone asked to make
sure such a shift doesn't happen, so that users could click on the
same place more than once without moving the mouse, to toggle the
setting back and forth.  If we don't make each of these characters a
separate string with its separate min-width, we cannot make sure such
shifts don't happen.

So I think the solution of making each of these characters a separate
string with a separate min-width, which is "wide enough for our
purposes" is a better solution, which achieves both goals at the same
time.

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 18:35:31 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 1) Be able to specify a min width based on a "standard" char width (for
> >> "-" in the mode line, for instance)
> >> 
> >> 2) A specific pixel width (for justification, for instance)
> >> 
> >> 3) The integral multiple (i.e., "grid")
> >
> > 1) is for mode line, and is satisfied with min-width display spec
> > (which needs to be fixed, perhaps, see bug#52183).
> > 2) is for pixel-resolution justification, and will be satisfied by a
> > new kind of display spec.
> > 3) will should be per-buffer (or globally), and will be satisfied by a new
> > buffer-local variable.
> >
> > Is something missing?
> 
> Yes.
> 
> 1) is difficult to achieve, because we haven't implemented a recursive
> `min-width'.  To do so it possible, but finicky, since we have to look
> far ahead in the buffer to see whether a new min-width spec ends the
> current one, or starts a new recursive one.  I'd rather not do that,
> because it'd be ugly and weird. 
> 
> So all three of these should be a new kind of text property.  In
> addition, 3) should also be a buffer-local variable in addition to being
> a text property.  (The text property is useful if you have a monospace
> table in a buffer, but there may be other text in the buffer that you
> don't want to quantise.)

I've now implemented the "variable" part of 3).  To try it, set the
new variable align-columns-display (suggestions for a better name are
welcome) to a non-nil value.  I'd like our CJK users to try this and
tell if they like the results, before implementing also the
text-property part of the feature, as that is significantly more
complex to code.

Note: there's currently a heuristic in the code I installed, meant to
detect fixed-pitch fonts (the above feature only affects fixed-pitch
faces).  In the long run, we probably should extend 'struct font' to
have this flag readily available, so there should be no need for that
heuristic.

Re: Variable pitch text filling

[Yuan Fu]

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



> On Dec 2, 2021, at 9:53 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 01 Dec 2021 18:35:31 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> 1) Be able to specify a min width based on a "standard" char width (for
>>>> "-" in the mode line, for instance)
>>>> 
>>>> 2) A specific pixel width (for justification, for instance)
>>>> 
>>>> 3) The integral multiple (i.e., "grid")
>>> 
>>> 1) is for mode line, and is satisfied with min-width display spec
>>> (which needs to be fixed, perhaps, see bug#52183).
>>> 2) is for pixel-resolution justification, and will be satisfied by a
>>> new kind of display spec.
>>> 3) will should be per-buffer (or globally), and will be satisfied by a new
>>> buffer-local variable.
>>> 
>>> Is something missing?
>> 
>> Yes.
>> 
>> 1) is difficult to achieve, because we haven't implemented a recursive
>> `min-width'.  To do so it possible, but finicky, since we have to look
>> far ahead in the buffer to see whether a new min-width spec ends the
>> current one, or starts a new recursive one.  I'd rather not do that,
>> because it'd be ugly and weird. 
>> 
>> So all three of these should be a new kind of text property.  In
>> addition, 3) should also be a buffer-local variable in addition to being
>> a text property.  (The text property is useful if you have a monospace
>> table in a buffer, but there may be other text in the buffer that you
>> don't want to quantise.)
> 
> I've now implemented the "variable" part of 3).  To try it, set the
> new variable align-columns-display (suggestions for a better name are
> welcome) to a non-nil value.  I'd like our CJK users to try this and
> tell if they like the results, before implementing also the
> text-property part of the feature, as that is significantly more
> complex to code.

This is very cool! When I test it it seems CJK characters are not aligned when first displayed, but are aligned after the cursor goes over them. Opening a directory, I first see



Where there is no space inserted between CJK characters (the spaces seems to be accumulated at the end of consecutive CJK characters, in this case before the period). If I place my cursor on one CJK character, I see



Emacs adds spaces after the character under point, but the space obstructs the character after. If I hold on C-f and go over every character, their alignment are fixed:



Highlighting the region puts them back:



This is a dired buffer, the text properties are

There are text properties here:
  dired-filename       t
  fontified            t
  help-echo            "mouse-2: visit this file in other window"
  mouse-face           highlight

HTH,
Yuan


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

[-- Attachment #2.2: Screen Shot 2021-12-02 at 10.54.40 AM.png --]
[-- Type: image/png, Size: 66218 bytes --]

[-- Attachment #2.3: Screen Shot 2021-12-02 at 10.57.19 AM.png --]
[-- Type: image/png, Size: 24096 bytes --]

[-- Attachment #2.4: Screen Shot 2021-12-02 at 10.59.35 AM.png --]
[-- Type: image/png, Size: 66295 bytes --]

[-- Attachment #2.5: Screen Shot 2021-12-02 at 11.00.06 AM.png --]
[-- Type: image/png, Size: 76633 bytes --]

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 2 Dec 2021 11:03:36 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  Feng Shu <tumashu@163.com>,
>  emacs-devel@gnu.org
> 
> When I test it it seems CJK characters are not aligned when first
> displayed, but are aligned after the cursor goes over them.

You mean, you do

  M-: (setq align-columns-display t) RET

and then you visit a file with CJK characters, say etc/HELLO, and
initially you don't see the characters aligned in columns?

> Opening a directory, I first see
> 
> 
> 
> Where there is no space inserted between CJK characters (the spaces seems to be accumulated at the end of consecutive CJK characters, in this case before the period). If I place my cursor on one CJK character, I see
> 
> 
> 
> Emacs adds spaces after the character under point, but the space obstructs the character after. If I hold on C-f and go over every character, their alignment are fixed:
> 
> 
> 
> Highlighting the region puts them back:

Does this happen only in Dired, or also in etc/HELLO, and in any other
situation?

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 2 Dec 2021 11:03:36 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  Feng Shu <tumashu@163.com>,
>  emacs-devel@gnu.org
> 
> This is very cool! When I test it it seems CJK characters are not aligned when first displayed, but are aligned after the cursor goes over them. Opening a directory, I first see
> 
> 
> 
> Where there is no space inserted between CJK characters (the spaces seems to be accumulated at the end of consecutive CJK characters, in this case before the period). If I place my cursor on one CJK character, I see
> 
> 
> 
> Emacs adds spaces after the character under point, but the space obstructs the character after. If I hold on C-f and go over every character, their alignment are fixed:

Yes, I see it as well.  Strange.  I guess I'm missing something here.
Hmm...

Re: Variable pitch text filling

[Jim Porter]

On 12/2/2021 12:56 AM, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> But they don't.  They shouldn't be shorter than a normal character here,
>>> because that makes them difficult to click, but they will change size
>>> individually.
>>
>> Putting a min-width property on each of them will achieve that goal,
>> right?
> 
> The goal is not to make the individual characters in U:-- not change
> displayed width.  To do that, you'd have to make each character as wide
> as the widest glyph in the font, and that will be really ugly.  The goal
> is to make the "-" wide enough that you can click it, which is why they
> should have a char-spacing property of "one normal character".

How bad would it look if the U:--- thing specifically were fixed width 
by default, even if the rest of the mode line used a variable-width 
font? Keeping the individual characters in the U:--- thing from moving 
around would be very nice. Getting partway there by using :min-width 
might still be useful for people who *really* want the U:--- thing to be 
variable-width, but it seems worse than being able to rely[1] on each 
character staying the same size (and in the same spot).

- Jim

[1] Well, mostly rely. Some stuff like setting an input method will push 
the U:--- thing to the right, but that's due to adding all-new 
characters to the U:--- thing, so I don't see an easy way to avoid that.

Re: Variable pitch text filling

[Stefan Kangas]

Jim Porter <jporterbugs@gmail.com> writes:

> How bad would it look if the U:--- thing specifically were fixed width
> by default, even if the rest of the mode line used a variable-width
> font?

Another idea is to think about using SVG icons for (some?) of this
information on graphical displays.  I have no idea how viable this is,
but I'm putting the idea out there (unless someone already did?).  In
any case, I hope to set aside some time to finish up icons.el over the
holidays, and once that is done it should be easy to play around with it
to see if we can come up with something.

Yet another idea is to just not display anything in some states.  For
example, I almost always edit Unicode files with Unix line endings, so I
would only want an indication if this is *not* the case.  Maybe this is
different on other platforms, but I expect this is fairly typical on
GNU/Linux at least.  Similarly, maybe we don't need to show any
indicator at all until a buffer is modified?

RE: [External] : Re: Variable pitch text filling

[Drew Adams]

YA case where the state specified by AntiNEWS
is preferable to that specified by NEWS.
YAWAGNI.

Re: Variable pitch text filling

[Jim Porter]

On 12/2/2021 1:19 PM, Stefan Kangas wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
>> How bad would it look if the U:--- thing specifically were fixed width
>> by default, even if the rest of the mode line used a variable-width
>> font?
> 
> Another idea is to think about using SVG icons for (some?) of this
> information on graphical displays.  I have no idea how viable this is,
> but I'm putting the idea out there (unless someone already did?).  In
> any case, I hope to set aside some time to finish up icons.el over the
> holidays, and once that is done it should be easy to play around with it
> to see if we can come up with something.

I mentioned that in the mode-line thread, but yeah, that would also be 
an option. Assuming we could find a good set of icons that cover all the 
possible states, that would solve this nicely.

That said, I forgot to mention the most obvious case where the default 
Emacs configuration already changes the width of elements of the U:--- 
thing: the newline indicator. For example, DOS newlines are indicated 
via U(DOS)---. (Unless you're on a Windows/DOS system, that is.)

I use single-character indicators so that it's easier to cycle through 
them without clicking on the wrong thing. The default is probably easier 
to understand for new users, but I find it pretty annoying. Switching to 
icons here would be a nice improvement if they were all the same width.

- Jim

Re: Variable pitch text filling

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Another idea is to think about using SVG icons for (some?) of this
> information on graphical displays.  I have no idea how viable this is,
> but I'm putting the idea out there (unless someone already did?).  In
> any case, I hope to set aside some time to finish up icons.el over the
> holidays, and once that is done it should be easy to play around with it
> to see if we can come up with something.

Please don't make the MULE status display use SVG icons.  Keeping it
monospace text would work to solve this problem, with less of an effort
needed.

> Yet another idea is to just not display anything in some states.  For
> example, I almost always edit Unicode files with Unix line endings, so I
> would only want an indication if this is *not* the case.

That is not the case at my workplace, where we have to work on files
that are either CR/LF or Unix.  (Not because we use Windows much, but
that's how it is.)

That display is very useful.

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 2 Dec 2021 13:19:39 -0800
> Cc: emacs-devel@gnu.org
> 
> Yet another idea is to just not display anything in some states.  For
> example, I almost always edit Unicode files with Unix line endings, so I
> would only want an indication if this is *not* the case.

Patches to make this customizable will be welcome, I think.  We
already allow customization for the EOL indication.

But please keep in mind that an Emacs buffer doesn't only show files,
it also shows text from other sources.  For example, email, where
Unicode is not as common as files on certain platforms.  And even with
files, don't you see "-" there many times?  If not, it means you are
looking at ELisp files too much ;-)

> Maybe this is different on other platforms, but I expect this is
> fairly typical on GNU/Linux at least.

No, the most typical is to have "-" there, not U.  As long as you deal
mainly with ASCII files, that is.

> Similarly, maybe we don't need to show any indicator at all until a
> buffer is modified?

That indicator has very little to do with the buffer being modified,
so no, that will make little sense.  Moreover, having the indicator
pop up suddenly will attract attention and distract for no good
reason.

Re: Variable pitch text filling

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Thu, 2 Dec 2021 14:32:08 -0800
> 
> That said, I forgot to mention the most obvious case where the default 
> Emacs configuration already changes the width of elements of the U:--- 
> thing: the newline indicator. For example, DOS newlines are indicated 
> via U(DOS)---. (Unless you're on a Windows/DOS system, that is.)
> 
> I use single-character indicators so that it's easier to cycle through 
> them without clicking on the wrong thing. The default is probably easier 
> to understand for new users, but I find it pretty annoying. Switching to 
> icons here would be a nice improvement if they were all the same width.

It was deliberately designed to annoy and attract attention, because I
was told back then that users might otherwise miss an indication
that's telling them the file has an unusual (a.k.a. "foreign") EOL
format.  If this is no longer an issue nowadays, we could change the
default to be one-character no matter what is the platform.

Re: Variable pitch text filling

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>> Date: Thu, 2 Dec 2021 14:32:08 -0800
>> 
>> That said, I forgot to mention the most obvious case where the default 
>> Emacs configuration already changes the width of elements of the U:--- 
>> thing: the newline indicator. For example, DOS newlines are indicated 
>> via U(DOS)---. (Unless you're on a Windows/DOS system, that is.)
>> 
>> I use single-character indicators so that it's easier to cycle through 
>> them without clicking on the wrong thing. The default is probably easier 
>> to understand for new users, but I find it pretty annoying. Switching to 
>> icons here would be a nice improvement if they were all the same width.

> It was deliberately designed to annoy and attract attention, because I
> was told back then that users might otherwise miss an indication
> that's telling them the file has an unusual (a.k.a. "foreign") EOL
> format.  If this is no longer an issue nowadays, we could change the
> default to be one-character no matter what is the platform.

FWIW it saved me from checking in files with the wrong type of EOL a few
times today.

So I think it is still a relevant problem.

Re: Variable pitch text filling

[Eli Zaretskii]

> Date: Thu, 02 Dec 2021 22:18:51 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: tumashu@163.com, larsi@gnus.org, emacs-devel@gnu.org
> 
> > Emacs adds spaces after the character under point, but the space obstructs the character after. If I hold on C-f and go over every character, their alignment are fixed:
> 
> Yes, I see it as well.  Strange.  I guess I'm missing something here.
> Hmm...

I'm very sorry.  This cannot work.  The problem is that we can easily
change the pixel-width of the character glyphs Emacs uses for its
layout calculations (which is what the change did), but when we
actually draw the glyphs on the glass, we ask the font backend to draw
a series of glyphs in one go, and the font backend uses the original
glyph metrics as reported by the font.  So, unless we draw each glyph
separately (which is what moving the cursor through text causes us to
do), something that will slow down redisplay, we cannot add spacing to
characters that way.

This is one of the "TIL" situations each one of us has with Emacs from
time to time.  It means my thinking about adding character spacing was
based on wrong assumptions, and the only way to do that is to add
stretch glyphs (which can be done only between words).

I reverted the changeset installed yesterday.

Re: Variable pitch text filling

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 02 Dec 2021 22:18:51 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: tumashu@163.com, larsi@gnus.org, emacs-devel@gnu.org
>> 
>> > Emacs adds spaces after the character under point, but the space obstructs the character after. If I hold on C-f and go over every character, their alignment are fixed:
>> 
>> Yes, I see it as well.  Strange.  I guess I'm missing something here.
>> Hmm...
>
> I'm very sorry.  This cannot work.  The problem is that we can easily
> change the pixel-width of the character glyphs Emacs uses for its
> layout calculations (which is what the change did), but when we
> actually draw the glyphs on the glass, we ask the font backend to draw
> a series of glyphs in one go, and the font backend uses the original
> glyph metrics as reported by the font.  So, unless we draw each glyph
> separately (which is what moving the cursor through text causes us to
> do), something that will slow down redisplay, we cannot add spacing to
> characters that way.
>
> This is one of the "TIL" situations each one of us has with Emacs from
> time to time.  It means my thinking about adding character spacing was
> based on wrong assumptions, and the only way to do that is to add
> stretch glyphs (which can be done only between words).
>
> I reverted the changeset installed yesterday.

this is really a bad news :-(

-- 

Re: Variable pitch text filling

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 02 Dec 2021 22:18:51 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: tumashu@163.com, larsi@gnus.org, emacs-devel@gnu.org
>> 
>> > Emacs adds spaces after the character under point, but the space obstructs the character after. If I hold on C-f and go over every character, their alignment are fixed:
>> 
>> Yes, I see it as well.  Strange.  I guess I'm missing something here.
>> Hmm...
>
> I'm very sorry.  This cannot work.  The problem is that we can easily
> change the pixel-width of the character glyphs Emacs uses for its
> layout calculations (which is what the change did), but when we
> actually draw the glyphs on the glass, we ask the font backend to draw
> a series of glyphs in one go, and the font backend uses the original
> glyph metrics as reported by the font.  So, unless we draw each glyph
> separately (which is what moving the cursor through text causes us to
> do), something that will slow down redisplay, we cannot add spacing to
> characters that way.
>
> This is one of the "TIL" situations each one of us has with Emacs from
> time to time.  It means my thinking about adding character spacing was
> based on wrong assumptions, and the only way to do that is to add
> stretch glyphs (which can be done only between words).
>
> I reverted the changeset installed yesterday.

Maybe we should conside the below feature:
1. Prevent minibuffer/mode/header/tab-line from shaking up and down 
2. Provide a simple fontset config UI? customize-fontset?
3. line-height-factor


-- 

Re: Variable pitch text filling

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: casouri@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 03 Dec 2021 16:17:56 +0800
> 
> > I'm very sorry.  This cannot work.  The problem is that we can easily
> > change the pixel-width of the character glyphs Emacs uses for its
> > layout calculations (which is what the change did), but when we
> > actually draw the glyphs on the glass, we ask the font backend to draw
> > a series of glyphs in one go, and the font backend uses the original
> > glyph metrics as reported by the font.  So, unless we draw each glyph
> > separately (which is what moving the cursor through text causes us to
> > do), something that will slow down redisplay, we cannot add spacing to
> > characters that way.
> >
> > This is one of the "TIL" situations each one of us has with Emacs from
> > time to time.  It means my thinking about adding character spacing was
> > based on wrong assumptions, and the only way to do that is to add
> > stretch glyphs (which can be done only between words).
> >
> > I reverted the changeset installed yesterday.
> 
> this is really a bad news :-(

What I can propose instead, as a kind-of "second best", is a similar
feature that will only affect whitespace characters (SPC and TAB):
when the proposed feature is turned on, those whitespace characters
will always end at X coordinate that is an integral multiple of the
"standard" column width.  This way, a word within a text that mixes
ASCII and non-ASCII characters will always start on an integral column
boundary, as defined by the ASCII font of the face.

Would this be useful enough to implement?

Re: Variable pitch text filling

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: casouri@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 03 Dec 2021 16:51:41 +0800
> 
> Maybe we should conside the below feature:
> 1. Prevent minibuffer/mode/header/tab-line from shaking up and down 
> 2. Provide a simple fontset config UI? customize-fontset?
> 3. line-height-factor

First, I don't see how any feature that affects the height of the
lines could be useful for horizontal character-spacing, in general.

Second, I already implemented 1 and 3, and you rejected the results as
unsatisfactory, so this is off the table.

As for easier customization of fontsets: patches are welcome, of
course.  But again, I'm not sure it will fix the problem discussed
here, since no one has yet come up with a list of fonts where the
problems that bother you are resolved.

Re: Variable pitch text filling

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: casouri@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Fri, 03 Dec 2021 16:51:41 +0800
>> 
>> Maybe we should conside the below feature:
>> 1. Prevent minibuffer/mode/header/tab-line from shaking up and down 
>> 2. Provide a simple fontset config UI? customize-fontset?
>> 3. line-height-factor
>
> First, I don't see how any feature that affects the height of the
> lines could be useful for horizontal character-spacing, in general.
>
> Second, I already implemented 1 and 3, and you rejected the results as

What patch is implement 1?  I only seen line-height-factor patch.

> unsatisfactory, so this is off the table.
>
> As for easier customization of fontsets: patches are welcome, of
> course.  But again, I'm not sure it will fix the problem discussed
> here, since no one has yet come up with a list of fonts where the
> problems that bother you are resolved.

-- 

Re: Variable pitch text filling

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: casouri@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Fri, 03 Dec 2021 16:51:41 +0800
>> 
>> Maybe we should conside the below feature:
>> 1. Prevent minibuffer/mode/header/tab-line from shaking up and down 
>> 2. Provide a simple fontset config UI? customize-fontset?
>> 3. line-height-factor
>
> First, I don't see how any feature that affects the height of the
> lines could be useful for horizontal character-spacing, in general.
>
> Second, I already implemented 1 and 3, and you rejected the results as

the patch implemented 1, do you mean the below?

+++ b/src/window.c
@@ -5246,7 +5246,10 @@ grow_mini_window (struct window *w, int delta)
 {
   struct frame *f = XFRAME (w->frame);
   int old_height = window_body_height (w, true);
-  int min_height = FRAME_LINE_HEIGHT (f);
+  int min_height =
+    FLOATP (Vline_height_factor)
+    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
+    : FRAME_LINE_HEIGHT (f);
 
   eassert (MINI_WINDOW_P (w));
 
@@ -5279,7 +5282,11 @@ grow_mini_window (struct window *w, int delta)
 shrink_mini_window (struct window *w)
 {
   struct frame *f = XFRAME (w->frame);
-  int delta = window_body_height (w, true) - FRAME_LINE_HEIGHT (f);
+  int min_line_height =
+    FLOATP (Vline_height_factor)
+    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
+    : FRAME_LINE_HEIGHT (f);
+  int delta = window_body_height (w, true) - min_line_height;
 
   eassert (MINI_WINDOW_P (w));
 
diff --git a/src/xdisp.c b/src/xdisp.c



> unsatisfactory, so this is off the table.
>
> As for easier customization of fontsets: patches are welcome, of
> course.  But again, I'm not sure it will fix the problem discussed
> here, since no one has yet come up with a list of fonts where the
> problems that bother you are resolved.

-- 

Re: Variable pitch text filling

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: casouri@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 03 Dec 2021 19:44:25 +0800
> 
> > Second, I already implemented 1 and 3, and you rejected the results as
> 
> What patch is implement 1?  I only seen line-height-factor patch.

The same line-height-factor did.

Re: Variable pitch text filling

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: casouri@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Fri, 03 Dec 2021 16:17:56 +0800
>> 
>> > I'm very sorry.  This cannot work.  The problem is that we can easily
>> > change the pixel-width of the character glyphs Emacs uses for its
>> > layout calculations (which is what the change did), but when we
>> > actually draw the glyphs on the glass, we ask the font backend to draw
>> > a series of glyphs in one go, and the font backend uses the original
>> > glyph metrics as reported by the font.  So, unless we draw each glyph
>> > separately (which is what moving the cursor through text causes us to
>> > do), something that will slow down redisplay, we cannot add spacing to
>> > characters that way.
>> >
>> > This is one of the "TIL" situations each one of us has with Emacs from
>> > time to time.  It means my thinking about adding character spacing was
>> > based on wrong assumptions, and the only way to do that is to add
>> > stretch glyphs (which can be done only between words).
>> >
>> > I reverted the changeset installed yesterday.
>> 
>> this is really a bad news :-(
>
> What I can propose instead, as a kind-of "second best", is a similar
> feature that will only affect whitespace characters (SPC and TAB):
> when the proposed feature is turned on, those whitespace characters
> will always end at X coordinate that is an integral multiple of the
> "standard" column width.  This way, a word within a text that mixes
> ASCII and non-ASCII characters will always start on an integral column
> boundary, as defined by the ASCII font of the face.
>
> Would this be useful enough to implement?

If it is not hard implement, I suggest provide this patch, so we can try
it and provide feekback.



-- 

Re: Variable pitch text filling

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: casouri@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 03 Dec 2021 19:55:51 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What I can propose instead, as a kind-of "second best", is a similar
> > feature that will only affect whitespace characters (SPC and TAB):
> > when the proposed feature is turned on, those whitespace characters
> > will always end at X coordinate that is an integral multiple of the
> > "standard" column width.  This way, a word within a text that mixes
> > ASCII and non-ASCII characters will always start on an integral column
> > boundary, as defined by the ASCII font of the face.
> >
> > Would this be useful enough to implement?
> 
> If it is not hard implement, I suggest provide this patch, so we can try
> it and provide feekback.

Lars, WDYT?

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This is one of the "TIL" situations each one of us has with Emacs from
> time to time.  It means my thinking about adding character spacing was
> based on wrong assumptions, and the only way to do that is to add
> stretch glyphs (which can be done only between words).

Why can stretch glyphs only be added between words?  Is it because we
ask the font backend to draw a series of glyphs in one go?

If that's the case, perhaps we could stop doing that if we're doing a
gridded display?

One other thing that occurred to me (but I didn't look at closely) is
whether it would be feasible to work on the glyph matrix for a line
after it's been composed.  I remember you doing some work on that when
we talked about "compressing the mode line" -- I think you basically
went over the matrix and removed some of the space glyphs?  (That
approach didn't work for other reasons, but the basic post processing
thing did work, I think?)

Do we have enough info about the glyphs at that stage that we could add
some stretch glyphs to gridify the line?

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

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Not the widest glyph in the font, only the widest of the characters
> that can be displayed in that place on the mode line.  Which is a
> small set, so there's no problem finding the widest one, even
> statically and in advance.

I don't think that will look nice.  That is, the "%" glyph is usually so
much larger than the "-" glyph that it'll just look weird.

>> The goal is to make the "-" wide enough that you can click it, which
>> is why they should have a char-spacing property of "one normal
>> character".
>
> But it is also ugly to have those characters move when we display a
> different character in one of those places.  Someone asked to make
> sure such a shift doesn't happen, so that users could click on the
> same place more than once without moving the mouse, to toggle the
> setting back and forth.  If we don't make each of these characters a
> separate string with its separate min-width, we cannot make sure such
> shifts don't happen.

I don't agree that that should be our goal here, because it'll look
ugly.  The goal here is to ensure that the user can click on the "-"
glyphs.

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

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Another idea is to think about using SVG icons for (some?) of this
> information on graphical displays.

Yes, I think using SVG icons for this stuff (optionally) would be nice.
But we should get this (in general) when not doing SVG icons, so it's
kinda an orthogonal issue.

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

Re: Variable pitch text filling

[Jim Porter]

On 12/2/2021 11:08 PM, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>> Date: Thu, 2 Dec 2021 14:32:08 -0800
>>
>> That said, I forgot to mention the most obvious case where the default
>> Emacs configuration already changes the width of elements of the U:---
>> thing: the newline indicator. For example, DOS newlines are indicated
>> via U(DOS)---. (Unless you're on a Windows/DOS system, that is.)
>>
>> I use single-character indicators so that it's easier to cycle through
>> them without clicking on the wrong thing. The default is probably easier
>> to understand for new users, but I find it pretty annoying. Switching to
>> icons here would be a nice improvement if they were all the same width.
> 
> It was deliberately designed to annoy and attract attention, because I
> was told back then that users might otherwise miss an indication
> that's telling them the file has an unusual (a.k.a. "foreign") EOL
> format.  If this is no longer an issue nowadays, we could change the
> default to be one-character no matter what is the platform.

I think it's still an issue, and making the indicator "louder" for 
non-native EOL formats is probably still a good move.

Maybe it'd be enough to make the indicator for non-native EOL formats be 
a different color, or some other face property, like adding a bright box 
around it. That would still be attention-grabbing, but wouldn't change 
the size of the U:--- thing.

- Jim

Re: Variable pitch text filling

[Stefan Kangas]

Jim Porter <jporterbugs@gmail.com> writes:

> I think it's still an issue, and making the indicator "louder" for
> non-native EOL formats is probably still a good move.

Sorry if I'm repeating myself, but just showing nothing by default will
make it "louder" (more attention grabbing) when it is actually shown.

> Maybe it'd be enough to make the indicator for non-native EOL formats be
> a different color, or some other face property, like adding a bright box
> around it. That would still be attention-grabbing, but wouldn't change
> the size of the U:--- thing.

I think we should be careful to avoid a Christmas tree effect though.

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: casouri@gmail.com,  tumashu@163.com,  emacs-devel@gnu.org
> Date: Fri, 03 Dec 2021 16:41:35 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is one of the "TIL" situations each one of us has with Emacs from
> > time to time.  It means my thinking about adding character spacing was
> > based on wrong assumptions, and the only way to do that is to add
> > stretch glyphs (which can be done only between words).
> 
> Why can stretch glyphs only be added between words?  Is it because we
> ask the font backend to draw a series of glyphs in one go?

Yes.  A series of glyphs of the same type (character glyphs, stretch
glyphs, composition glyphs, etc.) are collected into a "glyph string"
and drawn by the backend in one go.

> If that's the case, perhaps we could stop doing that if we're doing a
> gridded display?

That'd be much slower, I guess?  For each such separate glyph we need
first clear the background with the color of the face, then draw the
glyph itself.  Right now, we clear the background for all of the
glyphs in one GUI call, then write all of the glyphs in a single call
to the font driver.

> One other thing that occurred to me (but I didn't look at closely) is
> whether it would be feasible to work on the glyph matrix for a line
> after it's been composed.  I remember you doing some work on that when
> we talked about "compressing the mode line" -- I think you basically
> went over the matrix and removed some of the space glyphs?  (That
> approach didn't work for other reasons, but the basic post processing
> thing did work, I think?)

That'd cause the same problem as above: each character glyph will be
drawn separately, because the stretch glyphs in-between them will
break the sequence of character glyphs into individual characters.

> Do we have enough info about the glyphs at that stage that we could add
> some stretch glyphs to gridify the line?

Yes, information is not the problem.

Re: Variable pitch text filling

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That'd be much slower, I guess?  For each such separate glyph we need
> first clear the background with the color of the face, then draw the
> glyph itself.  Right now, we clear the background for all of the
> glyphs in one GUI call, then write all of the glyphs in a single call
> to the font driver.

Every decent font system has the ability to specify glyph advances
manually.

Perhaps we could extend the font driver's draw function with another
`advance' parameter that specifies the width of each glyph?

We already do this in the Cairo font backend, and the Mac font backend,
but transparently without the knowledge of the rest of Emacs.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> If that's the case, perhaps we could stop doing that if we're doing a
>> gridded display?
>
> That'd be much slower, I guess?  For each such separate glyph we need
> first clear the background with the color of the face, then draw the
> glyph itself.  Right now, we clear the background for all of the
> glyphs in one GUI call, then write all of the glyphs in a single call
> to the font driver.

Perhaps we could try to benchmark -- it might be acceptable (and we
wouldn't be doing this in all buffers normally).  But I don't know how
to benchmark this.

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

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  tumashu@163.com,
>  casouri@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 04 Dec 2021 08:35:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That'd be much slower, I guess?  For each such separate glyph we need
> > first clear the background with the color of the face, then draw the
> > glyph itself.  Right now, we clear the background for all of the
> > glyphs in one GUI call, then write all of the glyphs in a single call
> > to the font driver.
> 
> Every decent font system has the ability to specify glyph advances
> manually.
> 
> Perhaps we could extend the font driver's draw function with another
> `advance' parameter that specifies the width of each glyph?

If you find a way of doing that with the main font drivers we have on
all the supported platforms, I don't see why not.

Re: Variable pitch text filling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: casouri@gmail.com,  tumashu@163.com,  emacs-devel@gnu.org
> Date: Sat, 04 Dec 2021 06:41:43 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> If that's the case, perhaps we could stop doing that if we're doing a
> >> gridded display?
> >
> > That'd be much slower, I guess?  For each such separate glyph we need
> > first clear the background with the color of the face, then draw the
> > glyph itself.  Right now, we clear the background for all of the
> > glyphs in one GUI call, then write all of the glyphs in a single call
> > to the font driver.
> 
> Perhaps we could try to benchmark -- it might be acceptable (and we
> wouldn't be doing this in all buffers normally).

Actually, CJK users are likely to turn this on globally.

> But I don't know how to benchmark this.

Write some Lisp to add a (space :width (1)) display spec on every
second letter of a large buffer, and then scroll through it one line
at a time, calling redisplay after each scroll.  You'd probably need
to disable double-buffering, to avoid its skewing the results.  Some
of the slowdown will be due to processing the display properties, but
if we care about that, we could measure just that separately and
subtract.

Re: Variable pitch text filling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, CJK users are likely to turn this on globally.

Yeah, I guess.  But I think it's acceptable to get a slowdown for an
optional setting.

Outside of CJK settings, it's likely that things that use a tabulated
display would set this to avoid having glitches when showing CJK
characters -- but we'd only insert the spacing glyphs when we see some
CJK characters, so it should be OK there, too.

>> But I don't know how to benchmark this.
>
> Write some Lisp to add a (space :width (1)) display spec on every
> second letter of a large buffer, and then scroll through it one line
> at a time, calling redisplay after each scroll.  You'd probably need
> to disable double-buffering, to avoid its skewing the results.  Some
> of the slowdown will be due to processing the display properties, but
> if we care about that, we could measure just that separately and
> subtract.

I think it's likely that the `display' handling would greatly overwhelm
the benchmark, so perhaps the only way to get a realistic benchmark is
to implement it and see.

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