* completion-auto-help
@ 2005-11-11 1:30 Drew Adams
2005-11-11 4:55 ` completion-auto-help Stefan Monnier
0 siblings, 1 reply; 16+ messages in thread
From: Drew Adams @ 2005-11-11 1:30 UTC (permalink / raw
1. Question:
The doc string for `completion-auto-help' says this:
Non-nil means automatically provide help for invalid completion input.
The Elisp manual says this about it:
If this variable is non-`nil', the completion commands
automatically display a list of possible completions whenever
nothing can be completed because the next character is not
uniquely determined.
In neither case are different non-nil values distinguished. So, I don't
understand this code in complete.el:
(if (or (eq completion-auto-help t)
(and completion-auto-help
(eq last-command this-command))
(eq mode 'help))
The second arg to `or' can only be evaluated if `completion-auto-help' is
not `t', and that second arg tests whether it is non-nil.
Am I missing something - is there some special treatment somewhere for
non-nil, non-t value? (That's what the second arg seems to be doing.) I see
no other occurrences of `completion-auto-help' anywhere in the Lisp code
that distinguish different non-nil values.
2. New feature proposal - How about allowing for an
"always-display-*Completions*' behavior:
- t means what it means now
- nil means what it means now
- other means this:
Display *Completions* right from the beginning (empty minibuffer input).
Display it as long as the minibuffer contents match more than one
completion.
IOW, with this value, the user would not need to hit `TAB' to display
*Completions*. (S)he would see the list of completions whenever there are
more than one. There is currently no way to make `completing-read',
`read-file-name' etc. display *Completions* from the outset.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion-auto-help
2005-11-11 1:30 completion-auto-help Drew Adams
@ 2005-11-11 4:55 ` Stefan Monnier
2005-11-11 17:47 ` completion-auto-help Drew Adams
2005-11-12 3:38 ` completion-auto-help Richard M. Stallman
0 siblings, 2 replies; 16+ messages in thread
From: Stefan Monnier @ 2005-11-11 4:55 UTC (permalink / raw
Cc: Emacs-Devel
> The Elisp manual says this about it:
> If this variable is non-`nil', the completion commands
> automatically display a list of possible completions whenever
> nothing can be completed because the next character is not
> uniquely determined.
> In neither case are different non-nil values distinguished. So, I don't
> understand this code in complete.el:
> (if (or (eq completion-auto-help t)
> (and completion-auto-help
> (eq last-command this-command))
> (eq mode 'help))
complete.el extends the meaning of the variable so that a non-nil non-t
value means "show the help but only on the second attempt to complete".
I.e. if TAB finds nothing to complete, the first TAB will just say "[Next
char not unique]" without bringing up the *Completions* buffer, and the
second TAB will then bring up the *Completions* buffer.
It happens to be my favorite behavior.
> 2. New feature proposal - How about allowing for an
> "always-display-*Completions*' behavior:
> - t means what it means now
> - nil means what it means now
> - other means this:
We could have
t = what it means now
nil = what it means now
eager = what you suggest (always show the completions and update them
after each key stroke)
lazy = what complete.el does for non-nil non-t values
> IOW, with this value, the user would not need to hit `TAB' to display
> *Completions*. (S)he would see the list of completions whenever there are
> more than one. There is currently no way to make `completing-read',
> `read-file-name' etc. display *Completions* from the outset.
Indeed. The closest is icomplete-mode.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion-auto-help
2005-11-11 4:55 ` completion-auto-help Stefan Monnier
@ 2005-11-11 17:47 ` Drew Adams
2005-11-11 18:39 ` completion-auto-help Drew Adams
2005-11-11 19:10 ` completion-auto-help Stefan Monnier
2005-11-12 3:38 ` completion-auto-help Richard M. Stallman
1 sibling, 2 replies; 16+ messages in thread
From: Drew Adams @ 2005-11-11 17:47 UTC (permalink / raw
complete.el extends the meaning of the variable so that a non-nil non-t
value means "show the help but only on the second attempt to complete".
I.e. if TAB finds nothing to complete, the first TAB will just
say "[Next
char not unique]" without bringing up the *Completions* buffer, and the
second TAB will then bring up the *Completions* buffer.
It happens to be my favorite behavior.
Thanks. I knew about that behavior, but I couldn't make out the related use
of completion-auto-help.
I still don't see it in complete.el (it is only tested there, never bound),
and I don't see it in C code either. Where is `completion-auto-help's
non-nil, non-t value bound?
If it is only a user who sets such a value, then shouldn't the non-nil,
non-t behavior be documented for the user option? I don't see that, as I
mentioned.
> 2. New feature proposal - How about allowing for an
> "always-display-*Completions*' behavior:
> - t means what it means now
> - nil means what it means now
> - other means this:
We could have
t = what it means now
nil = what it means now
eager = what you suggest (always show the completions and update them
after each key stroke)
lazy = what complete.el does for non-nil non-t values
Good.
> IOW, with this value, the user would not need to hit `TAB' to display
> *Completions*. (S)he would see the list of completions
whenever there are
> more than one. There is currently no way to make `completing-read',
> `read-file-name' etc. display *Completions* from the outset.
Indeed. The closest is icomplete-mode.
Yes, in fact, I implement this behavior with regexp matching in Icicles,
where I refer to it, by analogy, as "apropos icompletion" ("apropos" because
it uses a regexp, "icompletion" because it is incremental completion). That
was one of the motivations for this request: I currently have no way to
display the candidates right from the beginning - a user must first request
the display (via, e.g., `TAB').
I proposed `eager' _without_ the automatic update after each keystroke, in
order to allow that as an additional (separate) option. I think that would
be better. Some people (or some functions) might like to display the list of
candidates right from the beginning, as a kind of menu, but prefer to update
it only upon demand (via `TAB'), not automatically at each keystroke. Some
people might find the automatic list updating to be distracting (I find it
very helpful, personally).
IOW, I think we should separate the control of when to display of
*Completions* from the control of whether or not to automatically update it.
The difference only makes sense, probably, for the `eager' value, so we
could just have two values instead of one: `eager-with-auto-update' and
`eager-without-auto-update'.
My implementation of this kind of incremental completion in Icicles uses an
option that is checked in the special self-insert I use. The option values:
non-nil means update *Completions* incrementally, as you type.
t means do nothing if *Completions* is not already displayed.
non-nil and non-t means display *Completions* and update it.
So, for instance, non-nil, non-t causes character insertion to display
*Completions*. That does not take care of displaying it, however, right from
the beginning, which is why I made this request. The special self-insert
gets called inside `completing-read', upon insertion, but I see no way to
get `completing-read' to display *Completions* without any user action.
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion-auto-help
2005-11-11 17:47 ` completion-auto-help Drew Adams
@ 2005-11-11 18:39 ` Drew Adams
2005-11-11 19:10 ` completion-auto-help Stefan Monnier
1 sibling, 0 replies; 16+ messages in thread
From: Drew Adams @ 2005-11-11 18:39 UTC (permalink / raw
I wrote:
Some people might find the automatic list updating to be distracting
(I find it very helpful, personally).
Correction - I find it very helpful, provided I want to see the
*Completions* list at all. If *Completions* is automatically displayed from
the outset, and updated at each keystroke, that can be distracting in some
contexts and helpful in others.
I mentioned two optional auto-update behaviors in Icicles:
non-nil means update *Completions* incrementally, as you type.
t means do nothing if *Completions* is not already displayed.
non-nil and non-t means display *Completions* and update it.
It is the `t' behavior that I find very helpful. I find the non-nil, non-t
behavior distracting, depending on the size of the alist for
completing-read. With a large alist, auto-update as soon as you start typing
something can lead to massive update changes in *Completions*.
I'm still requesting a way to display *Completions* from the beginning, but
I would use that only in particular contexts - for example, when the list of
candidates is relatively small (*Completions* is treated as a menu), in
which case, auto-update is not distracting. Otherwise I would use it without
auto-update.
That's why I'd like to keep the two (display *Completions* initially and
auto-update it) as separate options.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion-auto-help
2005-11-11 17:47 ` completion-auto-help Drew Adams
2005-11-11 18:39 ` completion-auto-help Drew Adams
@ 2005-11-11 19:10 ` Stefan Monnier
2005-11-11 19:32 ` completion-auto-help Drew Adams
2005-11-19 12:10 ` completion-auto-help Eli Zaretskii
1 sibling, 2 replies; 16+ messages in thread
From: Stefan Monnier @ 2005-11-11 19:10 UTC (permalink / raw
Cc: Emacs-Devel
> complete.el extends the meaning of the variable so that a non-nil non-t
> value means "show the help but only on the second attempt to complete".
> I.e. if TAB finds nothing to complete, the first TAB will just
> say "[Next
> char not unique]" without bringing up the *Completions* buffer, and the
> second TAB will then bring up the *Completions* buffer.
> It happens to be my favorite behavior.
> Thanks. I knew about that behavior, but I couldn't make out the related use
> of completion-auto-help.
> I still don't see it in complete.el (it is only tested there, never bound),
> and I don't see it in C code either. Where is `completion-auto-help's
> non-nil, non-t value bound?
completion-auto-help is a user variable. It's only meant to be changed in
the .emacs file.
> If it is only a user who sets such a value, then shouldn't the non-nil,
> non-t behavior be documented for the user option? I don't see that, as I
> mentioned.
It's not documented, because there's no place to document it:
completion-auto-help is part of the basic completion facilities, whereas the
added behavior is only provided in complete.el which is a separate package.
> I proposed `eager' _without_ the automatic update after each keystroke, in
> order to allow that as an additional (separate) option. I think that would
> be better. Some people (or some functions) might like to display the list of
> candidates right from the beginning, as a kind of menu, but prefer to update
> it only upon demand (via `TAB'), not automatically at each keystroke. Some
> people might find the automatic list updating to be distracting (I find it
> very helpful, personally).
I'd wait to see people complaint about one of the two behaviors before
providing both.
> gets called inside `completing-read', upon insertion, but I see no way to
> get `completing-read' to display *Completions* without any user action.
IIRC you can do it from minibuffer-setup-hook.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion-auto-help
2005-11-11 19:10 ` completion-auto-help Stefan Monnier
@ 2005-11-11 19:32 ` Drew Adams
2005-11-11 21:53 ` completion-auto-help Drew Adams
2005-11-19 12:10 ` completion-auto-help Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Drew Adams @ 2005-11-11 19:32 UTC (permalink / raw
> If it is only a user who sets such a value, then shouldn't
the non-nil,
> non-t behavior be documented for the user option? I don't see
that, as I
> mentioned.
It's not documented, because there's no place to document it:
completion-auto-help is part of the basic completion
facilities, whereas the
added behavior is only provided in complete.el which is a
separate package.
That doesn't sound right, somehow.
Is the non-nil behavior you describe behavior provided only by complete.el?
Or is it part of the basic completion facilities?
If the latter, then the doc string should be changed to mention the non-nil,
non-t case.
If the former, then complete.el is changing the behavior of the general user
option (instead of, for example, using a new user option). That's OK I
guess, but it should document that - at the very least in the Commentary of
the library. Better, would be for complete.el to update the doc string of
`completion-auto-help', describing the complete.el-specific behavior.
> I proposed `eager' _without_ the automatic update after each
> keystroke, in order to allow that as an additional (separate)
> option. I think that would be better. Some people (or some
> functions) might like to display the list of candidates right
> from the beginning, as a kind of menu, but prefer to update
> it only upon demand (via `TAB'), not automatically at each
> keystroke. Some people might find the automatic list updating
> to be distracting (I find it very helpful, personally).
I'd wait to see people complaint about one of the two behaviors before
providing both.
I'm complaining - see my second email on this.
The ability to display *Completions* from the start would typically be used
in situations where the number of candidates is not that large - in
particular, where *Completions* is treated much as a menu. In that context,
auto-update is not distracting, and can be very helpful.
However, displaying a long list from the start, and updating it with every
keystroke, can be distracting. You'll say, "Don't use `eager' in that case".
But I don't think the use cases are so cut and dried.
Automatic update is useful even without initial display. It means you need
not keep hitting `TAB' to see what the candidates are.
Initial display is likely to be useful even without automatic update (but I
don't have a great use case here).
> gets called inside `completing-read', upon insertion, but I
> see no way to get `completing-read' to display *Completions*
> without any user action.
IIRC you can do it from minibuffer-setup-hook.
I've tried that. This is not about minibuffer setup, and it's not about
completion-list setup (for which there is also a hook). This is about
_completion_ setup.
I believe that what's needed is a hook that kicks in as soon as
completing-read (and read-file-name...) displays its prompt (just before or
after). That hook doesn't exist.
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion-auto-help
2005-11-11 19:32 ` completion-auto-help Drew Adams
@ 2005-11-11 21:53 ` Drew Adams
2005-11-11 22:43 ` completion-auto-help Drew Adams
0 siblings, 1 reply; 16+ messages in thread
From: Drew Adams @ 2005-11-11 21:53 UTC (permalink / raw
> gets called inside `completing-read', upon insertion, but I
> see no way to get `completing-read' to display *Completions*
> without any user action.
IIRC you can do it from minibuffer-setup-hook.
I've tried that. This is not about minibuffer setup, and it's not about
completion-list setup (for which there is also a hook). This is about
_completion_ setup.
I believe that what's needed is a hook that kicks in as soon as
completing-read (and read-file-name...) displays its prompt
(just before or
after). That hook doesn't exist.
My bad. I did try `minibuffer-setup-hook' previously with no luck, but I
must not have done things correctly. I just retried, and it does what I want
in this regard.
(add-hook 'minibuffer-setup-hook 'show-it)
(defun show-it ()
"Show *Completions* on empty input."
(with-output-to-temp-buffer "*Completions*"
(display-completion-list (all-completions "" my-completions)))
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion-auto-help
2005-11-11 21:53 ` completion-auto-help Drew Adams
@ 2005-11-11 22:43 ` Drew Adams
2005-11-13 20:42 ` completion-auto-help Stefan Monnier
0 siblings, 1 reply; 16+ messages in thread
From: Drew Adams @ 2005-11-11 22:43 UTC (permalink / raw
> gets called inside `completing-read', upon insertion, but I
> see no way to get `completing-read' to display *Completions*
> without any user action.
IIRC you can do it from minibuffer-setup-hook.
I've tried that. This is not about minibuffer setup, and
it's not about
completion-list setup (for which there is also a hook).
This is about _completion_ setup.
I believe that what's needed is a hook that kicks in as soon as
completing-read (and read-file-name...) displays its prompt
(just before or after). That hook doesn't exist.
My bad. I did try `minibuffer-setup-hook' previously with no luck, but I
must not have done things correctly. I just retried, and it
does what I want
in this regard.
(add-hook 'minibuffer-setup-hook 'show-it)
(defun show-it ()
"Show *Completions* on empty input."
(with-output-to-temp-buffer "*Completions*"
(display-completion-list (all-completions "" my-completions)))
Guess I'll have to flip-flop again. minibuffer-setup-hook is used for all
entrance to the minibuffer, not just for completion functions.
I'm looking for a hook specific to completion. I think we still need a hook
that runs whenever a completion function (e.g. completing-read) displays its
prompt.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion-auto-help
2005-11-11 4:55 ` completion-auto-help Stefan Monnier
2005-11-11 17:47 ` completion-auto-help Drew Adams
@ 2005-11-12 3:38 ` Richard M. Stallman
1 sibling, 0 replies; 16+ messages in thread
From: Richard M. Stallman @ 2005-11-12 3:38 UTC (permalink / raw
Cc: drew.adams, emacs-devel
complete.el extends the meaning of the variable so that a non-nil non-t
value means "show the help but only on the second attempt to complete".
I.e. if TAB finds nothing to complete, the first TAB will just say "[Next
char not unique]" without bringing up the *Completions* buffer, and the
second TAB will then bring up the *Completions* buffer.
It happens to be my favorite behavior.
Could you document this? It seems not to be documented now,
not even in complete.el. It would be convenient to document this
in the doc string of that variable.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion-auto-help
2005-11-11 22:43 ` completion-auto-help Drew Adams
@ 2005-11-13 20:42 ` Stefan Monnier
2005-11-13 21:06 ` completion-auto-help Drew Adams
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2005-11-13 20:42 UTC (permalink / raw
Cc: Emacs-Devel
> Guess I'll have to flip-flop again. minibuffer-setup-hook is used for all
> entrance to the minibuffer, not just for completion functions.
> I'm looking for a hook specific to completion. I think we still need a hook
> that runs whenever a completion function (e.g. completing-read) displays its
> prompt.
Check the value of minibuffer-completion-table in your hook.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion-auto-help
2005-11-13 20:42 ` completion-auto-help Stefan Monnier
@ 2005-11-13 21:06 ` Drew Adams
2005-11-13 23:09 ` completion-auto-help Stefan Monnier
0 siblings, 1 reply; 16+ messages in thread
From: Drew Adams @ 2005-11-13 21:06 UTC (permalink / raw
> minibuffer-setup-hook is used for all
> entrance to the minibuffer, not just for completion functions.
> I'm looking for a hook specific to completion. I think we
> still need a hook that runs whenever a completion function
> (e.g. completing-read) displays its prompt.
Check the value of minibuffer-completion-table in your hook.
Not sure what you mean. Do you mean to check, inside the hook, whether that
var is non-nil, and use that test to determine whether or not we are
completing? That is, use (not (null minibuffer-completion-table)) as a kind
of `completing-p'?
If that's what you mean, it doesn't seem to work -
`minibuffer-completion-table' is not nil, even when doing things like
read-from-minibuffer (which doesn't use completion).
Hoping I misunderstand and there is a simple solution.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion-auto-help
2005-11-13 21:06 ` completion-auto-help Drew Adams
@ 2005-11-13 23:09 ` Stefan Monnier
2005-11-13 23:40 ` completion-auto-help Drew Adams
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2005-11-13 23:09 UTC (permalink / raw
Cc: Emacs-Devel
> Not sure what you mean. Do you mean to check, inside the hook, whether
> that var is non-nil, and use that test to determine whether or not we are
> completing? That is, use (not (null minibuffer-completion-table)) as
> a kind of `completing-p'?
Yes.
> If that's what you mean, it doesn't seem to work -
> `minibuffer-completion-table' is not nil, even when doing things like
> read-from-minibuffer (which doesn't use completion).
That's rather odd. Can you show a recipe to reproduce it?
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: completion-auto-help
2005-11-13 23:09 ` completion-auto-help Stefan Monnier
@ 2005-11-13 23:40 ` Drew Adams
0 siblings, 0 replies; 16+ messages in thread
From: Drew Adams @ 2005-11-13 23:40 UTC (permalink / raw
> use (not (null minibuffer-completion-table)) as a kind of
> `completing-p'? it doesn't seem to work -
> `minibuffer-completion-table' is not nil, even when doing things like
> read-from-minibuffer (which doesn't use completion).
That's rather odd. Can you show a recipe to reproduce it?
My bad. In emacs -q, it works. I must be changing the table in my context.
Thanks.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion-auto-help
2005-11-11 19:10 ` completion-auto-help Stefan Monnier
2005-11-11 19:32 ` completion-auto-help Drew Adams
@ 2005-11-19 12:10 ` Eli Zaretskii
2005-11-20 23:23 ` completion-auto-help Richard M. Stallman
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2005-11-19 12:10 UTC (permalink / raw
Cc: drew.adams, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 11 Nov 2005 14:10:30 -0500
> Cc: Emacs-Devel <emacs-devel@gnu.org>
>
> > If it is only a user who sets such a value, then shouldn't the non-nil,
> > non-t behavior be documented for the user option? I don't see that, as I
> > mentioned.
>
> It's not documented, because there's no place to document it:
> completion-auto-help is part of the basic completion facilities, whereas the
> added behavior is only provided in complete.el which is a separate package.
I documented that in the doc string of partial-completion-mode.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion-auto-help
2005-11-19 12:10 ` completion-auto-help Eli Zaretskii
@ 2005-11-20 23:23 ` Richard M. Stallman
2005-11-26 11:20 ` completion-auto-help Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Richard M. Stallman @ 2005-11-20 23:23 UTC (permalink / raw
Cc: monnier, drew.adams, emacs-devel
> It's not documented, because there's no place to document it:
> completion-auto-help is part of the basic completion facilities, whereas the
> added behavior is only provided in complete.el which is a separate package.
I documented that in the doc string of partial-completion-mode.
I think it should be documented in the doc string of
completion-auto-help above all. Could you add something there?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: completion-auto-help
2005-11-20 23:23 ` completion-auto-help Richard M. Stallman
@ 2005-11-26 11:20 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2005-11-26 11:20 UTC (permalink / raw
Cc: monnier, drew.adams, emacs-devel
> From: "Richard M. Stallman" <rms@gnu.org>
> CC: monnier@iro.umontreal.ca, drew.adams@oracle.com,
> emacs-devel@gnu.org
> Date: Sun, 20 Nov 2005 18:23:11 -0500
>
> > It's not documented, because there's no place to document it:
> > completion-auto-help is part of the basic completion facilities, whereas the
> > added behavior is only provided in complete.el which is a separate package.
>
> I documented that in the doc string of partial-completion-mode.
>
> I think it should be documented in the doc string of
> completion-auto-help above all. Could you add something there?
Done.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-11-26 11:20 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-11 1:30 completion-auto-help Drew Adams
2005-11-11 4:55 ` completion-auto-help Stefan Monnier
2005-11-11 17:47 ` completion-auto-help Drew Adams
2005-11-11 18:39 ` completion-auto-help Drew Adams
2005-11-11 19:10 ` completion-auto-help Stefan Monnier
2005-11-11 19:32 ` completion-auto-help Drew Adams
2005-11-11 21:53 ` completion-auto-help Drew Adams
2005-11-11 22:43 ` completion-auto-help Drew Adams
2005-11-13 20:42 ` completion-auto-help Stefan Monnier
2005-11-13 21:06 ` completion-auto-help Drew Adams
2005-11-13 23:09 ` completion-auto-help Stefan Monnier
2005-11-13 23:40 ` completion-auto-help Drew Adams
2005-11-19 12:10 ` completion-auto-help Eli Zaretskii
2005-11-20 23:23 ` completion-auto-help Richard M. Stallman
2005-11-26 11:20 ` completion-auto-help Eli Zaretskii
2005-11-12 3:38 ` completion-auto-help Richard M. Stallman
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).