Re: GNU Emacs raison d'etre

[martin rudalics]

>>  > 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'?

>>  > 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.

>> It's not as simple as that.  Users who want to use that mode have to
>> make themselves familiar with child frames and minibuffer-only frames
>> first.
>
> Please, no.
>
> You know the reason why we only fixed child frames under GNOME now? Or why 
packages using child frames only started to become popular?
>
> 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.

Sometimes I'm not sure whether child frames are used only because they
are there.  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.

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.

>> 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 and transfer the text you want to show there to it.

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).

>> 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.

> 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.  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.

>> 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.

>>  > - 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 ...

> 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.

> 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.

>>  > 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 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.

> 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.

>> 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.

martin