emacs-devel
[Top][All Lists]
Advanced

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

Re: Stop frames stealing eachothers' minibuffers!


From: Alan Mackenzie
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Tue, 5 Jan 2021 18:07:18 +0000

Hello, Martin and everybody else.

On Mon, Jan 04, 2021 at 10:20:11 +0100, martin rudalics wrote:

[ .... ]

>  > 3/- From Gregory: Start emacs -Q, and set enable-recursive-minibuffers
>  > to t.   Do C-x C-f  C-x 5 o twice, then C-x C-f a third time.  It was
>  > possible to enter filenames for and visit files for the innermost two
>  > minibuffers, but not the outermost one.  This has (I believe) been
>  > fixed.

> I'm not sure what's missing here, probably a C-x 5 2 to get the frame
> C-x 5 o can act upon.  So I let Gregory tell whether this has been
> fixed.  What I see is that with 'enable-recursive-minibuffers' t C-x 5 2
> followed by two C-x C-f C-x 5 o

> - doesn't get me _always_ into the minibuffer window of the frame
>    switched to (I'm not sure whether it should and under which
>    circumstances - this should be clarified),

I don't think it should, in general, unless the miniwindow is (still) the
frame's current window.

I've found out why, in Gregory's scenario, after the "middle" RET to
visit a file, point was not moving back to the "middle frame": it's
because select_frame is insufficient of itself to move X-Window's focus,
which stays in the "old" frame.  Any command now causes a "switch-frame"
event which moves the minibuffers back into the "old" frame, which isn't
what we want.  The solution (a bit ugly) is to call the lisp function
select-frame-set-input-focus rather than just do_switch_frame near the
end of read_minibuf.

> and

> - typing C-g to quit an inner invocation of C-x C-f sometimes gets me a
>    catatonic minibuffer window where either nothing is displayed or just
>    a simple "Quit" appears - I have to get out of it via C-x o.

Yes.  I still have some work to do in this area.

>  > 4/- With minibuffer-follows-selected-frame nil, and
>  > enable-recursive-minibuffers t, there were problems caused by editing
>  > outer level minibuffers whilst an inner level buffer was still active.
>  > I've tried to fix this by giving outer level MBs the keymap
>  > minibuffer-inactive-mode-map temporariliy whilst a recursive MB is
>  > active.

> How do I edit an outer level minibuffer whilst an inner level buffer is
> active?

At the moment, you can't.  This isn't good.  What do you think of the
following solution?

Instead of setting outer minibuffers' maps temporarily to
minibuffer-inactive-mode-map, I could amend exit-minibuffer so that it
would throw an error when there was a more nested active minibuffer, but
leave the current minibuffers untouched.  Also, C-g should then abort the
current minibuffer's caller, together with those of any more nested MBs.

[ .... ]

The change in the current version of the patch (attached) is that, as
already mentioned, select-frame-set-input-focus is called rather than
just do_select_frame from near the end of read_minibuf.  Also, that call
has been moved from just after the recursive edit to the very end of
read_minibuf.  Also, move_minibuffer_onto_frame now moves the entire
stack of minibuffers, not just the current one (it is not called when
minibuffers-follows-selected-frame is nil).

How would you feel about committing this patch?  It is an improvement
over the current state, even though not yet finished.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Attachment: diff.20210105.diff
Description: Text document


reply via email to

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