paths vs files tags

paths vs files tags

[Andrej Borsenkow]

Both are tested in _path_files only and both are used to configure _path_files
behaviour. Are they not redundant?

Just thinking about KISS rule.

-andrej

Have a nice DOS!
B >>

RE: paths vs files tags

[Sven Wischnowsky]

I wrote:

> ...
> 
> So, may I commit it?

There wasn't much of an uproar, so I've now committed it. I really
prefer to have this cleaned up, as we did with other tags some time
ago.

As a reminder, this patch changes some tags used for looking up styles 
in filename completion, namely:

  file-sort       no tag
  fake-files      no tag
  ignore-parents  no tag
  accept-exact    `paths' tag

Bye
 Sven


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

RE: paths vs files tags

[Sven Wischnowsky]

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

RE: paths vs files tags

[Andrej Borsenkow]

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

-andrej

Re: paths vs files tags

[Sven Wischnowsky]

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

Bye
 Sven


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