zsh-workers
 help / color / mirror / code / Atom feed
From: Adam Spiers <adam@spiers.net>
To: zsh-workers@sunsite.auc.dk
Subject: Re: _files vs _path_files discussion (old thread)
Date: Sun, 12 Mar 2000 13:02:33 +0000	[thread overview]
Message-ID: <20000312130233.A4744@thelonious.new.ox.ac.uk> (raw)
In-Reply-To: <1000312062134.ZM27047@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Sun, Mar 12, 2000 at 06:21:34AM +0000

Thanks for these explanations Bart, and apologies for missing the
thread the first time round.

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> So you also need e.g.:
> 
> zstyle ':completion::complete:tar::directories' file-patterns '*(-/)'
> 
> You can of course replace :tar:: there with :*:*: to make all commands
> that use _files complete directories; but as Sven mentions in 9864,
> you may not want that, which is why the file-patterns are required to
> be given in the first place.

I've settled on the following for now, and it doesn't seem to have any
of the unwanted side-effects mentioned:

   # Include non-hidden directories in globbed file completions
   compstyle '::complete:*' \
     tag-order 'globbed-files directories' all-files 
   compstyle '::complete:*:*:directories' file-patterns '*~.*(-/)'

It's almost perfect ...  The only problem left is in the handling of
hidden directories; ideally, I would want hidden directories only to
appear when the leading `.' is specified manually, because I have so
many hidden directories in my home directory that they swamp the
initial completion list.  However, because they are not covered by the
file-patterns style for the directories tag, if I do:

   $ tar zxf .foodir/<TAB>

it's presumably using all-files, which has the initial problem of not
listing directories by default.  So what I'm really after is something
like:

   zstyle ':completion::complete:*:*:directories' \
     file-patterns '*(-/)'
   zstyle ':completion::complete:*:*:unhidden-directories' \
     file-patterns '*~.*(-/)'
   zstyle ':completion::complete:*' tag-order \
     'globbed-files unhidden-directories' \
     'globbed-files directories' \
     all-files

except that that doesn't work, presumably because you can't just dream
up new tags like that, and maybe you can't even mention tags twice in
tag-order.  So, is there a solution, and if not, would it be totally
unrealistic to allow something like the above zstyle code?  Actually,
even if that code worked, it still wouldn't quite do what I want,
because at the `.foodir/<TAB>' stage it would be completing from the
'globbed-files directories' bit (or would it?), which would mean that
it would list `.foodir/.bardir', which I wouldn't want it to.  Looks
like what I'm asking for would require considering each path component
separately.  Urgh.  Now my head's spinning.

> [*] Sven's suggested change was:
> } ... should we make the directories tag with its usual pattern be
> } tried automatically if the user explicitly sets the file-patterns tag
> } for globbed-files? Or should we do that only if the directories tag,
> } file-patterns style is given, but allow an empty value to stand for
> } `the normal pattern'?
> 
> I meant to reply to that and hadn't got around to it yet.
> 
> My short answer is that I don't think there's any good solution.  The
> tag-order style is going to be confusing no matter what we do; people
> are always going to wonder why, when they can see "directories" in the
> tag-order style, they still don't get any directories completed.  It's
> a case of intuition being at odds with logical semantics, and I can't
> think of any way to make the intuition work without ruining the logic.
> 
> Automatically adding directories when globbed-files is given only makes
> things cloudier; allowing an empty pattern to stand for '*(-/)' doesn't
> alleviate the need to provide the directories style, which is the real
> basis of the confusion.  So I think I'd leave the code as is, and put
> some kind of blaring all-caps text in the tag-order documentation:
> 
> NAMING A TAG IN TAG-ORDER DOES NOT CAUSE COMPLETIONS FOR THAT TAG TO BE
> GENERATED; RATHER, IT SORTS THE COMPLETIONS AFTER THEY ARE GENERATED.

I'd agree.  Actually, now I know the stuff in blaring all-caps, I
don't find it that confusing anyway.

> One additional thought:  It would be nice to be able to specify that
> _paths_ are completed, rather than merely directories; i.e. like the
> difference between "compctl -g '*(-/)'" and "compctl -/".  I'm not
> convinced that "zstyle *directories file-patterns '*(-/)'" does that.

What is the difference?  I can't see any, but I'm probably missing
something (again).

> Hrm, maybe even add "... BUT ONLY _IF_ ANY ARE GENERATED FOR THAT TAG."

Good plan.

Adam


  parent reply	other threads:[~2000-03-12 13:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-17  7:28 PATCH: _rpm tweaks (_files vs _path_files discussion) Sven Wischnowsky
2000-03-11 22:22 ` _files vs _path_files discussion (old thread) Adam Spiers
2000-03-12  0:18   ` Bart Schaefer
2000-03-12  0:51     ` Adam Spiers
2000-03-12  6:21       ` Bart Schaefer
2000-03-12  6:34         ` Bart Schaefer
2000-03-12 13:02 ` Adam Spiers [this message]
2000-03-12 19:43   ` Bart Schaefer
2000-03-12 20:14     ` Adam Spiers
2000-03-12 22:51       ` Bart Schaefer
2000-03-13 13:07 Sven Wischnowsky
2000-03-13 17:54 ` 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=20000312130233.A4744@thelonious.new.ox.ac.uk \
    --to=adam@spiers.net \
    --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).