RE: [External] : Immediate completion help in minibuffer for specific commands

[Drew Adams]

> It could be convenient for certain commands that
> prompt for minibuffer input to immediately display 
> the possible completions.  A new variable could be > added that would be a 
> list of interactive commands > that immediately invoke 
> `minibuffer-completion-help'.

(BTW, you don't need to test the var for
non-nil before using `memq'.  If it's nil
`memq' returns nil immediately.) 

Making this a command-specific variable
isn't a bad idea.

But if Emacs sticks to its convention that
code should never bind or otherwise change
option values then an option here prohibits
coders from using it to tailor behavior
for commands or other code they write.  And
that's too bad, because that's an important
use case for this kind of thing, IMO.

(Another possibility, instead of a membership
variable (option or not) is to do initial
completion for commands that have a given
property on their symbol, such as what
`delete-selection-mode' does, for instance.)
___


FWIW, since 2005 Icicles has had an option
for this, albeit not command-specific:

 icicle-show-Completions-initially-flag
  is a variable defined in `icicles-opt.el'.

 Its value is nil

 Documentation:
 Non-nil means to show buffer `*Completions*'
  even without user input.
 nil means that `*Completions*' is shown upon
  demand, via `TAB' or `S-TAB'.

 For an alternative but similar behavior to
 using non-nil for 
 `icicle-show-Completions-initially-flag', you
 can set option `icicle-incremental-completion'
 to a value that is neither nil nor t.
 That displays buffer `*Completions*' as soon
 as you type or delete input, but not initially.

My own feeling is that it's OK to bind an option
I bind that option when defining commands that
really should always show *Completions* initially.
This also lets you get per-command behavior (but
not as a user option).

Anyway, good to see vanilla get something like
this, even if 20 years later.