Re: Completion function directories

Re: Completion function directories

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Apr 27, 11:59am, Andrej Borsenkow wrote:
>
> ...
> 
> > I believe, in all cases when it is
> > possible we need automatic test for GNU utilities so, that completion
> > really works "out of the box". And only when it's not possible - last
> > resort like styles for particular command.
> 
> Following the same sort of suggestion as above, we'd have something like
> 
>     _detect_gnu () {
>         (( $+_is_gnu )) || typeset -gA _is_gnu
>         if (( ! $+_is_gnu[$1] ))
>         then
>                 if [[ $(_call version "$@" </dev/null 2>/dev/null) = *GNU* ]]
>                 then
>                         _is_gnu[$1]=yes 
>                 else
>                         _is_gnu[$1]= 
>                 fi
>         fi
> 	[[ $_is_gnu[$1] = yes ]]
>     }
> 
> And then _make would use
> 
> 	if _detect_gnu $words[1] -v -f /dev/null; then
> 
> and _diff_options would use
> 
> 	if _detect_gnu $cmd -v; then
> 
> and so on for any other completion functions that needed to notice GNU.

Hmhm. Does anyone see if and how we could turn this into a more
generic `_check_type' function? Something like:

  local type

  _check_type type $words[1] ... # args?

  case $type in
  GNU) ...
  AIX) ...
  *)   ...
  esac

Would that be possible withou making _check_type too expensive?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: completion for file descriptors

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> If put _file_descriptors in Core because
> it will be used by _redirect and because other things like _options is
> there - it can always be moved.

Yes, function moving and ordering before 4.0...

The directories we have now have mostly historical reasons and several 
functions could sensibly be moved in other directories even now.

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

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'd like to hear suggestions about all this. (And now Andrej comes and 
says that we should put all the GNU commands on the side... which
wouldn't work with the ordering-by-what-they-do, of course. I still
think there should be only one function per command and we try to find 
out what to complete by investigating the environment inside the
functions.)


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: completion for file descriptors

[Oliver Kiddle]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

Sven Wischnowsky wrote:

> Yes, function moving and ordering before 4.0...

What you suggest for the basic stuff sounds good to me.

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

That is a bit more diffcult. 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. Would there be problems involved in making
the installation of the functions intelligently only pick out
completions for commands which exist on the system?

> (And now Andrej comes and
> says that we should put all the GNU commands on the side... which
> wouldn't work with the ordering-by-what-they-do, of course. I still
> think there should be only one function per command and we try to find
> out what to complete by investigating the environment inside the
> functions.)

I agree with you on this. It keeps things all together better than if we
say had 10 different completions for the same command on different
systems so it is easier to make useful changes affect all the different
systems where they have commonality. It is common for GNU stuff to be
installed alongside originals, sometimes in a different directory and
sometimes with a different name and it would be important to me that
completion for these works.

I've attached my AIX specific completions. I haven't put them in cvs or
anything but when you (or whoever) come to sort out the directories, a
place could be found for them (and those FreeBSD ones someone sent
yesterday). I've actually got a few more AIX (and IRIX) completions but
they are very old (pre-_arguments) and could really do with a rewrite.

Oliver

[-- Attachment #2: Aixcomps.tgz --]
[-- Type: application/x-unknown-content-type-WinZip, Size: 1662 bytes --]

Completion function directories

[Bart Schaefer]

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

RE: Completion function directories

[Andrej Borsenkow]

>
> 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 am not sure I understand what do you mean under "standard completion
environment" in this respect. I believe, in all cases when it is
possible we need automatic test for GNU utilities so, that completion
really works "out of the box". And only when it's not possible - last
resort like styles for particular command.



-andrej

Re: Completion function directories

[Bart Schaefer]

On Apr 27, 11:59am, Andrej Borsenkow wrote:
> Subject: RE: Completion function directories
> >
> > 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 am not sure I understand what do you mean under "standard completion
> environment" in this respect.

The two lines of setopts that have to appear at the top of each of several
of the completion functions to be sure all the globs and parameter refs
work as expected in all the rest of the functions those call.

My idea was to write a function:

    _standard_completer_setopts () {
	unsetopt localoptions	# This is the problem part
        setopt nullglob rcexpandparam extendedglob
        unsetopt markdirs globsubst shwordsplit nounset ksharrays
    }

Then there's only one place to edit if we ever need to change the setopts
used by all the completion scripts -- but the present unpredictable
behavior of `unsetopt localoptions' makes this idea unworkable.

> I believe, in all cases when it is
> possible we need automatic test for GNU utilities so, that completion
> really works "out of the box". And only when it's not possible - last
> resort like styles for particular command.

Following the same sort of suggestion as above, we'd have something like

    _detect_gnu () {
        (( $+_is_gnu )) || typeset -gA _is_gnu
        if (( ! $+_is_gnu[$1] ))
        then
                if [[ $(_call version "$@" </dev/null 2>/dev/null) = *GNU* ]]
                then
                        _is_gnu[$1]=yes 
                else
                        _is_gnu[$1]= 
                fi
        fi
	[[ $_is_gnu[$1] = yes ]]
    }

And then _make would use

	if _detect_gnu $words[1] -v -f /dev/null; then

and _diff_options would use

	if _detect_gnu $cmd -v; then

and so on for any other completion functions that needed to notice GNU.