[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if
From: |
martin rudalics |
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:47:21 +0100 |
> What do you type to accept a suggestion? I can't find a key
> to accept a suggestion without exiting the minibuffer.
When I type here
C-h f set- RET
I get a completions window with the "set-" prefixed completions. When I
now type
auto RET
the completions window pops down and the minibuffer window shows
set-auto-
When I now type another RET, the completions window pops up again and
shows the "set-auto-" prefixed completions with the minibuffer showing
set-auto-
When I now type an "m" I get a help window showing me help for
'set-auto-mode'.
So here the pop down works already and I have no idea why it cannot be
extended to the entire completion 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?
The completion mechanism should clean up its traces as soon as it is
finished - either a choice has been made or it has been aborted: This
can mean to clean up windows or frames, size back a minibuffer window or
remove a pop up menu or a dialogue box. But I hardly ever use that
mechanism so I cannot tell how it works (or should work) in practice.
In either case 'exit-minibuffer' is too late. It must be either the
caller of completions - just in case it wants to, for example, reuse the
present window for refining the list of completions - or the called
which might be more noisy with windows popping up and down. And I
suppose that completions are not invoked from minibuffer interactions
alone ...
> 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.
Yes. But IMO that should be done _before_ reading from the minibuffer
interaction finished.
martin
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, (continued)
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, Juri Linkov, 2020/12/09
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, martin rudalics, 2020/12/10
- 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/10
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, martin rudalics, 2020/12/10
- 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/10
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, martin rudalics, 2020/12/10
- 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/10
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, Juri Linkov, 2020/12/11
- 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/11
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, Juri Linkov, 2020/12/10
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing,
martin rudalics <=
- 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/10
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, martin rudalics, 2020/12/10
- 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/10
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, Juri Linkov, 2020/12/12
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, martin rudalics, 2020/12/13
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, Juri Linkov, 2020/12/14
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, martin rudalics, 2020/12/15
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, Richard Stallman, 2020/12/08
- bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing, Eli Zaretskii, 2020/12/08