Zsh Mailing List Archive
Messages sorted by:
Re: still confused about completion and matching
- X-seq: zsh-workers 13074
- From: "E. Jay Berkenbilt" <ejb@xxxxxx>
- To: wischnow@xxxxxxxxxxxxxxxxxxxxxxx
- Subject: Re: still confused about completion and matching
- Date: Tue, 24 Oct 2000 11:00:58 -0400
- Cc: zsh-workers@xxxxxxxxxxxxxx
- In-reply-to: <200010240744.JAA21146@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> (message from Sven Wischnowsky on Tue, 24 Oct 2000 09:44:42 +0200 (MET DST))
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <200010240744.JAA21146@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> > ...
> > If I omit "suffix" from :completion:*:paths expand, although
> > ls u?/ TAB
> > doesn't generate a superfluous / anymore,
> > ls u?/q/ TAB
> > still does.
> This is a different case. These are the automatically added slashes we
> get due to LIST_TYPES. I've got a patch for the C-code to fix it there.
> I'll commit it. We won't want it to ever add a file-type character
> after a slash anyway or do we?
Yes, I see. I can't imagine why you would ever want to add path
characters after /. The committed patch to the C code does indeed
seem to solve that problem.
> > ls u?/q/d TAB
> > lists u1/q/devel and u3/q/dark as it should. However,
> > ls u?/q/de TAB
> > doesn't list anything. Similarly,
> As you found out, this happened in cases where there was only one match.
> This was caused by the yet unchanged compadd around line 624 in _path_files
> which used pattern matching even if there was a pattern in a component in
> the -p-prefix (which is used using the match specs).
Okay, seems fine now.
> > ...
> > Finally,
> > ls u? TAB
> > works fine, but
> > ls ./u? TAB
> > makes the ? disappear from the commandline.
> A small problem with an attempt at additional cleverness in _match.
The most recent change to _match seems to cause it to revert to menu
completion in many cases. If I just completely remove lines 56 and 57
(dealing with unambiguous_cursor) then all my test cases work just the
way I want them to. The only thing I lose is earlier expansion in
some cases, but the result doesn't change the behavior or the amount
of typing required. I don't quite understand what the purpose of
those two lines are. I believe I understand what they literally mean,
but I don't understand why the behavior is desirable. Do they do
something important in a case that is excluded by my style settings?
What is the exact purpose of those lines?
I'm running now with the latest CVS release (including your path
characters after slash patch) and the latest round of patches here
with the unambiguous cursor code commented out. Everything is working
The only thing that differs from my original ideal description is that
if you have u1/q/something and u2/q/something, then u?/q/s TAB will
show both choices but will not complete out the something and show
u?/q/something. You already explained why that can't be done right
now though and it has an easy workaround since now u?/q/s*/ does
exactly the same thing as that would have done. The result can be
achieved in a maximum of two additional keystrokes.
So I guess what I'm saying is that the latest patches, after excluding
the unambiguous_cursor stuff, give me what I want. Assuming the
unambiguous_cursor stuff is actually serving a purpose that I fail to
see, can we make it conditional upon something I can turn off? I'd
suggest something but I don't have enough of a conceptual grasp of
what that code is doing to give the style a suitable name. Would the
next step be committing these changes and waiting for fallout? :-)
Thanks again for all your work on this!
Messages sorted by: