unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
Cc: larsi@gnus.org, Jean Louis <bugs@gnu.support>, 45072@debbugs.gnu.org
Subject: bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing
Date: Thu, 10 Dec 2020 10:32:54 +0200	[thread overview]
Message-ID: <87wnxqxdx5.fsf@mail.linkov.net> (raw)
In-Reply-To: <57c673d0-e6e7-120d-8893-92b02ab1530e@gmx.at> (martin rudalics's message of "Thu, 10 Dec 2020 08:44:57 +0100")

> We'd have to augment the 'quit-restore' mechanism somehow and run it on
> all windows instead of restoring the configuration.
>
> But I still don't understand the logic of the following:
>
> (1) Start minibuffer interaction, type a-
>
> (2) Pop up a completion window for a- and accept suggestion a-b

What do you type to accept a suggestion?  I can't find a key
to accept a suggestion without exiting the minibuffer.

> (3) Type another - so you now get a-b-
>
> (4) Pop up a completion window for a-b- and accept a-b-c
>
> In this scenario I'd want, after accepting a-b, the completion window to
> disappear (or show its old buffer again) without the minibuffer action
> having terminated.  So I'm still convinced that restoring a previous
> state should be triggered by the completion mechanism and not by the
> read from minibuffer mechanism.

Then maybe the commands that pop up the completions window
should clean up their windows after use.  What would be the
right place to remove used windows?  Maybe in exit-minibuffer?
Or in some unwind-protect in case the user types C-g?

> One thing that has to be considered too is user interaction during
> completion: Suppose I have one window, the completion mechanism pops up
> a new one and I delete the old one.  Terminating completion now cannot
> delete the new window (especially if it's on the only frame in use) but
> has to show another buffer in the new window.  It maybe should try to
> show the one previously shown in the old window.

This means that quit-window should be used on the completions window.
It should do the right thing: either restore a previous buffer in that window,
or close the window if no more buffers were displayed in it.

> And let's not forget that the completion mechanism might pop up a new
> frame or a window on any other frame.  In such case, restoring window
> configurations won't help at all.

That's fine, I create a new tab when the minibuffer is active,
to preserve new windows created during the active minibuffer.
For more convenience, now I installed a patch that allows creating
a new tab even from the minibuffer.





  parent reply	other threads:[~2020-12-10  8:32 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-06 14:07 bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing Jean Louis
2020-12-07 16:10 ` Lars Ingebrigtsen
2020-12-07 16:42   ` Jean Louis
2020-12-07 17:20     ` Eli Zaretskii
2020-12-07 18:49       ` Jean Louis
2020-12-07 19:27         ` Eli Zaretskii
2020-12-07 19:45           ` Jean Louis
2020-12-08  8:09           ` martin rudalics
2020-12-08 14:09             ` Lars Ingebrigtsen
2020-12-08 14:18               ` Jean Louis
2020-12-08 14:47               ` martin rudalics
2020-12-08 14:58                 ` Jean Louis
2020-12-08 16:08                   ` Eli Zaretskii
2020-12-08 16:14                     ` Jean Louis
2020-12-08 15:51               ` Eli Zaretskii
2020-12-09  9:33                 ` martin rudalics
2021-08-03  7:57                   ` Juri Linkov
2021-08-04  6:52                     ` Lars Ingebrigtsen
2021-08-04  8:39                       ` Juri Linkov
2021-08-04  8:56                         ` Lars Ingebrigtsen
2021-08-04 20:17                           ` Juri Linkov
2021-08-05 10:55                             ` Lars Ingebrigtsen
2021-08-05 23:36                               ` Juri Linkov
2020-12-08 19:15             ` Juri Linkov
2020-12-09  9:34               ` martin rudalics
2020-12-09 10:06                 ` Jean Louis
2020-12-09 15:16                   ` martin rudalics
2020-12-09 19:11                 ` Juri Linkov
2020-12-10  7:44                   ` martin rudalics
2020-12-10  8:30                     ` Jean Louis
2020-12-10  9:46                       ` martin rudalics
2020-12-10 10:16                         ` Jean Louis
2020-12-10 11:52                           ` martin rudalics
2020-12-10 12:07                             ` Jean Louis
2020-12-11  9:39                               ` Juri Linkov
2020-12-12  1:47                                 ` Jean Louis
2020-12-10  8:32                     ` Juri Linkov [this message]
2020-12-10  9:47                       ` martin rudalics
2020-12-10 10:21                         ` Jean Louis
2020-12-10 11:52                           ` martin rudalics
2020-12-10 12:21                             ` Jean Louis
2020-12-12 20:49                         ` Juri Linkov
2020-12-13  7:26                           ` martin rudalics
2020-12-14 20:28                             ` Juri Linkov
2020-12-15  7:59                               ` martin rudalics
2021-01-15  8:57                               ` Juri Linkov
2021-04-19 13:54                                 ` Stefan Monnier
2021-04-19 16:02                                   ` martin rudalics
2021-04-19 18:09                                     ` Juri Linkov
2021-04-19 13:52                               ` Stefan Monnier
2021-04-19 16:02                                 ` martin rudalics
2021-04-19 16:22                                   ` Stefan Monnier
2021-04-19 17:11                                     ` martin rudalics
2020-12-08  5:33       ` Richard Stallman
2020-12-08 15:13         ` Eli Zaretskii

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=87wnxqxdx5.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=45072@debbugs.gnu.org \
    --cc=bugs@gnu.support \
    --cc=larsi@gnus.org \
    --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).