Re: Completion in pwd before subdirecories

Re: Completion in pwd before subdirecories

[Bart Schaefer]

On Dec 15, 12:49pm, Oliver Kiddle wrote:
}
}   zstyle ':completion:*' file-patterns \
}       '*(-/):directories %p(^-/):globbed-files' '*:all-files'
} 
} Unfortunately, that will now break for any completion which specifies a
} glob qualifier such as _chown.

Are you sure about that?

} I've been meaning to go through adding `#q' into all of them

There's code in _files to attempt to merge together any trailing stuff
that looks like glob qualifiers, because _files predates the #q flag.
In fact, I'm suspicious that adding #q might actually break things.

} I'm not quite sure whether the default file-patterns style shouldn't
} use %p(^-/) for globbed-files anyway.

I don't think I understand the question.

Are you suggesting that we should split the existing globbed-files default
into globbed-files and globbed-directories?  I.e., so that instead of the
default ordering of

    globbed-files directories all-files

we'd have

    globbed-files globbed-directories all-directories all-files 

or something like that?

} What if we want to glob directory names from a completion function?

I'm not making the connection between that question and the previous one.

However, nothing stops any completion function from doing something like

    zstyle -m ":completion:${curcontext}:" file-patterns '*' ||
	zstyle ":completion:${curcontext}:" file-patterns \
	    '%p(-/):directories %p(^-/):globbed-files' '*:all-files'

Re: Completion in pwd before subdirecories

[Peter Stephenson]

Bart Schaefer wrote:
> There's code in _files to attempt to merge together any trailing stuff
> that looks like glob qualifiers, because _files predates the #q flag.
> In fact, I'm suspicious that adding #q might actually break things.

How?

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


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Completion in pwd before subdirecories

[Bart Schaefer]

On Dec 15,  5:09pm, Peter Stephenson wrote:
}
} Bart Schaefer wrote:
} > There's code in _files to attempt to merge together any trailing stuff
} > that looks like glob qualifiers, because _files predates the #q flag.
} > In fact, I'm suspicious that adding #q might actually break things.
} 
} How?

I haven't deciphered in detail the subst-expression that's used to patch
this all up, but I'm worried that if you start with e.g. *(r) on the
command line, and then the completion function appends e.g. (#q*), and
then the file-patterns style is %p(^-/), you end up with something like

	*(r)(#q*)(^-/)

and then the substitution will fail to collapse it all the way down to

	*(r*^-/)

because the #q in the middle won't match the expression in _files.

Re: Completion in pwd before subdirecories

[Oliver Kiddle]

Bart wrote:
> On Dec 15, 12:49pm, Oliver Kiddle wrote:
> }
> }   zstyle ':completion:*' file-patterns \
> }       '*(-/):directories %p(^-/):globbed-files' '*:all-files'
> } 
> } Unfortunately, that will now break for any completion which specifies a
> } glob qualifier such as _chown.
> 
> Are you sure about that?

No. Sorry, didn't test it so based on what you say below, I'm probably
wrong.

> There's code in _files to attempt to merge together any trailing stuff
> that looks like glob qualifiers, because _files predates the #q flag.
> In fact, I'm suspicious that adding #q might actually break things.

I'll have to test. I seem to remember it not working once in the past.

> } I'm not quite sure whether the default file-patterns style shouldn't
> } use %p(^-/) for globbed-files anyway.
> 
> I don't think I understand the question.

For that you need to look back at the original question on -users and
look at why the file-patterns style above was needed. Patterns like *
match directories so the directories were completed twice. This meant
the directory got completed in the globbed-files group before the
directories group was reached. Working out that the file-patterns style
is needed and why is not obvious. So I wondered whether the default
file-patterns style shouldn't be this.

> Are you suggesting that we should split the existing globbed-files default
> into globbed-files and globbed-directories?  I.e., so that instead of the

I wasn't suggesting that but it is an idea that may be worth thinking
about.

> } What if we want to glob directory names from a completion function?
> 
> I'm not making the connection between that question and the previous one.
> 
> However, nothing stops any completion function from doing something like
> 
>     zstyle -m ":completion:${curcontext}:" file-patterns '*' ||
> 	zstyle ":completion:${curcontext}:" file-patterns \
> 	    '%p(-/):directories %p(^-/):globbed-files' '*:all-files'
> 

Doing that from every completion function which just wants to glob for
a certain file extension is not pleasant.

It has never seemed ideal to me that, for example, gunzip completion
will complete a directory called dir.gz even if the user has
directories after files in their file-patterns style. Ideally we should
tidy things up from the completion functions and not expect user's to
set the file-patterns style for every command.

For the majority of commands we use something like _files -g '*.gz' to
specify a filename extension. These should ideally not match
directories. For some commands like chown, we use a more complex glob
where it is valid to match directories (though some user's may still
want directory completion deferred).

One option might be for _files to add the (^-/) when substituting
%p and to add a -/g option to suppress this when the glob should also
match directories. We could even have other escapes in addition to %p
which give the user more control. A user who relies on _next_tags to
get at directories may want explicitly globbed directories first for
commands like chown.

Oliver

Re: Completion in pwd before subdirecories

[Bart Schaefer]

On Dec 15,  7:56pm, Oliver Kiddle wrote:
}
} It has never seemed ideal to me that, for example, gunzip completion
} will complete a directory called dir.gz even if the user has
} directories after files in their file-patterns style. Ideally we should
} tidy things up from the completion functions and not expect user's to
} set the file-patterns style for every command.
} 
} For the majority of commands we use something like _files -g '*.gz' to
} specify a filename extension. These should ideally not match
} directories.

So why aren't we using "_files -g '*.gz(.)'" in that case?

The most general case is that we want globs to match both directories and
files.  If the user is actually completing (rather than expanding) a word
containing a glob pattern, in the absence of other info (such as that gzip
can't inflate a directory) I'd think the user expectation is that all the
matches get lumped together.

It's quite possible that I'm still missing something, though.

} One option might be for _files to add the (^-/) when substituting
} %p and to add a -/g option to suppress this when the glob should also
} match directories.

I'm not convinced that this wouldn't amount to coding for a fringe case
and turning the most common situation into an option.

} We could even have other escapes in addition to %p which give the user
} more control. A user who relies on _next_tags to get at directories
} may want explicitly globbed directories first for commands like chown.

I agree in principle with that, though.

Re: Completion in pwd before subdirecories

[Oliver Kiddle]

Bart wrote:
> 
> So why aren't we using "_files -g '*.gz(.)'" in that case?

That's actually a much better plan. I was thinking in terms of keeping
the most common case simple instead of the most general case but I think
you're right.

That'll need patching a lot of files so unless someone else wants to
volunteer I'll try to find time to do it at some stage.

> It's quite possible that I'm still missing something, though.

We still need to ask whether the user should need a file-patterns style
to achieve directories after files for the original menu completion
question. Is globbed-files somewhere defaulting to `*'. Should it
perhaps default to `*(.)'? I've not looked at _files but try ^Xh after
something like `cat' or `:' with and without a file-patterns style.

Oliver

Re: Completion in pwd before subdirecories

[Bart Schaefer]

On Dec 15,  9:07pm, Oliver Kiddle wrote:
}
} Bart wrote:
} > 
} > So why aren't we using "_files -g '*.gz(.)'" in that case?
} 
} That's actually a much better plan.

I suppose really it should be "_files -g '*.gz(-.)'" ...

} We still need to ask whether the user should need a file-patterns style
} to achieve directories after files for the original menu completion
} question.

I presume this only applies in the case of also using the group-name and
group-order styles, because otherwise you don't get them separated in the
first place.

} Is globbed-files somewhere defaulting to `*'. Should it
} perhaps default to `*(.)'? I've not looked at _files but try ^Xh after
} something like `cat' or `:' with and without a file-patterns style.

It depends.

By default without a file-patterns style the only group is `*:all-files'.
So you have to have the file-patterns style to get any differentiation
at all.

tags in context :completion::complete:cat::
    all-files  (_files _default)

For commands that use "_files -g ..." the pattern passed in with -g is
used for globbed-files.

tags in context :completion::complete:gcc::
    argument-rest options  (_arguments _gcc)
tags in context :completion::complete:gcc:argument-rest:
    globbed-files  (_files _arguments _gcc) 
    directories    (_files _arguments _gcc) 
    all-files      (_files _arguments _gcc)

E.g. for "-g foo" it would be

    "foo:globbed-files *(-/):directories" "*:all-files"

Note that directories and globbed-files are completed together, which
normally means the extra directory would be suppressed as a duplicate.
It's only when wanting to split globbed-files and directories that you
see some directories twice, and that would be suppressed by using the
appropriate flags on the argument of -g.

Re: Completion in pwd before subdirecories

[Oliver Kiddle]

Bart wrote:

> I suppose really it should be "_files -g '*.gz(-.)'" ...

Yes. And I'm now convinced that we should make that change throughout.

Only, in my testing, I have to include a `#q' for it to work so _files'
merging of glob qualifiers must have problems somewhere.

The manual includes this example:
          zstyle ':completion:*' file-patterns \
              '%p:globbed-files' '*(-/):directories' '*:all-files'

We perhaps ought to point out that the globbed-files may include
directories and the user may want to use '%p(^-/):globbed-files' to
have all directories completed later.

> } We still need to ask whether the user should need a file-patterns style
> } to achieve directories after files for the original menu completion
> } question.

I've just realised that this is of course solved by using things like
'*.gz(-.)'.

Unfortunately, things are broken by the many completion functions which
do something like:

  _wanted files expl file _files -g '*.gz(-.)'

The `files' group takes precedence and everything ends up back in one
group.

So we're back to the old problem of precedence of compadd options in
nested tag loops.

Oliver

Re: Completion in pwd before subdirecories

[Oliver Kiddle]

Bart wrote:

> There's code in _files to attempt to merge together any trailing stuff
> that looks like glob qualifiers, because _files predates the #q flag.
> In fact, I'm suspicious that adding #q might actually break things.

Where?

I can't find it anywhere in _files and if it is in _path_files then it
doesn't work. Try: _foo() { _files -g '*.gz(.)(.)' }

So either we need to add #q when using glob qualifiers or _files should
attempt to merge trailing glob qualifiers. I favour the latter.

So _files needs to match a trailing glob qualifier in the parameter to
-g and stick #q in. Can a glob qualifier contain quoted parenthesis?

Oliver

Re: Completion in pwd before subdirecories

[Bart Schaefer]

On Dec 17,  4:57pm, Oliver Kiddle wrote:
}
} Bart wrote:
} 
} > There's code in _files to attempt to merge together any trailing stuff
} > that looks like glob qualifiers, because _files predates the #q flag.
} > In fact, I'm suspicious that adding #q might actually break things.
} 
} Where?

Hrm.  I thought I'd found it the other day but now I can't any more.  I
believe it _used_ to be there (or in _path_files) because Sven grumbled
at least once about how difficult it was to write.  But maybe something
changed so that it was possible for it to be taken out again.

In fact, that may have been what led to the introduction of (#q) in the
first place.

I'm sorry, I've been seriously ill these past three days and my concetration
is shot.

} So either we need to add #q when using glob qualifiers or _files should
} attempt to merge trailing glob qualifiers. I favour the latter.

Good luck, then.

Re: Completion in pwd before subdirecories

[Oliver Kiddle]

Bart wrote:
> 
> Hrm.  I thought I'd found it the other day but now I can't any more.  I
> believe it _used_ to be there (or in _path_files) because Sven grumbled
> at least once about how difficult it was to write.  But maybe something
> changed so that it was possible for it to be taken out again.

Doing a bit of a search in the archives, the nearest I can find is
11635. That deals with _path_files and glob qualifiers on the
command-line when doing pattern based matching. Is that perhaps what
you were thinking of?

> In fact, that may have been what led to the introduction of (#q) in the
> first place.

It was a comment by me in 16447 that led to (#q). I was suggesting
using things like -g '*.png(.)' back then so must have been thinking
clearer than earlier this week. I managed to forget why I had wanted to
add qualifiers in series but it might have been for the file-patterns
style.

> } So either we need to add #q when using glob qualifiers or _files should
> } attempt to merge trailing glob qualifiers. I favour the latter.
> 
> Good luck, then.
> 

The documentation is fairly clear that a glob qualifier is a trailing
set of parentheses containing no `|', `(' (or `~' if it is special).
Not sure I understand what the "if it is special" means - anyone? The
_path_files stuff from 11635 believes the documentation, using the 
pattern \([^\|\~]##\)
So the patch below (to _files) uses that pattern to find a glob
qualifier in the argument to the -g option and sticks a #q in.

Unfortunately, the documentation doesn't give the whole story:
  *(e:'[[ -d ~/$REPLY || -d ../$REPLY ]]':) and
  *(e:'(( 1 ))':)
both work. Seems to me that anything is valid just so long as it is
quoted. *(e'|'true'|') works while *(e|true|) doesn't.

So how do I match a quoted string with a glob? Does anyone have something
already? Is it even possible given nested quoting?

The only thing I can think of would be to dig into the C and add a
globbing flag which matches quoted characters, unquoting them before
matching so I could do something like:
 \(([^\|\~]|(#U)*(#u))##\)

I'm inclined to apply this patch as it is for now. I can't see any
existing uses of qualifiers with quotes and we could always add `#q'
manually for the odd case and exclude quotes along with |, ( and ~ in
_files.

My tip for the day for taking advantage of this change is this style:

zstyle ':completion:*:approximate*:*' file-patterns \
    '%p(D):globbed-files *(D-/):directories' '*(D):all-files'

With that, _approximate can correct `,zshrc' to `.zshrc'.

Now for the dull job of adding lots of (-.) qualifiers.

Oliver

PS. Hope you get well soon Bart.

Index: Completion/Unix/Type/_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_files,v
retrieving revision 1.8
diff -u -r1.8 _files
--- Completion/Unix/Type/_files	4 Jul 2003 18:19:20 -0000	1.8
+++ Completion/Unix/Type/_files	18 Dec 2003 09:24:24 -0000
@@ -11,6 +11,10 @@
   glob="${${${${(@M)tmp:#-g*}#-g}##[[:blank:]]#}%%[[:blank:]]#}"
   [[ "$glob" = *[^\\][[:blank:]]* ]] &&
       glob="{${glob//(#b)([^\\])[[:blank:]]##/${match[1]},}}"
+
+  # add `#q' to the beginning of any glob qualifier if not there already
+  [[ "$glob" = (#b)(*\()([^\|\~]##\)) && $match[2] != \#q* ]] &&
+      glob="${match[1]}#q${match[2]}"
 fi
 tmp=$opts[(I)-F]
 if (( tmp )); then