help-gnu-emacs
[Top][All Lists]
Advanced

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

RE: [External] : Re: Is there a way to avoid clobbering minibuffer by me


From: Drew Adams
Subject: RE: [External] : Re: Is there a way to avoid clobbering minibuffer by messages?
Date: Thu, 30 Mar 2023 16:28:16 +0000

> > If that is what you see, then it's the intended behavior.  That you are
> > not used to it doesn't mean it's incorrect or broken. Functionally, it
> > does the job, and we don't have any better alternatives for the case
> > when a message should be shown when the minibuffer is active.
> 
> It's true that we don't have any better _built-in_ alternatives, but I
> think what the OP wants is something like the code in the attached file.

FWIW, maybe it's time to add an _option_ to separate
the echo-area real estate from that of the minibuffer.

E.g., optionally use separate windows (or standalone
frames) for them.

____

Personally, I'm not a fan of the change introduced
in Emacs 28 (with no way to opt-out, IIUC).

IIUC, the problem it tries to fix (work around) is
the display of msgs that arrive during minibuffer
input (in particular from async processes).  Yes,
that's a real problem (which we've lived with for
decades).

The Emacs 28 "solution" substitutes (1) showing
the output (a message in [...] brackets) in the
minibuffer (an input area), at the _same time_ as
showing the input there, for (2) the longstanding
behavior of temporarily overwriting that shared
screen area, that is, momentarily showing the echo
area _instead of_ the minibuffer.

Arguably, at least for some users (I'm one), the
Emacs 28+ cure is worse than the traditional
disease.  It's not that I think the cure shouldn't
be available; I just think it should be optional -
one possible choice.

A better solution would be to let users choose to
substitute having ~persistently separate display
spaces for input and output.

That is, instead of both (1) the pre-28 behavior
of temporarily swapping what's shown in that
screen space shared between the minibuffer (for
input) and the echo area (for output), and (2)
the 28+ behavior of showing both input & output
in the same space at the same time.

IOW, _no space sharing_: be able to cut the cord
and separate the input and output screen spaces.

Further options could be added for _how_ to show
the output (messages): whether to dedicate a
window or just pop up a window, etc.

But the main thing would be to offer a choice to
just stop sharing screen real estate between
minibuffer (input) and echo area (output).

Why not let users choose among several behaviors?

 1. Emacs 28+ approach: message and input in
    minibuffer at the same time.

 2. Traditional approach: echo area displayed
    temporarily, in place of the minibuffer.

 3. Minibuffer and echo area shown separately,
    in different places?

And offer various choices for #3: how to show
the echo area.



reply via email to

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