RE: [External] : Re: Allowing completion sources to customize completion display

[Drew Adams <drew.adams@oracle.com>]

> Now just separately speculating about what concrete options might be
> nice to add at some point to the default completion UI, to get nice
> inline preview behavior for multi-line strings... Perhaps two options:
> - completions-ghost-preview=t shows, in the buffer or minibuffer, a
>   grayed-out "ghost" preview of the currently selected completion
>   candidate.
> - completions-multi-line-suppress=t makes the *Completions* buffer
>   shrink down to just show completion-header-format and
>   completion-show-help whenever there's multi-line candidates among the
>   completions.  (So you'd only have the preview from
>   completions-ghost-preview.)

FWIW (I'm not following this thread) -

Icicles has option `icicle-hide-non-matching-lines-flag',
which you can toggle anytime during completion with
`C-u C-x .':

  Non-nil means hide candidate lines that do not match input.
  This applies only to multi-line candidates in buffer
  `*Completions*'.  Lines that do not contain text matched
  by your current minibuffer input are elided using ellipsis
  (`...').

Also option `icicle-hide-common-match-in-Completions-flag',
which you can toggle during completion with just `C-x .':

  Non-nil means hide the common match for your input, in
  `*Completions*'.  The common match used here is governed
  by option `icicle-expand-input-to-common-match'.  It is
  elided using ellipsis (`...').

When you hide non-matching lines of completions or their
common-match portions you still see all of the candidates.
It's just that some of their text may be elided.

Hiding common-match text can be especially useful when
that portion of the candidates is large, as it often is
with absolute file names having a common subdirectory.

This is _not_ specific to any particular kind or category
of completion.  It's a question of what a particular user
finds most useful at any given time.  Do _you_ want to
hide some candidate details right _now_, or not?

As usual, my advice for this kind of thing is to give
users control - don't just deciding on a "DWIM" behavior
(which might be fine as a _default_ behavior but should
not be the only one).  Let _users_ decide what "I mean"
means at any given time in any given context.

A user option sets a user's preferred default behavior.
But it's even more important to be able to control the
behavior dynamically, by toggling or cycling among
possible behaviors.

It's good (imperative, really) to give users dynamic
control.  But it can also help to give them (and library
writers) control over the default behavior of a _given
command_.  For hiding the common match among the current
completions this is done by adding/removing property
`icicle-hide-common-match' to/from a command symbol that
uses completion.

For example, by default command `icicle-locate-file' has
(put 'icicle-locate-file 'icicle-hide-common-match t).
But someone who wants that command to show common matches
by default can put this it their init file:
(put 'icicle-locate-file 'icicle-hide-common-match nil)

HTH.