zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: RE: paths vs files tags
Date: Thu, 19 Oct 2000 11:02:10 +0200 (MET DST)	[thread overview]
Message-ID: <200010190902.LAA15815@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Andrej Borsenkow"'s message of Wed, 18 Oct 2000 11:26:12 +0400


Andrej Borsenkow wrote:

> > Andrej Borsenkow wrote:
> > 
> > > Both are tested in _path_files only and both are used to 
> > configure _path_files
> > > behaviour. Are they not redundant?
> > 
> > I've been wondering about this, too.  Initially I did that to
> > distinguish between styles that affect single components and those
> > that affect whole paths. But maybe we could reasonably change it.
> > 
> > And then use `files' or `paths'?
> 
> paths is more close to the semantic, but files is easier to pronounce :-)
> 
> I vote for paths. 

After looking again: yes and no. For some styles I would suggest to
use no tag at all (see the patch below, not yet committed). There is
also another reason to use `paths': that tag is used nowhere else, but 
`files' is the standard tag used by _files if no tag is specified in
the file-patterns style.

I've not committed this because I'm not sure how much it'll break
(I've not even looked at compinstall, yet). But I like this patch --
we've done such a tag-cleanup before (and using a tag together with
the file-sort and fake-files styles is really redundent, as their
names clearly show).

So, may I commit it?

Bye
 Sven

--- ../oz/Completion/Core/_path_files	Wed Oct 18 22:26:23 2000
+++ Completion/Core/_path_files	Wed Oct 18 22:37:26 2000
@@ -96,7 +96,7 @@
 
 (( $#matcher )) && mopts=( "$mopts[@]" "$matcher[@]" )
 
-if zstyle -s ":completion:${curcontext}:files" file-sort tmp1; then
+if zstyle -s ":completion:${curcontext}:" file-sort tmp1; then
   case "$tmp1" in
   *size*)             sort=oL;;
   *links*)            sort=ol;;
@@ -141,10 +141,10 @@
 [[ "$pats" = ((|*[[:blank:]])\*(|[[:blank:]]*)|*\([^[:blank:]]#/[^[:blank:]]#\)*) ]] &&
     sopt=$sopt/
 
-zstyle -a ":completion:${curcontext}:files" accept-exact accex
-zstyle -a ":completion:${curcontext}:files" fake-files fake
+zstyle -a ":completion:${curcontext}:paths" accept-exact accex
+zstyle -a ":completion:${curcontext}:" fake-files fake
 
-zstyle -s ":completion:${curcontext}:files" ignore-parents ignpar
+zstyle -s ":completion:${curcontext}:" ignore-parents ignpar
 
 if [[ -n "$compstate[pattern_match]" &&
       ( ( -z "$SUFFIX" && "$PREFIX" = (|*[^\$])\([^\|\~]##\) ) ||
--- ../oz/Doc/Zsh/compsys.yo	Wed Oct 18 22:26:14 2000
+++ Doc/Zsh/compsys.yo	Wed Oct 18 22:42:41 2000
@@ -848,7 +848,7 @@
 same as the string on the line, this match will immediately be
 accepted.
 
-When completing filenames (where it is looked up for the tt(files)
+When completing pathnames (where it is looked up for the tt(paths)
 tag), this style also accepts any number of patterns as the value. If
 this is used, pathnames matching one of these patterns will be
 accepted immediately even if the command line contains some more
@@ -1014,8 +1014,8 @@
 )
 kindex(fake-files, completion style)
 item(tt(fake-files))(
-Currently, this style is only used when completing files and looked up 
-with the tag tt(files).  Its values are of the form
+This style is used when completing files and looked up 
+without a tag.  Its values are of the form
 `var(dir)tt(:)var(names...)'.  This will add the var(names) (strings
 separated by spaces) as
 possible matches when completing in the directory var(dir), even if no 
@@ -1098,7 +1098,7 @@
 kindex(file-sort, completion style)
 item(tt(file-sort))(
 The completion function that generates filenames as possible matches
-uses this style with the tt(files) tag to determine in which order the 
+uses this style without a tag to determine in which order the 
 names should be listed and completed when using menu completion.  The
 value may be one of `tt(size)' to sort them by the size of the file,
 `tt(links)' to sort them by the number of links to the file,
@@ -1271,7 +1271,8 @@
 )
 kindex(ignore-parents, completion style)
 item(tt(ignore-parents))(
-The style is tested for the tt(files) tag to determine whether to ignore
+The style is tested by the function completing pathnames without a tag to
+determine whether to ignore
 the names of directories already mentioned in the current word, or the
 name of the current working directory.  The value must include one or both
 of the following strings:

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


             reply	other threads:[~2000-10-19  9:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-19  9:02 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-10-23  8:10 Sven Wischnowsky
2000-10-18  7:14 Sven Wischnowsky
2000-10-18  7:26 ` Andrej Borsenkow
2000-10-18  6:32 Andrej Borsenkow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200010190902.LAA15815@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).