* bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete
@ 2017-02-07 15:52 Michael Heerdegen
2017-02-07 16:23 ` Stefan Monnier
2019-01-23 17:38 ` Stefan Monnier
0 siblings, 2 replies; 6+ messages in thread
From: Michael Heerdegen @ 2017-02-07 15:52 UTC (permalink / raw)
To: 25644; +Cc: Stefan Monnier
Hi,
[I CC Stefan because he has installed the fix for #12221 that added the
code that bites me]
I like to use icomplete-mode, but I prefer to have the bindings of RET
and C-j switched.
This sometimes collides with the transient-map installed by
minibuffer-force-complete.
Here is a random recipe for emacs -Q:
Setup:
#+begin_src emacs-lisp
(icomplete-mode)
(define-key icomplete-minibuffer-map [return] #'icomplete-force-complete-and-exit)
(define-key icomplete-minibuffer-map [(control ?j)] #'exit-minibuffer)
#+end_src
Now (just a silly example):
M-x epatch
- Answer y to the question whether the patch is in a buffer
- Hit RET to confirm the suggested default
Note that nothing happens, or you get a `ding'. The second RET works
OTOH. Without the "Setup" part it works as expected however.
I debugged a bit and found that in the first place, the transient map
installed by minibuffer-force-complete shadows the (my) binding of RET.
Someone with insight into that code (Stefan, probably): am I'm doing
something forbidden, or should we improve that code?
Thanks,
Michael.
In GNU Emacs 26.0.50.15 (x86_64-pc-linux-gnu, GTK+ Version 3.22.7)
of 2017-02-06 built on drachen
Repository revision: d45dbccc5d2360818e70bbb0bc816c62c8cf6cbe
Windowing system distributor 'The X.Org Foundation', version 11.0.11901000
System Description: Debian GNU/Linux 9.0 (stretch)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete
2017-02-07 15:52 bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete Michael Heerdegen
@ 2017-02-07 16:23 ` Stefan Monnier
2017-02-07 16:41 ` Michael Heerdegen
2019-01-23 17:38 ` Stefan Monnier
1 sibling, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2017-02-07 16:23 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 25644
> (define-key icomplete-minibuffer-map [return]
> #'icomplete-force-complete-and-exit)
FWIW, I think this should be
(define-key icomplete-minibuffer-map [?\r]
#'icomplete-force-complete-and-exit)
aka
(define-key icomplete-minibuffer-map (kbd "RET")
#'icomplete-force-complete-and-exit)
> M-x epatch
> - Answer y to the question whether the patch is in a buffer
> - Hit RET to confirm the suggested default
> Note that nothing happens, or you get a `ding'. The second RET works
> OTOH. Without the "Setup" part it works as expected however.
> I debugged a bit and found that in the first place, the transient map
> installed by minibuffer-force-complete shadows the (my) binding of RET.
> Someone with insight into that code (Stefan, probably): am I'm doing
> something forbidden, or should we improve that code?
I can't see anything in your Setup code which justifies the behavior
you're seeing, so it seems like a bug somewhere. Probably in the
case of force-complete-and-exit, we should prevent/disable the transient-map.
BTW, if you do
M-x epatch
- Answer y to the question whether the patch is in a buffer
- C-h k RET
what does it say?
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete
2017-02-07 16:23 ` Stefan Monnier
@ 2017-02-07 16:41 ` Michael Heerdegen
0 siblings, 0 replies; 6+ messages in thread
From: Michael Heerdegen @ 2017-02-07 16:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 25644
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > (define-key icomplete-minibuffer-map [return]
> > #'icomplete-force-complete-and-exit)
>
> FWIW, I think this should be
>
> (define-key icomplete-minibuffer-map [?\r]
> #'icomplete-force-complete-and-exit)
> aka
> (define-key icomplete-minibuffer-map (kbd "RET")
> #'icomplete-force-complete-and-exit)
Why?
> BTW, if you do
>
> M-x epatch
> - Answer y to the question whether the patch is in a buffer
> - C-h k RET
>
> what does it say?
It says
| <return> runs the command icomplete-force-complete-and-exit, which is
| an interactive compiled Lisp function in `icomplete.el'.
but I know that this is wrong (it doesn't consider the transient map).
This is one reason why I needed more than one hour before I found out
what's going on.
FWIW `interaction-log' says that the command run has been
| #[0 \303.\305\300`\301\302$)\207 [#<marker at 1 in *Minibuf-1*> #[771 \211\301>\203.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete
2017-02-07 15:52 bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete Michael Heerdegen
2017-02-07 16:23 ` Stefan Monnier
@ 2019-01-23 17:38 ` Stefan Monnier
2019-01-24 22:54 ` Michael Heerdegen
1 sibling, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2019-01-23 17:38 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 25644
I believe Joao has recently installed changes to minibuffer.el and
icomplete.el which fincally fix this bug. Could you confirm?
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete
2019-01-23 17:38 ` Stefan Monnier
@ 2019-01-24 22:54 ` Michael Heerdegen
2019-01-25 13:59 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Michael Heerdegen @ 2019-01-24 22:54 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 25644
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> I believe Joao has recently installed changes to minibuffer.el and
> icomplete.el which fincally fix this bug. Could you confirm?
Can't say for sure, I'm not using icomplete currently. But my original
recipe seems indeed to be fixed.
Thanks,
Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete
2019-01-24 22:54 ` Michael Heerdegen
@ 2019-01-25 13:59 ` Stefan Monnier
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2019-01-25 13:59 UTC (permalink / raw)
To: 25644-done
> Can't say for sure, I'm not using icomplete currently. But my original
> recipe seems indeed to be fixed.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-01-25 13:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-07 15:52 bug#25644: 26.0.50; Problematic transient map in minibuffer-force-complete Michael Heerdegen
2017-02-07 16:23 ` Stefan Monnier
2017-02-07 16:41 ` Michael Heerdegen
2019-01-23 17:38 ` Stefan Monnier
2019-01-24 22:54 ` Michael Heerdegen
2019-01-25 13:59 ` Stefan Monnier
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).