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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 12 Oct 2020 09:12:05 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> emacs -Q
> (progn
>   (set-frame-width nil 80)
>   (setq max-mini-window-height 1)
>   (setq default-directory (concat "/" (make-string 67 ?a)))
>   (call-interactively 'find-file))
> press C-x o
> press C-s
> 
> At this point you see no indication that I-search has been started. (If you look close enough, the only thing you can see is a curly arrow in the right fringe of the miniwindow.) Likewise, if you press C-x C-s, you see no indication that changes have been saved (or not). And so forth.

Right.

> I suggest the following fourth condition in set-minibuffer-message:
> 
> (< (buffer-size (window-buffer (active-minibuffer-window))) (/ (frame-width 
> (window-frame (active-minibuffer-window))) 2))

So you suggest in that case to overwrite the minibuffer prompt, like
Emacs 26 did?  I'm not sure I like this: it would bring back many
problems this feature was supposed to fix.  Can we do better than
obliterating the entire minibuffer text?

Juri, any ideas?

In any case, I think the condition could be relaxed: we only care
about how much space is left from the minibuffer text's end till the
end of the screen line, so "if minibuffer text size modulo
window-width is less than something" would be better, I think.  E.g.,
if you use 70 instead of 67 in your recipe, the problem is mostly
gone.

Also, it would be safer to use string-width instead of the number of
characters, or even window-text-pixel-size: some people do customize
the faces used in the minibuffer.

> It is amazing that such a feature got accepted, was included in an official Emacs release, and became Emacs' default behavior, without even trying the two obvious cases to test: what happens when there is not enough free space in the minibuffer? and what happens when the active minibuffer is not on the same frame?

This has some history.  You are welcome to read the discussion in
bug#38457, especially starting at

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38457#17

You will see that many issues were discussed, the dangers were
expected, and as result the change became less invasive, which was
especially important because the release cycle was about to start.
However, it didn't sound wise to reject the changes outright because
they've fixed several important use cases that were an annoyance for a
long time.

But yes, any significant change in such basic functionality runs a
risk to break something, especially in relatively rare use cases
(max-mini-window-height set to 1, followed by "C-x o" out of the
minibuffer).  This risk is inherent part of development, and sometimes
mistakes are being made.  We try at least not to make the mistakes we
know about.

> It is even more amazing that, at the same time, my proposed solution to display completion candidates in the minibuffer is rejected on the grounds that it could cause "potential problems", when so far no one has managed to show a case in which it would create an actual problem.

Maybe because we are now wiser and don't want to repeat past mistakes?

Btw, the C-s use case is special, you can see that if you do just
this:

  C-x C-f
  C-s

Juri, would it make sense to do something special for Isearch in the
"C-x o" case as well?  Or am I wrong, and there's nothing special
with Isearch using the mini-window here?