Re: [PATCH] _compdef: Use zsh/param instead of a glob.

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Bart Schaefer wrote on Mon, 27 Aug 2018 11:22 -0700:
> On Mon, Aug 27, 2018 at 3:07 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > That said, if there is some way to generate a set of names that is less
> > complete but has fewer false positives, we could offer that set under
> > one tag and the ${(k)functions[(I)_*]} set under another tag, to allow
> > users to get their preferred way by setting the tag-order style.
> 
> The ${(k)functions[(I)_*]} set will only differ from the
> ${^fpath:/.}/_(|*[^~])(:t) set in two ways:
> (1) The fpath search will find functions that have not yet been marked autoload.
> (2) After autoload functions have been invoked for the first time
> ${(k)functions[(I)_*]} will have the additional functions from the
> base files.
> 
> Skipping (1) for only (2) might be considered just as much a loss as
> not including (2).

I suppose we could do both.

An fpath search could be expensive (it does I/O) but no one has
complained so let's assume the cost is acceptable.

> Also, ${(V)_comps} might be a more reasonable
> source of the extra functions.
> 

I like this.  That will filter out things in fpath that aren't completion
functions, and will filter in things like «compdef 'compadd -a foo' bar».

> > (Incidentally, I never understood why completion functions didn't use a
> > proper namespace, zshfoo_* or some such, like virtually everyone else —
> > but that ship has sailed.)
> 
> Can't say anybody was really thinking about needing function
> namespaces back then.  Miinimize length of identifiers and maximize
> similarity to the command for which the completion was being defined
> were pretty much the only things in mind.  Remember, this was pretty
> close to the era when commands like "ls", "rm", "mv", "ld", etc. were
> named.

Would that also be why all the variables in the C code are named as the
acronyms of whatever their names _should_ be? :-)