Re: C Headers completion candidates

[bvraghav@iitk.ac.in (B.V. Raghav)]

Drew Adams <drew.adams@oracle.com> writes:

> .. Lots of fantastic stuff, and explanation of the code...
>
Your acknowledgement is very encouraging. Thank you.

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

Yes, in fact there were #2 and #3
2. Projectile use a completion set for projectile-find-file (probably
   using completing-read).

   a. Leverage it on the include list for first level of completions,
      with a user custom regexp variable for filter, e.g. "\\.h[pp]\?$"

   b. May be it is just worth accumulating the results of a shell `find'
      on the projectile-root with flags `-type f -iname ...' and so
      forth.

3. Make use of the point, e.g.
   #include <vec|>

   If I invoke the command `insert-c-header' here, then the software
   should:
   a. mark a region like ...<[vec]|>... (`[]' representing the region, and
      `|' -- the point)
   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*

      Is there another way? What more should I read?

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

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

> 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'.
>
I did not realize that the code creating persistent list may be
orthogonal to `c-header', also --- until I read this. Thank you.

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

> [There might be better (in some sense) ways to code some of
> what you have.  For example, it might be that using dolist
`C-h i m elisp RET i dolist RET' Thanks, I did not know about this. `C-x
r m'

> 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
Yeah... Thank you this looks both simpler to read and easy to type.

> multiple suffixes separately using `string-suffix-p'.  But
> such considerations, even assuming they make sense, are not
> important.]

Thanks... 

-- 
(B.V. Raghav)
Ph.D. Student,
Design Programme, IIT Kanpur