zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.dk
Subject: RE: Getting context sensitive glob expansions using new completion
Date: Mon, 13 Aug 2001 12:53:49 +0200	[thread overview]
Message-ID: <15223.45501.691717.93669@gargle.gargle.HOWL> (raw)
In-Reply-To: <OF5525F00D.F26F93BD-ON80256AA7.0038BB55@uk.jpmorgan.com>


martin.ebourne@arcordia.com wrote:

> > Borsenkow Andrej wrote:
> 
> > Alternatively one can make _all_matches insert a pseudo-match for all
> > results from _match, if any:
> 
> >   zstyle ':completion:*' completer _complete _all_matches _match
> >   zstyle ':completion:*:match:*' group-order all-matches
> 
> Thanks, that nearly does what I want. However, I think that tag-order
> should do exactly what I want. As in the line I tried previously:
> 
>   zstyle ':completion:*:match:*' tag-order all-matches
> 
> However, this seems to have no effect. Why is that?

That's because all-matches is used *after* the real matches have been
generated and *on* the matches generated.  _all_matches really only
adds a pseudo-match containing the real matches, so of course those
have to be there...

One could at least hide the other matches from the display using the
`hidden' style (there was a buglet for that in _path_files, patch
below), but that'll really only keep them from being listed.

> > But the question is: do you really want that?  The consens on this
> > list seems to be now that _all_matches is most useful as a separate
> > widget.  I.e. you set up completion as you like, without thinking
> > about the possibility to insert all matches.  Then you add a new
> > binding as described in the manual for _all_matches:
> >   zle -C all-matches complete-word _generic
> >   bindkey '^Xa' all-matches
> >   zstyle ':completion:all-matches:*' old-matches only
> >   zstyle ':completion:all-matches:*' completer _all_matches
> > And voila, now you can use normal completion until you have the set
> > matches you want to insert in the line and then hit ^Xa to do that.
> 
> Well I guess its just what I'm used to. Currently I tab to expand the line
> and if I don't like it I just undo (ctrl-/), which has always been how Zsh
> used to do it. Having said that I like the sound of what you suggest here
> so I'll try that out. Some habits are worth changing. ;)

Well, zsh couldn't `expand' to all *completions* before...

> As an aside, the completion system is extremely powerful and not a little
> bit difficult to understand and configure when completely new to it.
> There's also lots of these little nuggets of information which can help
> configure it how you like. Some of them are in various places in the
> manual, some on this list, and most are probably still 'secret'. What I
> think would be really useful is a hints & tips section in the manual. Kind
> of 'if you want this - do this'.

Yes.  Noone took the time to collect (or invent) such questions and
answers.  Peter's User's Guide (available www.zsh.org) is at least a
whole lot more readable.

I guess we just had enough to do with writing all that code and the
manual :-}


Bye
  Sven

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.9
diff -u -r1.9 _path_files
--- Completion/Unix/Type/_path_files	2001/07/13 12:30:21	1.9
+++ Completion/Unix/Type/_path_files	2001/08/13 10:47:36
@@ -17,7 +17,7 @@
 zparseopts -a mopts \
     'P:=pfx' 'S:=pfxsfx' 'q=pfxsfx' 'r:=pfxsfx' 'R:=pfxsfx' \
     'W:=prepaths' 'F:=ignore' 'M+:=matcher' \
-    J+: V+: X+: 1: 2: n: 'f=tmp1' '/=tmp1' 'g+:-=tmp1'
+    J+: V+: X+: 1 2 n 'f=tmp1' '/=tmp1' 'g+:-=tmp1'
 
 sopt="-${(@j::M)${(@)tmp1#-}#?}"
 (( $tmp1[(I)-[/g]*] )) && haspats=yes

-- 
Sven Wischnowsky                    wischnow@informatik.hu-berlin.de


           reply	other threads:[~2001-08-13 10:54 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <OF5525F00D.F26F93BD-ON80256AA7.0038BB55@uk.jpmorgan.com>]

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=15223.45501.691717.93669@gargle.gargle.HOWL \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.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).