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

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

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