GNU bug report logs - #73734
[PATCH] Fix tmm menu layout

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: rudalics <at> gmx.at, 73734 <at> debbugs.gnu.org
Subject: Re: bug#73734: [PATCH] Fix tmm menu layout
Date: Fri, 11 Oct 2024 09:51:31 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: rudalics <at> gmx.at,  73734 <at> debbugs.gnu.org
> Date: Fri, 11 Oct 2024 08:37:00 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.)

> >> >>       - I don't think "(window-width)" is what we need since, by
> >> >>         default, the *Completions* buffer will use the full frame width.
> >> >
> >> > Martin, is that guaranteed?
> >> >
> >> > And even if it is, what's the harm in keeping window-width?
> >> 
> >> I don't think that a full frame width *Completions* buffer is
> >> guaranteed: it is only what I see with "emacs -Q".
> >> 
> >> Keeping window-width in this calculation seems a bit strange because, by
> >> default, it has nothing to do with the *Completions* buffer window
> >> width.
> >
> > Which window's width does this return in this case?
> 
> AFAIU, this window-width call is done from the user's current window.

Then it's indeed not relevant, but let's wait for Martin to chime in.

Previous Next

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