* bug#5849: 23.1.95; completion-auto-help blocks icomplete-mode
2010-04-10 18:51 ` Chong Yidong
@ 2010-04-10 19:32 ` Drew Adams
2010-04-11 11:53 ` Leo
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Drew Adams @ 2010-04-10 19:32 UTC (permalink / raw)
To: 'Chong Yidong'; +Cc: 5849, 'Leo'
> > If your suggestion were to just not show the message
> > [Next char not unique] when icomplete-mode is on
>
> Yes, obviously this is what I meant. Like this:
>
> (if (cond (icomplete-mode t)
> ((eq completion-auto-help 'lazy)
> (eq this-command last-command))
> (t completion-auto-help))
> (minibuffer-completion-help)
> (minibuffer-message "Next char not unique")))
Yes, that's OK by me.
But either of these (equivalent) forms is clearer, IMO:
(if (or icomplete-mode
(and completion-auto-help
(or (not (eq completion-auto-help 'lazy))
(eq this-command last-command))))
(minibuffer-completion-help)
(minibuffer-message "Next char not unique"))
(if (or icomplete-mode
(if (eq completion-auto-help 'lazy)
(eq this-command last-command)
completion-auto-help))
(minibuffer-completion-help)
(minibuffer-message "Next char not unique"))
---
And if we didn't care whether a non-t, non-`lazy', non-nil value calls
`minibuffer-completion-help', then this (not equivalent) would be OK too:
(if (or icomplete-mode
(eq t completion-auto-help)
(and (eq completion-auto-help 'lazy)
(eq this-command last-command)))
(minibuffer-completion-help)
(minibuffer-message "Next char not unique"))
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#5849: 23.1.95; completion-auto-help blocks icomplete-mode
2010-04-10 18:51 ` Chong Yidong
2010-04-10 19:32 ` Drew Adams
@ 2010-04-11 11:53 ` Leo
2010-05-10 6:58 ` Leo
2010-07-23 22:18 ` Stefan Monnier
3 siblings, 0 replies; 11+ messages in thread
From: Leo @ 2010-04-11 11:53 UTC (permalink / raw)
To: bug-gnu-emacs
On 2010-04-10 19:51 +0100, Chong Yidong wrote:
>> If your suggestion were to just not show the message [Next char not
>> unique] when icomplete-mode is on
>
> Yes, obviously this is what I meant.
The behaviour described is desirable. But it seems it will be better to
make minibuffer completion code more flexible instead of special-case
icomplete.
Leo
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#5849: 23.1.95; completion-auto-help blocks icomplete-mode
2010-04-10 18:51 ` Chong Yidong
2010-04-10 19:32 ` Drew Adams
2010-04-11 11:53 ` Leo
@ 2010-05-10 6:58 ` Leo
2011-04-10 21:30 ` Chong Yidong
2010-07-23 22:18 ` Stefan Monnier
3 siblings, 1 reply; 11+ messages in thread
From: Leo @ 2010-05-10 6:58 UTC (permalink / raw)
To: Chong Yidong; +Cc: 5849
On 2010-04-10 19:51 +0100, Chong Yidong wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> If your suggestion were to just not show the message [Next char not
>> unique] when icomplete-mode is on
>
> Yes, obviously this is what I meant. Like this:
[...]
I wonder if it makes sense to always have the message from completion
append to the text in the minibuffer. For example, in this case, the
icomplete hint will go first and the completion message last.
This would seem to fix another problem seen in M-:. When users try to
complete while in minibuffer for example when using M-:, it switches to
show the completion message and blocks users from seeing the text they
are editing in the minibuffer.
Leo
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#5849: 23.1.95; completion-auto-help blocks icomplete-mode
2010-05-10 6:58 ` Leo
@ 2011-04-10 21:30 ` Chong Yidong
2011-07-09 15:00 ` Johan Bockgård
0 siblings, 1 reply; 11+ messages in thread
From: Chong Yidong @ 2011-04-10 21:30 UTC (permalink / raw)
To: 5849
I have checked in the patch that I posted earlier for this bug into the
emacs-23 branch, and a more complete fix into the trunk. The latter
involves a new variable completion-show-inline-help, which
icomplete-mode binds to nil.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#5849: 23.1.95; completion-auto-help blocks icomplete-mode
2011-04-10 21:30 ` Chong Yidong
@ 2011-07-09 15:00 ` Johan Bockgård
2011-09-18 16:13 ` Chong Yidong
0 siblings, 1 reply; 11+ messages in thread
From: Johan Bockgård @ 2011-07-09 15:00 UTC (permalink / raw)
To: Chong Yidong; +Cc: 5849
Chong Yidong <cyd@stupidchicken.com> writes:
> I have checked in the patch that I posted earlier for this bug into the
> emacs-23 branch, and a more complete fix into the trunk. The latter
> involves a new variable completion-show-inline-help, which
> icomplete-mode binds to nil.
The fix in the trunk sets completion-show-inline-help globally which is
not quite right:
emacs -Q
M-x icomplete-mode RET
C-x C-f nonexistingfile TAB
=> no message
Expected: "[No match]"
This patch to the current trunk sets completion-show-inline-help locally
when icomplete is actually being used (simple completion).
2011-07-09 Johan Bockgård <bojohan@gnu.org>
Fix previous fix of Bug#5849.
* icomplete.el (icomplete-mode): Don't set
completion-show-inline-help.
(icomplete-minibuffer-setup): Set completion-show-inline-help
locally during icompletion.
=== modified file 'lisp/icomplete.el'
--- lisp/icomplete.el 2011-05-31 03:03:38 +0000
+++ lisp/icomplete.el 2011-07-09 14:01:48 +0000
@@ -179,11 +179,8 @@
(if icomplete-mode
;; The following is not really necessary after first time -
;; no great loss.
- (progn
- (setq completion-show-inline-help nil)
- (add-hook 'minibuffer-setup-hook 'icomplete-minibuffer-setup))
- (remove-hook 'minibuffer-setup-hook 'icomplete-minibuffer-setup)
- (setq completion-show-inline-help t)))
+ (add-hook 'minibuffer-setup-hook 'icomplete-minibuffer-setup)
+ (remove-hook 'minibuffer-setup-hook 'icomplete-minibuffer-setup)))
;;;_ > icomplete-simple-completing-p ()
(defun icomplete-simple-completing-p ()
@@ -209,6 +206,7 @@
"Run in minibuffer on activation to establish incremental completion.
Usually run by inclusion in `minibuffer-setup-hook'."
(when (and icomplete-mode (icomplete-simple-completing-p))
+ (set (make-local-variable 'completion-show-inline-help) nil)
(add-hook 'pre-command-hook
(lambda () (run-hooks 'icomplete-pre-command-hook))
nil t)
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#5849: 23.1.95; completion-auto-help blocks icomplete-mode
2011-07-09 15:00 ` Johan Bockgård
@ 2011-09-18 16:13 ` Chong Yidong
0 siblings, 0 replies; 11+ messages in thread
From: Chong Yidong @ 2011-09-18 16:13 UTC (permalink / raw)
To: 5849
Johan Bockgård <bojohan@gnu.org> writes:
> The fix in the trunk sets completion-show-inline-help globally which is
> not quite right:
>
> emacs -Q
> M-x icomplete-mode RET
> C-x C-f nonexistingfile TAB
> => no message
> Expected: "[No match]"
>
> This patch to the current trunk sets completion-show-inline-help locally
> when icomplete is actually being used (simple completion).
Thanks, committed.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#5849: 23.1.95; completion-auto-help blocks icomplete-mode
2010-04-10 18:51 ` Chong Yidong
` (2 preceding siblings ...)
2010-05-10 6:58 ` Leo
@ 2010-07-23 22:18 ` Stefan Monnier
3 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2010-07-23 22:18 UTC (permalink / raw)
To: Chong Yidong; +Cc: 5849, 'Leo'
> Yes, obviously this is what I meant. Like this:
> === modified file 'lisp/minibuffer.el'
> *** lisp/minibuffer.el 2010-03-24 18:02:56 +0000
> --- lisp/minibuffer.el 2010-04-10 18:49:41 +0000
> ***************
> *** 528,536 ****
> ;; Show the completion table, if requested.
> (cond
> ((not exact)
> ! (if (case completion-auto-help
> ! (lazy (eq this-command last-command))
> ! (t completion-auto-help))
> (minibuffer-completion-help)
> (minibuffer-message "Next char not unique")))
> ;; If the last exact completion and this one were the same, it
> --- 528,537 ----
> ;; Show the completion table, if requested.
> (cond
> ((not exact)
> ! (if (cond (icomplete-mode t)
> ! ((eq completion-auto-help 'lazy)
> ! (eq this-command last-command))
> ! (t completion-auto-help))
> (minibuffer-completion-help)
> (minibuffer-message "Next char not unique")))
> ;; If the last exact completion and this one were the same, it
It's a good workaround, thanks. Note that most other messages from the
completion code are similarly problematic, I think. So maybe we should
have a buffer-local completion-inhibit-messages variable, which
icomplete could set in the minibuffer.
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread