unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Gregory Heytings <ghe@sdf.org>
Cc: acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
	juri@linkov.net
Subject: Re: New multi-command facility displays in the wrong echo area.
Date: Mon, 12 Oct 2020 20:20:46 +0300	[thread overview]
Message-ID: <83ft6j2wep.fsf@gnu.org> (raw)
In-Reply-To: <alpine.NEB.2.22.394.2010121808250453.19729@sdf.lonestar.org> (message from Gregory Heytings on Mon, 12 Oct 2020 16:31:27 +0000)

> 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	other threads:[~2020-10-12 17:20 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 16:34 New multi-command facility displays in the wrong echo area Alan Mackenzie
2020-10-09 19:47 ` Stefan Monnier
2020-10-09 20:38   ` Alan Mackenzie
2020-10-09 22:12     ` Stefan Monnier
2020-10-09 22:56       ` Drew Adams
2020-10-10  6:52     ` Eli Zaretskii
2020-10-10 10:32       ` Alan Mackenzie
2020-10-10 11:13         ` Eli Zaretskii
2020-10-10 12:36           ` Gregory Heytings via Emacs development discussions.
2020-10-10 12:44           ` Alan Mackenzie
2020-10-10 12:50             ` Eli Zaretskii
2020-10-10 13:00               ` Eli Zaretskii
2020-10-10 20:30                 ` Gregory Heytings via Emacs development discussions.
2020-10-11 14:38                   ` Eli Zaretskii
2020-10-12  9:12                     ` Gregory Heytings via Emacs development discussions.
2020-10-12 12:00                       ` Alan Mackenzie
2020-10-12 12:18                         ` Gregory Heytings via Emacs development discussions.
2020-10-12 14:37                       ` Eli Zaretskii
2020-10-12 15:41                         ` Gregory Heytings via Emacs development discussions.
2020-10-12 16:01                           ` Eli Zaretskii
2020-10-12 16:31                             ` Gregory Heytings via Emacs development discussions.
2020-10-12 17:20                               ` Eli Zaretskii [this message]
2020-10-12 21:06                                 ` Gregory Heytings via Emacs development discussions.
2020-10-13 14:03                                   ` Eli Zaretskii
2020-10-13 19:27                                     ` Gregory Heytings via Emacs development discussions.
2020-10-13 21:22                                       ` Gregory Heytings via Emacs development discussions.
2020-10-12 17:12                         ` Drew Adams
2020-10-12 17:34                           ` Eli Zaretskii
2020-10-12 19:46                         ` Juri Linkov
2020-10-13  2:25                           ` Eli Zaretskii
2020-10-14 20:44                       ` Gregory Heytings via Emacs development discussions.
     [not found]                         ` <1cd65040-f7ad-4613-b3fb-7cfa62bb0488@default>
2020-10-14 22:15                           ` Gregory Heytings via Emacs development discussions.
2020-10-14 22:51                         ` Stefan Monnier
2020-10-16  7:19                           ` Eli Zaretskii
2020-10-16  7:19                         ` Eli Zaretskii
2020-10-10 13:03             ` Gregory Heytings via Emacs development discussions.
2020-10-10 13:47               ` Alan Mackenzie
2020-10-10 20:20                 ` Gregory Heytings via Emacs development discussions.
2020-10-09 21:14   ` Gregory Heytings via Emacs development discussions.
2020-10-09 21:48     ` Gregory Heytings via Emacs development discussions.
2020-10-10 10:15       ` Alan Mackenzie
2020-10-10 13:44         ` Stefan Monnier
     [not found] <<20201009163445.GB4027@ACM>
     [not found] ` <<jwv362nkwss.fsf-monnier+emacs@gnu.org>
     [not found]   ` <<20201009203810.GC4027@ACM>
     [not found]     ` <<83imbi609a.fsf@gnu.org>
2020-10-10 16:11       ` Drew Adams
2020-10-10 20:40         ` Gregory Heytings via Emacs development discussions.
2020-10-11  0:59           ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83ft6j2wep.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=ghe@sdf.org \
    --cc=juri@linkov.net \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).