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

[Alan Mackenzie]

Hello, Gregory.

On Mon, Oct 12, 2020 at 09:12:05 +0000, Gregory Heytings wrote:

> > Thanks.  So I think your change is a definite improvement, and I 
> > therefore installed it on the emacs-27 branch.

> Thank you.  Alas, it's not the only bug of this new feature.  A recipe:

> 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.

Well, whoever sees/doesn't see this did set max-mini-window-height to 1.
Surely this is a case of you ask for it, you get it.

> 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))

> Of course it's a heuristic (it could still fail when the face used in the 
> miniwindow is different, and larger than, the default face), but it should 
> catch 99.99% of the remaining error cases.

Perhaps there's a less heuristic way of dealing with it.  I haven't
looked into it closely.

> 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?

Bugs are always obvious after somebody's pointed them out.  Well done
for finding them!

> 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.

Emacs is ~45 years old.  Some of the maintainers have been on the job
for more than half of that time.  They've developed a feel for what fits
in harmoniously and what could easily jar and cause problems in the
future.  Given the complexity of Emacs, we can't really afford to wait
until potential problems become real problems - there might just be too
many of these to cope with.

For what it's worth, others (including me) have had effective bug fixes
rejected on various grounds.  For better or for worse, it's just part of
Emacs development.

-- 
Alan Mackenzie (Nuremberg, Germany).