From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference between 3.1.6 and 3.1.9))
Date: Wed, 7 Jun 2000 08:46:02 +0200 (MET DST) [thread overview]
Message-ID: <200006070646.IAA11684@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Tue, 6 Jun 2000 16:44:23 +0000
Bart Schaefer wrote:
> ...
>
> I'm sorry; I was trying zsh-3.1.7 -f ... it behaves as Sven says in 3.1.9,
> though I don't understand why they differ.
Dunno either, I can only remember the 3.1.9 behaviour...
> And this part still puzzles me:
>
> } And if your tag-order were going to matter, shouldn't it need to be:
> }
> } zstyle ':completion:*:expand:*' tag-order - all-expansions
> }
> } because
> } If any string in the value consists of only a hyphen, then
> } *only* the tags specified by the other strings in the value
> } are generated. Normally all tags not explicitly selected are
> } tried last if the specified tags fail to generate any
> } matches.
>
> Is that doc excerpt wrong now?
No. It's tag-order: try sets of tags one after another until one
generates matches, then stop. Since in _expand all tags succeed (if
there are expansions at all), it will never come to try the second set
(and, for that reason, _expand doesn't even have a tag loop).
Wayne Davison wrote:
> ...
>
> 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 would love to
> see a version of _expand that works like it did in 3.0.x.
You can also try the substs-globs-only style.
> On a related note, I've always disliked the fact that wildcard
> expansion expands variables and tilde references.
Maybe we should add a style for this...
> 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:
We are talking about *expansion* here. If you do `echo ~/.z', what do
you see? What does it *expand* to?
Bart's answer to this:
> It was 11777. Confusion about a double-negative, or something like that.
> Sven changed a test to be:
>
> if ! zstyle -T ":completion:${curcontext}:" add-space; then
>
> Either it should go back to what it was before:
>
> if zstyle -T ":completion:${curcontext}:" add-space; then
>
> Or else it should use `-t':
>
> if ! zstyle -t ":completion:${curcontext}:" add-space; then
>
> The two are subtly different; the former means "no value for add-space is
> set to for the current context" and the latter means "it is not the case
> that add-space is set to one of `true', `yes', `on' or `1' for the current
> context."
I know all that. And I still insist, that the current behaviour is
correct; from the docs:
item(tt(add-space))(
This style is used by the tt(_expand) completer. If it is `true' (the
default), a space will be inserted after all words resulting from the
expansion (except for directory names which get a slash).
So, it appends a space to the generated expansion.
What you folks really want is a more sophisticated add-space
behaviour, namely (I'm guessing ;-): if add-space if false, never add
a space; if it is true, add a space if the generated word is the name
of an existing file. But then I would insist, that we change add-space
to:
- true: always add a space (after all, one might want to use it to
generate names of non-existing files)
- false: never add a space
- exisiting: add a space only if the word is the name of an
exisiting file
Ok? Can anyone think of even more possible wishes?
Wayne Davison wrote:
> On Wed, 7 Jun 2000, Bart Schaefer wrote:
> > 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.
>
> That would be cool if I could get it to work. However, no matter
> what I try, tab does not expand wildcards with expand-or-complete
> set. It just expands $VARIABLES.
[Scratching head...] Hm. It works for me.
> > You can still get the new behavior of _expand from <C-x e> in this case.
>
> The only thing I get when I do that is this error:
>
> _expand_word:5: curcontext: parameter not set
>
> This is caused by my predilection to having the "no_unset" option set
> for my interactive-shell use.
Oh, that one again. The patch below fixes this.
Bye
Sven
Index: Completion/Commands/_correct_word
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_correct_word,v
retrieving revision 1.1.1.6
diff -u -r1.1.1.6 _correct_word
--- Completion/Commands/_correct_word 2000/02/03 17:22:42 1.1.1.6
+++ Completion/Commands/_correct_word 2000/06/07 06:45:38
@@ -7,6 +7,9 @@
# If configurations keys with the prefix `correctword_' are
# given they override those starting with `correct_'.
+setopt localoptions nullglob rcexpandparam extendedglob
+unsetopt markdirs globsubst shwordsplit nounset ksharrays
+
local curcontext="$curcontext"
if [[ -z "$curcontext" ]]; then
Index: Completion/Commands/_expand_word
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_expand_word,v
retrieving revision 1.2
diff -u -r1.2 _expand_word
--- Completion/Commands/_expand_word 2000/04/20 08:04:56 1.2
+++ Completion/Commands/_expand_word 2000/06/07 06:45:38
@@ -2,6 +2,9 @@
# Simple completion front-end implementing expansion.
+setopt localoptions nullglob rcexpandparam extendedglob
+unsetopt markdirs globsubst shwordsplit nounset ksharrays
+
local curcontext="$curcontext"
if [[ -z "$curcontext" ]]; then
Index: Completion/Commands/_next_tags
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_next_tags,v
retrieving revision 1.6
diff -u -r1.6 _next_tags
--- Completion/Commands/_next_tags 2000/05/23 08:54:30 1.6
+++ Completion/Commands/_next_tags 2000/06/07 06:45:38
@@ -3,6 +3,9 @@
# Main widget.
_next_tags() {
+ setopt localoptions nullglob rcexpandparam extendedglob
+ unsetopt markdirs globsubst shwordsplit nounset ksharrays
+
local ins ops="$PREFIX$SUFFIX"
unfunction _all_labels _next_label
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-06-07 6:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-07 6:46 Sven Wischnowsky [this message]
2000-06-07 7:07 ` Sven Wischnowsky
2000-06-07 15:28 ` Bart Schaefer
2000-06-07 15:31 ` Bart Schaefer
2000-06-07 22:21 ` PATCH: expansion Wayne Davison
2000-06-08 10:03 ` Oliver Kiddle
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=200006070646.IAA11684@beta.informatik.hu-berlin.de \
--to=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).