unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: martin rudalics <rudalics@gmx.at>
Cc: 48674@debbugs.gnu.org, "Iris García" <iris.garcia.desebastian@gmail.com>
Subject: bug#48674: Frames and minibuffer bug
Date: Sat, 29 May 2021 13:10:09 +0000	[thread overview]
Message-ID: <YLI9MbzMCFPwL4GK@ACM> (raw)
In-Reply-To: <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at>

Hello, Martin.

On Sat, May 29, 2021 at 11:20:58 +0200, martin rudalics wrote:
>  > I think the following patch, along the above lines, solves the bug
>  > completely.  Could you review it for me, please?

Thanks for the review.  I withdraw my assertion about a complete
solution to the bug.  :-(

> It fixes the bug and the potential use case I mentioned earlier.  But
> for this part

>    /* If the new frame's selected window is the mini-window, select
>       some other window if we don't have an active minibuffer there.  */
>    if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (f)))
>        && !live_minibuffer_p (XWINDOW (FRAME_SELECTED_WINDOW (f))->contents))
>      Fselect_window (Fframe_first_window (selected_frame), Qnil);

> I would first have to understand why such a minibuffer window should be
> OT1H its frame's selected window and OTOH not be active when switching
> back to that frame.

When the user switches from F1 to F2 with C-x 5 o, and there was an
active minibuffer on F1, that MB gets moved to F2.  The user then
terminnates the MB....then switches back to F1.  There is no longer an
active MB.

> As a user I can always do

> (select-window (minibuffer-window))

> regardless of whether a minibuffer is active.  Switching away from that
> window's frame and back to it is problematic in Emacs 27 - no window has
> the active cursor.  You apparently fixed this by selecting the frame's
> first window when switching back.  Right?

Yes.

> One reason why I ask is because with emacs -Q and the present patch

> (setq default-frame-alist '((minibuffer . nil)))

> followed by C-x 5 2 and

> (select-window (minibuffer-window))

> in the new frame violates the assertion on line 548 of window.c

>        /* Fselect_frame called us back so we've done all the work already.  */
>        eassert (EQ (window, selected_window));

> with the backtrace below.

Just as a quick aside, how do I configure Emacs so as to generate these
easserts?  At the moment I've got CFLAGS='-O0 -g3' and --enable-checking
in my ./configure command line.  I think I'm missing something.

> Basically, I would try to avoid that a non-selected frame's selected
> window is an inactive minibuffer window.  But I'm not sure how difficult
> it is to achieve that.

That's the way it currently is (without the patch).  It is difficult to
make it work properly.

Maybe the best workaround would be to create a new flag in struct frame,
which when set means "select mini-window if "possible" when selecting
this frame".  "Possible" meaning there's an active MB.
(i) This flag would be set, somehow, by with-selected-frame when moving
away from F1.  
(ii) do_switch_frame would test this flag, act on it, and clear it.
f->flag would always be clear when f is the selected frame.

With this, F1's selected window would be moved away from the mini-window
and the flag set, when F2 gets selected.  Or something like that.

What do you think?

> martin

[ Backtrace snipped, but understood. ]

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2021-05-29 13:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26 11:23 bug#48674: Frames and minibuffer bug Iris García
2021-05-26 17:45 ` martin rudalics
2021-05-27 10:34   ` Alan Mackenzie
2021-05-27 16:33     ` martin rudalics
2021-05-27 19:56       ` Iris García
2021-05-28  8:25         ` martin rudalics
2021-05-28  9:34           ` Iris García
2021-05-28  9:51             ` martin rudalics
2021-05-31 16:36         ` Alan Mackenzie
2021-06-01 11:29           ` Iris García
2021-05-27 20:01       ` Alan Mackenzie
2021-05-28  8:26         ` martin rudalics
2021-05-28 17:15           ` Alan Mackenzie
2021-05-28 20:14             ` Alan Mackenzie
2021-05-29  9:20               ` martin rudalics
2021-05-29 13:10                 ` Alan Mackenzie [this message]
2021-05-29 15:12                   ` martin rudalics
2021-05-29 15:24                     ` Eli Zaretskii
2021-05-29 17:00                     ` Alan Mackenzie
2021-05-30 13:58                       ` Alan Mackenzie
2021-05-31  7:55                         ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YLI9MbzMCFPwL4GK@ACM \
    --to=acm@muc.de \
    --cc=48674@debbugs.gnu.org \
    --cc=iris.garcia.desebastian@gmail.com \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).