* Completion system directories
@ 2000-05-03 9:14 Sven Wischnowsky
2000-05-03 9:57 ` Adam Spiers
2000-05-03 10:30 ` Bart Schaefer
0 siblings, 2 replies; 11+ messages in thread
From: Sven Wischnowsky @ 2000-05-03 9:14 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Completion system directories
2000-05-03 9:14 Completion system directories Sven Wischnowsky
@ 2000-05-03 9:57 ` Adam Spiers
2000-05-03 10:52 ` Bart Schaefer
2000-05-03 10:30 ` Bart Schaefer
1 sibling, 1 reply; 11+ messages in thread
From: Adam Spiers @ 2000-05-03 9:57 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Completion system directories
2000-05-03 9:14 Completion system directories Sven Wischnowsky
2000-05-03 9:57 ` Adam Spiers
@ 2000-05-03 10:30 ` Bart Schaefer
2000-05-03 11:03 ` Andrej Borsenkow
` (2 more replies)
1 sibling, 3 replies; 11+ messages in thread
From: Bart Schaefer @ 2000-05-03 10:30 UTC (permalink / raw)
To: Sven Wischnowsky, zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Completion system directories
2000-05-03 9:57 ` Adam Spiers
@ 2000-05-03 10:52 ` Bart Schaefer
0 siblings, 0 replies; 11+ messages in thread
From: Bart Schaefer @ 2000-05-03 10:52 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Completion system directories
2000-05-03 10:30 ` Bart Schaefer
@ 2000-05-03 11:03 ` Andrej Borsenkow
2000-05-03 11:10 ` Peter Stephenson
2000-05-03 11:35 ` Oliver Kiddle
2 siblings, 0 replies; 11+ messages in thread
From: Andrej Borsenkow @ 2000-05-03 11:03 UTC (permalink / raw)
To: Bart Schaefer, Sven Wischnowsky, zsh-workers
>
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Completion system directories
2000-05-03 10:30 ` Bart Schaefer
2000-05-03 11:03 ` Andrej Borsenkow
@ 2000-05-03 11:10 ` Peter Stephenson
2000-05-03 11:24 ` Geoff Wing
2000-05-03 11:35 ` Oliver Kiddle
2 siblings, 1 reply; 11+ messages in thread
From: Peter Stephenson @ 2000-05-03 11:10 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Completion system directories
2000-05-03 11:10 ` Peter Stephenson
@ 2000-05-03 11:24 ` Geoff Wing
2000-05-03 16:35 ` Bart Schaefer
0 siblings, 1 reply; 11+ messages in thread
From: Geoff Wing @ 2000-05-03 11:24 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Completion system directories
2000-05-03 10:30 ` Bart Schaefer
2000-05-03 11:03 ` Andrej Borsenkow
2000-05-03 11:10 ` Peter Stephenson
@ 2000-05-03 11:35 ` Oliver Kiddle
2000-05-03 16:23 ` CVS merge conflicts (Re: Completion system directories) Bart Schaefer
2 siblings, 1 reply; 11+ messages in thread
From: Oliver Kiddle @ 2000-05-03 11:35 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* CVS merge conflicts (Re: Completion system directories)
2000-05-03 11:35 ` Oliver Kiddle
@ 2000-05-03 16:23 ` Bart Schaefer
0 siblings, 0 replies; 11+ messages in thread
From: Bart Schaefer @ 2000-05-03 16:23 UTC (permalink / raw)
To: Oliver Kiddle, zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Completion system directories
2000-05-03 11:24 ` Geoff Wing
@ 2000-05-03 16:35 ` Bart Schaefer
2000-05-03 16:51 ` Peter Stephenson
0 siblings, 1 reply; 11+ messages in thread
From: Bart Schaefer @ 2000-05-03 16:35 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Completion system directories
2000-05-03 16:35 ` Bart Schaefer
@ 2000-05-03 16:51 ` Peter Stephenson
0 siblings, 0 replies; 11+ messages in thread
From: Peter Stephenson @ 2000-05-03 16:51 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2000-05-03 16:51 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-03 9:14 Completion system directories Sven Wischnowsky
2000-05-03 9:57 ` Adam Spiers
2000-05-03 10:52 ` Bart Schaefer
2000-05-03 10:30 ` Bart Schaefer
2000-05-03 11:03 ` Andrej Borsenkow
2000-05-03 11:10 ` Peter Stephenson
2000-05-03 11:24 ` Geoff Wing
2000-05-03 16:35 ` Bart Schaefer
2000-05-03 16:51 ` Peter Stephenson
2000-05-03 11:35 ` Oliver Kiddle
2000-05-03 16:23 ` CVS merge conflicts (Re: Completion system directories) Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).