RE: GNU Emacs raison d'etre

[Drew Adams]

> FWIW, to get started, you just need:
>     emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
> 
> But this indeed just begs the question of how to *manage* that
> minibuffer-only frame (i.e. make it so that it's easily accessible when
> the user needs it but it doesn't constantly get in the way the rest of
> the time).

And it always has input focus when you expect/want
it to, and only then, regardless of what interactions
might be going on.

> I don't know of any package/theme/thingy that provides a good solution
> to that yet.  I think such a thing could be very useful&popular, so I'd
> encourage you (or whoever else) to take a stab at it.

+1.

I do think I have a good solution - I've been
using it for decades.  But it's not a perfect
solution.

It's essentially a code-coordinated set of
settings that might be considered more or less
workarounds to the facts that (1) Emacs is not
very friendly to frames (frame-oriented), and
(2) Emacs doesn't ultimately control frame
management/behavior - a window manager does.

Wrt #1, I've long thought that this is because
most Emacs developers (and users) don't try to
use it - Catch-22.  Wrt #2, that's something
to live with, and Emacs generally tries to
work well regardless of window manager.