zsh-workers
 help / color / mirror / code / Atom feed
From: "E. Jay Berkenbilt" <ejb@ql.org>
To: wischnow@informatik.hu-berlin.de
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: still confused about completion and matching
Date: Tue, 24 Oct 2000 11:00:58 -0400	[thread overview]
Message-ID: <200010241500.LAA05877@soup.ql.org> (raw)
In-Reply-To: <200010240744.JAA21146@beta.informatik.hu-berlin.de> (message from Sven Wischnowsky on Tue, 24 Oct 2000 09:44:42 +0200 (MET DST))


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

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!

                                Jay


  reply	other threads:[~2000-10-24 15:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-24  7:44 Sven Wischnowsky
2000-10-24 15:00 ` E. Jay Berkenbilt [this message]
2000-10-24 15:15   ` Bart Schaefer
2000-10-24 15:28     ` Andrej Borsenkow
  -- strict thread matches above, loose matches on Subject: below --
2000-10-25  7:50 Sven Wischnowsky
2000-11-06 15:34 ` E. Jay Berkenbilt
2000-10-25  7:12 Sven Wischnowsky
2000-10-25  7:41 ` Andrej Borsenkow
2000-10-23 13:20 Sven Wischnowsky
2000-10-19  9:11 Sven Wischnowsky
2000-10-20 16:38 ` E. Jay Berkenbilt
2000-10-20 16:57   ` Andrej Borsenkow
2000-10-20 20:45     ` E. Jay Berkenbilt
2000-10-23  7:15       ` Andrej Borsenkow
2000-10-23 13:11         ` E. Jay Berkenbilt
2000-10-16  8:05 Sven Wischnowsky
2000-10-17 19:30 ` E. Jay Berkenbilt
2000-10-13 11:03 Sven Wischnowsky
2000-10-12 19:56 E. Jay Berkenbilt
2000-10-12 20:32 ` E. Jay Berkenbilt
2000-10-16  5:01 ` Bart Schaefer

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=200010241500.LAA05877@soup.ql.org \
    --to=ejb@ql.org \
    --cc=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).