Re: Moving completion functions

Re: Moving completion functions

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> I don't particularly object, but it doesn't seem to me to be necessary.
> If the issue is having "room" in a section for more than 100 test files,
> just use three digits instead of two after the letter; surely no section
> is ever going to need more than 1000 files?!?

I was mostly thinking about a) ensuring that the tests for zle are run 
before those for completion without having to start numbering at `50'
or whatever and b) leaving room after all the basic shell stuff for
user contributions and whatnot.

The script below now does that, using only upper-case letters.

I'll do a dry run on my laptop at the weekend and look through it
again.  And if I don't get any more comments until monday, I'll
probably run it then -- after sending a note to the list.  At least I
have the impression that the dust has settled now, right?

Bye
 Sven


move2() {
  perl -ne \
    's/\b_set_options\b/_options_set/g;
     s/\b_unset_options\b/_options_unset/g;
     s/\b_popd\b/_directory_stack/g;
     s/\b_call\b/_call_program/g;
     s/\b_funcall\b/_call_function/g;
     s/\b_compalso\b/_contexts/g;
     print' $1 > $2
}


move1() {
  local name dir1 dir2

  name=${1:t}
  [[ $2 = */*/* && $2 != */*/*/* ]] && 2=${2}/${name}

  if [[ ! -f $1 ]]; then
    if [[ -f $2 ]]; then
      echo $1 already moved to $2
      return
    else
      echo ERROR: $1 does not exist
      return
    fi
  fi

  echo moving $1 to $2

  dir2=${2:h}
  dir1=${dir2:h}

  if [[ ! -d $dir1 ]]; then
    echo new directory $dir1
    mkdir $dir1
    echo "  cvs add    $dir1"
    cvs add $dir1
    echo "  cvs commit $dir1"
    cvs commit -m 'new completion directory' $dir1
  fi

  if [[ ! -d $dir2 ]]; then
    echo new directory $dir2
    mkdir $dir2
    echo "  cvs add    $dir2"
    cvs add $dir2
    echo "  cvs commit $dir2"
    cvs commit -m 'new completion directory' $dir2
  fi

  move2 $1 $2
  chmod 600 $2
  rm $1

  echo "  cvs remove $1"
  cvs remove $1
  echo "  cvs commit $1"
  cvs commit -m "moved to $2" $1

  echo "  cvs add    $2"
  cvs add $2
  echo "  cvs commit $2"
  cvs commit -m "moved from $1" $2
}


# Overall structure:
#
# Completion
#   comp{init,install,...}
#   Base
#     Core        basic functions
#     Completer   completers
#     Utility     utility functions (_arguments,...)
#     Widget      bindable commands
#   Zsh
#     Type        types of matches
#     Context     special contexts
#     Command     builtins and functions
#   Unix
#     Type
#     Command
#   X/AIX/BSD/Debian/Redhat
#     Utility
#     Type
#     Command


files=(

## Completion

Core/compaudit                  compaudit
Core/compdump                   compdump
Core/compinit                   compinit
Core/compinstall                compinstall

Core/_all_labels                Base/Core
Core/_description               Base/Core
Core/_main_complete             Base/Core
Core/_message                   Base/Core
Core/_next_label                Base/Core
Core/_normal                    Base/Core
Core/_requested                 Base/Core
Core/_setup                     Base/Core
Core/_tags                      Base/Core
Core/_wanted                    Base/Core
Core/_all_matches               Base/Completer
Core/_approximate               Base/Completer
Core/_complete                  Base/Completer
Core/_correct                   Base/Completer
Core/_expand                    Base/Completer
Core/_expand_alias              Base/Completer
Core/_history                   Base/Completer
Core/_ignored                   Base/Completer
Core/_list                      Base/Completer
Core/_match                     Base/Completer
Core/_menu                      Base/Completer
Core/_oldlist                   Base/Completer
Core/_prefix                    Base/Completer
Base/_arg_compile               Base/Utility
Base/_arguments                 Base/Utility
Base/_cache_invalid             Base/Utility
Base/_combination               Base/Utility
Core/_compalso                  Base/Utility/_contexts
Base/_describe                  Base/Utility
Base/_regex_arguments           Base/Utility
Base/_retrieve_cache            Base/Utility
Base/_store_cache               Base/Utility
Base/_sub_commands              Base/Utility
Base/_values                    Base/Utility
Builtins/_nothing               Base/Utility
Core/_alternative               Base/Utility
Core/_multi_parts               Base/Utility
Core/_sep_parts                 Base/Utility
Core/_funcall                   Base/Utility/_call_function
Core/_call                      Base/Utility/_call_program
Commands/_bash_completions      Base/Widget
Commands/_complete_debug        Base/Widget
Commands/_complete_help         Base/Widget
Commands/_complete_tag          Base/Widget
Commands/_correct_filename      Base/Widget
Commands/_correct_word          Base/Widget
Commands/_expand_word           Base/Widget
Commands/_generic               Base/Widget
Commands/_history_complete_word Base/Widget
Commands/_most_recent_file      Base/Widget
Commands/_next_tags             Base/Widget
Commands/_read_comp             Base/Widget

Base/_command_names             Zsh/Type
Base/_jobs                      Zsh/Type
Builtins/_aliases               Zsh/Type
Builtins/_arrays                Zsh/Type
Builtins/_functions             Zsh/Type
Builtins/_limits                Zsh/Type
Builtins/_vars                  Zsh/Type
Core/_file_descriptors          Zsh/Type
Core/_options                   Zsh/Type
Core/_parameters                Zsh/Type
Builtins/_popd                  Zsh/Type/_directory_stack
Builtins/_bg_jobs               Zsh/Type/_jobs_bg
Builtins/_fg_jobs               Zsh/Type/_jobs_fg
Core/_set_options               Zsh/Type/_options_set
Core/_unset_options             Zsh/Type/_options_unset
Base/_brace_parameter           Zsh/Context
Base/_condition                 Zsh/Context
Base/_default                   Zsh/Context
Base/_equal                     Zsh/Context
Base/_first                     Zsh/Context
Base/_in_vared                  Zsh/Context
Base/_math                      Zsh/Context
Base/_parameter                 Zsh/Context
Base/_redirect                  Zsh/Context
Base/_subscript                 Zsh/Context
Base/_tilde                     Zsh/Context
Base/_value                     Zsh/Context
Base/_precommand                Zsh/Command
Builtins/_autoload              Zsh/Command
Builtins/_bindkey               Zsh/Command
Builtins/_builtin               Zsh/Command
Builtins/_cd                    Zsh/Command
Builtins/_command               Zsh/Command
Builtins/_compdef               Zsh/Command
Builtins/_disable               Zsh/Command
Builtins/_echotc                Zsh/Command
Builtins/_emulate               Zsh/Command
Builtins/_enable                Zsh/Command
Builtins/_fc                    Zsh/Command
Builtins/_hash                  Zsh/Command
Builtins/_kill                  Zsh/Command
Builtins/_print                 Zsh/Command
Builtins/_read                  Zsh/Command
Builtins/_sched                 Zsh/Command
Builtins/_set                   Zsh/Command
Builtins/_setopt                Zsh/Command
Builtins/_source                Zsh/Command
Builtins/_stat                  Zsh/Command
Builtins/_trap                  Zsh/Command
Builtins/_unhash                Zsh/Command
Builtins/_unsetopt              Zsh/Command
Builtins/_wait                  Zsh/Command
Builtins/_which                 Zsh/Command
Builtins/_zcompile              Zsh/Command
Builtins/_zftp                  Zsh/Command
Builtins/_zle                   Zsh/Command
Builtins/_zmodload              Zsh/Command
Builtins/_zpty                  Zsh/Command
Builtins/_zstyle                Zsh/Command
User/_mere                      Zsh/Command
User/_prompt                    Zsh/Command
Builtins/_vars_eq               Zsh/Command/_typeset

Builtins/_pids                  Unix/Type
Builtins/_signals               Unix/Type
Core/_files                     Unix/Type
Core/_path_files                Unix/Type
User/_diff_options              Unix/Type
User/_dir_list                  Unix/Type
User/_domains                   Unix/Type
User/_groups                    Unix/Type
User/_hosts                     Unix/Type
User/_mailboxes                 Unix/Type
User/_my_accounts               Unix/Type
User/_newsgroups                Unix/Type
User/_other_accounts            Unix/Type
User/_pdf                       Unix/Type
User/_perl_basepods             Unix/Type
User/_perl_builtin_funcs        Unix/Type
User/_perl_modules              Unix/Type
User/_ports                     Unix/Type
User/_printers                  Unix/Type
User/_ps                        Unix/Type
User/_pspdf                     Unix/Type
User/_tar_archive               Unix/Type
User/_tex                       Unix/Type
User/_texi                      Unix/Type
User/_tilde_files               Unix/Type
User/_urls                      Unix/Type
User/_user_at_host              Unix/Type
User/_users                     Unix/Type
User/_users_on                  Unix/Type
User/_dirs                      Unix/Type/_directories
User/_a2ps                      Unix/Command
User/_apachectl                 Unix/Command
User/_archie                    Unix/Command
User/_arp                       Unix/Command
User/_bison                     Unix/Command
User/_bzip2                     Unix/Command
User/_chown                     Unix/Command
User/_compress                  Unix/Command
User/_configure                 Unix/Command
User/_cpio                      Unix/Command
User/_cvs                       Unix/Command
User/_dd                        Unix/Command
User/_dict                      Unix/Command
User/_diff                      Unix/Command
User/_dvi                       Unix/Command
User/_enscript                  Unix/Command
User/_fakeroot                  Unix/Command
User/_fetchmail                 Unix/Command
User/_find                      Unix/Command
User/_finger                    Unix/Command
User/_flex                      Unix/Command
User/_gcc                       Unix/Command
User/_gdb                       Unix/Command
User/_getconf                   Unix/Command
User/_gprof                     Unix/Command
User/_grep                      Unix/Command
User/_gs                        Unix/Command
User/_gzip                      Unix/Command
User/_iconv                     Unix/Command
User/_imagemagick               Unix/Command
User/_init_d                    Unix/Command
User/_ispell                    Unix/Command
User/_java                      Unix/Command
User/_joe                       Unix/Command
User/_killall                   Unix/Command
User/_look                      Unix/Command
User/_lp                        Unix/Command
User/_ls                        Unix/Command
User/_lynx                      Unix/Command
User/_lzop                      Unix/Command
User/_make                      Unix/Command
User/_man                       Unix/Command
User/_mh                        Unix/Command
User/_mount                     Unix/Command
User/_mutt                      Unix/Command
User/_mysql_utils               Unix/Command
User/_ncftp                     Unix/Command
User/_nslookup                  Unix/Command
User/_pack                      Unix/Command
User/_patch                     Unix/Command
User/_pbm                       Unix/Command
User/_perl                      Unix/Command
User/_perldoc                   Unix/Command
User/_prcs                      Unix/Command
User/_psutils                   Unix/Command
User/_rcs                       Unix/Command
User/_rlogin                    Unix/Command
User/_sh                        Unix/Command
User/_slrn                      Unix/Command
User/_socket                    Unix/Command
User/_ssh                       Unix/Command
User/_strip                     Unix/Command
User/_stty                      Unix/Command
User/_su                        Unix/Command
User/_sudo                      Unix/Command
User/_tar                       Unix/Command
User/_telnet                    Unix/Command
User/_tiff                      Unix/Command
User/_tin                       Unix/Command
User/_w3m                       Unix/Command
User/_webbrowser                Unix/Command
User/_wget                      Unix/Command
User/_whereis                   Unix/Command
User/_whois                     Unix/Command
User/_xargs                     Unix/Command
User/_yodl                      Unix/Command
User/_yp                        Unix/Command
User/_zcat                      Unix/Command
User/_zdump                     Unix/Command
User/_zip                       Unix/Command
User/_use_lo                    Unix/Command/_gnu_generic

X/_x_borderwidth                X/Type
X/_x_color                      X/Type
X/_x_colormapid                 X/Type
X/_x_cursor                     X/Type
X/_x_display                    X/Type
X/_x_extension                  X/Type
X/_x_font                       X/Type
X/_x_geometry                   X/Type
X/_x_keysym                     X/Type
X/_x_locale                     X/Type
X/_x_modifier                   X/Type
X/_x_name                       X/Type
X/_x_resource                   X/Type
X/_x_selection_timeout          X/Type
X/_x_title                      X/Type
X/_x_window                     X/Type
X/_xt_session_id                X/Type
X/_x_arguments                  X/Utility
X/_xt_arguments                 X/Utility
User/_gv                        X/Command
User/_nedit                     X/Command
User/_netscape                  X/Command
X/_xauth                        X/Command
X/_xdvi                         X/Command
X/_xfig                         X/Command
X/_xmodmap                      X/Command
X/_xrdb                         X/Command
X/_xset                         X/Command
X/_xterm                        X/Command
X/_xv                           X/Command
X/_xwit                         X/Command
X/_xutils                       X/Command/_x_utils

AIX/_logical_volumes            AIX/Type
AIX/_object_classes             AIX/Type
AIX/_physical_volumes           AIX/Type
AIX/_volume_groups              AIX/Type
AIX/_floppy                     AIX/Command
AIX/_lscfg                      AIX/Command
AIX/_lsdev                      AIX/Command
AIX/_lslv                       AIX/Command
AIX/_lspv                       AIX/Command
AIX/_lsvg                       AIX/Command
AIX/_smit                       AIX/Command

Bsd/_bsd_pkg                    BSD/Command
Bsd/_cvsup                      BSD/Command
Bsd/_kld                        BSD/Command

Debian/_deb_packages            Debian/Type
Debian/_apt                     Debian/Command
Debian/_bug                     Debian/Command
Debian/_dpkg                    Debian/Command
Debian/_dupload                 Debian/Command
Debian/_dpkg-source             Debian/Command/_dpkg_source

Linux/_rpm                      Redhat/Command

## Other functions

Functions/Misc/acx		Functions/Example	# Misc?
Functions/Misc/allopt		Functions/Misc
Functions/Misc/cat		Functions/Example
Functions/Misc/cdmatch		Functions/Compctl
Functions/Misc/cdmatch2		Functions/Compctl
Functions/Misc/checkmail	Functions/Misc
Functions/Misc/colors		Functions/Misc
Functions/Misc/cx		Functions/Example	# Misc?
Functions/Misc/harden		Functions/Misc
Functions/Misc/is-at-least	Functions/Misc
Functions/Misc/mere		Functions/Misc
Functions/Misc/multicomp	Functions/Compctl
Functions/Misc/nslookup		Functions/Misc
Functions/Misc/promptnl		Functions/Misc
Functions/Misc/proto		Functions/Example
Functions/Misc/pushd		Functions/Example
Functions/Misc/randline		Functions/Example
Functions/Misc/run-help		Functions/Misc
Functions/Misc/yp		Functions/Example	# Misc?
Functions/Misc/yu		Functions/Example	# Misc?
Functions/Misc/zed		Functions/Misc
Functions/Misc/zkbd		Functions/Misc
Functions/Misc/zless		Functions/Example
Functions/Misc/zls		Functions/Example
Functions/Misc/zmv		Functions/Misc
Functions/Misc/zrecompile	Functions/Misc
Functions/Misc/zstyle+		Functions/Misc


## Test scripts

# Section A: basic command parsing and execution

Test/01grammar.ztst 	       	 Test/A01grammar.ztst
Test/02alias.ztst		 Test/A02alias.ztst
Test/03quoting.ztst		 Test/A03quoting.ztst
Test/04redirect.ztst		 Test/A04redirect.ztst
Test/05command.ztst		 Test/A05execution.ztst

# Section B: builtins

Test/50cd.ztst      	       	 Test/B01cd.ztst
# More, more, more

# Section C: shell commands with special syntax

Test/06arith.ztst		 Test/C01arith.ztst
Test/07cond.ztst		 Test/C02cond.ztst
Test/08traps.ztst		 Test/C03traps.ztst
Test/09funcdef.ztst		 Test/C04funcdef.ztst

# Section D: substititution

Test/10prompt.ztst		 Test/D01prompt.ztst
Test/11glob.ztst		 Test/D02glob.ztst
Test/12procsubst.ztst		 Test/D03procsubst.ztst
Test/13parameter.ztst		 Test/D04parameter.ztst
Test/14array.ztst		 Test/D05array.ztst

# Section E: options

# We need more tests here!  There was going to be an options test, but
# it's huge to write.

#                                [E01options.ztst]

Test/51xtrace.ztst		 Test/E02xtrace.ztst

# Section V: builtins

#				 [V01zmodload.ztst]

Test/52zregexparse.ztst		 Test/V02zregexparse.ztst

# Section W: builtin interactive commands and constructs

# Section X: line editing

# Section Y: completion

Test/53completion.ztst      	 Test/Y01completion.ztst
Test/54compmatch.ztst		 Test/Y02compmatch.ztst
Test/55arguments.ztst            Test/Y03arguments.ztst

# Section Z: separate systems and user contributions

#                                [Z01zftp.ztst ??]

)


move() {
  local i

  while (( $# )); do
    [[ $1 = (Functions|Test)/* ]]; then
      move1 ./$1 ./$2
    else
      move1 Completion/$1 Completion/$2
    fi
    shift 2
  done

  for i in Completion/*/*(/) Functions/*(/) Test
    print "DISTFILES_SRC='" >  $i/.distfiles
    print .distfiles        >> $i/.distfiles
    print -c $i/*(.N)        >> $i/.distfiles
    print "'"               >> $i/.distfiles
  done

  # Change:
  #   Completion/.distfiles
  #   Completion/compaudit
  #   Completion/compinstall
  #   Doc/Zsh/compsys.yo
  #   Doc/Zsh/contrib.yo
  #   Doc/Zsh/zftpsys.yo
  #   INSTALL
  #   Src/Zle/complete.mdd
  #   Test/ztst.zsh
  #   Etc/completion-style-guide
  #   _dict_words
  #   is-at-least
  #   _zed and _vared from 13827
  #   The Guide
}


echo updating
cvs update
echo adding tag
cvs tag pre-func-move .

move $files

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

Re: Moving completion functions

[Bart Schaefer]

On Mar 30,  4:00pm, Sven Wischnowsky wrote:
} 
} Bart Schaefer wrote:
} 
} > I don't particularly object, but it doesn't seem to me to be necessary.
} 
} I was mostly thinking about a) ensuring that the tests for zle are run 
} before those for completion without having to start numbering at `50'
} or whatever and b) leaving room after all the basic shell stuff for
} user contributions and whatnot.

ZLE is either a module (my section X) or an interactive feature that has
to be tested with zpty (section Y) both of which precede completion (Z).

But of course it doesn't hurt to break it down further, and a section
for other stuff at the end doesn't hurt either.
 
} # Section V: builtins

You mean modules?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Bart Schaefer]

On Mar 29, 11:33am, Sven Wischnowsky wrote:
} Subject: Re: Moving completion functions
}
} Felix Rosencrantz wrote:
} 
} > I've been busy and away, so I'm quite a bit behind on the mailing
} > list. But just wanted to stick my nose in.... It might be worth
} > splitting completion and the rest of zle in to separate sections.
} > Both of these modules represent a lot of space in the documentation
} > and code. Because there is a lot of code/functionality that can be
} > tested, it seems like it would be worthwhile to give each a separate
} > section.
}
} That sounds sensible.  Maybe start using lower-case letters for the
} parts that are big enough to be called `systems', i.e. completion and
} zftp and later probably more?

I don't particularly object, but it doesn't seem to me to be necessary.
If the issue is having "room" in a section for more than 100 test files,
just use three digits instead of two after the letter; surely no section
is ever going to need more than 1000 files?!?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> BTW, a remark on my sectioning scheme for the Test directory:  Section Y
> is for tests of builtin interactive commands/constructs (select, read -q,
> etc.) where the tests themselves need to use the zpty module, which will
> (eventually) have been tested in section X ...
> 
> We might want to add description of this naming to a Test/README or to the
> comments in ztst.zsh.

Hmhm.


Felix Rosencrantz wrote:

> ...
>
> I've been busy and away, so I'm quite a bit behind on the mailing list. But
> just wanted to stick my nose in....  It might be worth splitting completion and
> the rest of zle in to separate sections.  Both of these modules represent 
> a lot of space in the documentation and code.  Because there is a lot of
> code/functionality that can be tested, it seems like it would be worthwhile to
> give each a separate section.

That sounds sensible.  Maybe start using lower-case letters for the
parts that are big enough to be called `systems', i.e. completion and
zftp and later probably more?


Peter Stephenson wrote:

> ... [ _wanted and firends ]
> 
> In that case, better leave it, in case anyone's being looking at the user
> guide, which makes quite heavy use of _wanted.

That's fine with me.


and Bart again:

> I won't commit these yet (hence they're not presented in diff form); either
> Sven can add them at the Great Renaming, or I'll add them after it happens.

I've added that to the todo-list in the script.

> The only reason for using _arguments in fned is to get "no more arguments"
> behavior after the first name is completed; otherwise it could simply
> call _functions directly.

Or test [[ CURRENT -gt 2 ]] directly...


Bye
 Sven


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

Re: Moving completion functions

[Peter Stephenson]

Bart wrote:
> } And a better name for `_wanted' might be `_offer', but that doesn't
> } make it easier to find in a directory listing, of course.  Although it
> } would end up just before `_requested' and there are only twelve
> } functions in the directory anyway.
> 
> That one is a toss-up.  I don't know whether _offer is better than _wanted.
> The number of functions in the directory isn't an issue.

In that case, better leave it, in case anyone's being looking at the user
guide, which makes quite heavy use of _wanted.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Moving completion functions

[Bart Schaefer]

On Mar 28,  4:12pm, Sven Wischnowsky wrote:
}
} I really only have a suggestion for _compalso: putting it into
} Base/Utility and renaming it to `_contexts' because it completes
} everything for the context described in the arguments, just like
} _arguments and other functions in Utility.

That sounds like a fine idea to me.

} And a better name for `_wanted' might be `_offer', but that doesn't
} make it easier to find in a directory listing, of course.  Although it
} would end up just before `_requested' and there are only twelve
} functions in the directory anyway.

That one is a toss-up.  I don't know whether _offer is better than _wanted.
The number of functions in the directory isn't an issue.

} Twelve, unless we move the _call_* function into the Utility directory,
} too, which seems sensible, somehow.

Yes, that does seem sensible.

BTW, a remark on my sectioning scheme for the Test directory:  Section Y
is for tests of builtin interactive commands/constructs (select, read -q,
etc.) where the tests themselves need to use the zpty module, which will
(eventually) have been tested in section X ...

We might want to add description of this naming to a Test/README or to the
comments in ztst.zsh.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Moving completion functions

[Sven Wischnowsky]

Here's the latest version of the script.

The things left to decide are (if I'm not mistaken) the names of some
of the functions.

I really only have a suggestion for _compalso: putting it into
Base/Utility and renaming it to `_contexts' because it completes
everything for the context described in the arguments, just like
_arguments and other functions in Utility.

And a better name for `_wanted' might be `_offer', but that doesn't
make it easier to find in a directory listing, of course.  Although it
would end up just before `_requested' and there are only twelve
functions in the directory anyway.

Twelve, unless we move the _call_* function into the Utility directory,
too, which seems sensible, somehow.


I've rearranged the functions, sorted by their new position.


Bye
 Sven


move2() {
  perl -ne \
    's/\b_set_options\b/_options_set/g;
     s/\b_unset_options\b/_options_unset/g;
     s/\b_popd\b/_directory_stack/g;
     s/\b_call\b/_call_program/g;
     s/\b_funcall\b/_call_function/g;
     print' $1 > $2
}


move1() {
  local name dir1 dir2

  name=${1:t}
  [[ $2 = */*/* && $2 != */*/*/* ]] && 2=${2}/${name}

  if [[ ! -f $1 ]]; then
    if [[ -f $2 ]]; then
      echo $1 already moved to $2
      return
    else
      echo ERROR: $1 does not exist
      return
    fi
  fi

  echo moving $1 to $2

  dir2=${2:h}
  dir1=${dir2:h}

  if [[ ! -d $dir1 ]]; then
    echo new directory $dir1
    mkdir $dir1
    echo "  cvs add    $dir1"
    cvs add $dir1
    echo "  cvs commit $dir1"
    cvs commit -m 'new completion directory' $dir1
  fi

  if [[ ! -d $dir2 ]]; then
    echo new directory $dir2
    mkdir $dir2
    echo "  cvs add    $dir2"
    cvs add $dir2
    echo "  cvs commit $dir2"
    cvs commit -m 'new completion directory' $dir2
  fi

  move2 $1 $2
  chmod 600 $2
  rm $1

  echo "  cvs remove $1"
  cvs remove $1
  echo "  cvs commit $1"
  cvs commit -m "moved to $2" $1

  echo "  cvs add    $2"
  cvs add $2
  echo "  cvs commit $2"
  cvs commit -m "moved from $1" $2
}


# Overall structure:
#
# Completion
#   comp{init,install,...}
#   Base
#     Core        basic functions
#     Completer   completers
#     Utility     utility functions (_arguments,...)
#     Widget      bindable commands
#   Zsh
#     Type        types of matches
#     Context     special contexts
#     Command     builtins and functions
#   Unix
#     Type
#     Command
#   X/AIX/BSD/Debian/Redhat
#     Utility
#     Type
#     Command


files=(

## Completion

Core/compaudit                  compaudit
Core/compdump                   compdump
Core/compinit                   compinit
Core/compinstall                compinstall

Core/_all_labels                Base/Core
Core/_compalso                  Base/Core
Core/_description               Base/Core
Core/_main_complete             Base/Core
Core/_message                   Base/Core
Core/_next_label                Base/Core
Core/_normal                    Base/Core
Core/_requested                 Base/Core
Core/_setup                     Base/Core
Core/_tags                      Base/Core
Core/_wanted                    Base/Core
Core/_funcall                   Base/Core/_call_function
Core/_call                      Base/Core/_call_program
Core/_all_matches               Base/Completer
Core/_approximate               Base/Completer
Core/_complete                  Base/Completer
Core/_correct                   Base/Completer
Core/_expand                    Base/Completer
Core/_expand_alias              Base/Completer
Core/_history                   Base/Completer
Core/_ignored                   Base/Completer
Core/_list                      Base/Completer
Core/_match                     Base/Completer
Core/_menu                      Base/Completer
Core/_oldlist                   Base/Completer
Core/_prefix                    Base/Completer
Base/_arg_compile               Base/Utility
Base/_arguments                 Base/Utility
Base/_cache_invalid             Base/Utility
Base/_combination               Base/Utility
Base/_describe                  Base/Utility
Base/_regex_arguments           Base/Utility
Base/_retrieve_cache            Base/Utility
Base/_store_cache               Base/Utility
Base/_sub_commands              Base/Utility
Base/_values                    Base/Utility
Builtins/_nothing               Base/Utility
Core/_alternative               Base/Utility
Core/_multi_parts               Base/Utility
Core/_sep_parts                 Base/Utility
Commands/_bash_completions      Base/Widget
Commands/_complete_debug        Base/Widget
Commands/_complete_help         Base/Widget
Commands/_complete_tag          Base/Widget
Commands/_correct_filename      Base/Widget
Commands/_correct_word          Base/Widget
Commands/_expand_word           Base/Widget
Commands/_generic               Base/Widget
Commands/_history_complete_word Base/Widget
Commands/_most_recent_file      Base/Widget
Commands/_next_tags             Base/Widget
Commands/_read_comp             Base/Widget

Base/_command_names             Zsh/Type
Base/_jobs                      Zsh/Type
Builtins/_aliases               Zsh/Type
Builtins/_arrays                Zsh/Type
Builtins/_functions             Zsh/Type
Builtins/_limits                Zsh/Type
Builtins/_vars                  Zsh/Type
Core/_file_descriptors          Zsh/Type
Core/_options                   Zsh/Type
Core/_parameters                Zsh/Type
Builtins/_popd                  Zsh/Type/_directory_stack
Builtins/_bg_jobs               Zsh/Type/_jobs_bg
Builtins/_fg_jobs               Zsh/Type/_jobs_fg
Core/_set_options               Zsh/Type/_options_set
Core/_unset_options             Zsh/Type/_options_unset
Base/_brace_parameter           Zsh/Context
Base/_condition                 Zsh/Context
Base/_default                   Zsh/Context
Base/_equal                     Zsh/Context
Base/_first                     Zsh/Context
Base/_in_vared                  Zsh/Context
Base/_math                      Zsh/Context
Base/_parameter                 Zsh/Context
Base/_redirect                  Zsh/Context
Base/_subscript                 Zsh/Context
Base/_tilde                     Zsh/Context
Base/_value                     Zsh/Context
Base/_precommand                Zsh/Command
Builtins/_autoload              Zsh/Command
Builtins/_bindkey               Zsh/Command
Builtins/_builtin               Zsh/Command
Builtins/_cd                    Zsh/Command
Builtins/_command               Zsh/Command
Builtins/_compdef               Zsh/Command
Builtins/_disable               Zsh/Command
Builtins/_echotc                Zsh/Command
Builtins/_emulate               Zsh/Command
Builtins/_enable                Zsh/Command
Builtins/_fc                    Zsh/Command
Builtins/_hash                  Zsh/Command
Builtins/_kill                  Zsh/Command
Builtins/_print                 Zsh/Command
Builtins/_read                  Zsh/Command
Builtins/_sched                 Zsh/Command
Builtins/_set                   Zsh/Command
Builtins/_setopt                Zsh/Command
Builtins/_source                Zsh/Command
Builtins/_stat                  Zsh/Command
Builtins/_trap                  Zsh/Command
Builtins/_unhash                Zsh/Command
Builtins/_unsetopt              Zsh/Command
Builtins/_wait                  Zsh/Command
Builtins/_which                 Zsh/Command
Builtins/_zcompile              Zsh/Command
Builtins/_zftp                  Zsh/Command
Builtins/_zle                   Zsh/Command
Builtins/_zmodload              Zsh/Command
Builtins/_zpty                  Zsh/Command
Builtins/_zstyle                Zsh/Command
User/_mere                      Zsh/Command
User/_prompt                    Zsh/Command
Builtins/_vars_eq               Zsh/Command/_typeset

Builtins/_pids                  Unix/Type
Builtins/_signals               Unix/Type
Core/_files                     Unix/Type
Core/_path_files                Unix/Type
User/_diff_options              Unix/Type
User/_dir_list                  Unix/Type
User/_domains                   Unix/Type
User/_groups                    Unix/Type
User/_hosts                     Unix/Type
User/_mailboxes                 Unix/Type
User/_my_accounts               Unix/Type
User/_newsgroups                Unix/Type
User/_other_accounts            Unix/Type
User/_pdf                       Unix/Type
User/_perl_basepods             Unix/Type
User/_perl_builtin_funcs        Unix/Type
User/_perl_modules              Unix/Type
User/_ports                     Unix/Type
User/_printers                  Unix/Type
User/_ps                        Unix/Type
User/_pspdf                     Unix/Type
User/_tar_archive               Unix/Type
User/_tex                       Unix/Type
User/_texi                      Unix/Type
User/_tilde_files               Unix/Type
User/_urls                      Unix/Type
User/_user_at_host              Unix/Type
User/_users                     Unix/Type
User/_users_on                  Unix/Type
User/_dirs                      Unix/Type/_directories
User/_a2ps                      Unix/Command
User/_apachectl                 Unix/Command
User/_archie                    Unix/Command
User/_arp                       Unix/Command
User/_bison                     Unix/Command
User/_bzip2                     Unix/Command
User/_chown                     Unix/Command
User/_compress                  Unix/Command
User/_configure                 Unix/Command
User/_cpio                      Unix/Command
User/_cvs                       Unix/Command
User/_dd                        Unix/Command
User/_dict                      Unix/Command
User/_diff                      Unix/Command
User/_dvi                       Unix/Command
User/_enscript                  Unix/Command
User/_fakeroot                  Unix/Command
User/_fetchmail                 Unix/Command
User/_find                      Unix/Command
User/_finger                    Unix/Command
User/_flex                      Unix/Command
User/_gcc                       Unix/Command
User/_gdb                       Unix/Command
User/_getconf                   Unix/Command
User/_gprof                     Unix/Command
User/_grep                      Unix/Command
User/_gs                        Unix/Command
User/_gzip                      Unix/Command
User/_iconv                     Unix/Command
User/_imagemagick               Unix/Command
User/_init_d                    Unix/Command
User/_ispell                    Unix/Command
User/_java                      Unix/Command
User/_joe                       Unix/Command
User/_killall                   Unix/Command
User/_look                      Unix/Command
User/_lp                        Unix/Command
User/_ls                        Unix/Command
User/_lynx                      Unix/Command
User/_lzop                      Unix/Command
User/_make                      Unix/Command
User/_man                       Unix/Command
User/_mh                        Unix/Command
User/_mount                     Unix/Command
User/_mutt                      Unix/Command
User/_mysql_utils               Unix/Command
User/_ncftp                     Unix/Command
User/_nslookup                  Unix/Command
User/_pack                      Unix/Command
User/_patch                     Unix/Command
User/_pbm                       Unix/Command
User/_perl                      Unix/Command
User/_perldoc                   Unix/Command
User/_prcs                      Unix/Command
User/_psutils                   Unix/Command
User/_rcs                       Unix/Command
User/_rlogin                    Unix/Command
User/_sh                        Unix/Command
User/_slrn                      Unix/Command
User/_socket                    Unix/Command
User/_ssh                       Unix/Command
User/_strip                     Unix/Command
User/_stty                      Unix/Command
User/_su                        Unix/Command
User/_sudo                      Unix/Command
User/_tar                       Unix/Command
User/_telnet                    Unix/Command
User/_tiff                      Unix/Command
User/_tin                       Unix/Command
User/_w3m                       Unix/Command
User/_webbrowser                Unix/Command
User/_wget                      Unix/Command
User/_whereis                   Unix/Command
User/_whois                     Unix/Command
User/_xargs                     Unix/Command
User/_yodl                      Unix/Command
User/_yp                        Unix/Command
User/_zcat                      Unix/Command
User/_zdump                     Unix/Command
User/_zip                       Unix/Command
User/_use_lo                    Unix/Command/_gnu_generic

X/_x_borderwidth                X/Type
X/_x_color                      X/Type
X/_x_colormapid                 X/Type
X/_x_cursor                     X/Type
X/_x_display                    X/Type
X/_x_extension                  X/Type
X/_x_font                       X/Type
X/_x_geometry                   X/Type
X/_x_keysym                     X/Type
X/_x_locale                     X/Type
X/_x_modifier                   X/Type
X/_x_name                       X/Type
X/_x_resource                   X/Type
X/_x_selection_timeout          X/Type
X/_x_title                      X/Type
X/_x_window                     X/Type
X/_xt_session_id                X/Type
X/_x_arguments                  X/Utility
X/_xt_arguments                 X/Utility
User/_gv                        X/Command
User/_nedit                     X/Command
User/_netscape                  X/Command
X/_xauth                        X/Command
X/_xdvi                         X/Command
X/_xfig                         X/Command
X/_xmodmap                      X/Command
X/_xrdb                         X/Command
X/_xset                         X/Command
X/_xterm                        X/Command
X/_xv                           X/Command
X/_xwit                         X/Command
X/_xutils                       X/Command/_x_utils

AIX/_logical_volumes            AIX/Type
AIX/_object_classes             AIX/Type
AIX/_physical_volumes           AIX/Type
AIX/_volume_groups              AIX/Type
AIX/_floppy                     AIX/Command
AIX/_lscfg                      AIX/Command
AIX/_lsdev                      AIX/Command
AIX/_lslv                       AIX/Command
AIX/_lspv                       AIX/Command
AIX/_lsvg                       AIX/Command
AIX/_smit                       AIX/Command

Bsd/_bsd_pkg                    BSD/Command
Bsd/_cvsup                      BSD/Command
Bsd/_kld                        BSD/Command

Debian/_deb_packages            Debian/Type
Debian/_apt                     Debian/Command
Debian/_bug                     Debian/Command
Debian/_dpkg                    Debian/Command
Debian/_dupload                 Debian/Command
Debian/_dpkg-source             Debian/Command/_dpkg_source

Linux/_rpm                      Redhat/Command

## Other functions

Functions/Misc/acx		Functions/Example	# Misc?
Functions/Misc/allopt		Functions/Misc
Functions/Misc/cat		Functions/Example
Functions/Misc/cdmatch		Functions/Compctl
Functions/Misc/cdmatch2		Functions/Compctl
Functions/Misc/checkmail	Functions/Misc
Functions/Misc/colors		Functions/Misc
Functions/Misc/cx		Functions/Example	# Misc?
Functions/Misc/harden		Functions/Misc
Functions/Misc/is-at-least	Functions/Misc
Functions/Misc/mere		Functions/Misc
Functions/Misc/multicomp	Functions/Compctl
Functions/Misc/nslookup		Functions/Misc
Functions/Misc/promptnl		Functions/Misc
Functions/Misc/proto		Functions/Example
Functions/Misc/pushd		Functions/Example
Functions/Misc/randline		Functions/Example
Functions/Misc/run-help		Functions/Misc
Functions/Misc/yp		Functions/Example	# Misc?
Functions/Misc/yu		Functions/Example	# Misc?
Functions/Misc/zed		Functions/Misc
Functions/Misc/zkbd		Functions/Misc
Functions/Misc/zless		Functions/Example
Functions/Misc/zls		Functions/Example
Functions/Misc/zmv		Functions/Misc
Functions/Misc/zrecompile	Functions/Misc
Functions/Misc/zstyle+		Functions/Misc


## Test scripts

# Section A: basic command parsing and execution

Test/01grammar.ztst 	       	 Test/A01grammar.ztst
Test/02alias.ztst		 Test/A02alias.ztst
Test/03quoting.ztst		 Test/A03quoting.ztst
Test/04redirect.ztst		 Test/A04redirect.ztst
Test/05command.ztst		 Test/A05execution.ztst

# Section B: builtins

Test/50cd.ztst      	       	 Test/B01cd.ztst
# More, more, more

# Section C: shell commands with special syntax

Test/06arith.ztst		 Test/C01arith.ztst
Test/07cond.ztst		 Test/C02cond.ztst
Test/08traps.ztst		 Test/C03traps.ztst
Test/09funcdef.ztst		 Test/C04funcdef.ztst

# Section D: substititution

Test/10prompt.ztst		 Test/D01prompt.ztst
Test/11glob.ztst		 Test/D02glob.ztst
Test/12procsubst.ztst		 Test/D03procsubst.ztst
Test/13parameter.ztst		 Test/D04parameter.ztst
Test/14array.ztst		 Test/D05array.ztst

# Section E: options

# We need more tests here!  There was going to be an options test, but
# it's huge to write.

#                                [E01options.ztst]

Test/51xtrace.ztst		 Test/E02xtrace.ztst

# Section X: builtins

#				 [X01zmodload.ztst]

Test/52zregexparse.ztst		 Test/X02zregexparse.ztst

# Section Z: line editing and completion

Test/53completion.ztst      	 Test/Z01completion.ztst
Test/54compmatch.ztst		 Test/Z02compmatch.ztst
Test/55arguments.ztst            Test/Z03arguments.ztst

)


move() {
  local i

  while (( $# )); do
    [[ $1 = (Functions|Test)/* ]]; then
      move1 ./$1 ./$2
    else
      move1 Completion/$1 Completion/$2
    fi
    shift 2
  done

  for i in Completion/*/*(/) Functions/*(/) Test
    print "DISTFILES_SRC='" >  $i/.distfiles
    print .distfiles        >> $i/.distfiles
    print -c $i/*(.N)        >> $i/.distfiles
    print "'"               >> $i/.distfiles
  done

  # Change:
  #   Completion/.distfiles
  #   Completion/compaudit
  #   Completion/compinstall
  #   Doc/Zsh/compsys.yo
  #   Doc/Zsh/contrib.yo
  #   Doc/Zsh/zftpsys.yo
  #   INSTALL
  #   Src/Zle/complete.mdd
  #   Test/ztst.zsh
  #   Etc/completion-style-guide
  #   _dict_words
  #   is-at-least
  #   The Guide
}


echo updating
cvs update
echo adding tag
cvs tag pre-func-move .

move $files

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

Re: Moving completion functions

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> Finally, there was a mention at some point about changing the letters
> of some compadd options as we were originally constrained by
> consistency with compgen which had many of the old compctl options. Was
> this ever done or looked in to? I suppose we still have compctl but
> some could be better like -J and -V.

See 8866, 13472 and 13494.

I'm not sure how many users might have used compadd by now.  Also I'm
not sure if I want to go through all completion functions to change
the option names used there.  Oh, you meant to volunteer? ;-)

Bye
 Sven


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

Re: Moving completion functions

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> > The only way is to "zcompile -z" the whole thing and then put the .zwc
> > file in fpath.  This has been mentioned before (it may even be in the
> > docs somewhere).
> 
> I couldn't see it in the docs but these things aren't so easy to find.
> If it gets asked much, we can always add it to the FAQ.

For the completion system it's documented in zshcompsys at the end of
the `Autoloaded files' section.


Bye
 Sven


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

Re: Moving completion functions

[Bart Schaefer]

(Gotta find some more zsh-workers in my timezone.  Half the time I feel
like I'm talking to myself.  "... and the award for the most consecutive
messages to zsh-workers, none intercepted, goes to ...")

On Mar 25,  4:26pm, Oliver Kiddle wrote:
} Subject: Re: Moving completion functions
}
} Bart wrote:
} > I'd actually rather split compctl-examples up into smaller files and put
} > them all in Functions/Compctl, but I suppose we're trying to discourage
} > use of compctl ...
} 
} That's not a bad idea. They'd be out of the way in the Compctl directory
} so I don't think it would be too much of an encouragement.

Unfortunately, thinking about it a bit more, most of compctl-examples is
not functions but compctl commands.  Unlike the new completion system,
there's no convenient way to autoload them, so putting them under the
Functions directory doesn't make as much sense.

Unless ...

I just had a wonderful, awful idea ... one could use `compctl -T' to call
a function, which runs an autoloaded function, which defines a compctl,
which is then called because the -T attempt didn't generate a match ...

Oh, dear.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Peter Stephenson]

Oliver Kiddle wrote:
> Bart wrote:
> > The main thing I want to do with the example startup files is to add a
> > batch of comments, possibly in all-caps, telling system administrators
> > NOT to drop these files into /etc/z*.  And maybe even put a "return 0"
> > at the top of each file just in case some nimrod copies them to /etc/
> > without looking at them.
> 
> I would definitely agree with that.

As far as I'm concerned a nimrod is (a) a hunter mentioned in Genesis (b)
one of the Enigma variations referring to Elgar's friend and publisher
A.J. Jaeger (c) a search and reconnaissance aircraft, but if someone wants
to do that that's fine by me.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: Moving completion functions

[Oliver Kiddle]

Bart wrote:

> Long, long ago it was decided that it was a bad idea to import FPATH.
> So long ago that it's not in the zsh-workers archive, unfortunately.
> Probably has something to do with the fact that its a huge security
> hole, i.e., you can cause some other user's shell to inherit a trojan
> via any function you can guess he might autoload.

That's a good point. I have a horrible feeling you mentioned that before
sometime. It made me wonder though: surely PATH is similar. I've always
tended to add to the path in my .zshrc so this makes me wonder if it
wise to set it fully and in .zshenv for similar security reasons.
 
> } As I said with the original suggestion, there could be a variable set
> } to point to the base of the installed functions.
> 
> A parameter set how?  By hardwiring it at compile time?  I suppose that
> the zsh/complete module could define one.

Yes, or in the same way as how $fpath is set. I've used things like
${fpath[(r)*Core]:-$fpath[(r)*/functions]} in a few places (such as my
zrecompile script) to get at this directory so it might be useful
anyway.

I did a bit of thinking last week and as for the whole suggestion about
setting $fpath, I think you've convinced me that the current situation
is probably just as good/bad as my suggestion. I think it would
definitely be worse if we ended up supporting both ways of doing it with
a configure option so I won't mention it again. So I suggest we leave it
as it is and I shut up.

> } Do we need to account for kshautoload though?

> The only way is to "zcompile -z" the whole thing and then put the .zwc
> file in fpath.  This has been mentioned before (it may even be in the
> docs somewhere).

I couldn't see it in the docs but these things aren't so easy to find.
If it gets asked much, we can always add it to the FAQ.

As for sourcing compinit, I suppose it might have a performance
implication. I just felt that sourcing is more natural for what it is
doing and is possibly an easier concept for new users to understand.
>From the perspective of my own use of zsh, I don't really care how
compinit does its stuff. I'm not too keen on us complicating compinit so
that sourcing it is an option but with autoload being the method
mentioned in the manual.

Bart Schaefer wrote:
> 
> I would include harden, checkmail, mere, and definitely zed as "useful
> functions which many people might want to use," but proto is marginal
> (how many people code in C with exactly Paul Falstad's style?) and to
> autoload all those those trivial one-liners is IMO a waste.

Sorry, I didn't really know what proto was but assumed it was something
more general and so more useful.

> It's too big to reasonably put in compctl-examples and remains relevant

fair enough. Again I've never used it and just glanced to see what it
did.

> > > Functions/Misc/run-help             Functions/Misc  # Add #autoload line?
> >
> That's why there's a `?' at the end of my comment.  So, leave run-help
> as it is.

Er? I saw the ? and meant my comment as an answer but probably got the
tone of it wrong.

In some ways, I wonder that #autoload as a wider feature might be
useful.

> I'd actually rather split compctl-examples up into smaller files and put
> them all in Functions/Compctl, but I suppose we're trying to discourage
> use of compctl ...

That's not a bad idea. They'd be out of the way in the Compctl directory
so I don't think it would be too much of an encouragement. More
functions in Compctl would better justify its existence. I've also been
convinced that compctl still serves a purpose.

> The main thing I want to do with the example startup files is to add a
> batch of comments, possibly in all-caps, telling system administrators
> NOT to drop these files into /etc/z*.  And maybe even put a "return 0"
> at the top of each file just in case some nimrod copies them to /etc/
> without looking at them.

I would definitely agree with that.

Oliver

Re: Moving completion functions

[Bart Schaefer]

On Mar 22,  9:46pm, Oliver Kiddle wrote:
> Subject: Re: Moving completion functions
> 
> > Functions/Misc/acx		Functions/Examples	# Misc?
> > Functions/Misc/cx		Functions/Examples	# Misc?
> 
> I'd delete these because they would be better written as aliases.

I agree, which (jumping ahead) is why I do NOT agree with:

> I would class acx, cx, harden, proto, yp, yu, checkmail, mere, zed
> and zmv as useful functions which many people might want to use.

I would include harden, checkmail, mere, and definitely zed as "useful
functions which many people might want to use," but proto is marginal
(how many people code in C with exactly Paul Falstad's style?) and to
autoload all those those trivial one-liners is IMO a waste.

> > Functions/Misc/multicomp	Functions/Compctl
> 
> Is this one still relevant now that we have matching control.

It's too big to reasonably put in compctl-examples and remains relevant
to anyone not using the new completion system.  (multicomp is like the
_path_files function; no real overlap with matching control AFAICT.)

> > Functions/Misc/promptnl		Functions/Misc
> 
> This is new right? Was this something to do with evading the promptcr
> problem?

Yes, you call promptnl from precmd.  I suppose it (or contrib.yo) should
say that, somewhere.

> > Functions/Misc/run-help		Functions/Misc	# Add #autoload line?
> 
> On the basis that functions starting #autoload are autoloaded by
> compinit, and that #autoload was intended for functions which are part
> of the completion system, should we be using #autoload in
> non-completion system related functions.

That's why there's a `?' at the end of my comment.  So, leave run-help
as it is.

> > Functions/Misc/zless		Functions/Misc
> 
> I'd delete this one too because of the LESSPIPE feature in recent
> versions of less. It could always be found a good home on the web
> pages. If it stays, I'd put it in Examples.

I have no objection to moving this to Example.

> > Functions/Misc/zls		Functions/Misc
> 
> This I'd definitely put in Examples. I can't believe anyone would use
> it instead of their binary ls but it is a nice example for the stat
> module.

This is also fine with me.

> I agree with the Compctl division although it might be better to put
> them in the compctl-examples file to get them out of the way.

I'd actually rather split compctl-examples up into smaller files and put
them all in Functions/Compctl, but I suppose we're trying to discourage
use of compctl ...

> The example startup files are another thing we should look at before
> 4.0. I'd be in favour of modifying them to use new-style completion and
> having some typical example zstyles and generally to be a bit more
> up-to-date. If there is agreement on this, I'll come up with a
> suggested patch for them.

The main thing I want to do with the example startup files is to add a
batch of comments, possibly in all-caps, telling system administrators
NOT to drop these files into /etc/z*.  And maybe even put a "return 0"
at the top of each file just in case some nimrod copies them to /etc/
without looking at them.

Re: Moving completion functions

[Oliver Kiddle]

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

I wrote:
> The other thing which might be worth doing is looking through any other
> functions any of us have. From these we may find some suitable for the

> I've attached two of mine: hgrep is like grep but highlights

Of course, it would help if I actually remembered to attach them.
They should be on this e-mail.

Oliver

[-- Attachment #2: hgrep --]
[-- Type: text/plain, Size: 361 bytes --]

# hgrep - highlight grep

if (( ! $# )); then
  echo "Usage: $0:t [-e pattern...] [file...]" >&2
  return 1
fi

local -a regex
local htext=`echotc so` ntext=`echotc se`

while [[ "$1" = -e ]]; do
  regex=( $regex "$2" )
  shift 2
done

if (( ! $#regex )); then
  regex=( "$1" )
  shift
fi

regex=( "-e
s/${^regex[@]}/$htext&$ntext/g" )
sed ${(Ff)regex[@]} "$@"

[-- Attachment #3: showargs --]
[-- Type: text/plain, Size: 103 bytes --]

local arg s

(( $# == 1 )) || s=s
echo received $# argument$s

for arg; do
  echo -E - ">>$arg<<"
done

Re: Moving completion functions

[Oliver Kiddle]

First, I've got some comments relating to specific functions:

> Functions/Misc/acx		Functions/Examples	# Misc?
> Functions/Misc/cx		Functions/Examples	# Misc?

I'd delete these because they would be better written as aliases. They
could always be added to the example startup files.

> Functions/Misc/multicomp	Functions/Compctl

Is this one still relevant now that we have matching control.

> Functions/Misc/promptnl		Functions/Misc

This is new right? Was this something to do with evading the promptcr
problem?

> Functions/Misc/run-help		Functions/Misc	# Add #autoload line?

On the basis that functions starting #autoload are autoloaded by
compinit, and that #autoload was intended for functions which are part
of the completion system, should we be using #autoload in
non-completion system related functions. I'm not sure that I'd want
this autoloaded anyway because I don't use it.

> Functions/Misc/zless		Functions/Misc

I'd delete this one too because of the LESSPIPE feature in recent
versions of less. It could always be found a good home on the web
pages. If it stays, I'd put it in Examples.

> Functions/Misc/zls		Functions/Misc

This I'd definitely put in Examples. I can't believe anyone would use
it instead of their binary ls but it is a nice example for the stat
module.

Bart wrote:
> I've
> left in Functions/Misc anything that it seemed likely one might want to
> have in one's "standard" fpath, relocated stuff related to old compctl
> completions into Functions/Compctl, and stashed everything else in
> Functions/Examples.  A few of those latter might possibly want to be
> in Misc instead; I've marked those.

I agree with the Compctl division although it might be better to put
them in the compctl-examples file to get them out of the way.

For the rest it isn't very easy. The only ones which I can't see anyone
possibly wanting in their $fpath are zls and randline. pushd is
basically there for backward compatibility which would make a good
category if there were more. I would class acx, cx, harden, proto, yp,
yu, checkmail, mere, zed and zmv as useful functions which many people
might want to use. Most of the rest (zkbd, is-at-least, nslookup,
zstyle+, run-help, colors and zrecompile) are the ones which are almost
an integral part of zsh in that other things rely on them and they are
mentioned in the documentation.

This might suggest some sort of Example/Contrib/Zsh division although
that isn't want I originally meant to suggest. Maybe we could not
install the examples, have a configure option to install the user
contributions and always install the other things.

The other thing which might be worth doing is looking through any other
functions any of us have. From these we may find some suitable for the
distribution and others which can go under the user contributions on
the web pages.

I've attached two of mine: hgrep is like grep but highlights
matches. showargs lists arguments one per line which can be handy when
trying to work out what is going on with some quoting. Do you think
either of these may be suitable?

I also have these:
  freload() { while (( $# )); do; unfunction $1; autoload -U $1; shift; done }
  dr() { ls -lFbd ${@:-*}(/) }
  lx() { ls -lFbd ${@:-*}(x^/) }

The example startup files are another thing we should look at before
4.0. I'd be in favour of modifying them to use new-style completion and
having some typical example zstyles and generally to be a bit more
up-to-date. If there is agreement on this, I'll come up with a
suggested patch for them.

Finally, there was a mention at some point about changing the letters
of some compadd options as we were originally constrained by
consistency with compgen which had many of the old compctl options. Was
this ever done or looked in to? I suppose we still have compctl but
some could be better like -J and -V.

Oliver

Re: Moving completion functions

[Bart Schaefer]

On Mar 22, 11:40am, Sven Wischnowsky wrote:
} Subject: Re: Moving completion functions
} 
} > Functions/Misc/is-at-least	Functions/Misc	# Needs un-ksh-autoloading
} 
} So should I change it to our normal format while moving it?

That's what I meant, yes.

} > Functions/Misc/acx		Functions/Examples	# Misc?
} > Functions/Misc/cx		Functions/Examples	# Misc?
} > Functions/Misc/yp		Functions/Examples	# Misc?
} > Functions/Misc/yu		Functions/Examples	# Misc?
} 
} I've always thought that these are almost not worth a separate
} function file.  Because of that I think `Examples' is fine.

[...]

} Changing top-level directory names to their singular forms seems to
} not have been considered anymore.

Oh, I forgot about that.  At least make that Functions/Example rather
than Examples.  I wouldn't object to Function/* either, but I wasn't
thinking about directory renaming.  (A problem with directory renaming
in CVS is that you then forever afterward have to remember to use
"cvs update -P" to keep the empty directories out of your sandbox.)

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Peter Stephenson]

Sven wrote:
> - renaming of the files in Test

We could do them in sections.  There are obviously gaps, but doing them
this way makes it easier to reorder to something more rational when the
gaps (particularly in options and builtins) are filled a bit better.
(It also makes it easier to add an extra digit in one section if that every
becomes necessary, heaven forfend.)

Some of these could still be reordered.  For example, arith could be later
in section B and parameter could be earlier in section C.  We can't
completely get rid of the dependencies, so there's no point losing too much
sleep over it.


Section A: basic command parsing and execution

01grammar.ztst 	       	       	 A01grammar.ztst
02alias.ztst			 A02alias.ztst
03quoting.ztst			 A03quoting.ztst
04redirect.ztst			 A04redirect.ztst
05command.ztst			 A05execution.ztst

Section B: shell commands with special syntax

06arith.ztst			 B01arith.ztst
07cond.ztst			 B02cond.ztst
08traps.ztst			 B03traps.ztst
09funcdef.ztst			 B04funcdef.ztst

Section C: substititution

10prompt.ztst			 C01prompt.ztst
11glob.ztst			 C02glob.ztst
12procsubst.ztst		 C03procsubst.ztst
13parameter.ztst		 C04parameter.ztst
14array.ztst			 C05array.ztst

Section D: options

# We need more tests here!  There was going to be an options test, but
# it's huge to write.
                                [D01options.ztst]
51xtrace.ztst			 D02xtrace.ztst

Section E: builtins

50cd.ztst      	       	       	 E01cd.ztst
# More, more, more
52zregexparse.ztst		 E02zregexparse.ztst

Section F: line editing and completion

53completion.ztst      	       	 F01completion.ztst
54compmatch.ztst		 F02compmatch.ztst
55arguments.ztst                 F03arguments.ztst

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Moving completion functions

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 19, 10:46am, Sven Wischnowsky wrote:
> } Subject: Re: Moving completion functions
> }
> } echo adding tag
> } cvs tag comp-dirs .
> } 
> } move $files
> 
> I'd throw a "cvs update" in there before the "cvs tag", just in case.

Yes, right.

> Here are my suggestions for renaming in the Functions subdirectory.  I've
> left in Functions/Misc anything that it seemed likely one might want to
> have in one's "standard" fpath, relocated stuff related to old compctl
> completions into Functions/Compctl, and stashed everything else in
> Functions/Examples.  A few of those latter might possibly want to be
> in Misc instead; I've marked those.

For now I've just copied it into the script.

> And of course we could then rename the entire Misc directory to something
> less vague, but I didn't put any thought into that yet.
> 
> Functions/Misc/acx		Functions/Examples	# Misc?
> Functions/Misc/cx		Functions/Examples	# Misc?
> Functions/Misc/yp		Functions/Examples	# Misc?
> Functions/Misc/yu		Functions/Examples	# Misc?

I've always thought that these are almost not worth a separate
function file.  Because of that I think `Examples' is fine.

> Functions/Misc/is-at-least	Functions/Misc	# Needs un-ksh-autoloading

So should I change it to our normal format while moving it?

> Functions/Misc/run-help		Functions/Misc	# Add #autoload line?

There's the problem that the file then wouldn't work as a script
(because currently the `#autoload' has to be in the first line, this
could be changed, though).

Btw. is hard-wiring /usr/local/bin/zsh a good idea? And others say
`#! /bin/sh'.

We've been talking once or twice about a more general sub-system
configuration and autoloading mechanism.  And it's still on my list.
Then we just had the discussion about the completion directories.

Maybe we could try to collect ideas after 4.0, come up with a generic
mechanism for auto-loading and installing packages (or sub-packages)
and then convert all functions in the distribution as needed,
integrating Peter's work on config.modules.


Ok, things left:

- possible renaming of the Functions/Misc directory
- possible renaming of the tag- and label-completion-functions
- renaming of the files in Test

Changing top-level directory names to their singular forms seems to
not have been considered anymore.


Bye
 Sven


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

Re: Moving completion functions

[Bart Schaefer]

On Mar 19, 10:46am, Sven Wischnowsky wrote:
} Subject: Re: Moving completion functions
}
} echo adding tag
} cvs tag comp-dirs .
} 
} move $files

I'd throw a "cvs update" in there before the "cvs tag", just in case.

Otherwise this looks good.

Here are my suggestions for renaming in the Functions subdirectory.  I've
left in Functions/Misc anything that it seemed likely one might want to
have in one's "standard" fpath, relocated stuff related to old compctl
completions into Functions/Compctl, and stashed everything else in
Functions/Examples.  A few of those latter might possibly want to be
in Misc instead; I've marked those.

And of course we could then rename the entire Misc directory to something
less vague, but I didn't put any thought into that yet.

Functions/Misc/acx		Functions/Examples	# Misc?
Functions/Misc/allopt		Functions/Misc
Functions/Misc/cat		Functions/Examples
Functions/Misc/cdmatch		Functions/Compctl
Functions/Misc/cdmatch2		Functions/Compctl
Functions/Misc/checkmail	Functions/Misc
Functions/Misc/colors		Functions/Misc
Functions/Misc/cx		Functions/Examples	# Misc?
Functions/Misc/harden		Functions/Misc
Functions/Misc/is-at-least	Functions/Misc	# Needs un-ksh-autoloading
Functions/Misc/mere		Functions/Misc
Functions/Misc/multicomp	Functions/Compctl
Functions/Misc/nslookup		Functions/Misc
Functions/Misc/promptnl		Functions/Misc
Functions/Misc/proto		Functions/Examples
Functions/Misc/pushd		Functions/Examples
Functions/Misc/randline		Functions/Examples
Functions/Misc/run-help		Functions/Misc	# Add #autoload line?
Functions/Misc/yp		Functions/Examples	# Misc?
Functions/Misc/yu		Functions/Examples	# Misc?
Functions/Misc/zed		Functions/Misc
Functions/Misc/zkbd		Functions/Misc
Functions/Misc/zless		Functions/Misc
Functions/Misc/zls		Functions/Misc
Functions/Misc/zmv		Functions/Misc
Functions/Misc/zrecompile	Functions/Misc
Functions/Misc/zstyle+		Functions/Misc


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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> > Builtins/_popd                  Zsh/Command
> 
> _popd could possibly be something like Zsh/Type/_directory_stack as
> that is all it completes and it is called by _cd. It might make _cd
> more readable and would adapt better to changes in popd's usage.

Ah, right, I had thought that, too, sometimes (and then forgotten).

> Other than the naming of _compalso, _wanted, _requested, _next_label,
> _all_labels and the cvs tag are there any other outstanding issues on
> this?

No.  Unless we want to do other things at the same, such as renaming
the Test files and moving the functions, as mentioned by Bart.


Bye
 Sven


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

Re: Moving completion functions

[Bart Schaefer]

On Mar 20,  9:32pm, Oliver Kiddle wrote:
} Subject: Re: Moving completion functions
}
} Bart wrote:
}  
} > What exactly would you like fpath to contain by default?  Nothing?
} 
} Yes. Unless the parent process exported FPATH to zsh.

Long, long ago it was decided that it was a bad idea to import FPATH.
So long ago that it's not in the zsh-workers archive, unfortunately.

Probably has something to do with the fact that its a huge security
hole, i.e., you can cause some other user's shell to inherit a trojan
via any function you can guess he might autoload.

} > it also sets it to get the stuff from the Functions subdirectory, etc.
} 
} I always thought of them as just examples and user contributions as
} opposed to being part of zsh's functionality. Before the new
} completion, they had to be manually installed and added to $fpath. I've
} just noticed though that they are now mentioned in the documentation
} which I suppose makes them more official.

Not all of them are mentioned in the docs, and some of them really are
not much more than examples; I think we should rearrange some of the
files under Functions/ while we're doing the ones for Completion/.  (I
will try to make some suggestions after I've had some sleep.)
 
} > If we remove the Completion directories from the default fpath, then we
} > must also give up --enable-function-subdirs.  Not that we can't use the
} > subdirs for installation, but that we must hardwire the installation so
} > that compinit can know what to add to fpath.  Even then, compinit needs
} > to get the base path (to which to append /Completion/...) from 
} > somewhere.
} 
} As I said with the original suggestion, there could be a variable set
} to point to the base of the installed functions.

A parameter set how?  By hardwiring it at compile time?  I suppose that
the zsh/complete module could define one.

} I don't understand why compinit would need to know before-hand what
} directories it should add - it would just use a bit of globbing
} modified for $OSTYPE and options passed to it

Maybe; I'm not convinced.

} Do we need to account for kshautoload though?

The patch I included for compinit, did so, for compinit itself; but:

} How does someone with kshautoload set get the new completion system to
} work short of doing unsetopt kshautoload?

The only way is to "zcompile -z" the whole thing and then put the .zwc
file in fpath.  This has been mentioned before (it may even be in the
docs somewhere).

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Oliver Kiddle]

Sven wrote:

> Radical idea: let's just wait and do nothing about all this yet.  If

Probably a good plan.

> I don't like _want(|ed)_now, though, because it is too easily confused 
> with _wanted, I think.  And with _wanted we want to add the
> completions *now*, too.

Fair enough. _wanted_yet would possibly address your second point above
but not the first. It would be nice though if we can find some names
which better express the difference between _wanted and _requested. I
can't though and the current names aren't too bad.

> There's now the call to `cvs tag' in it, too.  I think using a tag
> that looks completely different than the version tags is a good idea
> but I otherwise I don't know what to use as a tag.

I agree that it shouldn't look like the version tags. I'd try to use
something which makes it clear that the tag is set before the move -
something like old-comp-dirs or pre-comp-mv. I've never dealt with cvs
tags though so am probably not the best person to answer this.

> Builtins/_popd                  Zsh/Command

_popd could possibly be something like Zsh/Type/_directory_stack as
that is all it completes and it is called by _cd. It might make _cd
more readable and would adapt better to changes in popd's usage.

The script looks fine though I've not looked in as much detail as
before.

Other than the naming of _compalso, _wanted, _requested, _next_label,
_all_labels and the cvs tag are there any other outstanding issues on
this?

Bart wrote:
 
> What exactly would you like fpath to contain by default?  Nothing?

Yes. Unless the parent process exported FPATH to zsh. At the least, we
should change zsh so that if FPATH is set in the environment when it
starts, the completion directories are added to it instead of replacing
it..

> it also sets it to get the stuff from the Functions subdirectory, etc.

I always thought of them as just examples and user contributions as
opposed to being part of zsh's functionality. Before the new
completion, they had to be manually installed and added to $fpath. I've
just noticed though that they are now mentioned in the documentation
which I suppose makes them more official. 

> If we remove the Completion directories from the default fpath, then we
> must also give up --enable-function-subdirs.  Not that we can't use the
> subdirs for installation, but that we must hardwire the installation so
> that compinit can know what to add to fpath.  Even then, compinit needs
> to get the base path (to which to append /Completion/...) from 
> somewhere.

As I said with the original suggestion, there could be a variable set
to point to the base of the installed functions. I don't understand why
compinit would need to know before-hand what directories it should add -
it would just use a bit of globbing modified for $OSTYPE and options
passed to it, I'd be very much against any manufacturing of compinit,
especially while it is installed below /usr/local/share.

> Issues of setting fpath aside, the following patch makes it possible to
> source compinit.  (Not committed yet, pending further discussion.)  One
> thing that bothers me a bit is that the (ARGC=0) test will give the
> wrong result if compinit is sourced from within some other function; as far 
> as
> I can tell, there's no completely reliable way to determine that 
> "source"
> (or ".") is in progress.

The ARGC test thing is clever. Do we need to account for kshautoload
though? How does someone with kshautoload set get the new completion
system to work short of doing unsetopt kshautoload? Having tried a few
ideas, I can't think of any better ways to detect when source is in
progress.

Oliver

Re: Moving completion functions

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> I'm not sure that it should be _ps_utils because the psutils is a single
> package of utilities distributed together which has always been called psutils
> in one word. _ps_utils might imply that some other unrelated PostScript utility
> should go in there also. Keeping it _mysql_utils and renaming to _x_utils is
> fine though.

Ok.

> ...
> 
> > - And there could be a better name for _compalso.
> 
> I agree but I can't think of anything better.

Neither could I.

> > - 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
> >
> 
> I like the sorting behaviour too but am not particularly convinced by these.
> _tag_requested just seems quite long for something which is used a lot. One
> option is removing the 'ed' so we just have _tag_want and _tag_request.
> 
> Another option which I think I prefer would be to use something like _want_now
> or _wanted_now for _requested which groups it with _wanted while possibly
> better expressing the difference with _wanted which you were getting at with
> the _tag_selected idea.

I haven't changed these yet (below is the next version of the script).

I don't like _want(|ed)_now, though, because it is too easily confused 
with _wanted, I think.  And with _wanted we want to add the
completions *now*, too.


Bart Schaefer wrote:

> ...
> 
> So I think _use_lo actually belongs in Unix/Command/, where the convention
> is to use names that describe the command for which the function completes,
> rather than names that describe what the function completes, or how.
> 
> Hence I think _use_lo should move to Unix/Command/_gnu_generic ...  I'd
> say _gnu_style, except for other "style" connotations.

Good point, good name, I've used it.

> ...
> 
> } > 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.
> 
> I'd put anything that actually needs X under X first.
> 
> The biggest problem with doing so is X programs that are nothing more
> than front-ends for text-based tools, when the text one is not installed.
> Presumably it does little harm to have a few completion functions for X
> commands that don't exist, but if there are actually dependencies among
> the completion functions, errors could result if a completion for one of
> those X commands happens to be attempted.

Radical idea: let's just wait and do nothing about all this yet.  If
we get more functions that make the kind of logical grouping we are
talking about more important we could think about adding configuration 
magic that builds link farms for logical groups of commands.  And then 
leave the functions in the system-specific and development-friendly
grouping we have now.


There's now the call to `cvs tag' in it, too.  I think using a tag
that looks completely different than the version tags is a good idea
but I otherwise I don't know what to use as a tag.


Bye
 Sven


move2() {
  perl -ne \
    's/\b_set_options\b/_options_set/g;
     s/\b_unset_options\b/_options_unset/g;
     s/\b_call\b/_call_program/g;
     s/\b_funcall\b/_call_function/g;
     print' $1 > $2
}


move1() {
  local name dir1 dir2

  name=${1:t}
  [[ $2 = */*/* && $2 != */*/*/* ]] && 2=${2}/${name}

  if [[ ! -f $1 ]]; then
    if [[ -f $2 ]]; then
      echo $1 already moved to $2
      return
    else
      echo ERROR: $1 does not exist
      return
    fi
  fi

  echo moving $1 to $2

  dir2=${2:h}
  dir1=${dir2:h}

  if [[ ! -d $dir1 ]]; then
    echo new directory $dir1
    mkdir $dir1
    echo "  cvs add    $dir1"
    cvs add $dir1
    echo "  cvs commit $dir1"
    cvs commit -m 'new completion directory' $dir1
  fi

  if [[ ! -d $dir2 ]]; then
    echo new directory $dir2
    mkdir $dir2
    echo "  cvs add    $dir2"
    cvs add $dir2
    echo "  cvs commit $dir2"
    cvs commit -m 'new completion directory' $dir2
  fi

  move2 $1 $2
  chmod 600 $2
  rm $1

  echo "  cvs remove $1"
  cvs remove $1
  echo "  cvs commit $1"
  cvs commit -m "moved to $2" $1

  echo "  cvs add    $2"
  cvs add $2
  echo "  cvs commit $2"
  cvs commit -m "moved from $1" $2
}


# Overall structure:
#
# Completion
#   comp{init,install,...}
#   Base
#     Core        basic functions
#     Completer   completers
#     Utility     utility functions (_arguments,...)
#     Widget      bindable commands
#   Zsh
#     Type        types of matches
#     Context     special contexts
#     Command     builtins and functions
#   Unix
#     Type
#     Command
#   X/AIX/BSD/Debian/Redhat
#     Utility
#     Type
#     Command


files=(

Core/_all_labels                Base/Core
Core/_all_matches               Base/Completer
Core/_alternative               Base/Utility
Core/_approximate               Base/Completer
Core/_call                      Base/Core/_call_program
Core/_compalso                  Base/Core
Core/_complete                  Base/Completer
Core/_correct                   Base/Completer
Core/_description               Base/Core
Core/_expand                    Base/Completer
Core/_expand_alias              Base/Completer
Core/_file_descriptors          Zsh/Type
Core/_files                     Unix/Type
Core/_funcall                   Base/Core/_call_function
Core/_history                   Base/Completer
Core/_ignored                   Base/Completer
Core/_list                      Base/Completer
Core/_main_complete             Base/Core
Core/_match                     Base/Completer
Core/_menu                      Base/Completer
Core/_message                   Base/Core
Core/_multi_parts               Base/Utility
Core/_next_label                Base/Core
Core/_normal                    Base/Core
Core/_oldlist                   Base/Completer
Core/_options                   Zsh/Type
Core/_parameters                Zsh/Type
Core/_path_files                Unix/Type
Core/_prefix                    Base/Completer
Core/_requested                 Base/Core
Core/_sep_parts                 Base/Utility
Core/_set_options               Zsh/Type/_options_set
Core/_setup                     Base/Core
Core/_tags                      Base/Core
Core/_unset_options             Zsh/Type/_options_unset
Core/_wanted                    Base/Core
Core/compaudit                  compaudit
Core/compdump                   compdump
Core/compinit                   compinit
Core/compinstall                compinstall

Base/_arg_compile               Base/Utility
Base/_arguments                 Base/Utility
Base/_brace_parameter           Zsh/Context
Base/_cache_invalid             Base/Utility
Base/_combination               Base/Utility
Base/_command_names             Zsh/Type
Base/_condition                 Zsh/Context
Base/_default                   Zsh/Context
Base/_describe                  Base/Utility
Base/_equal                     Zsh/Context
Base/_first                     Zsh/Context
Base/_in_vared                  Zsh/Context
Base/_jobs                      Zsh/Type
Base/_math                      Zsh/Context
Base/_parameter                 Zsh/Context
Base/_precommand                Zsh/Command
Base/_redirect                  Zsh/Context
Base/_regex_arguments           Base/Utility
Base/_retrieve_cache            Base/Utility
Base/_store_cache               Base/Utility
Base/_sub_commands              Base/Utility
Base/_subscript                 Zsh/Context
Base/_tilde                     Zsh/Context
Base/_value                     Zsh/Context
Base/_values                    Base/Utility

Commands/_bash_completions      Base/Widget
Commands/_complete_debug        Base/Widget
Commands/_complete_help         Base/Widget
Commands/_complete_tag          Base/Widget
Commands/_correct_filename      Base/Widget
Commands/_correct_word          Base/Widget
Commands/_expand_word           Base/Widget
Commands/_generic               Base/Widget
Commands/_history_complete_word Base/Widget
Commands/_most_recent_file      Base/Widget
Commands/_next_tags             Base/Widget
Commands/_read_comp             Base/Widget

Builtins/_aliases               Zsh/Type
Builtins/_arrays                Zsh/Type
Builtins/_autoload              Zsh/Command
Builtins/_bg_jobs               Zsh/Type/_jobs_bg
Builtins/_bindkey               Zsh/Command
Builtins/_builtin               Zsh/Command
Builtins/_cd                    Zsh/Command
Builtins/_command               Zsh/Command
Builtins/_compdef               Zsh/Command
Builtins/_disable               Zsh/Command
Builtins/_echotc                Zsh/Command
Builtins/_emulate               Zsh/Command
Builtins/_enable                Zsh/Command
Builtins/_fc                    Zsh/Command
Builtins/_fg_jobs               Zsh/Type/_jobs_fg
Builtins/_functions             Zsh/Type
Builtins/_hash                  Zsh/Command
Builtins/_kill                  Zsh/Command
Builtins/_limits                Zsh/Type
Builtins/_nothing               Base/Utility
Builtins/_pids                  Unix/Type
Builtins/_popd                  Zsh/Command
Builtins/_print                 Zsh/Command
Builtins/_read                  Zsh/Command
Builtins/_sched                 Zsh/Command
Builtins/_set                   Zsh/Command
Builtins/_setopt                Zsh/Command
Builtins/_signals               Unix/Type
Builtins/_source                Zsh/Command
Builtins/_stat                  Zsh/Command
Builtins/_trap                  Zsh/Command
Builtins/_unhash                Zsh/Command
Builtins/_unsetopt              Zsh/Command
Builtins/_vars                  Zsh/Type
Builtins/_vars_eq               Zsh/Command/_typeset
Builtins/_wait                  Zsh/Command
Builtins/_which                 Zsh/Command
Builtins/_zcompile              Zsh/Command
Builtins/_zftp                  Zsh/Command
Builtins/_zle                   Zsh/Command
Builtins/_zmodload              Zsh/Command
Builtins/_zpty                  Zsh/Command
Builtins/_zstyle                Zsh/Command

User/_a2ps                      Unix/Command
User/_apachectl                 Unix/Command
User/_archie                    Unix/Command
User/_arp                       Unix/Command
User/_bison                     Unix/Command
User/_bzip2                     Unix/Command
User/_chown                     Unix/Command
User/_compress                  Unix/Command
User/_configure                 Unix/Command
User/_cvs                       Unix/Command
User/_dd                        Unix/Command
User/_dict                      Unix/Command
User/_diff                      Unix/Command
User/_diff_options              Unix/Type
User/_dir_list                  Unix/Type
User/_dirs                      Unix/Type/_directories
User/_domains                   Unix/Type
User/_dvi                       Unix/Command
User/_enscript                  Unix/Command
User/_fakeroot                  Unix/Command
User/_fetchmail                 Unix/Command
User/_find                      Unix/Command
User/_finger                    Unix/Command
User/_flex                      Unix/Command
User/_gcc                       Unix/Command
User/_gdb                       Unix/Command
User/_getconf                   Unix/Command
User/_gprof                     Unix/Command
User/_grep                      Unix/Command
User/_groups                    Unix/Type
User/_gs                        Unix/Command
User/_gv                        X/Command
User/_gzip                      Unix/Command
User/_hosts                     Unix/Type
User/_iconv                     Unix/Command
User/_imagemagick               Unix/Command
User/_init_d                    Unix/Command
User/_ispell                    Unix/Command
User/_java                      Unix/Command
User/_joe                       Unix/Command
User/_killall                   Unix/Command
User/_look                      Unix/Command
User/_lp                        Unix/Command
User/_ls                        Unix/Command
User/_lynx                      Unix/Command
User/_lzop                      Unix/Command
User/_mailboxes                 Unix/Type
User/_make                      Unix/Command
User/_man                       Unix/Command
User/_mere                      Zsh/Command
User/_mh                        Unix/Command
User/_mount                     Unix/Command
User/_mutt                      Unix/Command
User/_my_accounts               Unix/Type
User/_mysql_utils               Unix/Command
User/_ncftp                     Unix/Command
User/_nedit                     X/Command
User/_netscape                  X/Command
User/_newsgroups                Unix/Type
User/_nslookup                  Unix/Command
User/_other_accounts            Unix/Type
User/_pack                      Unix/Command
User/_patch                     Unix/Command
User/_pbm                       Unix/Command
User/_pdf                       Unix/Type
User/_perl                      Unix/Command
User/_perl_basepods             Unix/Type
User/_perl_builtin_funcs        Unix/Type
User/_perl_modules              Unix/Type
User/_perldoc                   Unix/Command
User/_ports                     Unix/Type
User/_prcs                      Unix/Command
User/_printers                  Unix/Type
User/_prompt                    Zsh/Command
User/_ps                        Unix/Type
User/_pspdf                     Unix/Type
User/_psutils                   Unix/Command
User/_rcs                       Unix/Command
User/_rlogin                    Unix/Command
User/_sh                        Unix/Command
User/_slrn                      Unix/Command
User/_socket                    Unix/Command
User/_ssh                       Unix/Command
User/_strip                     Unix/Command
User/_stty                      Unix/Command
User/_su                        Unix/Command
User/_sudo                      Unix/Command
User/_tar                       Unix/Command
User/_tar_archive               Unix/Type
User/_telnet                    Unix/Command
User/_tex                       Unix/Type
User/_texi                      Unix/Type
User/_tiff                      Unix/Command
User/_tilde_files               Unix/Type
User/_tin                       Unix/Command
User/_urls                      Unix/Type
User/_use_lo                    Unix/Command/_gnu_generic
User/_user_at_host              Unix/Type
User/_users                     Unix/Type
User/_users_on                  Unix/Type
User/_w3m                       Unix/Command
User/_webbrowser                Unix/Command
User/_wget                      Unix/Command
User/_whereis                   Unix/Command
User/_whois                     Unix/Command
User/_xargs                     Unix/Command
User/_yodl                      Unix/Command
User/_yp                        Unix/Command
User/_zcat                      Unix/Command
User/_zdump                     Unix/Command
User/_zip                       Unix/Command

X/_x_arguments                  X/Utility
X/_x_borderwidth                X/Type
X/_x_color                      X/Type
X/_x_colormapid                 X/Type
X/_x_cursor                     X/Type
X/_x_display                    X/Type
X/_x_extension                  X/Type
X/_x_font                       X/Type
X/_x_geometry                   X/Type
X/_x_keysym                     X/Type
X/_x_locale                     X/Type
X/_x_modifier                   X/Type
X/_x_name                       X/Type
X/_x_resource                   X/Type
X/_x_selection_timeout          X/Type
X/_x_title                      X/Type
X/_x_window                     X/Type
X/_xauth                        X/Command
X/_xdvi                         X/Command
X/_xfig                         X/Command
X/_xmodmap                      X/Command
X/_xrdb                         X/Command
X/_xset                         X/Command
X/_xt_arguments                 X/Utility
X/_xt_session_id                X/Type
X/_xterm                        X/Command
X/_xutils                       X/Command/_x_utils
X/_xv                           X/Command
X/_xwit                         X/Command

AIX/_floppy                     AIX/Command
AIX/_logical_volumes            AIX/Type
AIX/_lscfg                      AIX/Command
AIX/_lsdev                      AIX/Command
AIX/_lslv                       AIX/Command
AIX/_lspv                       AIX/Command
AIX/_lsvg                       AIX/Command
AIX/_object_classes             AIX/Type
AIX/_physical_volumes           AIX/Type
AIX/_smit                       AIX/Command
AIX/_volume_groups              AIX/Type

Bsd/_bsd_pkg                    BSD/Command
Bsd/_cvsup                      BSD/Command
Bsd/_kld                        BSD/Command

Linux/_rpm                      Redhat/Command

Debian/_apt                     Debian/Command
Debian/_bug                     Debian/Command
Debian/_deb_packages            Debian/Type
Debian/_dpkg                    Debian/Command
Debian/_dpkg-source             Debian/Command/_dpkg_source
Debian/_dupload                 Debian/Command

)


move() {
  local i

  while (( $# )); do
    move1 Completion/$1 Completion/$2

    shift 2
  done

  for i in Completion/*/*(/)
    print "DISTFILES_SRC='" >  $i/.distfiles
    print .distfiles        >> $i/.distfiles
    print -c $i/*(.)        >> $i/.distfiles
    print "'"               >> $i/.distfiles
  done

  # Change:
  #   Completion/.distfiles
  #   Completion/compaudit
  #   Completion/compinstall
  #   Doc/Zsh/compsys.yo
  #   Doc/Zsh/contrib.yo
  #   Doc/Zsh/zftpsys.yo
  #   INSTALL
  #   Src/Zle/complete.mdd
  #   Test/ztst.zsh
  #   Etc/completion-style-guide
  #   _dict_words
  #   The Guide
}


echo adding tag
cvs tag comp-dirs .

move $files

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

Re: Moving completion functions

[Bart Schaefer]

On Mar 18, 10:20pm, Oliver Kiddle wrote:
} Subject: Re: Moving completion functions
}
} Bart wrote:
} > Aliasing is not the only reason for making compinit a function.
} 
} More user's would understand what they are doing when told to source a
} file than the autoloading. And, it would avoid the zsh always setting
} fpath stuff that I mentioned my dislike for before.

What exactly would you like fpath to contain by default?  Nothing?

The current scheme doesn't set fpath just to get the Completion functions;
it also sets it to get the stuff from the Functions subdirectory, etc.

If we remove the Completion directories from the default fpath, then we
must also give up --enable-function-subdirs.  Not that we can't use the
subdirs for installation, but that we must hardwire the installation so
that compinit can know what to add to fpath.  Even then, compinit needs
to get the base path (to which to append /Completion/...) from somewhere.

Either that, or compinit needs to become a manufactured file, built from
a .in that can substitute the necessary fpath from configure.  I don't
find that a particularly exciting prospect.

Issues of setting fpath aside, the following patch makes it possible to
source compinit.  (Not committed yet, pending further discussion.)  One
thing that bothers me a bit is that the (ARGC=0) test will give the wrong
result if compinit is sourced from within some other function; as far as
I can tell, there's no completely reliable way to determine that "source"
(or ".") is in progress.

Index: Completion/Core/compinit
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Completion/Core/compinit,v
retrieving revision 1.75
diff -c -r1.75 compinit
--- Completion/Core/compinit	2001/03/19 02:32:16	1.75
+++ Completion/Core/compinit	2001/03/19 04:13:16
@@ -65,6 +65,8 @@
 # queried for whether to use or ignore the insecure directories (which
 # means compinit should not be called from non-interactive shells).
 
+compinit() {
+
 emulate -L zsh
 setopt extendedglob
 
@@ -481,3 +483,11 @@
 autoload -U compinit compaudit
 
 return 0
+
+}
+
+# Find out if this file is being read with "source" or ".", or called as
+# an autoloaded function, and re-call as appropriate.
+
+local -i ARGC	# Harmless if sourced, removes readonly if autoloaded.
+{ (ARGC=0) 2>/dev/null && [[ -o kshautoload ]] } || compinit "$@"


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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Oliver Kiddle]

Sven wrote:

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

It would depend on whether we remove the second-level on installation
or remove any directories which don't contain subdirectories on
installation. The latter would allow you to use Unix/Network if you
wanted. I don't really mind about this or about whether we do any
further subdivision - 84 functions in Unix/Command is not so much.

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

I agree with Bart that anything needing X should be under X first.
Bart's point about the dependencies is also very much valid - an X
wrapper for a command-line network program is very likely to call
things in Network/Types.

Bart wrote:
> Let me jump back a bit and point out that it's not really correct to say
> that _use_lo is a "utility" -- _arguments is the utility, and _use_lo
> calls it; nobody would call _use_lo from some other function.

I'd agree with this. It was easy to miss that with _use_lo not being
the completion for any commands anymore. _gnu_generic is a good name.

> Aliasing is not the only reason for making compinit a function.  It also
> uses quite a few local parameters, "emulate -L zsh", and extendedglob.
> Those are all messy to deal with in a sourced file.

I remembered the aliasing as the main reason because there are ways
around the other problems such as the way you describe of using a
function defined within the sourced script. I'd prefer that way of doing
things. More user's would understand what they are doing when told to
source a file than the autoloading. And, it would avoid the zsh always
setting fpath stuff that I mentioned my dislike for before.

Oliver

Re: Moving completion functions

[Bart Schaefer]

On Mar 16, 11:20am, Sven Wischnowsky wrote:
} Subject: Re: Moving completion functions
}
} - _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?)

Let me jump back a bit and point out that it's not really correct to say
that _use_lo is a "utility" -- _arguments is the utility, and _use_lo
calls it; nobody would call _use_lo from some other function.

So I think _use_lo actually belongs in Unix/Command/, where the convention
is to use names that describe the command for which the function completes,
rather than names that describe what the function completes, or how.

Hence I think _use_lo should move to Unix/Command/_gnu_generic ...  I'd
say _gnu_style, except for other "style" connotations.

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

This is OK, but ...

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

I'd put anything that actually needs X under X first.

The biggest problem with doing so is X programs that are nothing more
than front-ends for text-based tools, when the text one is not installed.
Presumably it does little harm to have a few completion functions for X
commands that don't exist, but if there are actually dependencies among
the completion functions, errors could result if a completion for one of
those X commands happens to be attempted.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Bart Schaefer]

On Mar 15,  8:50pm, Oliver Kiddle wrote:
} Subject: Re: Moving completion functions
}
} When I last moaned about $fpath being set, it was probably together
} with the why is compinit autoloaded and not sourced question. The most
} compelling answer was because of the need for autoload -U to avoid
} aliases. We now have the noalias option so compinit could be sourced.

Aliasing is not the only reason for making compinit a function.  It also
uses quite a few local parameters, "emulate -L zsh", and extendedglob.
Those are all messy to deal with in a sourced file.

I suppose we could do the usual trick of wrapping most of the contents of
the compinit file in a function definition and then calling that function
at the end ... or maybe we need two versions of compinit, one to be used
as a function and one as a source-able file (and have one call the other,
it probably doesn't matter which is the "outer layer").

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Oliver Kiddle]

Sven wrote:

> - I was wondering if _mere is for the function or for some command I
>   don't know...

I assumed it was for the function and judging by the ChangeLog it must be
because in the first mention of _mere it is commited with mere.

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

I'm not sure that it should be _ps_utils because the psutils is a single
package of utilities distributed together which has always been called psutils
in one word. _ps_utils might imply that some other unrelated PostScript utility
should go in there also. Keeping it _mysql_utils and renaming to _x_utils is
fine though.

> - _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?)

My main reservation about _parse_help is that the function doesn't do the
actual parsing itself, it gets _arguments to do it. That aside, it looks and
sounds better than _options_from__help.

> - We could also change _call to _call_program and _funcall to
>   _call_function.

That seems good. The documentation for _call talks about calling a 'command' so
maybe it should be _call_command but program might be clearer.

> - And there could be a better name for _compalso.

I agree but I can't think of anything better.

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

I like the sorting behaviour too but am not particularly convinced by these.
_tag_requested just seems quite long for something which is used a lot. One
option is removing the 'ed' so we just have _tag_want and _tag_request.

Another option which I think I prefer would be to use something like _want_now
or _wanted_now for _requested which groups it with _wanted while possibly
better expressing the difference with _wanted which you were getting at with
the _tag_selected idea.

I'm not sure about the labels. Anyway, I'm being dragged down the pub so I'll
have to finish this reply next week.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Control Centre. For further information visit
http://www.messagelabs.com/stats.asp

Re: Moving completion functions

[Peter Stephenson]

Oliver wrote:
> To further explain my reasoning; we install the functions in
> /usr/local/share, not /usr/local/lib. This means that we should be
> prepared for the functions to be *shared* between different computers,
> each of which may run a different operating system. For this reason,
> the installation should/could include AIX, Linux, etc directories.

This is a very good use for keeping subdirectories, but isn't the typical
case.

> But,
> supposing we add something like a cgywin _path_files or a Linux _lsdev,
> we would want to be sure that we are using the correct one.

I think we should take great pains to avoid functions with different
effects having the same names.  If it becomes necessary to split functions,
they should be _path_files_cygwin and _lsdev_linux with some kind of
aliasing or selection mechanism (possibly via styles) where there's a
possibility of a different function being called.  They can still go in
different directories, of course.

> For some reason if you omit the hash -d and just set the variable, i.e.
> for d in a b c; $d=/cygdrive/$d
> I get error messages like this:
> /home/administrator/.zshrc:48: no such file or directory: r=/cygdrive/r

That doesn't work any more; you need to do
  for d in a b c; eval $d=/cygdrive/$d
or
  for d in a b c; typeset -g $d=/cygdrive/$d
(where the -g is mostly paranoia).

There was some kind of reason for doing this at the time, beyond making
people complain about gratuitous changes which stop things working (though
I often think the second effect is the more significant).

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Moving completion functions

[Sven Wischnowsky]

[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@informatik.hu-berlin.de

Re: Moving completion functions

[Oliver Kiddle]

Bart Schaefer wrote:

> The question to ask is, what's our primary purpose in splitting them up?
> Is it to allow selective installation?  (The original reason for BSD/ and
> AIX/, I think.)  Is it to help us as developers decide where to put new
> ones?  To help users decide what should be in $fpath?  To help users 
> and developers understand how the system works?

>From the perspective of an installation as opposed to the distribution,
I think the selectively filled $fpath is the key useful purpose of
splitting them up. From the perspective of the distribution the logical
separation of commands into types, utilities and completers etc is
useful.

For this reason, I favour the approach of leaf directories being used
for the logical separation and non-leaf directories being used for
useful installation-specific separations. Then on installation, the
logical separations (leaf directories) are ditched.

> me important for understanding to subdivide Base/ as you did.  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.

My main reasons for considering splitting Unix/Command would be for
selective choice of functions but other than our current divisions (X,
Bsd etc), I wouldn't bother unless Unix/Commands contains a lot of
files. It is certainly worth thinking about now while we are doing a
rename though.

> I think I'd also rename _set_options and _unset_options as _options_on
> and _options_off respectively.  In a similar vein, consider _labels_all
> and _labels_next, _matches_all, _parts_multi, _parts_sep, _cache_store,
> _cache_retrieve, _jobs_bg, _jobs_fg, ...  (I have a tendency to want
> related files to group together in a sorted listing, but in some cases
> [like _all_matches and _dir_list] I waffle because the readability of
> the calling scripts will suffer.  I also wouldn't use _options_diff
> because the relationship to _diff is the more important one.  Etc.)

This seems like a good idea to me. _combination could possibly have a name that
groups it with _parts_{sep,multi}. I'd not change _all_matches and _dir_list
though because of the readability.

> The script looks good.

Yes, it does. Cheers Sven.

> On a slightly related note, I was wondering whether it's worthwhile to
> create Cygwin/Type/_path_files that includes Andrej's suggestions about
> calling cygdrive, etc.  Then we'd have to make sure that Cygwin
> appeared
> first in $fpath with --enable-function-subdirs, but was installed
> *after*
> Unix without it ... it's also possible that netscape has different
> options
> when executed under cygwin, so we'd need Cygwin/Command/_netscape, etc.

We're going to get many more problems of this sort once we have more
platform specific completions. Linux has it's own lsdev for example
which fortunately doesn't take arguments so the AIX one doesn't get in
its way too much. I wouldn't be suprised if this becomes messy once
IBM finishes it's lvm for Linux if it get's widely adopted for Linux
because my AIX completions will probably half work but have the same
names. I could come up with numerous other examples and have no doubt
that separate directories for the purpose of overloading our namespace
is going to be essential.

This is why my preference remains having no option on installation
(i.e. no options like --enable-function-subdirs) and with functions all
installed into the (non-leaf) directories.

Why have most other people not used --enable-function-subdirs? If it is
because it is quicker to get at the functions with less, vi or whatever
then maybe we should extend equals expansion to expand for autoloaded
functions to their full location in $fpath?

I'm fairly sure that I've said it before but I don't like it that
running zsh, even with -f sets my $fpath to a whole load of things. The
completion functions should be *added* by compinit. To see why I
emphasise added, try the following:
fpath=/whatever zsh
and watch as your .zshrc can't find compinit and has lots of other
errors.

To further explain my reasoning; we install the functions in
/usr/local/share, not /usr/local/lib. This means that we should be
prepared for the functions to be *shared* between different computers,
each of which may run a different operating system. For this reason,
the installation should/could include AIX, Linux, etc directories. But,
supposing we add something like a cgywin _path_files or a Linux _lsdev,
we would want to be sure that we are using the correct one. If the
installation can include Aix, Cygwin etc then we can't rely on
performing this separation during a make install. compinit could check
$OSTYPE and use some intelligence about what it adds to $fpath. In
addition, we could maybe pass compinit options, for example, -x X -i
RedHat if we want to exclude X and include redhat because maybe we used
rpm but didn't use X. promptinit and zfinit would also be responsbile
for their fpath additions.

When I last moaned about $fpath being set, it was probably together
with the why is compinit autoloaded and not sourced question. The most
compelling answer was because of the need for autoload -U to avoid
aliases. We now have the noalias option so compinit could be sourced.
As for the how do we find compinit question, we'd have a variable named
something like $fundir which zsh would automatically set to point to
its location.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Control Centre. For further information visit
http://www.messagelabs.com/stats.asp

Re: Moving completion functions

[Bart Schaefer]

On Mar 15,  3:46pm, Oliver Kiddle wrote:
} Subject: Re: Moving completion functions
}
} > Base/_precommand                Zsh/Builtin
} > Builtins/_compdef               Zsh/Builtin      
} > # some of these are functions
} 
} >From the perspective of a user it doesn't make much difference so it is
} probably better to keep them together. _precommand is also completing a
} reserved word and one non-builtin command. Maybe we should put all the
} builtins in Zsh/Command?

This makes sense to me, too.  Zsh/Builtin is, in a way, redundant; whose
builtins would we be completing, if not zsh's?

} > User/_gv                        Unix/Command
} > User/_nedit                     Unix/Command
} > User/_netscape                  Unix/Command
} 
} I think these should go in X/Command because they are all dependant on
} having X.

I agree there.

On a slightly related note, I was wondering whether it's worthwhile to
create Cygwin/Type/_path_files that includes Andrej's suggestions about
calling cygdrive, etc.  Then we'd have to make sure that Cygwin appeared
first in $fpath with --enable-function-subdirs, but was installed *after*
Unix without it ... it's also possible that netscape has different options
when executed under cygwin, so we'd need Cygwin/Command/_netscape, etc.

What should we do when there might be two conflicting implementations of
a given completion component for different operating systems?

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

I agree with this.  If you're going to put Unix/Command in your $fpath,
can you ever *not* need Unix/Utility and Unix/Type as well?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Bart Schaefer]

On Mar 15, 10:30am, Sven Wischnowsky wrote:
} 
} I've used Oliver's suggestion for exchanging the names of the Core and 
} Base directories and Bart's suggestion to use the singular.  I'm still 
} not too happy with the name `Type', but since we constantly say things 
} like `type of matches' in the docs, this name is probably not that
} bad.

The only alternatives I can think of would be "Category" or "Class",
but I'm not too excited about those either.
 
} Some directories (esp. Unix/Command) could make one think about
} splitting them up even further (Unix/Net, Unix/Graphic, but also
} Zsh/Function and probably others).

The question to ask is, what's our primary purpose in splitting them up?
Is it to allow selective installation?  (The original reason for BSD/ and
AIX/, I think.)  Is it to help us as developers decide where to put new
ones?  To help users decide what should be in $fpath?  To help users and
developers understand how the system works?

Of course it's some of each of those, but which ones are more important
can indicate just how much splitting up is worthwhile.  For example, no
one would ever selectively install parts of Base/, but it still seems to
me important for understanding to subdivide Base/ as you did.  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.

} The rule of thumb is that those functions were put into Type that are
} usable as functions for completing types of <whatever>, even if they
} aren't (yet) used in that way.

Seems reasonable to me.

} For some files we could also think about better names, maybe (_vars_eq 
} comes to mind).

Yes, that could definitely get renamed as _typeset.

I think I'd also rename _set_options and _unset_options as _options_on
and _options_off respectively.  In a similar vein, consider _labels_all
and _labels_next, _matches_all, _parts_multi, _parts_sep, _cache_store,
_cache_retrieve, _jobs_bg, _jobs_fg, ...  (I have a tendency to want
related files to group together in a sorted listing, but in some cases
[like _all_matches and _dir_list] I waffle because the readability of
the calling scripts will suffer.  I also wouldn't use _options_diff
because the relationship to _diff is the more important one.  Etc.)

} Any better way to update the .distfiles[1]?

Probably not.

The script looks good.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Moving completion functions

[Oliver Kiddle]

Sven Wischnowsky wrote:

> Some directories (esp. Unix/Command) could make one think about
> splitting them up even further (Unix/Net, Unix/Graphic, but also
> Zsh/Function and probably others).  And, again (or still), some
> functions could sensibly be put into different directories.

I think it would be better to keep the subdivisions so that they group
together things where users will either want all the functions or will
want to exclude the whole directory, either by removing the directory
from $fpath or by not installing it.

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

How many functions are we going to have in Unix/Commands?

> example, I've put things like _tex, _ps etc. into Unix/Type because

That all seems fine.

> For some files we could also think about better names, maybe (_vars_eq 
> comes to mind).

Yes, I was going to mention _vars_eq. Maybe _typeset for the name?

> Base/_precommand                Zsh/Builtin
> Builtins/_compdef               Zsh/Builtin      
> # some of these are functions

>From the perspective of a user it doesn't make much difference so it is
probably better to keep them together. _precommand is also completing a
reserved word and one non-builtin command. Maybe we should put all the
builtins in Zsh/Command?

> User/_dict                      Unix/Command

I know it isn't related to the function moving but it might be wise to
take the _dict_words out of it to make a separate function. _look for
example could also use _dict_words.

> User/_diff_options              Unix/Type

Should this maybe go in Unix/Utility?

> User/_dirs                      Unix/Type

We use _files -/ in a lot of places in the completion functions. Should
we really be calling _dirs instead. I'd be tempted to rename this to
_directories because the the abbreviation doesn't achieve much and the
name _dirs might be wanted for a completion for the dirs builtin.
Actually, we ought to be using this _dirs for dirs because, apart from
the -v option, its arguments are directories.

> User/_mere                      Unix/Command

I'm not sure this should be in Unix because it is one of the Zsh
functions. It could go in Unix/Type though (possibly after a rename)
because it is completing a type of files. It might be useful later in an
nroff completion or something.

> User/_mysql_utils               Unix/Command

Should this maybe be renamed to just _mysql or _mysql_client? I'm not
familiar with mysql so don't really know.

> User/_gv                        Unix/Command
> User/_nedit                     Unix/Command
> User/_netscape                  Unix/Command

I think these should go in X/Command because they are all dependant on
having X. If they do go in Unix/, then others such as _xv and _xdvi
should join them. _imagemagick is okay where it is because some of the
imagemagick commands don't require X.

> User/_pdf                       Unix/Command

This should be in Unix/Type like _ps.

> User/_prompt                    Zsh/Builtin      # hmm... Zsh/Function?

If it does go in Zsh/Function then so should _zftp. I think it should
stay but this further convinces me that Zsh/Command instead of
Zsh/Builtin is a good idea.

> User/_use_lo                    Base/Utility

Could this one maybe be renamed? It isn't obvious what the lo stands
for. I can't think of any particularly good alternatives
(_use--help, _parse_help maybe?) but it should be possible to think of
something better.

> Peter Stephenson wrote:
> > People are going to have to get used to truly huge $fpath's if they
> use
> > --enable-function-subdirs.
> 
> Yes, unless we want to use Bart's suggestion to remove one level on
> installs (personally I prefer to keep it, too -- hmm, maybe giving
> users a three-way choice?).

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. Pruning unwanted stuff out of $fpath can make a big
difference to speed when starting zsh on a slow computer, especially
when recreating the dump file. Is it only me who uses
--enable-function-subdirs? I've always thought it should be the default
and possibly only option. It allows a user to be selective about which
functions they are getting when zsh has been centrally installed.


Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Control Centre. For further information visit
http://www.messagelabs.com/stats.asp

Re: Moving completion functions

[Sven Wischnowsky]

Peter Stephenson wrote:

> > Below is the first version of the script I'll use.
> 
> You'll need to change the functions= line in Src/Zle/complete.mdd.

That's why it's mentioned at the end of the script ;-)

> If I
> knew what I was doing with config.modules, that might be the only
> configurational change you need.  Well, it would be amusing.

But I was worried about this, suspecting I had overlooked something...

> People are going to have to get used to truly huge $fpath's if they use
> --enable-function-subdirs.

Yes, unless we want to use Bart's suggestion to remove one level on
installs (personally I prefer to keep it, too -- hmm, maybe giving
users a three-way choice?).

Bye
 Sven


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

Re: Moving completion functions

[Peter Stephenson]

> Below is the first version of the script I'll use.

You'll need to change the functions= line in Src/Zle/complete.mdd.  If I
knew what I was doing with config.modules, that might be the only
configurational change you need.  Well, it would be amusing.

People are going to have to get used to truly huge $fpath's if they use
--enable-function-subdirs.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Moving completion functions

[Sven Wischnowsky]

Below is the first version of the script I'll use.  I'm planning to
wait until Monday so that everyone who wants can have a look if the
classification is fine.  On Monday I'll look through the suggestions I
got till then and  change the script accordingly.  Before starting,
I'll send a mail telling you when I'll begin so that you don't check
out messed up intermediate versions.  (Of course I'll also send a
notice when the script/function has finished -- after or before that
I'll have to change the files mentioned at the end of the script.)

Unless the script or my comments below make us think that we should
organise the functions in some other way, that is.  In that I won't
start on Monday.

There are 281 functions...

I've used Oliver's suggestion for exchanging the names of the Core and 
Base directories and Bart's suggestion to use the singular.  I'm still 
not too happy with the name `Type', but since we constantly say things 
like `type of matches' in the docs, this name is probably not that
bad.

Some directories (esp. Unix/Command) could make one think about
splitting them up even further (Unix/Net, Unix/Graphic, but also
Zsh/Function and probably others).  And, again (or still), some
functions could sensibly be put into different directories.  For
example, I've put things like _tex, _ps etc. into Unix/Type because
they complete certain types of files.  The rule of thumb is that those
functions were put into Type that are usable as functions for
completing types of <whatever>, even if they aren't (yet) used in that
way.  The difference between Type and Utility, btw., is that Utility
holds functions that don't generate matches themselves, they are only
used to generate matches, telling them how to do that (i.e.:
_arguments and the like).

For some files we could also think about better names, maybe (_vars_eq 
comes to mind).

Any better way to update the .distfiles[1]?

Ok, that's it for now... Opinions? Suggestions?


Bye
 Sven

[1] I've seen that Peter had to update some .distfiles again lately.
    That was almost certainly my fault again.  Sorry and thanks, Peter.


move1() {
  local name dir1 dir2

  name=${1:t}
  [[ $2 = */*/* && $2 != */*/*/* ]] && 2=${2}/${name}

  if [[ ! -f $1 ]]; then
    if [[ -f $2 ]]; then
      echo $1 already moved to $2
      return
    else
      echo ERROR: $1 does not exist
      return
    fi
  fi

  echo moving $1 to $2

  dir2=${2:h}
  dir1=${dir2:h}

  if [[ ! -d $dir1 ]]; then
    echo new directory $dir1
    mkdir $dir1
    echo "  cvs add    $dir1"
    cvs add $dir1
    echo "  cvs commit $dir1"
    cvs commit -m 'new completion directory' $dir1
  fi

  if [[ ! -d $dir2 ]]; then
    echo new directory $dir2
    mkdir $dir2
    echo "  cvs add    $dir2"
    cvs add $dir2
    echo "  cvs commit $dir2"
    cvs commit -m 'new completion directory' $dir2
  fi

  cp $1 $2
  chmod 600 $2
  rm $1

  echo "  cvs remove $1"
  cvs remove $1
  echo "  cvs commit $1"
  cvs commit -m "moved to $2" $1

  echo "  cvs add    $2"
  cvs add $2
  echo "  cvs commit $2"
  cvs commit -m "moved from $1" $2
}


# Overall structure:
#
# Completion
#   comp{init,install,...}
#   Base
#     Core        basic functions
#     Completer   completers
#     Utility     utility functions (_arguments,...)
#     Widget      bindable commands
#   Zsh
#     Type        types of matches
#     Context     special contexts
#     Builtin     builtins
#   Unix
#     Type
#     Command
#   X/AIX/BSD/Debian/Redhat
#     Utility
#     Type
#     Command


files=(

Core/_all_labels                Base/Core
Core/_all_matches               Base/Completer
Core/_alternative               Base/Utility
Core/_approximate               Base/Completer
Core/_call                      Base/Core
Core/_compalso                  Base/Core
Core/_complete                  Base/Completer
Core/_correct                   Base/Completer
Core/_description               Base/Core
Core/_expand                    Base/Completer
Core/_expand_alias              Base/Completer
Core/_file_descriptors          Zsh/Type
Core/_files                     Unix/Type
Core/_funcall                   Base/Core
Core/_history                   Base/Completer
Core/_ignored                   Base/Completer
Core/_list                      Base/Completer
Core/_main_complete             Base/Core
Core/_match                     Base/Completer
Core/_menu                      Base/Completer
Core/_message                   Base/Core
Core/_multi_parts               Base/Utility
Core/_next_label                Base/Core
Core/_normal                    Base/Core
Core/_oldlist                   Base/Completer
Core/_options                   Zsh/Type
Core/_parameters                Zsh/Type
Core/_path_files                Unix/Type
Core/_prefix                    Base/Completer
Core/_requested                 Base/Core
Core/_sep_parts                 Base/Utility
Core/_set_options               Zsh/Type
Core/_setup                     Base/Core
Core/_tags                      Base/Core
Core/_unset_options             Zsh/Type
Core/_wanted                    Base/Core
Core/compaudit                  compaudit
Core/compdump                   compdump
Core/compinit                   compinit
Core/compinstall                compinstall

Base/_arg_compile               Base/Utility
Base/_arguments                 Base/Utility
Base/_brace_parameter           Zsh/Context
Base/_cache_invalid             Base/Utility
Base/_combination               Base/Utility
Base/_command_names             Zsh/Type
Base/_condition                 Zsh/Context
Base/_default                   Zsh/Context
Base/_describe                  Base/Utility
Base/_equal                     Zsh/Context
Base/_first                     Zsh/Context
Base/_in_vared                  Zsh/Context
Base/_jobs                      Zsh/Type
Base/_math                      Zsh/Context
Base/_parameter                 Zsh/Context
Base/_precommand                Zsh/Builtin
Base/_redirect                  Zsh/Context
Base/_regex_arguments           Base/Utility
Base/_retrieve_cache            Base/Utility
Base/_store_cache               Base/Utility
Base/_sub_commands              Base/Utility
Base/_subscript                 Zsh/Context
Base/_tilde                     Zsh/Context
Base/_value                     Zsh/Context
Base/_values                    Base/Utility

Commands/_bash_completions      Base/Widget
Commands/_complete_debug        Base/Widget
Commands/_complete_help         Base/Widget
Commands/_complete_tag          Base/Widget
Commands/_correct_filename      Base/Widget
Commands/_correct_word          Base/Widget
Commands/_expand_word           Base/Widget
Commands/_generic               Base/Widget
Commands/_history_complete_word Base/Widget
Commands/_most_recent_file      Base/Widget
Commands/_next_tags             Base/Widget
Commands/_read_comp             Base/Widget

Builtins/_aliases               Zsh/Type
Builtins/_arrays                Zsh/Type
Builtins/_autoload              Zsh/Builtin
Builtins/_bg_jobs               Zsh/Type
Builtins/_bindkey               Zsh/Builtin
Builtins/_builtin               Zsh/Builtin
Builtins/_cd                    Zsh/Builtin
Builtins/_command               Zsh/Builtin
Builtins/_compdef               Zsh/Builtin      # some of these are functions
Builtins/_disable               Zsh/Builtin
Builtins/_echotc                Zsh/Builtin
Builtins/_emulate               Zsh/Builtin
Builtins/_enable                Zsh/Builtin
Builtins/_fc                    Zsh/Builtin
Builtins/_fg_jobs               Zsh/Type
Builtins/_functions             Zsh/Type
Builtins/_hash                  Zsh/Builtin
Builtins/_kill                  Zsh/Builtin
Builtins/_limits                Zsh/Type
Builtins/_nothing               Base/Utility
Builtins/_pids                  Unix/Type
Builtins/_popd                  Zsh/Builtin
Builtins/_print                 Zsh/Builtin
Builtins/_read                  Zsh/Builtin
Builtins/_sched                 Zsh/Builtin
Builtins/_set                   Zsh/Builtin
Builtins/_setopt                Zsh/Builtin
Builtins/_signals               Unix/Type
Builtins/_source                Zsh/Builtin
Builtins/_stat                  Zsh/Builtin
Builtins/_trap                  Zsh/Builtin
Builtins/_unhash                Zsh/Builtin
Builtins/_unsetopt              Zsh/Builtin
Builtins/_vars                  Zsh/Type
Builtins/_vars_eq               Zsh/Builtin
Builtins/_wait                  Zsh/Builtin
Builtins/_which                 Zsh/Builtin
Builtins/_zcompile              Zsh/Builtin
Builtins/_zftp                  Zsh/Builtin
Builtins/_zle                   Zsh/Builtin
Builtins/_zmodload              Zsh/Builtin
Builtins/_zpty                  Zsh/Builtin
Builtins/_zstyle                Zsh/Builtin

User/_a2ps                      Unix/Command
User/_apachectl                 Unix/Command
User/_archie                    Unix/Command
User/_arp                       Unix/Command
User/_bison                     Unix/Command
User/_bzip2                     Unix/Command
User/_chown                     Unix/Command
User/_compress                  Unix/Command
User/_configure                 Unix/Command
User/_cvs                       Unix/Command
User/_dd                        Unix/Command
User/_dict                      Unix/Command
User/_diff                      Unix/Command
User/_diff_options              Unix/Type
User/_dir_list                  Unix/Type
User/_dirs                      Unix/Type
User/_domains                   Unix/Type
User/_dvi                       Unix/Command
User/_enscript                  Unix/Command
User/_fakeroot                  Unix/Command
User/_fetchmail                 Unix/Command
User/_find                      Unix/Command
User/_finger                    Unix/Command
User/_flex                      Unix/Command
User/_gcc                       Unix/Command
User/_gdb                       Unix/Command
User/_getconf                   Unix/Command
User/_gprof                     Unix/Command
User/_grep                      Unix/Command
User/_groups                    Unix/Type
User/_gs                        Unix/Command
User/_gv                        Unix/Command
User/_gzip                      Unix/Command
User/_hosts                     Unix/Type
User/_iconv                     Unix/Command
User/_imagemagick               Unix/Command
User/_init_d                    Unix/Command
User/_ispell                    Unix/Command
User/_java                      Unix/Command
User/_joe                       Unix/Command
User/_killall                   Unix/Command
User/_look                      Unix/Command
User/_lp                        Unix/Command
User/_ls                        Unix/Command
User/_lynx                      Unix/Command
User/_lzop                      Unix/Command
User/_mailboxes                 Unix/Type
User/_make                      Unix/Command
User/_man                       Unix/Command
User/_mere                      Unix/Command
User/_mh                        Unix/Command
User/_mount                     Unix/Command
User/_mutt                      Unix/Command
User/_my_accounts               Unix/Type
User/_mysql_utils               Unix/Command
User/_ncftp                     Unix/Command
User/_nedit                     Unix/Command
User/_netscape                  Unix/Command
User/_newsgroups                Unix/Type
User/_nslookup                  Unix/Command
User/_other_accounts            Unix/Type
User/_pack                      Unix/Command
User/_patch                     Unix/Command
User/_pbm                       Unix/Command
User/_pdf                       Unix/Command
User/_perl                      Unix/Command
User/_perl_basepods             Unix/Type
User/_perl_builtin_funcs        Unix/Type
User/_perl_modules              Unix/Type
User/_perldoc                   Unix/Command
User/_ports                     Unix/Type
User/_prcs                      Unix/Command
User/_printers                  Unix/Type
User/_prompt                    Zsh/Builtin      # hmm... Zsh/Function?
User/_ps                        Unix/Type
User/_pspdf                     Unix/Type
User/_psutils                   Unix/Command
User/_rcs                       Unix/Command
User/_rlogin                    Unix/Command
User/_sh                        Unix/Command
User/_slrn                      Unix/Command
User/_socket                    Unix/Command
User/_ssh                       Unix/Command
User/_strip                     Unix/Command
User/_stty                      Unix/Command
User/_su                        Unix/Command
User/_sudo                      Unix/Command
User/_tar                       Unix/Command
User/_tar_archive               Unix/Type
User/_telnet                    Unix/Command
User/_tex                       Unix/Type
User/_texi                      Unix/Type
User/_tiff                      Unix/Command
User/_tilde_files               Unix/Type
User/_tin                       Unix/Command
User/_urls                      Unix/Type
User/_use_lo                    Base/Utility
User/_user_at_host              Unix/Type
User/_users                     Unix/Type
User/_users_on                  Unix/Type
User/_w3m                       Unix/Command
User/_webbrowser                Unix/Command
User/_wget                      Unix/Command
User/_whereis                   Unix/Command
User/_whois                     Unix/Command
User/_xargs                     Unix/Command
User/_yodl                      Unix/Command
User/_yp                        Unix/Command
User/_zcat                      Unix/Command
User/_zdump                     Unix/Command
User/_zip                       Unix/Command

X/_x_arguments                  X/Utility
X/_x_borderwidth                X/Type
X/_x_color                      X/Type
X/_x_colormapid                 X/Type
X/_x_cursor                     X/Type
X/_x_display                    X/Type
X/_x_extension                  X/Type
X/_x_font                       X/Type
X/_x_geometry                   X/Type
X/_x_keysym                     X/Type
X/_x_locale                     X/Type
X/_x_modifier                   X/Type
X/_x_name                       X/Type
X/_x_resource                   X/Type
X/_x_selection_timeout          X/Type
X/_x_title                      X/Type
X/_x_window                     X/Type
X/_xauth                        X/Command
X/_xdvi                         X/Command
X/_xfig                         X/Command
X/_xmodmap                      X/Command
X/_xrdb                         X/Command
X/_xset                         X/Command
X/_xt_arguments                 X/Utility
X/_xt_session_id                X/Type
X/_xterm                        X/Command
X/_xutils                       X/Command
X/_xv                           X/Command
X/_xwit                         X/Command

AIX/_floppy                     AIX/Command
AIX/_logical_volumes            AIX/Type
AIX/_lscfg                      AIX/Command
AIX/_lsdev                      AIX/Command
AIX/_lslv                       AIX/Command
AIX/_lspv                       AIX/Command
AIX/_lsvg                       AIX/Command
AIX/_object_classes             AIX/Type
AIX/_physical_volumes           AIX/Type
AIX/_smit                       AIX/Command
AIX/_volume_groups              AIX/Type

Bsd/_bsd_pkg                    BSD/Command
Bsd/_cvsup                      BSD/Command
Bsd/_kld                        BSD/Command

Linux/_rpm                      Redhat/Command

Debian/_apt                     Debian/Command
Debian/_bug                     Debian/Command
Debian/_deb_packages            Debian/Type
Debian/_dpkg                    Debian/Command
Debian/_dpkg-source             Debian/Command/_dpkg_source
Debian/_dupload                 Debian/Command

)


move() {
  local i

  while (( $# )); do
    move1 Completion/$1 Completion/$2

    shift 2
  done

  for i in Completion/*/*(/)
    print "DISTFILES_SRC='" >  $i/.distfiles
    print .distfiles        >> $i/.distfiles
    print -c $i/*(.)        >> $i/.distfiles
    print "'"               >> $i/.distfiles
  done

  # Change:
  #   Completion/.distfiles
  #   Completion/compaudit
  #   Completion/compinstall
  #   Doc/Zsh/compsys.yo
  #   Doc/Zsh/contrib.yo
  #   Doc/Zsh/zftpsys.yo
  #   INSTALL
  #   Src/Zle/complete.mdd
  #   Test/ztst.zsh
  #   The Guide
}


move $files

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