[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: |
Sun, 22 Nov 2020 18:38:26 +0000 |
Hello, Martin.
On Sun, Nov 22, 2020 at 18:57:30 +0100, martin rudalics wrote:
> > diff --git a/src/minibuf.c b/src/minibuf.c
> > index 464e3018f7..fc3fd92a88 100644
> > --- a/src/minibuf.c
> > +++ b/src/minibuf.c
> > @@ -508,7 +508,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial,
> Lisp_Object prompt,
> > mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
> > if (!EQ (mini_frame, selected_frame))
> > record_unwind_protect (restore_window_configuration,
> > - Fcons (Qt,
> > + Fcons (/* Arrange for the frame later to be
> > + switched back to the calling
> > + frame. */
> > + Qnil,
> > Fcurrent_window_configuration
> (mini_frame)));
> >
> > /* If the minibuffer is on an iconified or invisible frame,
> This one immediately chokes when I run
> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"
> and type C-x 5 2. Here the cursor disappears entirely although when I
> do some typing now the text shows up in the minibuffer window. TRT as
> with Emacs 27 is to select and focus the new frame.
On my machine (XFCE on X-Windows on GNU) I see TRT when I do this. Could
it be something to do with your window manager?
> > There seem to be quite a few things wrong, even on Emacs 27. On
> > starting it with loading your initialisation file from the command
> > line, the initial selected frame is the minibuffer frame, which is
> > surely suboptimal.
> Here the minibuffer-only frame is selected but partially hidden by the
> normal frame so that I don't see no cursor initially. I don't know why
> people like it that way. A minibuffer child frame is explicitly not
> selected.
Do people like it, or is it just not a big enough annoyance for anybody
to complain? If I were a minibuffer-only frame user, I suspect it would
drive me up the wall.
> Note that the way Emacs creates the two frames layout is atrocious - we
> first make a normal frame to do our usual initialization stuff and then
> we create the minibuffer-only and the minibuffer-less frames and delete
> the initial one (compare 'frame-notice-user-settings'). It's for years
> that I want to rewrite that ...
Yes, I can understand that. But you will be aware of all the nasty
little things which will leap out in front of you and force you to solve
along the way.
> > On M-: followed by C-x 5 o (moving to the normal frame),
> > the unfinished command in the minibuffer frame cannot now be cancelled,
> > and C-x 5 o doesn't move back into the minibuffer.
> 'other-frame' never selects a minibuffer-only frame. It probably should.
I'm more of the view that a minibuffer-only frame should never be
selected other than by activating a minibuffer.
> And the behavior of C-g in a separate minibuffer frame IME usually
> varies with the time of the day.
> > Yes, maybe, but modal dialogues are a right pain for the user, as can be
> > seen by using virtually any commericial software on non-free systems.
> Modal dialogues are supported by the windowing subsystem, regardless of
> whether it's free or not.
Yes. I hate these dialogues, which force you to cancel them and start
again, should you need some information from another part of the program
to be able to fill them in.
> martin
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Stop frames stealing eachothers' minibuffers!, (continued)
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/21
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/21
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/21
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/21
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/21
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/22
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2020/11/22
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/22
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2020/11/22
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/22
- Re: Stop frames stealing eachothers' minibuffers!,
Alan Mackenzie <=
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, Andrii Kolomoiets, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/24
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, Andrii Kolomoiets, 2020/11/23
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/24