Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: rudalics@gmx.at, 73734@debbugs.gnu.org >> Date: Fri, 11 Oct 2024 08:37:00 +0200 >> >> Eli Zaretskii writes: >> >> > Ah, I see now what you meant. But if this is the problem, then >> > changing the column width is not a reliable solution, because you >> > cannot know in advance what will be the width of the SPC glyph in a >> > font people use. I suggest to use 'display' properties instead, for >> > example '(space . (:width N)), where N is the number of canonical >> > columns we want the space to take on display. >> >> Sure this will be more reliable for proportional font's users but we'll >> still need to calculate this N that would be (- colwidth (string-width >> str) (string-width binding)) I think. And so we still need a value for >> colwidth, no? > > Yes, we will still need a value for colwidth. But string-width counts > columns, so it returns the same value for fixed-pitch and > variable-pitch fonts alike; it doesn't count pixels. Using 'display' > properties, we can force the SPC characters used as delimiters to take > exactly one canonical column, even if the font actually used has > narrower glyphs for SPC. So the computed colwidth value will be > displayed reliably, and will never cause the visual confusion which > you show on your screenshot. In which case we can leave the > currently-computed colwidth value alone, as it is not what causes the > problem. (We could also decide to use other values for colwidth, but > it would be a separate issue, unrelated to the confusing display.) With the following patch: