[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Emacs raison d'etre

From: Dmitry Gutov
Subject: Re: GNU Emacs raison d'etre
Date: Wed, 20 May 2020 04:01:49 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 19.05.2020 11:41, martin rudalics wrote:
 > I finally understood what I was doing wrong: I tried to visit the file
 > and 'M-x eval-buffer' from an existing graphical frame. That got me
 > the error.

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 would improve the starting experience quite a bit.

 > If I load it from init.el, the result is fairly functional (though
 > with a number of glitches),

Since I use it with my customizations only, such glitches are to be
expected.  And, as you know, mutter is not very child-frame friendly.

Thanks for the reminder: with the appropriate value of x-gtk-resize-child-frames, the behavior looks more sensible now.

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

 > and it really does look like an
 > improvement over the current situation. Even if the main benefit is
 > simply locality: it displays the "minibuffer" at the bottom of the
 > current window, not frame.

You can put it anywhere on the parent frame via 'pop-up-mini-host'
and/or 'pop-up-mini-position'.  If something is lacking here, it can be
added easily.

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]