Re: Moving completion functions

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

[Answering Oliver and Bart here, I'll shuffle things around a bit,
 simple stuff first.]


There are 84 functions in Unix/Command.

In the first version of the script I held myself back when thinking
about renaming files, that was probably wrong. Comments about the
files/directories that have been mentioned:

- I hadn't thought about using Zsh/Command. I like that. I'll use it.
- _vars_eq will become _typeset
- I can also put _dict_words into a separate function (compared to the 
  whole thing that extra bit of work doesn't count)
- I don't think _diff_options should be in Utility, after all, it
  completes a certain type of matches.
- _dirs becomes _directories, ok (I think this is one of the oldest
  functions -- hmm, the memories...)
- I was wondering if _mere is for the function or for some command I
  don't know...
- _mysql_utils should probably keep it's name. I think this was
  modelled after _psutils and _xutils. Those two should then be
  renamed to _ps_utils and _x_utils.
- move _gv, _nedit and _netscape to X/Command
- _pdf to User/Type (there I just pasted the wrong directory)
- _use_lo should get a better name, yes. Hm, I don't like mixing the
  underscore-style we use with hyphens in function names, and anyway I
  prefer _parse_help (or _options_from__help?)
- I'll change _(un|)set_options and _[fb]g_jobs.
- We could also change _call to _call_program and _funcall to
  _call_function.
- And there could be a better name for _compalso.
- _all_matches can stay as it is, I think, because this is a
   completer and those are more equal than the other animals.
- Btw: I thought about _oldlist -> _old_list, but since people might 
  have that in their .zshrc's...
- For the label functions (and the tag functions) I think we should
  either leave them or try to find names that are both readable and
  have the sorting behaviour Bart wants (and not only he, I like that, 
  too). So...

    _tags        _tags
    _wanted      _tag_wanted
    _requested   _tag_requested or _tag_selected
    _all_labels  _labels_for
    _next_label  _label_selected

  (These are used as in:

     _tags <tags...>
     while _tags; do ... done

     _tag_wanted <tag> <var> <descr> <cmd...>

     if _tag_selected <tag> ...; then ... fi

     _labels_for <tag> <var> <descr> <cmd...>

     while _label_selected <tag> <var> <descr>; do ... done
  )

  Would that be acceptable?  Lotsa changes...


Now to the other things...


Oliver Kiddle wrote:

> ...
> 
> My preference would be for the lowest level to be removed leaving
> directories for AIX, Linux, Zsh etc but not having directories for
> Type, Command etc. [...]

Like Bart I like this idea.

> Is it only me who uses
> --enable-function-subdirs? [...]

You're not alone.

Bart wrote:

> [...] On the
> other hand, the only reason I can see for splitting Unix/Command into
> more specific directories would be for selective installation, and I'm
> not sure that's important enough.

Yes, I wasn't sure either (obviously).  One gets functions for
commands one doesn't have... so what.  It only gets interesting if we
start writing different versions of certain functions (like the
_path_files-for-cygwin Bart mentioned) or if we want to put different
functions for the same command into different directories (as mentioned 
by Oliver).  That's the old problem which we've never solved.
Currently we put the different versions in the same file in the User
directory and decide there and then what to do.  I think this approach 
is better than using different files as long as there aren't too many
versions to support (although it'll look very wrong if we ever find
commands with the same name that do completely different things on
different systems).  My first reflex is to postpone this decision
until we run into serious problems.  Then we can start thinking about
a convention for dealing with different versions of one command and
about a way to configure this so that the right files will be
installed or loaded.  I just hope we can make sure that the directory
structure we build up now is able to deal with such possible changes.
But there's probably no way to ensure that if we don't decide now.


Oliver:

> For this reason, I think a Network directory is a good idea because it
> is quite possible to have a computer which is not connected to the
> network so all the networking related stuff are of no use. The X
> division is I think useful. 

If we remove the second level on installation, this should be a
first-level directory like X, though.  And there's even stuff to fill
a Network/Type directory.

> Graphic and Sound is a more complex issue
> because you might care about programs which manipulate sound files or
> images but not have the ability to play or display them.

Yes, similar foe Network if it's a first level directory.  There are
network commands that need X and ones that don't.

> Another
> possbile division would be for commands which are related to sysadmin
> such as those which are only likely to be in root's path.

Hmhm.


Considering this discussion (and that today is Friday) I think I'll
better not start on Monday...


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx