zsh-users
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-users@sunsite.auc.dk
Subject: Re: configuring the new completion system
Date: Wed, 7 Jun 2000 05:26:51 +0000	[thread overview]
Message-ID: <1000607052651.ZM4901@candle.brasslantern.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0006061440350.1718-100000@phong.blorf.net>

On Jun 6,  3:22pm, Wayne Davison wrote:
} Subject: configuring the new completion system
}
} On Tue, 6 Jun 2000, Bart Schaefer wrote:
} > As a workaround, the following should behave the way you want:
} > 
} > bindkey '\t' complete-word
} > autoload -U compinit
} > compinit
} > zstyle ':completion:*' completer _expand _complete
} > zstyle ':completion:*:expand:::' glob 1
} > zstyle ':completion:*:expand:::' substitute 1
} 
} My biggest gripe is that if I type "~/.z" or "$HOME/.z" and press tab,
} the prefix expands into my home directory path.  I *hate* this.  I'm
} typing an abbreviated directory path and I want to complete an
} abbreviated directory path.  When I remove the "_expand" portion of
} the zstyle, then that part of the completion works properly, but I can
} no longer expand "~/.z*" into a list of file names.

I think you want to NOT rebind '\t' to complete-word -- that is, leave it
bound to expand-or-complete -- AND leave out the _expand completer.  This
will give you the old behavior of expansion followed by the new behavior
of completion.

You can still get the new behavior of _expand from <C-x e> in this case.

You could also ignore the recommendation in the manual, and do this:

    bindkey '\t' expand-or-complete
    zstyle ':completion:*' completer _complete _expand

This will first try old-style expansion, and then new-style completion,
and finally (if nothing else has happened yet) new-style expansion.

} On a related note, I've always disliked the fact that wildcard
} expansion expands variables and tilde references.  For instance, if I
} type:
} 
}     touch ~/.tmp{1..3}
}     rm ~/.tmp*<tab>

Unfortunately tilde-references are considered part of filename generation
for purposes of _expand.  Variables are another matter; that's what the
`substitute' style is for.  Set it to 0 instead of to 1, and parameter
expressions (including $(...) etc.) will not be expanded.

} I want to see:
} 
}     rm ~/.tmp1 ~/.tmp2 ~/.tmp3

What's amusing is that _expand behaved this way for a while, but somebody
else complained that he wanted the tildes to expand like they do with
expand-or-complete.

However, there's also the `completions' style:

    zstyle ':completion:*:expand:*' completions 1

If you set that style and do

    zsh% rm ~/.tmp<C-x e>

(note no `*') then you'll see what you wanted.  I would not recommend
using that with _expand in the completer style, though.  (If you want to
be able to have the `*' in there, you'll need to setopt globcomplete as
well.)

You could also set the style so that <C-x e> behaves that way ONLY if
the current word begins with a tilde, like so:

    zstyle ':completion:*:expand:*' completions '${(M)#PREFIX#\~}'

The tricky bit is backslashing the tilde there; I'm not sure why that's
required.  Anyway, the value of the completions style is evaluated in
$[...] and if that returns nonzero then instead of expansion, it does
completion, but inserts all possible completions.  So the above says
that if there's a substring that matches ~ at the front of the current
word, then expand all completions, otherwise do expansion as usual.

} Finally, one of the just-committed cvs changes has introduced a bug
} where an extra space is getting added when it shouldn't be.  Now, if
} you type "~/.z<tab>" you get "/home/wayne/.z " even though that file
} does not exist.  You should be able to reproduce this as follows:
} 
} % zsh -f
} % autoload -U compinit
} % compinit

You should use "compinit -D" to test the real default behavior; without
the -D it may load a .zcompdump that isn't up to date.

} % zstyle ':completion:*' completer _expand _complete
} % zstyle ':completion:*:expand:::' glob 1
} % ls ~/.z<tab>

Hmm, you're right, it's one of the *really* recent ones, probably either
11777 or 11776 (I hope not 11768).  I had to re-"make install" to see it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


  reply	other threads:[~2000-06-07  5:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-06  1:07 blah*[TAB] (difference between 3.1.6 and 3.1.9) Vincent Lefevre
2000-06-06  3:20 ` Bart Schaefer
2000-06-06  9:22   ` Vincent Lefevre
2000-06-06 22:22   ` configuring the new completion system Wayne Davison
2000-06-07  5:26     ` Bart Schaefer [this message]
2000-06-07  6:03       ` Wayne Davison

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=1000607052651.ZM4901@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=zsh-users@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).