Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Drew Adams]

> > Would doing something like what eldoc-minibuffer-message does
> > possibly be a good solution?  It seems to me that this is safer than the
> > current situation, as it does not fiddle with the minibuffer contents.
> > If so, what do you (and others) think of the following...
> 
> I personally feel that moving echo-area messages to the mode line is
> too drastic a change to make it by default, and certainly in a minor
> release.  But let's hear wjat others think, and what other ideas will
> be brought up.

As I mentioned, the basic problem is due to sharing
the same area between minibuffer and echo area.

Ultimately, a good solution requires being able to
see both at the same time.  Juggling their content
wrt time, while sharing the same space, won't take
care of the problem in general.

The same problem will exist if you move output
(`message' echoes) to the mode-line: you won't be
able to see the mode-line info and the message at
the same time.

For simple interactions, there's no problem.  The
problem arises for more complex interactions, and
for that no "solution" that always uses the same
space can possibly be a real solution.

Do I think that using the mode-line makes more
sense than forcing `message' output to, in effect,
use `minibuffer-message', i.e., putting it at the
end of your minibuffer input?

Yes, probably the mode-line is usually better
than that, at least.  When you're responding to a
prompt, anything that's not directly related to
the prompt-&-response interaction doesn't belong
in the input area.

But we do need a real solution, assuming that we
think that bug #38457 is serious enough.  The fix
accepted for that bug isn't healthy, as I've said.

A real solution provides separate areas for echo
(output) and minibuffer input.

We could reserve some new area for echoing.  Or we
could choose to echo in a separate area only when
needed.  E.g., we might use the same area for echo
and minibuffer whenever there's no conflict (no
overlap in time), and show echoes in some other
place (e.g. pop-up) in the rarer cases when needed.

"Pop up" here could mean temporarily overwriting
the mode-line, as Gregory suggested.  Or it could
temporarily overwrite the last line(s) of the
window content. Or it could mean popping up a
window or frame.  Or...

The point is this:

1. For simple interactions, there's no problem.
   Most of the time there's no overlap in time
   between output and input.

2. For complex interactions, i.e., when output and
   input overlap in time, NO solution that shares
   the same space really takes care of the problem.

   At best, we end up showing the output for some
   brief period of time, and then return to showing
   the input.  And that doesn't really satisfy bug
   #38457.

3. To deal with #2, we need to use some separate
   space for output (echoes).  We could either (a)
   always have two separate spaces (e.g. a new area
   for `message' etc. echoes) or (b) show echoes in
   some other area only when needed ("pop up").

4. If we do choose to overwrite (hide) something
   in order to show output in a temporary way, then
   IMO it's better to overwrite/hide some buffer
   text, or the mode-line, than it is to do that
   to minibuffer input.

   The last thing we should hide or interfere with
   is the immediate user interaction (responding to
   a prompt by providing text input).

#4 is a personal opinion.  The rest should hopefully
be considered less controversial.
___


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

(Completely ignored there.)

Re: Where to show message output while inputting

[Kévin Le Gouguec]

Drew Adams <drew.adams@oracle.com> writes:

> 4. If we do choose to overwrite (hide) something
>    in order to show output in a temporary way, then
>    IMO it's better to overwrite/hide some buffer
>    text, or the mode-line, than it is to do that
>    to minibuffer input.
>
>    The last thing we should hide or interfere with
>    is the immediate user interaction (responding to
>    a prompt by providing text input).

Emacs is no stranger to popping up windows when the user needs to be
alerted of something (e.g. disabled-command-function).  Maybe, when the
echo area is unavailable, `message' could…

- pop up the *Messages* buffer, highlighting the latest message (or
  creating a window that's only tall enough for this message),

- arrange for *Messages* to be buried when the user exits the
  minibuffer, and for a reminder about C-h e to be messaged?

Re: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Gregory Heytings via Emacs development discussions.]

>
> The same problem will exist if you move output (`message' echoes) to the 
> mode-line: you won't be able to see the mode-line info and the message 
> at the same time.
>

That's obviously a problem that will exist in any possible solution to 
that problem: the message will hide something.  The question is then: what 
is the "something" that can be hidden with the least possible risk?  IMO 
the mode-line is, in this context, the least important element, and it can 
be temporarily right-shifted.  Eldoc does this, too.

>
> Or we could choose to echo in a separate area only when needed.  E.g., 
> we might use the same area for echo and minibuffer whenever there's no 
> conflict (no overlap in time), and show echoes in some other place (e.g. 
> pop-up) in the rarer cases when needed.
>

That's exactly what my proposed solution does.  The same area is used when 
there's no conflict, and the "pop-up" uses the space on the left of the 
mode-line, which is temporarily right-shifted.

>
> "Pop up" here could mean temporarily overwriting the mode-line, as 
> Gregory suggested.
>

No, the mode-line is not temporarily overwritten, it is temporarily 
right-shifted.  Usually (when the message is not too long) the leftmost 
part of the mode-line remains visible.

RE: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Drew Adams]

> > The same problem will exist if you move output (`message' echoes) to the
> > mode-line: you won't be able to see the mode-line info and the message
> > at the same time.
> 
> That's obviously a problem that will exist in any possible solution to
> that problem: the message will hide something.  

Not if the area used for echoes (output) is
separate from the area used for the minibuffer
(prompt and input).

Well yes, a previous message in the output area
is overwritten.  But it's logged in *Messages*.
The point here is to separate input and output
areas, so output doesn't hide prompt or input.

> The question is then: what
> is the "something" that can be hidden with the least possible risk?  IMO
> the mode-line is, in this context, the least important element, and it can
> be temporarily right-shifted.  Eldoc does this, too.

I said the same thing regarding importance, if
the candidates are only the mode-line and the
minibuffer.

But there are other possibilities.  (I mentioned
using the last line(s) of some window as one.)

But we need not overwrite - or displace at all,
if we show the output in its own area - at least
when there would otherwise be a conflict with the
minibuffer/echo area.  I mentioned "popping up"
such an output area as needed.

Shifting existing stuff around could be distracting
or annoying for some users.  A dedicated area for
output wouldn't have that problem, but it would
sacrifice real estate when nothing is being output.

Whatever we do, it would be good to let users get
different behavior as an option. 

> > Or we could choose to echo in a separate area only when needed.  E.g.,
> > we might use the same area for echo and minibuffer whenever there's no
> > conflict (no overlap in time), and show echoes in some other place (e.g.
> > pop-up) in the rarer cases when needed.
> 
> That's exactly what my proposed solution does.  The same area is used when
> there's no conflict, and the "pop-up" uses the space on the left of the
> mode-line, which is temporarily right-shifted.

Yes, I know.  And I mentioned that I prefer that
to appending output to the minibuffer input.

But that's one of the half measures.  It still
occludes or displaces something.  If the right
end of the mode-line gets truncated because the
content is right-shifted, then the truncated
part is "lost" (hidden).

There are half measures and full measures for
the general problem.  The use-the mode-line
half-measure is better than the one that's been
put in place for Emacs 27, IMO.

> > "Pop up" here could mean temporarily overwriting
> > the mode-line, as Gregory suggested.
> 
> No, the mode-line is not temporarily overwritten, it is temporarily
> right-shifted.  Usually (when the message is not too long) the leftmost
> part of the mode-line remains visible.

Got it.  (I meant that, but spoke imprecisely.)

IMO we can do still better.  But your suggestion
beats what we have now.  And it beats what we had
before Emacs 27 - at least in terms of not losing
or obscuring user input.

[IMO what we had before Emacs 27 is better than
what we have now, but on n'arrete pas le progres.]

RE: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Gregory Heytings via Emacs development discussions.]

>>> The same problem will exist if you move output (`message' echoes) to 
>>> the mode-line: you won't be able to see the mode-line info and the 
>>> message at the same time.
>>
>> That's obviously a problem that will exist in any possible solution to 
>> that problem: the message will hide something.
>
> Not if the area used for echoes (output) is separate from the area used 
> for the minibuffer (prompt and input).
>

I meant: it will hide something on screen.  For example with a 
conventional pop-up it would hide a part of a buffer.

>
> But we need not overwrite - or displace at all, if we show the output in 
> its own area - at least when there would otherwise be a conflict with 
> the minibuffer/echo area.  I mentioned "popping up" such an output area 
> as needed.
>

Yes, that's the idea of temporariy adding a "zeroth" / "minusoneth" line 
to the miniwindow in which the message would be shown.  But it will still 
hide something, namely another line in that frame.

>
> Shifting existing stuff around could be distracting or annoying for some 
> users.
>

It's what eldoc already does for a similar situation, and I haven't seen 
complaints about this.  IMO it's elegant to solve that problem in that 
way.

BTW, if you don't shift the contents of the mode-line, you shift the 
contents of the buffer(s) above the mode-line.  Which could also be 
distracting or annoying, because such a shift could imply a temporary 
recentering of these buffers in their windows, when point is on their last 
line.

RE: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Gregory Heytings via Emacs development discussions.]

>
> But sure, if Emacs covers your entire display, and if there's nothing 
> that you're willing to obscure (whitespace, menu-bar, tool-bar, frame 
> title, mode-line, buffer text,...) then yeah, something will be 
> obscured.
>

Full-screen Emacs is (I believe) very common nowadays.

>
> The only purely full-measure is to dedicate an area for the output. 
> That has advantages but also the disadvantage of losing real estate for 
> the frequent periods when nothing's being output.
>

So this full-measure is still a half-measure ;-)

>
> More to the point, it's an optional mode.  Those (like me) who don't 
> want it on all the time turn it off, and don't need to complain 
> anywhere.
>

The set-message-function is also optional, you can turn it off easily. 
And in fact with it you could create something like what you want: a 
separate frame with a buffer in which set-message-function would put 
messages.  A first attempt:

(progn
   (select-frame (make-frame '((minibuffer . nil) (name . "Drew's Echo Area"))))
   (set-frame-height nil 1)
   (switch-to-buffer " *Drew's Echo Area")
   (setq-local mode-line-format nil)
   (setq cursor-in-non-selected-windows nil))

(defun set-minibuffer-message (message)
   (with-current-buffer (get-buffer " *Drew's Echo Area") (erase-buffer) (insert message)) t)

Re: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Eli Zaretskii]

> Date: Tue, 13 Oct 2020 20:59:17 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Eli Zaretskii <eliz@gnu.org>, acm@muc.de, juri@linkov.net,
>         monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > Shifting existing stuff around could be distracting or annoying for some 
> > users.
> 
> It's what eldoc already does for a similar situation, and I haven't seen 
> complaints about this.  IMO it's elegant to solve that problem in that 
> way.

Eldoc's purpose is different from the purpose of displaying echo-area
messages.  For example, nothing significantly bad can happen if you
miss the Eldoc's hints, but the same is not true for some important
echo-area messages.

And I think using the mode line for Isearch would be jarring.

Re: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Gregory Heytings via Emacs development discussions.]

>>> Shifting existing stuff around could be distracting or annoying for 
>>> some users.
>>
>> It's what eldoc already does for a similar situation, and I haven't 
>> seen complaints about this.  IMO it's elegant to solve that problem in 
>> that way.
>
> Eldoc's purpose is different from the purpose of displaying echo-area 
> messages.  For example, nothing significantly bad can happen if you miss 
> the Eldoc's hints, but the same is not true for some important echo-area 
> messages.
>

AFAICS you can't miss them with the proposed solution: they are displayed 
on the left of the mode-line, with a different background and foreground. 
The echo-are messages are IMO much more visible there than when they are 
placed at EOB in the minibuffer between brackets.

>
> And I think using the mode line for Isearch would be jarring.
>

Remember that such cases will remain exceptional: they will happen only 
when the minibuffer is active on the current frame.  I've been using this 
for a day now, enabling that exceptional behavior from time to time, and 
don't find it troubling.

Re: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Stefan Monnier]

>> Eldoc's purpose is different from the purpose of displaying echo-area
>> messages.  For example, nothing significantly bad can happen if you miss
>> the Eldoc's hints, but the same is not true for some important
>> echo-area messages.
> AFAICS you can't miss them with the proposed solution: they are displayed on
>  the left of the mode-line, with a different background and foreground.

In my setup, the minibuffer is in its own frame, with no mode-line in
sight.  So indeed I don't get the eldoc hints in `M-:` because they're
placed in a non-displayed mode-line.  E.g.:

    % src/emacs -Q --eval '(setq default-frame-alist (quote ((minibuffer . nil))))'
    M-: (format
    ...wait a little...

...and see that the mode-line doesn't display anything about `format`


        Stefan

Re: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Gregory Heytings via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]


Hi Stefan,

>>> Eldoc's purpose is different from the purpose of displaying echo-area 
>>> messages.  For example, nothing significantly bad can happen if you 
>>> miss the Eldoc's hints, but the same is not true for some important 
>>> echo-area messages.
>>
>> AFAICS you can't miss them with the proposed solution: they are 
>> displayed on the left of the mode-line, with a different background and 
>> foreground.
>
> In my setup, the minibuffer is in its own frame, with no mode-line in 
> sight.  So indeed I don't get the eldoc hints in `M-:` because they're 
> placed in a non-displayed mode-line.  E.g.:
>
>    % src/emacs -Q --eval '(setq default-frame-alist (quote ((minibuffer . nil))))'
>    M-: (format
>    ...wait a little...
>
> ...and see that the mode-line doesn't display anything about `format`
>

I tried your recipe with Emacs 25 to 28, and the modeline _does_ display 
the eldoc info about 'format', so I'm not quite sure what you mean.

Your remark did, however, prompt me to look closer at this case, and to 
improve my "minibuffer-message-in-mode-line" feature a second time.  I 
attach its last version.  Could you perhaps have a look at/try this, and 
give your opinion on it?  It's an attempt to give a more robust solution 
to bug#38457.

[-- Attachment #2: Type: text/plain, Size: 2441 bytes --]

(defvar minibuffer-message-mode-line-string nil)
(defvar minibuffer-message-mode-line-buffer nil)
(defun clear-minibuffer-message ()
  (when (not noninteractive)
    (when (timerp minibuffer-message-timer)
      (cancel-timer minibuffer-message-timer)
      (setq minibuffer-message-timer nil))
    (setq minibuffer-message-mode-line-string nil)
    (when (bufferp minibuffer-message-mode-line-buffer)
      (with-current-buffer minibuffer-message-mode-line-buffer
        (let ((mls (and (listp mode-line-format)
                        (assq 'minibuffer-message-mode-line-string
                              mode-line-format))))
          (if mls (setq mode-line-format (cadr (remq mls mode-line-format))))))
      (setq minibuffer-message-mode-line-buffer nil))))
(defface minibuffer-message-face
  `((t (:background ,(face-attribute 'default :background)
        :foreground ,(face-attribute 'default :foreground)))) "")
(defun set-minibuffer-message (message)
  (when (and (not noninteractive)
             (window-live-p (active-minibuffer-window))
             (or (eq (window-frame) (window-frame (active-minibuffer-window)))
                 (eq (frame-parameter (window-frame (active-minibuffer-window)) 'minibuffer) 'only)))
    (progn
      (when (numberp minibuffer-message-clear-timeout)
        (setq minibuffer-message-timer
              (run-with-timer minibuffer-message-clear-timeout nil
                              #'clear-minibuffer-message)))
      (with-current-buffer
          (window-buffer
           (or (window-in-direction 'above (minibuffer-window))
               (minibuffer-selected-window)
               (get-largest-window)))
        (clear-minibuffer-message)
        (when (and mode-line-format
                   (not (and (listp mode-line-format)
                             (assq 'minibuffer-message-mode-line-string
                                   mode-line-format))))
          (setq minibuffer-message-mode-line-buffer (current-buffer))
          (setq mode-line-format
                (list "" '(minibuffer-message-mode-line-string
                           (" " (:propertize minibuffer-message-mode-line-string
                                             face minibuffer-message-face) " "))
                      mode-line-format)))
        (setq minibuffer-message-mode-line-string message)
        (force-mode-line-update))
      t)))

Re: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Stefan Monnier]

>>    % src/emacs -Q --eval '(setq default-frame-alist (quote ((minibuffer . nil))))'
>>    M-: (format
>>    ...wait a little...
>>
>> ...and see that the mode-line doesn't display anything about `format`
>
> I tried your recipe with Emacs 25 to 28, and the modeline _does_ display the
> eldoc info about 'format', so I'm not quite sure what you mean.

Hmm... it doesn't work in my build of `master`, but indeed it seems to
work with Debian's 26.3.  Not sure what's going on.


        Stefan

RE: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area]

[Drew Adams]

> >> > Would doing something like what eldoc-minibuffer-message does
> >> > possibly be a good solution?  It seems to me that this is safer than the
> >> > current situation, as it does not fiddle with the minibuffer contents.
> >> > If so, what do you (and others) think of the following...
> >>
> >> I personally feel that moving echo-area messages to the mode line is
> >> too drastic a change to make it by default, and certainly in a minor
> >> release.  But let's hear wjat others think, and what other ideas will
> >> be brought up.
> >
> > As I mentioned, the basic problem is due to sharing
> > the same area between minibuffer and echo area.
> >
> > Ultimately, a good solution requires being able to
> > see both at the same time.  Juggling their content
> > wrt time, while sharing the same space, won't take
> > care of the problem in general.
> >
> > The same problem will exist if you move output
> > (`message' echoes) to the mode-line: you won't be
> > able to see the mode-line info and the message at
> > the same time.
> >
> > For simple interactions, there's no problem.  The
> > problem arises for more complex interactions, and
> > for that no "solution" that always uses the same
> > space can possibly be a real solution.
> 
> For me, as a blind braille display user, using the same space in the
> *only* solution that works.  I only have one line of text output.  Which
> area of the screen this line represents is mostly controlled by the
> cursor location.  In essence, my attention can only be focused at one
> place at a time.  Magically showing messages in some other location will
> not work for me at all, I will just miss them.  I am fully aware that I am
> not
> representative for all Emacs users, but your wording seems to indicate
> that you are neglecting the fact that there might be use cases
> which do not work the way you imagine.
> 
> If your suggestion gets implemented, please dont forget to put it
> behind a configuration flag.  It will be the first thing I need to turn
> off in .emacs.

Don't worry; I think there's little chance that what
I suggested will be done.

And to be clear, I am in favor of the behavior we had
before the recent change to automatically sticking
output messages at the end of the minibuffer, instead
of in the echo area.

Minibuffer and echo area are in the same space on the
screen, so both are presumably OK for your use.

But I prefer that messages unrelated to the current
minibuffer interaction (i.e., messages from `message')
be shown in the echo area, and that _only_ messages
related to the minibuffer interaction be appended to
minibuffer input (i.e., as from `minibuffer-message').
Code should be able to use either the echo area or the
end of the minibuffer, to show output when the
minibuffer is active.

My point was only this:

IF people are worried about not noticing some messages
that come out of the blue from somewhere while the
minibuffer is active (because the minibuffer occludes
the echo area), then a proper solution would be to use
a different area for output (messages) than what is
used for input.

The general problem of such unnoticed messages exists.
I'm not particularly bothered by it, personally.  My
point is only that the solution chosen isn't a good
one.  A real solution for dealing with asynchronous
messages calls for separating the two (inputs and
outputs) spatially.

I'm not sure why exactly that would be problematic
for you, as focus does change in Emacs in other ways
anyway.  But I believe you.  And I appreciate your
input on this.  And yes, unfortunately, I hadn't
thought of how blind braille display users would
have to deal with such things.

A real solution needs to take your use cases into
account properly.  Thanks for your input about this.