Completion function directories

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Apr 20,  9:18am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: completion for file descriptors
}
} What I would like is a more logical ordering. I haven't really thought 
} about this yet, but maybe a Core with some of the functions it
} contains now [...]

I'd prefer that to be named something other than "Core" ...

} a directory with functions like _arguments (not really
} generating completions, only helping to add them), one directory with
} all those functions that generate a certain type of matches (options,
} jobs, pids, file-descriptors, etc.). And then certainly one for the
} builtin commands.

This sounds OK, too.  I also wonder whether we shouldn't move "compinit"
and related functions (anything not starting with an underscore, really)
up into the Completion directory itself.

} The other stuff is harder to decide. _rpm, for example can also be
} useful on non-Linux systems. I don't know debian, but I guess the
} commands from that directory can be useful elsewhere, too. So maybe we 
} should package the functions in a way that reflects what the commands
} do (network, package-managers, ...).

I don't think categorizing them that way is especially useful.  For one
thing, it means deciding on a list of categories, which is a potentially
deep rat-hole.  For another, it's no help when deciding which completions
to install; if I'm not going to install everything, then I'm probably
going to want all of the "networking" completions but only one of the
"package manager" completions, etc.  I'm not sure that it's even possible
to divide things up in a way that helps much with that, but the point is
to avoid making arbitrary divisions simply for the sake of dividing.

The main things I think we need are (1) to rename the Commands directory
(whatever meaning that name once had has long been lost on me) and (2)
break the User directory into two directories, one for helpers like
_user_at_host and _tilde_files and another for functions that handle
commands (which I think ought to be in a directory named Commands, but
what do I know).  And then if we're going to keep the system-specific
directories like AIX and even X, maybe we should subdivide them further
into the same two directories that we break User into, and eliminate
the system-specific level of hierarchy at install time.

So we'd end up with something like

Helpers  Commands  AIX/Helpers  AIX/Commands  Bsd/Helpers  Bsd/Commands
etc. etc.

(with probably a better name than "helpers").  Things like _diff_options
still end up in a fuzzy space, I know ...

On Apr 20, 10:19am, Oliver Kiddle wrote:
} Subject: Re: PATCH: completion for file descriptors
}
} I think I would prefer to stick to directories which group together
} commands which users will generally have all or none of as it is
} easier to specify whether you want a whole directory than to pick
} and choose from specific commands taking each on their own. I expect
} that it is fairly rare for someone to use rpm on something other than
} Linux.

That's less true that it would have been even a few months ago -- and
even if it's still true, it's silly for _rpm to be the only thing in
the Linux directory.  Might as well give it back its own, or put it in
one named RedHat; after all, almost-but-not-quite everything in the
Debian directory is related to the Debian package management system.

My general feeling on that specific issue is that we shouldn't worry
about it too much -- the packagers of the various linux distributions
will pick the completions that are appropriate for their own dists when
they build their zsh RPMs or dpkgs or whatever, and their end users
will never know or care otherwise (in the main).  Any division we make
should be either for our benefit as developers or to assist packagers
in making the right choices.  (Further, note that we -could- use a
.distfiles-type mechanism or some such to make the install structure
differ from the distribution structure.)

Much earlier, Sven wrote:
} [...] Andrej comes and says that we should put all the GNU commands
} on the side...

This brings up a a question of whether we should have helper functions
for setting/testing the _is_gnu assoc, like happens now in _make and
_diff_options, or to set up the "standard completion environment" like
in _main_complete and _complete_help.  I thought briefly about doing
the latter, but then I noticed this problem:

    function unfortunate () {
	setopt NO_localoptions ...
    }
    function unsuspecting () {
	setopt localoptions ...
	unfortunate
    }

Unsetting localoptions in a nested function has some rather peculiar
effects depending on which options change state where.  It's not exactly
nondeterministic, but it surely can't be determined from the context of
the function that unsets localoptions, and probably not from the context
of the function that calls that other function.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com