Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 22.05.2020 12:31, martin rudalics wrote:
>  >>  > I've also noticed that initial blink during startup,
>
> I forgot to ask what "startup" means here.  Invoking 'pop-up-mini-mode'
> itself or starting a dialogue as with 'ido-mode'?

Neither. Emacs startup, and the blink that comes with re-creating the 
frame. I just meant that I was going to talk about this at some later 
point, but now I didn't have to.

>  >>  > but didn't know
>  >>  > what to attribute it to. Would be great to be able to avoid it.
>  >>
>  >> Is this a blink that happens also when you do
>  >>
>  >> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
>  >>
>  >> or does it require the presence of a child frame?
>  >
>  > I couldn't manage to reproduce the bug there. Even with
>  >>  > resize-mini-frames=t. But then, it doesn't resize as responsively 
> as your code.
>
> Why not?  The resizing step is quite the same.

One difference I noticed is that the child frame created by 
pop-up-mini-mode is constant width, but the mini-frame created by the 
above recipe updates its width dynamically as well. And always feels 
kinda cramped.

In any case, it really seems like the blink is due to how updating the 
size of the popup works: first, the buffer is updated (and redrawn), 
then the timer resizes the popup, and the buffer is redrawn again. Not 
sure what the better implementation is going to do, though.

>  > This is arcane stuff, and it took someone really motivated to turn 
> the child frames support you created into a library every Emacs 
> developer can use. There are a few other authors who understand it, but 
> we can't expect the average user to know these details.
>
> This is not about understanding the details.  If you want to use a mode
> that is based on child frames and minibuffer-only frames, you first have
> to know what kind of advantages these offer.  And both, package
> developers and users, should be aware of the basic glitches that are to
> be expected in this area.

That could be described in the README, I suppose. And it's one thing to 
grasp the benefits/drawbacks, and another thing to know in advance how 
to set up a minibuffer-only frame for your own setup.

> Sometimes I'm not sure whether child frames are used only because they
> are there.

Well, why else? It's the only real way we have to implement "popup" 
windows. Too bad they don't work in the terminal.

> Basically, child frames make sense only if any changes the
> window manager applies to the parent frame (like deletion, iconifying,
> changes of visibility, size or position including the z-order) should
> automatically (without Emacs intervention) apply to the child frame too.
> I added child frame support mainly because the handling of the signals
> that come with any of these changes can be cumbersome and occasionally
> even daunting.

Makes sense.

> Things a package could handle with a normal frame or a tooltip frame
> should probably be done without child frames because, for example,
> reparenting a child frame and fitting its size and position to the new
> frame can be tricky.

Not sure how it's relevant to the package under discussion. The 
minibuffer frame I've tried with that default-frame-alist setup didn't 
really provide a good UI, looks or behavior-wise.

>  >> And even after that there may be glitches, especially when
>  >> working with multiple frames.  For example, transferring focus from one
>  >> frame to another, while a minibuffer interaction is in progress, is a
>  >> hairy operation regardless of whether you use the standard setup, a
>  >> top-level minibuffer(-only) frame or a minibuffer child frame.
>  >
>  > Is there a problem in creating a minibuffer child frame for every frame?
>
> I had that in an initial version but it's unlikely that I can still find
> the code.  By design, you can create and use an arbitrary number of
> minibuffer frames.  The only problem is to find the right frame you want
> to use ...

Via... a frame parameter? OK, I'm probably not going to be very helpful 
here, at this level of discussion detail. If there are specific hard 
problems with repro senarios, I could try to take a look later, but I'm 
only interested in going in this direction if our goal is to make a 
package for a broad audience.

Anyway, having glitches could be fine if they are outside of the main 
usage scenarios and/or well-understood and documented.

> Note also that IIRC the text you see in a minibuffer window is sometimes
> only available there and bears no relationship to any text stored in any
> buffer (or at least the buffer whose contents the minibuffer window is
> supposed to display).  The display engine automagically handles the
> display and sometimes cancels the traces of the source it used (Eli will
> correct me if I'm wrong).

That's um, sounds like space for improvement.

>  >> I would have to guess the user's intention here.  'pop-up-mini-mode'
>  >> does not forbid a mixed mode where one frame uses its own minibuffer
>  >> window for interaction and other frames want to use the more "global"
>  >> minibuffer-only window 'pop-up-mini-mode' found when it started.
>  >
>  > We don't have to support every possible intention, just the most 
> likely one. The rest can be left for future development, or available as 
> a customization option.
>
> Agreed.  And that's why users have to put the necessary customizations
> in their init files and not simply call 'pop-up-mini-mode' from a
> running session.  Although the latter might be a seductive way to test
> it.

Are you sure this customization couldn't be applied by pop-up-mini-mode? 
Alternatively, it could be a setup function.

>  > BTW, when you delete the initial frame at startup, is there a
>  > possibility to make in invisible at the start, so that it's actually
>  > never displayed, and when it's deleted, that blink doesn't happen?
>
> You mean when Emacs starts in minibuffer-only mode, I presume.  It
> should be possible but the following part
>
>          ;; If the frame isn't visible yet, wait till it is.
>          ;; If the user has to position the window,
>          ;; Emacs doesn't know its real position until
>          ;; the frame is seen to be visible.
>          (while (not (cdr (assq 'visibility
>                     (frame-parameters frame-initial-frame))))
>            (sleep-for 1))
>
> inhibits it currently.  The problem perceived here is that one cannot
> derive the actual coordinates of a frame _before_ that frame was mapped
> by the WM and mapping always means to make it visible.

What about full transparency, then?

> OTOH the actual
> coordinates of the minibuffer-equipped frame are needed to make the
> minibuffer-only frame appear at the same position and with the
> requested, properly modified size, taking the user customizations into
> account.

The minibuffer-only frame which is immediately hidden itself while 
pop-up-mini-mode is active?

>  >> Also
>  >> note that we have various strategies to assign the minibuffer window
>  >> ('set-minibuffer-window', the 'minibuffer' frame parameter) so all this
>  >> is more convoluted than it appears at first sight.
>  >
>  > These are implementation options, right? Just pick the most appropriate.
>
> These are user options a user can change any time in a running session.

Perhaps we can say that they shouldn't.

>  >>  > - pop-up-mini-mode is enabled in the user's init script. Is that 
> worse
>  >>  > than early init? We could try to document the early init as the best
>  >>  > option.
>  >>
>  >> It's not a good option if it fails for some reason.  On a TTY, say.
>  >
>  > So pop-up-mini-mode would check if it's running on a terminal, and if 
> so, abort with a message.
>
> But you don't like such aborts ...

I don't like abort which presume a lot of prior knowledge and/or manual 
setup.

"Sorry, pop-up-mini-mode is not supported in a terminal" sounds just 
fine to me. There's nothing else to do anyway.

>  > A full reinstall of a distro and/or switch to another one is out of 
> the question, I take it?
>  >
>  > I'm not sure it's a GNOME issue. It doesn't update itself: package 
> managers do it.
>
> Maybe it's a also just a GNOME on Debian (unstable) issue.  Installing
> GNOME shell here as additional desktop forced me to install all sorts of
> additional software amounting in sum to around one GB of code.  This
> included games and horrific applications like tracker which I had a hard
> time to switch off.  I'll eventually try to remove and reinstall it but
> it's nothing for the faint at heart.

There's also the option to use a virtual machine. Provided the 
"physical" machine is fast enough.

>  > With Mutter only, or with GTK3 toolkit build only? I can make a build
>  > using a different toolkit, at least.
>
> Try both, if you can.

With Lucid, the blink is the same.

>  >>  > Another issue: when the child frame covers the scroll bar, it 
> renders some junk on it.
>  >>
>  >> The horizontal scroll bar?  That's where it is here all the time.
>  >
>  > The vertical one. The child frame spans the whole width of the frame, 
> and its right end overlaps the parent frame's scroll bar.
>
> I faintly recall to have seen this with GNOME shell.  Which means you
> have to put it on the mode line or the horizontal scroll bar there.  Do
> other child frames too have problems when covering the scroll bar?  What
> happens with the scroll bar at the right?  What happens when the
> minibuffer window has a scroll bar itself?

I have just tried company-posframe, which renders its popup through the 
posframe package, and could find such artifacts, even when the popup 
overlapped the right scroll bar.

The minibuffer child frame from pop-up-mini-mode seemed to show glitches 
like that when it was resized, to accommodate multiple lines.

>  > I agree it's a problem, just don't see how it is a problem for this 
> particular endeavor.
>
> Because "this particular endeavor" would then only serve to cover an
> underlying, deeper-rooted problem and possibly postpone fixing that.

I wonder if anyone would be working on it at all, if we weren't talking 
about it here.

>  > Sounds like we're talking about low-level code only, right? Like 
> prin1. I suspect there's a limited number of functions like that.
>
> High-level code - for example, code that wants to know the width of the
> minibuffer window before putting things there.

OK. I've seen problems of this sort.

>  >> It would be interesting to see a list of requirements for a practical
>  >> solution to this problem.
>  >
>  > Behavior-wise, I think we're fairly close already, but "the user has 
> to get familiar with both, minibuffer windows and child frames, first" 
> sounds like a deal-breaker.
>
> I'd still like to see a list of what people really would like to see wrt
> positioning and resizing the minibuffer window first.

Does the list at the bottom here look useful? 
https://github.com/honmaple/emacs-maple-minibuffer/#maple-minibufferpostion-type 


If we had something like that, as well as automatic resizing of the 
minibuffer popup without blinking, that would be great. Especially if 
the result worked fine with packages such as icomplete-vertical-mode.