RE: C Headers completion candidates

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

I can't comment on most of what you wrote - I have no special
competence about the use case etc.  But I can at least speak
to the use of Icicles etc.

>    b. send this as completion string to match against. e.g. using
>       argument initial for the `completing-read' function. But
>       Info document for Elisp > Minibuffers > Initial Input, says:
> 
>        " This is a mostly-deprecated feature for specifying that the
>        minibuffer should start out with certain text, instead of empty
>        as usual.
>       AND
>        " *We discourage use of a non-'nil' value for INITIAL*

Vanilla Emacs considers parameter INITIAL-INPUT to be deprecated.
Icicles does not.  But even vanilla Emacs still respects it.  IMO,
it is up to _you_ to decide whether, for your context, it is more
useful to use INITIAL-INPUT or DEF (or both).

(`C-h f completing-read' in Icicle mode mentions this.)

In Icicle mode you can also choose to insert the default value
(DEF) if INITIAL-INPUT is nil.  You use var `icicle-default-value'
to control such behavior.  This is a user option, but you can also
bind it in code if you want.

> > By "persistent completions" I guess you mean a persistent list
> > of completions such as those you gather, as in
> > https://www.emacswiki.org/emacs/Icicles_-_Persistent_Completions.
> 
> Yes very much so. I will open another thread, to understand why
> Icicles-PersistentCompletions does not like me!

OK.  You can also take it off the mailing list, if you think
others might not be too interested.  It's up to you.  If you
think you've found a bug, that's best reported directly using
`icicle-send-bug-report'.

> > Or maybe you would even add a defcustom that has, as its default
> > value, a list of such completions.
> >
> Does it mean that the variable will be initialized once using 'customize
> variable' interface, and then subsequent automatic edits will be lost
> between different emacs sessions.

Automatic changes to a user option can also be saved persistently
(not lost), if that's what you want, using `customize-save-variable'.

The behavior depends on what you want.  But if you use a user
option then unless the user has explicitly chosen automatic
updating you generally don't want to change the value.

IMO it is OK for code to change an option value outside the
Customize UI (e.g. using `customize-save-variable'), but only
if the user is aware of this behavior and has chosen it.  I.e.,
you don't want to do something behind the user's back.

> > Please consider, if you haven't already, posting your code as
> > a library somewhere (e.g. Emacs Wiki, MELPA).  Others will not
> > only use it but also offer suggestions etc.
> >
> I am just a novice with lisp... Flattered with the suggestion. I will
> definitely try to package this, put it up on melpa, and discuss it on
> Emacs Wiki.

It can't hurt. ;-)  If something is useful for you it is likely
it will be useful for someone else.  Even code that doesn't do
something that someone else finds directly useful can serve as
food for thought for other uses.