Re: Completion script for the ctags program

[Oliver Kiddle <opk@xxxxxxx>]

Bart Schaefer wrote:
> On Tue, Feb 23, 2021 at 2:20 PM Oliver Kiddle <opk@xxxxxxx> wrote:
> >
> > That said, it is better that these get applied quickly rather than
> > missed and forgotten. Which leads me to reconsider that I never
> > applied the patch in 44804 to create a separate contrib directory for
> > completions. I would add "suppport for only some variants of a command"
> > to the criteria.
> >
> > That patch mainly didn't get applied because of the outstanding question
> > of what the directory/configure option should be named.
>
> What's the parent directory, specifically?  Or is there a directory
> called this underneath each of Unix, Darwin, etc.?

What that patch adds is "Contrib" as a subdirectory of Completion
with identical make rules as for all the other directories at that
level (Unix, BSD, AIX, Zsh etc). So it'd need it's own subdirectories
for Type, Command (and perhaps Utility and Widget). The only
other difference is that installation was conditional upon a
--enable-contrib-completions option (which defaults to false).

That approach seemed simplest but that's not to say it has to be
done that way if you think it'd be better under each of the other
directories. A single directory may be easier if we wanted to do git
subtree merges from the zsh-completions project though that might need
hacking around anyway if it isn't named "src".

> What about "Submitted" or "Volunteered" ?

Maybe, though I'm not sure they are any more accurate a description
of the contents than "Contrib". Given a lax license constraint on the
contents we might theoretically pick up functions found on the wider
Internet and dump them in without them ever being explicitly contributed
or submitted.* I probably favour Contrib because I've seen it used
similarly elsewhere.

Other ideas include 'External', 'Independent', 'Extra', 'Supplemental',
'Annex', 'Additional', 'Scrap', 'Dump', 'Diverse', 'Sundry'.

For reference, the criteria for inclusion I suggested were:
    - differently licenced
    - low quality
    - poorly maintained
    - obscure command
    - dead upstream
    - incomplete/work in progress
    - major variants of the command not handled
The first of these is probably the most important, especially for some
downstream packagers but I can't think of a way to capture that
succinctly in one word that doesn't begin with U.

Any preferences?

Oliver

* Note that I would only do this where at least some sort of free
redistribution terms are clear.