RE: GNU Emacs raison d'etre

[Drew Adams]

> macos users don't expect a floating kind of system "minibuffer".
> That's actually unlike the rest of macos UI. But it happens to exist
> (that's "Spotlight" in case you want to know and it is an *extremely*
> limited "minibuffer", by emacs standards.)
> 
> I was just mentioning that vs Drew's "in emacs the mini buffer *can* be
> in a frame". Because *that* requires a lot of manually installing
> packages that he refers to here:
> 
> https://www.emacswiki.org/emacs/OneOnOneEmacs
> 
> Which seems to be very nice, by the way.

I wouldn't say it "requires" all that I try
to do.

I'm sure it's possible to at least have (only)
a standalone minibuffer frame, without all of
what my code tries to do.

E.g., customize `initial-frame-alist' (and
`default-frame-alist' probably), to have a
nil `minibuffer' parameter, and create a
minibuffer frame, will get you partway there.

That wiki page you link to describes problems
I ran into when trying to get reasonable
behavior for a standalone minibuffer frame.
In particular, there can be problems of input
focus not being systematically what one might
expect.

But I think Stefan also uses a standalone
minibuffer frame, and probably he does something
simpler and perhaps better in some ways.  I've
never seen any code for his setup, but he might
have something useful to say about Emacs
offering such a thing as an option.  (Or not.)