Completion system directories

Completion system directories

[Sven Wischnowsky]

Here is my suggestion for moving functions around. Dunno if that
should be done before 3.1.7 or after it.

The whole list is below, an overview:

  Completion
    Core         - core system
      Base       - the functions used everywhere (_tags, ...) and
                   _main_complete
      Completers - completers
      Utils      - functions that don't generate matches themselves
                   but help in doing so (_arguments, ...)
      Widgets    - the `bindable commands' like _correct_word
    Zsh          - zsh-specific completion
      Types      - types of matches
      Contexts   - special contexts like subscripts
      Builtins   - well...
    Unix         - should be reasonable on all Unix machines
      Types      - _users, _hosts, ...
      Commands   - for external commands (*not* what is now called
                   Commands)
    X
      Utils      - the _x(|t)_arguments functions
      Types      - colors, fonts, ...
      Commands   - ...
    Debian/Redhat/Bsd/Aix  - system-specific completions
      Utils     \
      Types     |- as needed...
      Commands  /

Comments:

- Bart didn't like `Core', right? Any suggestions? It's especially
  ugly with the `Base' below it.
- Should it be `Utilities' instead of `Utils'?
- There must be a better name than `Types', too...
- Should `Unix' be `Generic' or some such?
- Somehow I like the distinction between `Zsh' and `Unix', makes even
  those function be (hopefully reasonably) grouped.

- For some functions I wasn't completely sure where to put them...


Oh, and does anyone have a list of places that need changing? (Manual, 
compinit, compinstall, Completion/README, the installation stuff in
configure.in, the comment in INSTALL, what else?)

And finally: what is the easiest way to make these changes in the CVS
repository? Is there really no simpler way than using `cvs add' and
`cvs remove'? If not: urgh. And that with the `cvs commit aborted:
broken pipe' I get at every second commit-attempt :-(


So, any comments? Suggestions? Opinions?

Bye
 Sven

  compinit
  compdump
  compinstall
  Core
    Base
      _main_complete
      _tags
      _wanted
      _requested
      _all_labels
      _next_label
      _description
      _message
      _setup
      _call
      _compalso
      _funcall
      _sort_tags
    Completer
      _complete
      _correct
      _approximate
      _expand
      _match
      _history
      _prefix
      _ignored
      _oldlist
      _list
      _menu
    Utils
      _normal
      _multi_parts
      _sep_parts
      _arguments
      _argument_sets
      _arg_compile
      _values
      _combination
      _describe
      _regex_arguments
    Widgets
      _correct_word
      _expand_word
      _bash_completions
      _history_complete_word
      _next_tags
      _most_recent_file
      _read_comp
      _complete_help
      _complete_debug
  Zsh
    Types
      _command_names
      _jobs
      _fg_jobs
      _bg_jobs
      _file_descriptors
      _options
      _set_options
      _unset_options
      _parameters
    Contexts
      _first
      _default
      _parameter
      _brace_parameter
      _equal
      _math
      _subscript
      _tilde
      _redirect
      _value
    Builtins
      _precommand
      _aliases
      _arrays
      _autoload
      _bindkey
      _builtin
      _cd
      _command
      _compdef
      _disable
      _echotc
      _emulate
      _enable
      _fc
      _functions
      _hash
      _kill
      _limits
      _popd
      _print
      _sched
      _set
      _setopt
      _source
      _stat
      _trap
      _unhash
      _unsetopt
      _vars
      _vars_eq
      _wait
      _which
      _zcompile
      _zftp
      _zle
      _zmodload
      _zpty
      _zstyle
  Unix
    Types
      _files
      _path_files
      _tilde_files  (probably in Zsh/Types)
      _dirs
      _dir_list
      _signals      (probably in Zsh/Types)
      _pids
      _users
      _groups
      _hosts
      _ports
      _user_at_host
      _my_accounts
      _other_accounts
      _printers
      _domains
      _urls
      _mailboxes
      _perl_basepods
      _perl_builtin_funcs
      _nothing
    Commands
      _a2ps
      _archie
      _bison
      _bzip2
      _chown
      _compress
      _configure
      _cvs
      _dd
      _diff
      _diff_options
      _dvi
      _enscript
      _fakeroot
      _find
      _finger
      _flex
      _gcc
      _gdb
      _getconf
      _gprof
      _gs
      _gv
      _gzip
      _imagemagick
      _ispell
      _joe
      _killall
      _lp
      _lynx
      _make
      _man
      _mh
      _mount
      _mutt
      _mysql_utils
      _nedit
      _netscape
      _nslookup
      _pack
      _patch
      _pbm
      _pdf
      _perl
      _perl_modules
      _perldoc
      _prcs
      _prompt
      _ps
      _pspdf
      _psutils
      _rcs
      _rlogin
      _sh
      _socket
      _ssh
      _strip
      _stty
      _su
      _sudo
      _tar
      _tar_archive
      _telnet
      _tex
      _texi
      _tiff
      _uncompress
      _unpack
      _use_lo
      _users_on
      _webbrowser
      _wget
      _whereis
      _whois
      _xargs
      _yodl
      _yp
      _zcat
      _zdump
  X
    Utils
      _x_arguments
      _xt_arguments
    Types
      _x_borderwidth
      _x_color
      _x_colormapid
      _x_cursor
      _x_display
      _x_extension
      _x_font
      _x_geometry
      _x_keysym
      _x_locale
      _x_modifier
      _x_name
      _x_resource
      _x_selection_timeout
      _x_title
      _x_window
      _xt_session_id
    Commands
      _xdvi
      _xfig
      _xmodmap
      _xrdb
      _xset
      _xterm
      _xutils
      _xv
      _xwit
  Debian
    Utils
    Types
      _deb_packages
    Commands
      _apt
      _bug
      _dpkg
      _dpkg-source
      _dupload
  Redhat
    Utils
    Types
    Commands
      _rpm
  Bsd
    Utils
    Types
    Commands
      _bsd_pkg
      _cvsup
      _kld
  Aix
    Utils
    Types
      _physical_volumes
      _volume_groups
    Commands
      _floppy
      _lsdev
      _lslv
      _lspv
      _lsvg
      _smit

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

Re: Completion system directories

[Adam Spiers]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> And finally: what is the easiest way to make these changes in the CVS
> repository? Is there really no simpler way than using `cvs add' and
> `cvs remove'? If not: urgh.

Renaming/moving files around is one of CVS' weaknesses.  If we had
direct access to the CVS repository we could just copy the RCS files
directly, and that would preserve history.  (See the FAQ for details
of this procedure.)  But we don't.  So I guess we can either ask the
sourceforge guys nicely, or obtain a tarball of the whole repository,
and declare the tree closed for a bit while someone messes around with
the tarball, and resubmits it for upload.

> And that with the `cvs commit aborted: broken pipe' I get at every
> second commit-attempt :-(

Hmm, no excuse for that.  You should submit a bug to sourceforge.

Re: Completion system directories

[Bart Schaefer]

On May 3, 10:57am, Adam Spiers wrote:
} Subject: Re: Completion system directories
}
} Renaming/moving files around is one of CVS' weaknesses.  If we had
} direct access to the CVS repository [...] But we don't.

We don't?  I thought ... no, I suppose that wouldn't make sense.  Ignore
my crossed-in-the-mail remarks on this ...

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

Re: Completion system directories

[Bart Schaefer]

On May 3, 11:14am, Sven Wischnowsky wrote:
} Subject: Completion system directories
}
} Here is my suggestion for moving functions around.

Structurally I think this looks fine.  I'm occassionally alarmed that we
need a hierarchy this deep, but the idea is that it condenses somewhat
upon installation, right?  E.g. it would lose the {Core,Zsh,...} layer.

} Dunno if that should be done before 3.1.7 or after it.

I have a slight preference for "after" but only a slight one.  There
are advantages either way.

} - Bart didn't like `Core', right? Any suggestions?

Right.  Perhaps "Kernel"?  "System"?

} - Should it be `Utilities' instead of `Utils'?

Probably.  Actually I think they should all be singular e.g. "Utility".
(Cf. "Util" et al.; too bad about "Functions" and "StartupFiles" [*].)

} - There must be a better name than `Types', too...

"Flavor"?  "Class"?

} - Should `Unix' be `Generic' or some such?

I think "Unix" is OK.  Amol D. or the Cygwin folks may have something to
say about how generic those are, after all.

} - Somehow I like the distinction between `Zsh' and `Unix', makes even
}   those function be (hopefully reasonably) grouped.

I agree.

} - For some functions I wasn't completely sure where to put them...

I know ...

} Oh, and does anyone have a list of places that need changing?

The only ones I can find with a grep are:

Completion/Core/compinit
Completion/Core/compinstall
Doc/Zsh/compsys.yo
Doc/Zsh/compsys.yo
INSTALL
configure.in

} And finally: what is the easiest way to make these changes in the CVS
} repository? Is there really no simpler way than using `cvs add' and
} `cvs remove'?

There's no way using :pserver:, but since we have shell access to the
repository ...

If we can impose a moritorium on commits for a while, we can simply copy
the ,v files to new directories in the repository, and then "cvs remove"
the originals.  (We could use mv rather than cp, but that messes up the
"cvs update" of people's existing checked-out sandboxes.  The only way
to make checked-out copies go away cleanly is to "cvs remove"/commit.)

} So, any comments? Suggestions? Opinions?

[*] On the subject of renaming, I've never liked "StartupFiles".  It
misleads people who don't read carefully into copying those files into
/etc (I recognize parts of RedHat's distributed /etc/z* in our samples).
And those samples still refer to zsh 2.7, which never even existed!!
Those files should be touched up and the directory renamed (perhaps to
"Samples").

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

RE: Completion system directories

[Andrej Borsenkow]

>
> Structurally I think this looks fine.  I'm occassionally
> alarmed that we
> need a hierarchy this deep, but the idea is that it condenses somewhat
> upon installation, right?  E.g. it would lose the
> {Core,Zsh,...} layer.
>

Why should we remove some levels? O.K., if somebody compiles
with --disable-function-subdirs - then there is no trace of original
hierarchy anyway. But I'd like to preserve it by the installation. It
gives more clear picture; it provides for easy update; it may also
provide for system-dependent initialisation (enable only selected
subdirs relevant for my system). I think, we should preserve full
existing hierarchy by the installation. Perl has potentially much deeper
structure without any harm.

-andrej

Re: Completion system directories

[Peter Stephenson]

Bart wrote:
> On May 3, 11:14am, Sven Wischnowsky wrote:
> } And finally: what is the easiest way to make these changes in the CVS
> } repository? Is there really no simpler way than using `cvs add' and
> } `cvs remove'?
> 
> There's no way using :pserver:, but since we have shell access to the
> repository ...
> 
> If we can impose a moritorium on commits for a while, we can simply copy
> the ,v files to new directories in the repository, and then "cvs remove"
> the originals.  (We could use mv rather than cp, but that messes up the
> "cvs update" of people's existing checked-out sandboxes.  The only way
> to make checked-out copies go away cleanly is to "cvs remove"/commit.)

I don't like mucking around in the archive in this way because it means we
can no longer checkout old versions of the shell.  As far as I'm concerned
using cvs add/remove would be perfectly OK.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Completion system directories

[Geoff Wing]

Peter Stephenson <pws@cambridgesiliconradio.com> typed:
:Bart wrote:
:> There's no way using :pserver:, but since we have shell access to the
:> repository ...

?  We've shell access to shell1 (orbital).  We don't have shell access
to the repository machine (slayer).  Do we?
 
:> If we can impose a moritorium on commits for a while, we can simply copy
:> the ,v files to new directories in the repository, and then "cvs remove"
:> the originals.  (We could use mv rather than cp, but that messes up the
:> "cvs update" of people's existing checked-out sandboxes.  The only way
:> to make checked-out copies go away cleanly is to "cvs remove"/commit.)

:I don't like mucking around in the archive in this way because it means we
:can no longer checkout old versions of the shell.  As far as I'm concerned
:using cvs add/remove would be perfectly OK.

Pretty much the only useful way to do it is:
1) cvs remove/cvs commit the file
2) copy the file (now in the Attic directory) to the new directory
3) edit the new file to change the state of all revisions except the
   newest to Dead and change the newest to Exp

And do all this via a script because it would be too easy for people to
make mistakes.  However, all this requires direct access on the
repository.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Re: Completion system directories

[Bart Schaefer]

On May 3, 12:10pm, Peter Stephenson wrote:
}
} Bart wrote:
} > If we can impose a moritorium on commits for a while, we can simply copy
} > the ,v files to new directories in the repository, and then "cvs remove"
} > the originals.
} 
} I don't like mucking around in the archive in this way because it means we
} can no longer checkout old versions of the shell.

On May 3, 11:24am, Geoff Wing wrote:
}
} Pretty much the only useful way to do it is:
} 1) cvs remove/cvs commit the file
} 2) copy the file (now in the Attic directory) to the new directory
} 3) edit the new file to change the state of all revisions except the
}    newest to Dead and change the newest to Exp

If you copy the file *before* the cvs remove and then delete all the
symbolic tags from the copy, you get the same effect.

However, now that I think of it, I'm nut sure what the effect of either of
these changes would be on future use of "cvs import".

How about this:

Leave the renaming alone until 4.0.

When we're ready to do 4.0, rename the entire existing repository to
"zsh-3.1" and create a new repository, with all the files in the right
places and no revision history.  I.e., make up the 4.0 tarball and then
"cvs import" it into the fresh repository.

There isn't *that* much history in the current repository now anyway;
many of the files that would be getting renamed already are the ones
that have the most history to lose.

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

Re: Completion system directories

[Peter Stephenson]

Bart wrote:
> How about this:
> 
> Leave the renaming alone until 4.0.
> 
> When we're ready to do 4.0, rename the entire existing repository to
> "zsh-3.1" and create a new repository, with all the files in the right
> places and no revision history.  I.e., make up the 4.0 tarball and then
> "cvs import" it into the fresh repository.

This would probably be fine, although I'm not sure we're able to rename the
repository as such.  We can create a new tree under /cvsroot/zsh rooted on
zsh-4.0, and possibly alias it under the name `zsh' (not sure about this if
there's a directory zsh, but it probably ought to work), by tricks in
CVSROOT/modules, and alias the existing zsh tree to `zsh-3.1', but renaming
the current zsh tree to zsh-3.1 might not be possible.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Completion system directories

[Oliver Kiddle]

Bart Schaefer wrote:
> 
> On May 3, 11:14am, Sven Wischnowsky wrote:
> } Subject: Completion system directories
> }
> } Here is my suggestion for moving functions around.
> 
> Structurally I think this looks fine.  I'm occassionally alarmed that we
> need a hierarchy this deep, but the idea is that it condenses somewhat
> upon installation, right?  E.g. it would lose the {Core,Zsh,...} layer.

It looks good to me. I'm quite happy with a deep hierarchy - I prefer it when directory listings don't scroll up endlessly. 

> } - Bart didn't like `Core', right? Any suggestions?
> Right.  Perhaps "Kernel"?  "System"?

I prefer 'Core' to those as they might be wrongly associated with the UNIX kernel/system by anyone first seeing them. I would be more inclined to use 'Base' and then rename the directory which would have been 'Base' in Core. 

> } - Should it be `Utilities' instead of `Utils'?
> 
> Probably.  Actually I think they should all be singular e.g. "Utility".
> (Cf. "Util" et al.; too bad about "Functions" and "StartupFiles" [*].)

I agree with Bart here. I'm not convinced by the idea of using capitalised first letters for all the directories. It looks especially strange with things like 'Bsd' and 'Aix'.
 
> } - There must be a better name than `Types', too...
> 
> "Flavor"?  "Class"?

Please not 'Flavor'. I think it is better to avoid any words which have different spellings in America and Britain if at all possible.

How about 'Entity'?
 
[ snipped a few more points where my answer would be 'I agree' ]

> } And finally: what is the easiest way to make these changes in the CVS
> } repository? Is there really no simpler way than using `cvs add' and
> } `cvs remove'?

It would be useful to be able to check out previous releases in the future so if the repository is going to be hacked then it would be better to try to leave things so that a 3.1.7 can be checked out in the future. Either by making the changes before 3.1.7 (the CVS doesn't go back to 3.1.6 does it?) or is it possible to just copy the RCS files (instead of mv) and clear out some of the tags from the copies so the old RCS files are still there but we have the history in the new ones. Of course it wouldn't be the first time if I'm talking complete crap about CVS so ignore me if I am.

While we're on the subject of cvs can people be a little careful with the ChangeLog - I've fixed it a couple of times when the merge has gone wrong. For an example, do:
cvs diff -r 1.183 -r 1.184 ChangeLog
An update before a commit might make it less likely?

> [*] On the subject of renaming, I've never liked "StartupFiles".  It
> misleads people who don't read carefully into copying those files into
> /etc (I recognize parts of RedHat's distributed /etc/z* in our samples).
> And those samples still refer to zsh 2.7, which never even existed!!
> Those files should be touched up and the directory renamed (perhaps to
> "Samples").

I'm not convinced that the example startup files have much value anymore as they are quite out of date. I have added a section for startup files to the contributed part of the web pages and I think it would be better to point people to there if they want examples and to remove those in the distribution. This might also reduce the chances of people mistaking them for example global startup files (I'll add a note to the web page to clarify that they are example user startup files). If anyone wants to contribute their startup files, I'll add them. I've already linked to Adam's. 

Oliver

CVS merge conflicts (Re: Completion system directories)

[Bart Schaefer]

On May 3, 12:35pm, Oliver Kiddle wrote:
}
} While we're on the subject of cvs can people be a little careful with
} the ChangeLog - I've fixed it a couple of times when the merge has gone
} wrong. For an example, do:
} cvs diff -r 1.183 -r 1.184 ChangeLog
} An update before a commit might make it less likely?

I always do update before I commit.  One *can't* commit without first
updating, in fact.  An update before editing the ChangeLog would help
if not for race conditions; in the case of r1.184 I'd already done an 
update, edited the file, and then attempted to commit, only to have it
fail because your commit had gone in in the meantime.  The 20 minutes
between r1.183 and r1.184 were me attempting (apparently unsuccessfully)
to fix the merge conflicts that resulted from my subsequent update.

The real problem is that the diff algorithm is very bad at handling
a series of short paragraphs separated by blank lines, because it
considers the overlap in the two versions to end at a matching line,
even if the matching lines are both empty.

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