From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: completion-auto-help
Date: Fri, 11 Nov 2005 11:32:35 -0800 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICAEKLCOAA.drew.adams@oracle.com> (raw)
In-Reply-To: <87y83vngw6.fsf-monnier+emacs@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.
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.
next prev parent reply other threads:[~2005-11-11 19:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` Drew Adams [this message]
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
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=DNEMKBNJBGPAOPIJOOICAEKLCOAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/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).