Re: GNU Emacs raison d'etre

[martin rudalics]

>> Right.  In a "normal" session you have to create a minibuffer-only frame
>> first and then delete the normal frame to get uniform behavior.  Emacs
>> does not offer a function to remove the minibuffer window from a normal
>> frame so this is the best you can get.
>
> Any chance to change the latter in Emacs 28? Is that difficult?

It's hairy and that's why people never tried to change the ritual of
setting up an initial frame with a minibuffer window.  Likely to make
sure that if things go wrong anywhere, there's always at least one
minibuffer window you can act upon or that displays vital information
about what went wrong during setup.

Note that producing the minibuffer-less + minibuffer-only setup is
accomplished by 'frame-notice-user-settings' which deletes the initial
minibuffer-equipped frame in a hair-raising fashion in order to make
sure that at least one minibuffer window is available at any time.

> It would improve the starting experience quite a bit.

The startup experience of general minibuffer-only frame setups or that
of the setup with a minibuffer-only child frame?  I think these are today
also affected by other parameters like, for example, whether you put
these specifications into an early init file or the normal one.

> The main remaining annoyance is the blink when the child frame is 
resized/repositioned.

You would have to tell me more about that blink.  If it's due to the
setting of 'x-gtk-resize-child-frames', there's nothing I can do about
it.  If it's due to the delay implied by 'pop-up-mini-hide-if-empty',
try to experiment with that.

> So how do you feel about a package in GNU ELPA?

Not really enthusiastic.  The historical constraints of how to set up
and use the minibuffer window are too restrictive IMHO so what you see
here is just a workaround.  Maybe things will change in a couple of
years.

> If we can move the settings into the definition of pop-up-mini-mode,
> it should be quite usable. And also do something with the scenario
> where someone installs it, turns on the mode, and simply stares at the
> error.

What's so bad about that error?  It simply tells what is missing.  If
you provide such a frame, things should work, even in parallel with the
already existing minibuffer window.

martin