RE: completion-auto-help

[Drew Adams]

    > 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.