emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New multi-command facility displays in the wrong echo area.


From: Eli Zaretskii
Subject: Re: New multi-command facility displays in the wrong echo area.
Date: Mon, 12 Oct 2020 20:20:46 +0300

> Date: Mon, 12 Oct 2020 16:31:27 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: juri@linkov.net, acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Indeed, this would also work:
> 
> (< (mod (car (window-text-pixel-size (active-minibuffer-window))) 
> (window-text-width (active-minibuffer-window) t))
>     (/ (car (window-text-pixel-size (active-minibuffer-window))) 2))
> 
> But going in that direction means that one should also take the current 
> window height into account: if the miniwindow is tall enough, the above 
> condition could be nil even though there would be enough room to display 
> the message.

You mean, if the message to be displayed in the minibuffer uses large
fonts or includes tall images?  In that case, we will simply display
the single line with partially-visible text/image (assuming
max-mini-window-height doesn't allow to resize to see all of it), and
I don't see what can be done about that.

It is highly unusual for messages to use such faces or images, and if
some features do that, users of those features should be told to not
limit the mini-window height to a size that's too small.

> > We can discuss other solutions, of course.  However, significant changes 
> > will have to wait for Emacs 28.
> 
> Ouch.  So this last-minute change will last for several years?

Unless we can come up with a change that is either simple or safe.  Or
if we decide that the current situation is so unacceptable that we are
willing to take higher risks of releasing a less stable Emacs 27.2.

> > Please give me the credit of having done so.  I've given you no reason 
> > to believe otherwise; disagreement doesn't imply incompetence or 
> > sloppiness on my part.  It is simply unfair and even rude to suggest 
> > that.
> 
> I do not suggest anything like that.  But I'm a doubting Thomas, and I 
> can't give you this credit until I see a recipe that would convincingly 
> demonstrate a potential problem that my proposed solution would create. 

I cannot help you with your doubts more than I already did.  If you
still have those doubts, I'd appreciate if you keep them to yourself,
because having them written here is an insult I don't think I deserve.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]