RE: C Headers completion candidates

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

.. Lots of fantastic stuff, and explanation of the code...

> Way forward, I want to implement this:
> 1. Implement a list of completions, at the user level; quite like
>    persistent completions;
> 
>    a. Any completion, after being pruned for prefix (before being
>       returned), goes as into the list of completions, without
>       duplicacy.
> 
>    b. This list is read, and appened to the lib-name-list; before the
>       first completion is invoked.

(There was no #2, right?  Not that one was needed - this is
already quite a lot. ;-))

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.
Or maybe you would even add a defcustom that has, as its default
value, a list of such completions.

It all sounds good to me.  And I expect it could be useful to
others too.  And this is so whether or not people use Icicles.
That's the beauty of using just `completing-read': it works
whether or not one uses Icicles.

And the code creating the persistent completions could also be
used by other completion libraries besides Icicles - they too
could no doubt make use of such a persistent list, even if they
do their thing otherwise than by `completing-read'.

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.

[There might be better (in some sense) ways to code some of
what you have.  For example, it might be that using dolist
instead of the more functional-style nested mapcars, etc.
would be faster.  And maybe just use `string-match-p' with a
regexp such as "[.~_]$", instead of bothering with testing
multiple suffixes separately using `string-suffix-p'.  But
such considerations, even assuming they make sense, are not
important.]