* Pattern matching with _files vs command line
@ 2016-09-09 5:39 Marko Myllynen
2016-09-10 2:40 ` Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Marko Myllynen @ 2016-09-09 5:39 UTC (permalink / raw)
To: zsh workers
Hi,
With the file-patterns style unset and the following compdef:
#compdef foo
local expl ret=1
_wanted files expl file _files -g '*(-FM)' && ret=0
return ret
I see the following difference, is this expected or perhaps a bug?
% find
.
./empty
./full
./full/test.txt
./file.txt
% ls -d *(-FM)
full/
% foo <TAB>
empty full full/
% foo empty/
Both the double match for full and empty being offered were
unexpected to me.
Thanks,
--
Marko Myllynen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pattern matching with _files vs command line
2016-09-09 5:39 Pattern matching with _files vs command line Marko Myllynen
@ 2016-09-10 2:40 ` Bart Schaefer
[not found] ` <20160911094221.GA18467@fujitsu.shahaf.local2>
2016-09-12 4:30 ` Pattern matching with _files vs command line Marko Myllynen
0 siblings, 2 replies; 6+ messages in thread
From: Bart Schaefer @ 2016-09-10 2:40 UTC (permalink / raw)
To: zsh workers
On Sep 9, 8:39am, Marko Myllynen wrote:
}
} _wanted files expl file _files -g '*(-FM)' && ret=0
}
} I see the following difference, is this expected or perhaps a bug?
It's perhaps a documentation shortcoming.
_files actually creates three groups of completion results:
globbed-files
directories
all-files
There's a little comment buried in _files:
# People prefer to have directories shown on first try as default.
# Even if the calling function didn't use -/.
So what you're seeing is both the globbed-files group and the directories
group. The all-files group is empty because the globbed-files group is
not.
The way around this is to use either the file-patterns style, or the
tag-order style. Either of these is supposed to work:
zstyle :completion::complete:foo:: file-patterns '%p:globbed-files'
zstyle :completion::complete:foo:: tag-order globbed-files -
HOWEVER, you've actually broken things with your glob pattern. Adding
the (M) flag means that the generated completions end with a "/" --
that is, the "/" is not just shown in the completion listing, it's
actually required to match against any partial word already on the
command line, which causes a variety of strange effects (including the
duplicates in your original listing). What you really mean is just:
--- 8< --- snip --- 8< ---
#compdef foo
_wanted files expl file _files -g '*(-F)'
--- 8< --- snip --- 8< ---
There's no need for the "ret" local if you're only making one call
to _wanted, you can just use the return value from that directly.
ADDITIONAL ASIDE to -workers: The weird side-effects that result
here from having the trailing "/" in the completion results seem
to be tangentially related to the thread from 39093 where the whole
current word gets erased. When all the completions end in "/", it
is the first unambigous character, so
% foo <TAB>
% foo /
with the curson on top of the "/". But now subsequent attempts to
complete end up looking for files in the root directory, because
the detail that there was an ambiguous prefix has been lost.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 39093 erases variant with slashes (was: Re: Pattern matching with _files vs command line)
[not found] ` <20160911094221.GA18467@fujitsu.shahaf.local2>
@ 2016-09-11 16:18 ` Bart Schaefer
0 siblings, 0 replies; 6+ messages in thread
From: Bart Schaefer @ 2016-09-11 16:18 UTC (permalink / raw)
To: zsh-workers
On Sep 11, 9:42am, Daniel Shahaf wrote:
} Subject: 39093 erases variant with slashes (was: Re: Pattern matching with
}
} Bart Schaefer wrote on Fri, Sep 09, 2016 at 19:40:33 -0700:
} > ADDITIONAL ASIDE to -workers: The weird side-effects that result
} > here from having the trailing "/" in the completion results seem
} > to be tangentially related to the thread from 39093 where the whole
} > current word gets erased. When all the completions end in "/", it
} > is the first unambigous character, so
} >
} > % foo <TAB>
} > % foo /
} >
}
} Could you share the reproducer for this please?
Run this anywhere with more than one subdirectory not all of which have
a common prefix; e.g., the zsh source tree:
torch% compinit -D
torch% _f () { _files -g '*(/M)' }
torch% compdef _f f
torch% zstyle \* file-patterns %p:globbed-files
torch% f <TAB>
torch% f /
If the zstyle is omitted, the groups globbed-files and directories contain
identical sets of matches but are for some reason not de-duped against one
another (probably because none of them matches an actual file name) so you
get a listing instead of the unambiguous-insertion behavior.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pattern matching with _files vs command line
2016-09-10 2:40 ` Bart Schaefer
[not found] ` <20160911094221.GA18467@fujitsu.shahaf.local2>
@ 2016-09-12 4:30 ` Marko Myllynen
2016-09-12 15:18 ` Bart Schaefer
1 sibling, 1 reply; 6+ messages in thread
From: Marko Myllynen @ 2016-09-12 4:30 UTC (permalink / raw)
To: zsh-workers
Hi,
On 2016-09-10 05:40, Bart Schaefer wrote:
> On Sep 9, 8:39am, Marko Myllynen wrote:
> }
> } _wanted files expl file _files -g '*(-FM)' && ret=0
> }
> } I see the following difference, is this expected or perhaps a bug?
>
> It's perhaps a documentation shortcoming.
>
> _files actually creates three groups of completion results:
> globbed-files
> directories
> all-files
>
> There's a little comment buried in _files:
>
> # People prefer to have directories shown on first try as default.
> # Even if the calling function didn't use -/.
>
> So what you're seeing is both the globbed-files group and the directories
> group. The all-files group is empty because the globbed-files group is
> not.
>
> The way around this is to use either the file-patterns style, or the
> tag-order style. Either of these is supposed to work:
>
> zstyle :completion::complete:foo:: file-patterns '%p:globbed-files'
Thanks, this did the trick!
> zstyle :completion::complete:foo:: tag-order globbed-files -
This, however, doesn't seem to work: with or without the former this
stops completion for foo altogether.
> HOWEVER, you've actually broken things with your glob pattern. Adding
> the (M) flag means that the generated completions end with a "/" --
> that is, the "/" is not just shown in the completion listing, it's
> actually required to match against any partial word already on the
> command line, which causes a variety of strange effects (including the
> duplicates in your original listing). What you really mean is just:
>
> --- 8< --- snip --- 8< ---
> #compdef foo
> _wanted files expl file _files -g '*(-F)'
> --- 8< --- snip --- 8< ---
>
> There's no need for the "ret" local if you're only making one call
> to _wanted, you can just use the return value from that directly.
Yeah, it was a copypaste from a larger function which wanted ret.
Thanks,
--
Marko Myllynen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pattern matching with _files vs command line
2016-09-12 4:30 ` Pattern matching with _files vs command line Marko Myllynen
@ 2016-09-12 15:18 ` Bart Schaefer
2016-09-12 15:34 ` Marko Myllynen
0 siblings, 1 reply; 6+ messages in thread
From: Bart Schaefer @ 2016-09-12 15:18 UTC (permalink / raw)
To: zsh-workers
On Sep 12, 7:30am, Marko Myllynen wrote:
}
} On 2016-09-10 05:40, Bart Schaefer wrote:
} > On Sep 9, 8:39am, Marko Myllynen wrote:
} > }
} > } _wanted files expl file _files -g '*(-FM)' && ret=0
} >
} > # People prefer to have directories shown on first try as default.
} > # Even if the calling function didn't use -/.
} >
} > zstyle :completion::complete:foo:: file-patterns '%p:globbed-files'
}
} Thanks, this did the trick!
}
} > zstyle :completion::complete:foo:: tag-order globbed-files -
}
} This, however, doesn't seem to work: with or without the former this
} stops completion for foo altogether.
Yes, that's connected to this:
} > HOWEVER, you've actually broken things with your glob pattern. Adding
} > the (M) flag means that the generated completions end with a "/"
If you fix the glob pattern to remove the (M) qualifier, then tag-order
works (at least for me). If you leave the (M) in there, tag-order is
broken. I don't really understand why this is the case; it seems to
have something to do with whether the string passed to "compadd" really
does match a file name (which it won't when the "/" is appended).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pattern matching with _files vs command line
2016-09-12 15:18 ` Bart Schaefer
@ 2016-09-12 15:34 ` Marko Myllynen
0 siblings, 0 replies; 6+ messages in thread
From: Marko Myllynen @ 2016-09-12 15:34 UTC (permalink / raw)
To: zsh-workers
Hi,
On 2016-09-12 18:18, Bart Schaefer wrote:
> On Sep 12, 7:30am, Marko Myllynen wrote:
> }
> } On 2016-09-10 05:40, Bart Schaefer wrote:
> } > On Sep 9, 8:39am, Marko Myllynen wrote:
> } > }
> } > } _wanted files expl file _files -g '*(-FM)' && ret=0
> } >
> } > # People prefer to have directories shown on first try as default.
> } > # Even if the calling function didn't use -/.
> } >
> } > zstyle :completion::complete:foo:: file-patterns '%p:globbed-files'
> }
> } Thanks, this did the trick!
> }
> } > zstyle :completion::complete:foo:: tag-order globbed-files -
> }
> } This, however, doesn't seem to work: with or without the former this
> } stops completion for foo altogether.
>
> Yes, that's connected to this:
>
> } > HOWEVER, you've actually broken things with your glob pattern. Adding
> } > the (M) flag means that the generated completions end with a "/"
>
> If you fix the glob pattern to remove the (M) qualifier, then tag-order
> works (at least for me). If you leave the (M) in there, tag-order is
> broken.
Sorry, should have mentioned that I tested already without (M). Both
with 5.0.2 and latest git master (otherwise I had default zstyle
settings). Since the earlier stanza already solved the issue, not sure
is this worth pursuing further.
Thanks,
--
Marko Myllynen
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-09-12 15:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-09 5:39 Pattern matching with _files vs command line Marko Myllynen
2016-09-10 2:40 ` Bart Schaefer
[not found] ` <20160911094221.GA18467@fujitsu.shahaf.local2>
2016-09-11 16:18 ` 39093 erases variant with slashes (was: Re: Pattern matching with _files vs command line) Bart Schaefer
2016-09-12 4:30 ` Pattern matching with _files vs command line Marko Myllynen
2016-09-12 15:18 ` Bart Schaefer
2016-09-12 15:34 ` Marko Myllynen
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).