RE: [External] : Re: Emphasizing the top of the frame

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

> Right.  But IIUC your minibuffer frame also hides the menubar and, when
> it grows (downwards), will hide other parts on top of the Emacs frame
> too.  And didn't you claim initially that hiding is a feasible
> strategy, something on which I agree because I do it myself.

FWIW, I prefer what Epoch did back in the 90s,
which is to have a monitor-wide separate
minibuffer frame.  I use that approach, and I'm
able to resize other frames (automatically or
on demand) to not overlap that piece of monitor
real estate.  I can always clearly see the
single  minibuffer/echo area, and it's always
in the same place.  

Frames can overlap, in general, and that can be
advantageous.  It can also be useful to prevent
or avoid overlapping, and that's what I do for
my standalone minibuffer (and echo area) frame.

I put that frame at the bottom of the monitor
(automatically, based on monitor size etc.).
But it can also be placed at the top.  And it
can be allowed to move, etc. to be positioned
near the cursor (in which case it overlaps
another frame or more).

It can also automatically (or on demand) grow
& shrink in height - or not.  That's important
for me because it's not too unusual for me to
have multiline minibuffer input.

>  > It is interesting that you mention that your separate
>  > minibuffer frame "rarely has let [you] down".  From
>  > that I conclude that you too know that the separate
>  > minibuffer experience is not as polished as that with
>  > a traditional minibuffer.

Emacs generally has limited support for using
frames, compared to windows.  Partly because
frames are ultimately under the control of a
window manager.  And partly (IMO) because of a
relative lack of experience/interest/attention
wrt frames on the part of Emacs developers and
most users.

> It is occasionally problematic when switching focus between two or more
> normal frames and a minibuffer interaction is going on and when trying
> to quit the minibuffer.

Yes, and changes in Emacs development can make
this worse across releases.  Getting things to
work properly is then frustrated by breakage
in a future release.

And this is exacerbated by the problem cited
above: new features, bug fixes, and other
changes can get implemented with little/no
attention to the effects on focus for frames.

And debugging the effects of such changes is
not easy.  And if changes are made in C code
then things become even harder.
___

All of what I've written here is just "FWIW",
i.e., for info.  It's general, abstract.  I
don't expect that it helps operationally, wrt
making things better.  Maybe it will somehow
help in the long run, if some more attention
is drawn to using frames, towards becoming
more on a par with using windows.