GNU bug report logs - #71605
30.0.50; [PATCH] Support variable-width text in 'visual-wrap-prefix-mode'

Previous Next

Full log

Message #53 received at 71605 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 71605 <at> debbugs.gnu.org
Subject: Re: bug#71605: 30.0.50; [PATCH] Support variable-width text in
 'visual-wrap-prefix-mode'
Date: Wed, 19 Jun 2024 14:45:56 +0300

> Date: Tue, 18 Jun 2024 15:17:29 -0700
> Cc: 71605 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 6/18/2024 4:37 AM, Eli Zaretskii wrote:
> >> Or maybe :align-to could take a string value, which would mean "use the
> >> pixel-width of this string as the value".
> > 
> > How is that different from using a column (as opposed to pixel) value
> > for :align-to?
> 
> A column wouldn't work, since for a variable-pitch font, N columns is 
> just N * <canonical character width>. If the actual characters you're 
> trying to align to are narrower than the canonical width, they won't 
> line up correctly.

If both the first line of the paragraph and the rest are aligned on
that width, they will all line up.  IOW, the idea is to make the text
of all the lines :align-to to the same column number, like this:

  * some text
    some other text

Then you don't care about the actual pixel width of "* ".

> Po Lu also raised the issue that in some cases, different frames can be 
> displaying the same buffer using different fonts. Conceptually, I'm 
> really trying to tell the display engine, "Put a space here exactly as 
> wide as <some text> using whatever font you end up using." At the buffer 
> level, I can't provide a numeric width here that works everywhere, since 
> it might really be multiple numbers, one for each frame.

IMNSHO, this is over-engineering, as we already have the means to do
the same with existing features.  Asking the display engine to measure
and record somewhere the pixel width of a string is a significant
complication to how the display code works, because the display
routines can be called to start their job at any arbitrary place in
the buffer.

> Providing a number in pixels is also challenging because then I need to 
> be able to determine when to recompute that number.

Which is why I didn't suggest that.  I suggested columns because they
scale with text-scale-adjust.

> >>>> If I set that correctly, then the pixel-size should adjust as the
> >>>> text scales. It wouldn't handle the case where the actual font
> >>>> changes though.
> >>>
> >>> Why not?
> >>
> >> I was planning to set :relative-width to <first_line_prefix_width> /
> >> <width_of_one_space>. If the font changes, the result of that
> >> calculation can change.
> > 
> > The idea is to set it to the multiple of the character's width, which
> > will then scale with the font.
> 
> Imagine two fonts A and B, where the only difference is that the space 
> character in B is twice as wide. So:
> 
>      <asterisk_width> = 15
>      <space_width_A> = 10
>      <space_width_B> = 20
>      <first_line_prefix_width_A> = 15 + 10 = 25
>      <first_line_prefix_width_B> = 15 + 20 = 35
> 
> If I compute :relative-width for font A, the result is 25/10 = 2.5. Then,
> 
>      2.5 * <space_width_A> = 25  = <first_line_prefix_width_A>  (good)
>      2.5 * <space_width_B> = 50 != <first_line_prefix_width_B>  (bad!)
> 
> So we'd need a way of keeping the width in-sync with any font changes.

I don't understand the example.  If these are two different
paragraphs, then their indentation cannot be guaranteed to be the same
anyway, because no one can assure you all the paragraphs will use the
same font.  So whatever you mean by <width_of_one_space>, it will
always be different for different fonts, and I don't see how this can
be solved for an arbitrary combination of fonts.

So my suggestion is to go back to the simpler idea of using :align-to
with an absolute value, either in pixels or in columns (which AFAIR is
interpreted in units of the frame's default font's width), and if
needed augment that by recalculation when necessary.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.