Completion/User functions again

Completion/User functions again

[Andrej Borsenkow]

I'm still feeling uneasy about installing all of these functions. There are
several reasons:

 - _tar and _find are hopelessly GNUish. You cannot expect, that users will
study every function to find out if it is applicable to there system. They will
simply install it and wonder why it does not work. Of course, gzip, configure
etc are GNU as well - but they do not conflict with system standard commands.

 - _hosts, _rlogin, _x_options are using array hosts. This most probably does
not exist. Again, I do not like installing something that does not work
out-of-the-box by default. This should be done explicitly in hope, that users
understand what's going on :-)

 - _chown, _chgrp, _stty are too system dependent. It is better to not provide
completion at all than provide completion that only partially works. I do not
suggest removing them from distribution - but to not install them by default.

To summarise - I firmly believe, that everything that gets installed must work
"as is" on every system. Anything that works only on some systems or something
that needs additional setup should only be installed explicitly.

/andrej

PATCH: Re: Completion/User functions again

[Oliver Kiddle]

Andrej Borsenkow wrote:
> 
>  - _tar and _find are hopelessly GNUish. You cannot expect, that users will
> study every function to find out if it is applicable to there system. They will
> simply install it and wonder why it does not work. Of course, gzip, configure
> etc are GNU as well - but they do not conflict with system standard commands.

This is why I suggested a while ago that things such as tar and find are
moved to a 'Gnu' directory and other directories such as Aix, Irix etc
can contain completions specific to
those systems.

>  - _hosts, _rlogin, _x_options are using array hosts. This most probably does
> not exist. Again, I do not like installing something that does not work
> out-of-the-box by default. This should be done explicitly in hope, that users
> understand what's going on :-)

This is why I changed _hosts to generate a hosts array from /etc/hosts
if $hosts is unset. This may not work perfectly on all systems but it's
better than just assuming $hosts is set and can always be improved
later. Following is a patch so _rlogin and _x_options use _hosts - I
must have forgotten to do this before. The patch to _x_options also
causes it to only complete options on words starting with a '-'. I
prefer to complete options this way as it keeps the number of matches
down.

>  - _chown, _chgrp, _stty are too system dependent. It is better to not provide
> completion at all than provide completion that only partially works. I do not
> suggest removing them from distribution - but to not install them by default.

chown and chgrp will work on the vast majority of systems. They could
certainly be improved to generate a more reliable list of groups though.
Maybe stty can be improved by parsing the output of stty -a.

> To summarise - I firmly believe, that everything that gets installed must work
> "as is" on every system. Anything that works only on some systems or something
> that needs additional setup should only be installed explicitly.

Maybe we should put a note in one of the readmes to make it clear that
the functions may not work on all systems, maybe detailing which might
have issues. I find many of the functions enormously useful and it would
be a pity for them not to be used.

One thing which I just noticed which I don't think is right:
rlogin <tab>
zsh: do you wish to see all 114 possibilities? n
The no returns to 'rlogin ' on the command-line. now, if I press tab
again, menu completion
starts. I think it should ignore the original tab if the question was
answered with no.

Oliver Kiddle

*** Completion/User/_rlogin.old	Wed Jul 14 12:36:32 1999
--- Completion/User/_rlogin	Wed Jul 14 12:37:42 1999
***************
*** 1,7 ****
  #compdef rlogin rsh ssh
  
  if [[ CURRENT -eq 2 ]]; then
!   compgen -k hosts
  elif [[ CURRENT -eq 3 ]]; then
    compadd - -l
  else
--- 1,7 ----
  #compdef rlogin rsh ssh
  
  if [[ CURRENT -eq 2 ]]; then
!   _hosts
  elif [[ CURRENT -eq 3 ]]; then
    compadd - -l
  else
*** Completion/User/_x_options.old	Wed Jul 14 12:36:39 1999
--- Completion/User/_x_options	Wed Jul 14 12:37:42 1999
***************
*** 3,9 ****
  # A simple pattern completion, just as an example.
  
  if [ "$words[CURRENT-1]" = "-display" ]; then
!   compgen -k hosts -S':0'
  else
!   compadd -J options - -display -name -xrm
  fi
--- 3,9 ----
  # A simple pattern completion, just as an example.
  
  if [ "$words[CURRENT-1]" = "-display" ]; then
!   ISUFFIX=':0' _hosts
  else
!   compadd -P- -J options - display name xrm
  fi

Re: Completion/User functions again

[Oliver Kiddle]

Sven Wischnowsky wrote:

> I've been thinking about this for a long time, too. The problems are
> that we would have to fill those directories (so that they don't look

I don't think it would matter too much if they were on the empty side
while we are still on version 3.1.x.

> silly) and with such directories users would expect to need only to
> copy the contents of one such directory (or link User to it), so they
> would have to be (almost) complete. That's a lot of work and who'll do
> that, I wonder.

Linking User to the directory probably wouldn't be the best approach
because there are many commands for which the completion won't be system
specific. I would go for an approach similar to that for installing
modules so users can add directories to install to a file listing the
completion directories. The configure script could possibly be enhanced
to intelligently add any appropriate directories. I would also subdivide
the User directory a little. For example if all the X programs were in
their own directory then they could be excluded on a system which lacks
X. We might later add directories for obscure software which would only
be relevant to a small number of users. This is a large reason why I
prefer the directories to be preserved with the installation (via
--enable-function-subdirs) and think it should be the default.

> While we are at it: we still don't have completion functions for some
> commands for which we have compctl examples, e.g. cvs and rpm. I don't
> use either of these often enough to be able to write good functions
> for them -- any volunteers for that?

I don't use rpm or cvs either so I won't volunteer for those but there
are many other programs for which I plan to write completions - I had an
enormous number of tcsh completes which I have yet to convert to zsh.
I've got a few IRIX/AIX specific ones which I'll contribute if and when
we have directories set up to accomodate them.

> Maybe we should add some kind of programming style guide some day,
> containing things like `make functions that can be used as helper
> functions do something useful with their arguments if possible' and
> `do not use compgen if you're only after the -k or -s options'
> (compadd is faster and -- I think -- cleaner for this).

A programming style guide would certainly be a good idea and its
usefulness would not be limited to writing zsh completions. It might be
a good idea to start one off as a simple text file, listing key points
particularly any which aren't immediately obvious like the compadd
point. We can always convert it to LaTeX/yodl/texinfo/whatever and
expand it into a readable document later.

Oliver Kiddle