RE: GNU Emacs raison d'etre

[Drew Adams <drew.adams@oracle.com>]

> > I agree that the prompts could be positioned better,
> > and the result could be better readability. After all,
> > if one uses the minibuffer a lot, isn't it a shame
> > that it resides somewhere down below, and uses
> > the same font as the rest of Emacs?
> 
> I personally think it's a very good idea.
> In combination with that, simple changes like
> giving it a border or a different background, 
              ^^^^^^                ^^^^^^^^^^
> would also help make it more visible.

FWIW, I use a separate minibuffer frame, which extends
across the bottom of the screen (by default - size &
position configurable).

I took this idea from Epoch back in the mid-90s.  The
fact that Emacs doesn't provide this as an option out
of the box, I've always thought is too bad.  (Epoch
had other UI innovations, but that's the one I missed
most when I went back to GNU Emacs.)

As a separate frame, `minibuffer-frame-alist' applies,
which includes its own default font (size, color) and
background color.  And as a frame, it has a border.
(By default, the text is larger, and red.)

Wrt positioning, one option is for moving the frame
so it's positioned near point whenever the minibuffer
is activated:

 1on1-move-minibuffer-frame-near-point is a variable
 defined in `oneonone.el'.  Its value is nil

 Documentation:
 Whether to move `1on1-minibuffer-frame' near point, and just where.

 * nil means do not move it.  

 * A single whole number, Y, means offset `top' by Y pixels from point.
   The `left' frame position is unchanged.  As always, positive is
   down (below point), negative is up (above point).

 * A cons of two whole numbers, (X . Y), means offset `left' by X and
   `top' by Y pixels from point.

   For example, (-200 . 30) moves the top left frame corner 200 pixels
   to the left and 30 pixels below point.  This option has no effect if
   `1on1-minibuffer-frame' is nil.

Personally, I prefer the default behavior, of remaining
at the bottom of the screen.  In particular, that way
it doesn't interfere with any Emacs content, anywhere.

> One frequent annoyance for me in more "modern" software
> is that the popups hide the thing they are about.

Exactly - see previous paragraph.  But I can understand
that, at least for some simple interactions, some users
like it.

That's also a problem in general for any popup frame,
whether for completions, info/help, whatever.  Some
DWIM can be applied, but the problem is inherent: how
to know just what is the most noticeable and near the
previous focus of attention, and simultaneously avoids
obscuring the info the user currently cares about.

Beyond letting users configure such behavior to some
extent, and giving some programmed positioning a bit
of "intelligence", giving users quick, keyboard, ways
to move frames around on the fly can help.

> so maybe the top positioning is a better default than
> in the center.

Top positioning has either the same problem as near
point (your annoyance: obscuring info) or the same
problem as bottom-positioning.

With my setup, other frames can be automatically
resized to fit their content, by default, in which
case they never overlap the minibuffer frame when it
stays put (e.g. at screen bottom).  (Auto-fitting of
frames can take a stay-put standalone minibuffer
frame into account, in effect reducing the available
screen space to exclude it.)

The problem with a minibuffer that stays put is that
it can be far from where your eye might currently be
focused.  That's more of a problem for the echo area
than the minibuffer, perhaps, because for the latter
you're anyway expecting to change your attention to it.

For a newbie, I think that having a separate frame,
with larger and more noticeable text takes care of
the problem of not being aware of the minibuffer or
echo-area messages - not knowing where to look or
what's expected of you.

In addition, with my setup the minibuffer frame
background changes hue slightly (configurable) when
it's active (and for each recursive minibuffer), and
also when Isearch is active.  That too helps draw
attention to it, and lets you know the interaction
status/expectation.

https://www.emacswiki.org/emacs/Dedicated_Minibuffer_Frame

Finally, although recursive editing is disabled by
default, to protect the innocent, I think it's
underappreciated as a feature. The main problem with
it is, once again, not being aware that you're in a
recursive edit - which interaction level you're on.
To help with that I have library `rec-edit.el'.  It
highlights the mode-line [[...]] indication, to make
it clear when you're in a recursive edit, and what
level it is.

https://www.emacswiki.org/emacs/RecursiveEdit#rec-edit.el