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

Previous Next

Full log

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71605 <at> debbugs.gnu.org
Subject: Re: bug#71605: 30.0.50; [PATCH] Support variable-width text in
 'visual-wrap-prefix-mode'
Date: Tue, 18 Jun 2024 15:17:29 -0700

On 6/18/2024 4:37 AM, Eli Zaretskii wrote:
> I don't think I understand how would this do the job.  Surely, the
> indentation space should be visible?

I mean the second-line "*  " prefix would be visible but transparent.

>> A face transparency attribute might do the trick, and be useful for
>> other things too:
> 
> It isn't universally supported, AFAIK.

I think it would be feasible to support an opacity level of 1.0 and 0.0. 
opacity=0.0 could just allocate the space for the text but not actually 
draw the glyphs. (Whether we want to go this route is another question.)

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

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.

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

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

Previous Next

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