Remove space added by completion

Remove space added by completion

[zzapper]

Hi
When you tab complete you get a trailing space for free which is mostly 
what you want but is there a flag etc which can remove it?

-- 
zzapper
https://twitter.com/dailyzshtip

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: Remove space added by completion

[Oliver Kiddle]

zzapper wrote:
> 
> When you tab complete you get a trailing space for free which is mostly 
> what you want but is there a flag etc which can remove it?

See the -q, -r and -R options to compadd in the documentation.

I assume you don't want to disable it completely given that it is
"mostly what you want". You should actually find that it gets removed if
the next key you type is something that would imply the suffix wasn't
wanted. I can't think of an example with a space but typing space after
a / suffix from a completed directory will usually remove the trailing
/.

It might be useful to have a specific example of an unwanted space.

Oliver

Re: Remove space added by completion

[Aaron Schrab]

At 23:11 +0100 14 Feb 2014, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>zzapper wrote:
>>
>> When you tab complete you get a trailing space for free which is mostly
>> what you want but is there a flag etc which can remove it?
>
>See the -q, -r and -R options to compadd in the documentation.
>
>I assume you don't want to disable it completely given that it is
>"mostly what you want". You should actually find that it gets removed if
>the next key you type is something that would imply the suffix wasn't
>wanted. I can't think of an example with a space but typing space after
>a / suffix from a completed directory will usually remove the trailing
>/.
>
>It might be useful to have a specific example of an unwanted space.

I don't know about the original poster, but one place where I often 
don't want a space after a completion is with git branch names, to make 
it easier to do commands like:

  # List commits in current branch but not in master
  git log master..
  # List commits from either branch which aren't in the other
  git log branch1...branch2

The completion for git already supports completing branches after those 
dots, but an unwanted space is automatically added after completing the 
first branch name.

Of course, I can't say for sure that I wouldn't get more annoyed by the 
space not being automatically added there in cases where I'm only going 
to be specifying a single branch.

Re: Remove space added by completion

[Bart Schaefer]

On Feb 14,  7:49pm, Aaron Schrab wrote:
}
} I don't know about the original poster, but one place where I often 
} don't want a space after a completion is with git branch names, to make 
} it easier to do commands like:
} 
}   # List commits in current branch but not in master
}   git log master..
}   # List commits from either branch which aren't in the other
}   git log branch1...branch2

Try something like the following; I won't hazard to commit it because
I don't know git branch syntax well enough yet.  With this diff you
should be able to complete the branch name and then type "." and it
will auto-remove the space.


diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index c09f255..0c1288a 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5398,7 +5398,7 @@ __git_branch_names () {
   branch_names=(${${(f)"$(_call_program branchrefs git for-each-ref --format='"%(refname)"' refs/heads 2>/dev/null)"}#refs/heads/})
   __git_command_successful $pipestatus || return 1
 
-  _wanted branch-names expl branch-name compadd $* - $branch_names
+  _wanted branch-names expl branch-name compadd -r . $* - $branch_names
 }
 
 (( $+functions[__git_remote_branch_names] )) ||
@@ -5409,7 +5409,7 @@ __git_remote_branch_names () {
   branch_names=(${${(f)"$(_call_program remote-branch-refs git for-each-ref --format='"%(refname)"' refs/remotes 2>/dev/null)"}#refs/remotes/})
   __git_command_successful $pipestatus || return 1
 
-  _wanted remote-branch-names expl 'remote branch name' compadd $* - $branch_names
+  _wanted remote-branch-names expl 'remote branch name' compadd -r . $* - $branch_names
 }
 
 (( $+functions[__git_remote_branch_names_noprefix] )) ||
@@ -5420,7 +5420,7 @@ __git_remote_branch_names_noprefix () {
   branch_names=(${${${(f)"$(_call_program remote-branch-refs-noprefix git for-each-ref --format='"%(refname)"' refs/remotes 2>/dev/null)"}##*/}:#HEAD})
   __git_command_successful $pipestatus || return 1
 
-  _wanted remote-branch-names-noprefix expl 'remote branch name' compadd $* - $branch_names
+  _wanted remote-branch-names-noprefix expl 'remote branch name' compadd -r . $* - $branch_names
 }
 
 (( $+functions[__git_commits] )) ||

Re: Remove space added by completion

[Aaron Schrab]

At 18:33 -0800 14 Feb 2014, Bart Schaefer <schaefer@brasslantern.com> wrote:
>On Feb 14,  7:49pm, Aaron Schrab wrote:
>}
>} I don't know about the original poster, but one place where I often
>} don't want a space after a completion is with git branch names, to make
>} it easier to do commands like:
>}
>}   # List commits in current branch but not in master
>}   git log master..
>}   # List commits from either branch which aren't in the other
>}   git log branch1...branch2
>
>Try something like the following; I won't hazard to commit it because
>I don't know git branch syntax well enough yet.  With this diff you
>should be able to complete the branch name and then type "." and it
>will auto-remove the space.

That doesn't seem to work at all for me.  Looking at the code now, I see 
that the main place I'd want that behaviour (git log) isn't even 
completing branches.  It calls __git_commit_ranges, which in turn calls 
__git_commits which uses _alternative to call __git_heads to get 
branches and similar names as well as a couple of other functions to 
complete other ways to specify a commit.

That first function is already attempting to do this by passing `-qS ..` 
on towards compadd, but that doesn't get through _alternative.  If I 
modify it to instead call __git_heads directly (as in the diff below) it 
works.  But then that loses the ability to complete tags.

In the below patch I've also modified the additional arguments for 
compadd to work a bit better.  I changed the suffix to only a single dot 
rather than 2.  This allows typing one more dot to get the first form 
from my previous message; if two dots are supplied already it actually 
becomes harder to get that at the end of the range.  I also changed to 
remove the suffix if anything other than an alphanumeric follows.  This 
allows forms like `master~` or `branch@{1}` to be entered without 
needing to manually remove the dot.

If there's a way to get these arguments passed through the call to 
_alternative in __git_commits, I think it would be an improvement to 
change the actual arguments used.

diff --git c/Completion/Unix/Command/_git w/Completion/Unix/Command/_git
index 0c1288a..bf9417a 100644
--- c/Completion/Unix/Command/_git
+++ w/Completion/Unix/Command/_git
@@ -5499,7 +5499,7 @@ __git_commit_ranges () {
   if compset -P '*..(.|)'; then
     __git_commits $*
   else
-    __git_commits $* -qS ..
+    __git_heads $* -S . -r '^a-zA-Z0-9'
   fi
 }
 

Re: Remove space added by completion

[zzapper]

Oliver Kiddle <okiddle@yahoo.co.uk> wrote in news:16835.1392415885
@thecus.kiddle.eu:


> /.
> 
> It might be useful to have a specific example of an unwanted space.
> 
> Oliver
> 

alias -g NF='*~vssver.scc(.om[1])'
ls NF<TAB>
completes to
ls *~vssver.scc(.om[1]) <- trailing space
I have to backspace to be able to complete a 2nd time
ls *~vssver.scc(.om[1])<TAB>


-- 
zzapper
https://twitter.com/dailyzshtip

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Re: Remove space added by completion

[Oliver Kiddle]

On 14 Feb, Aaron Schrab wrote:
> >} I don't know about the original poster, but one place where I often
> >} don't want a space after a completion is with git branch names, to make

> If there's a way to get these arguments passed through the call to 
> _alternative in __git_commits, I think it would be an improvement to 
> change the actual arguments used.

How about the following? This just uses zparseopts to get the suffixes
and puts them in to each of the alternatives. The trickiest part is
quoting. I've also added a compset -S call to handle an existing suffix.

Oliver

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index a2cbf74..cfdbc4f 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5526,10 +5526,13 @@ __git_remote_branch_names_noprefix () {
 __git_commits () {
   # TODO: deal with things that __git_heads and __git_tags has in common (i.e.,
   # if both exists, they need to be completed to heads/x and tags/x.
+  local -a sopts ropt
+  zparseopts -E -a sopts S: r:=ropt R: q
+  sopts+=( $ropt:q )
   _alternative \
-    'heads::__git_heads' \
-    'commit-tags::__git_commit_tags' \
-    'commit-objects::__git_commit_objects'
+    "heads::__git_heads $sopts" \
+    "commit-tags::__git_commit_tags $sopts" \
+    "commit-objects::__git_commit_objects"
 }
 
 (( $+functions[__git_heads] )) ||
@@ -5595,10 +5598,12 @@ __git_commits2 () {
 
 (( $+functions[__git_commit_ranges] )) ||
 __git_commit_ranges () {
+  local -a suf
   if compset -P '*..(.|)'; then
     __git_commits $*
   else
-    __git_commits $* -qS ..
+    compset -S '..*' || suf=( -qS .. -r '.@~ ^:' )
+    __git_commits $* $suf
   fi
 }
 

Re: Remove space added by completion

[Aaron Schrab]

At 17:54 +0100 18 Feb 2014, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>How about the following? This just uses zparseopts to get the suffixes
>and puts them in to each of the alternatives. The trickiest part is
>quoting. I've also added a compset -S call to handle an existing 
>suffix.

IMO, that works great!  Thanks.

Re: Remove space added by completion

[Oliver Kiddle]

On 15 Feb, zzapper wrote:
> > It might be useful to have a specific example of an unwanted space.
> alias -g NF='*~vssver.scc(.om[1])'
> ls NF<TAB>

_expand looks at an add-space style to see whether to add a space suffix
so it seems logical for _expand_alias to also observe that style. At
least only for a true/false value (_expand has special handling for
files/directories).

Note that _expand_alias is using expand-alias-word in the zstyle
context which is perhaps not what you'd first guess.

Oliver

diff --git a/Completion/Base/Completer/_expand_alias b/Completion/Base/Completer/_expand_alias
index 8848e66..8240e41 100644
--- a/Completion/Base/Completer/_expand_alias
+++ b/Completion/Base/Completer/_expand_alias
@@ -1,7 +1,7 @@
 #compdef -K _expand_alias complete-word \C-xa
 
 local word expl tmp pre sel what
-local -a tmpa
+local -a tmpa suf
 
 eval "$_comp_setup"
 
@@ -58,7 +58,8 @@ if [[ -n $tmp ]]; then
       tmp="\\$tmp"
     fi
   fi
-  $pre _wanted aliases expl alias compadd -UQ -- ${tmp%%[[:blank:]]##}
+  zstyle -T ":completion:${curcontext}:" add-space || suf=( -S '' )
+  $pre _wanted aliases expl alias compadd -UQ "$suf[@]" -- ${tmp%%[[:blank:]]##}
 elif (( $#pre )) && zstyle -t ":completion:${curcontext}:" complete; then
   $pre _aliases -s "$sel" -S ''
 else

Re: Remove space added by completion

[m0viefreak]

On 18.02.2014 17:54, Oliver Kiddle wrote:
> How about the following? This just uses zparseopts to get the suffixes
> and puts them in to each of the alternatives. The trickiest part is
> quoting. I've also added a compset -S call to handle an existing suffix.
> 
> Oliver
> 
> diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
> index a2cbf74..cfdbc4f 100644
> --- a/Completion/Unix/Command/_git
> +++ b/Completion/Unix/Command/_git
> @@ -5526,10 +5526,13 @@ __git_remote_branch_names_noprefix () {
>  __git_commits () {
>    # TODO: deal with things that __git_heads and __git_tags has in common (i.e.,
>    # if both exists, they need to be completed to heads/x and tags/x.
> +  local -a sopts ropt
> +  zparseopts -E -a sopts S: r:=ropt R: q
> +  sopts+=( $ropt:q )
>    _alternative \
> -    'heads::__git_heads' \
> -    'commit-tags::__git_commit_tags' \
> -    'commit-objects::__git_commit_objects'
> +    "heads::__git_heads $sopts" \
> +    "commit-tags::__git_commit_tags $sopts" \
> +    "commit-objects::__git_commit_objects"
>  }
>  
>  (( $+functions[__git_heads] )) ||
> @@ -5595,10 +5598,12 @@ __git_commits2 () {
>  
>  (( $+functions[__git_commit_ranges] )) ||
>  __git_commit_ranges () {
> +  local -a suf
>    if compset -P '*..(.|)'; then
>      __git_commits $*
>    else
> -    __git_commits $* -qS ..
> +    compset -S '..*' || suf=( -qS .. -r '.@~ ^:' )
> +    __git_commits $* $suf
>    fi
>  }
>  
> 

While this works great when completing something *after* a branch name,
such as

$ git log foo<tab>bar<tab>

which then ends up in

$ git log foo-branch..bar-branch

this new suffix behavior is pretty bad in the following case:

$ git log ma<tab><return>

It ends up executing the following:

$ git log master..

The expected result (and behavior before this change) is:

$ git log master

which is something else entirely.


For some reason the auto-removable suffix does not get removed when
accept-line is called.

Is there a reason for this or a way to fix this?
Or a way to disable the newly introduced .. suffix entirely?

I'd rather hit backspace and add the dots myself when I actually want
them instead of having to remove them when they are inserted automatically.

[PATCH] _git: auto-removable '..' suffix: remove at the end of lines

[m0viefreak]

Make sure
  $ git log mast<tab><return>
results in
  $ git log master
and not
  $ git log master..
---
 Completion/Unix/Command/_git | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index b082bb0..606b5e0 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5602,7 +5602,7 @@ __git_commit_ranges () {
   if compset -P '*..(.|)'; then
     __git_commits $*
   else
-    compset -S '..*' || suf=( -qS .. -r '.@~ ^:' )
+    compset -S '..*' || suf=( -S .. -r '.@~ ^:\t\n\-' )
     __git_commits $* $suf
   fi
 }
-- 
1.9.1.286.g5172cb3

Re: [PATCH] _git: auto-removable '..' suffix: remove at the end of lines

[Bart Schaefer]

[> workers]

On Mar 22,  5:43pm, m0viefreak wrote:
} Subject: [PATCH] _git: auto-removable '..' suffix: remove at the end of li
}
} -    compset -S '..*' || suf=( -qS .. -r '.@~ ^:' )
} +    compset -S '..*' || suf=( -S .. -r '.@~ ^:\t\n\-' )

The presence or absence of \n in the -r string doesn't seem to make any
difference for me.  The suffix is auto-removed on accept-line whether
invoked as ctrl+m or ctrl+j or enter/return, with or without \n there.

And of course the \t only matters if you type ctrl+v tab, because in
other cases complete-word is invoked and no character is inserted.

Hmm.  However, here's something really strange.  Starting from zsh -f
with compinit loaded and tab bound to complete-word ...

With the original code:

    compset -S '..*' || suf=( -qS .. -r '.@~ ^:' )

the trailing ".." is not boldfaced like an autoremovable suffix is by
default, and indeed it is not removed upon accept-line, though it is
auto-removed by e.g. a space.

With this:

    compset -S '..*' || suf=( -qS .. -r '.@~ ^:\-' )

(note that the only change is to add '\-' to the -r string), the ".." IS
shown in boldface and is auto-removed by accept-line.

I have no idea why that would make a difference.

Re: [PATCH] _git: auto-removable '..' suffix: remove at the end of lines

[m0viefreak]

On 22.03.2014 18:37, Bart Schaefer wrote:
> The presence or absence of \n in the -r string doesn't seem to make any
> difference for me.  The suffix is auto-removed on accept-line whether
> invoked as ctrl+m or ctrl+j or enter/return, with or without \n there.
> 
> And of course the \t only matters if you type ctrl+v tab, because in
> other cases complete-word is invoked and no character is inserted.

Right, I basically added them for completeness, because according to the
man page the default behavior (-q) includes them:

   Thus `-S "=" -q' is the same as `-S "=" -r "= \t\n\-"'.

Giving -q AND -r is superfluous, so I removed -q.

And there actually is use for \n: When entering multiple commands on
multiple lines (ALT+Return) without calling accept-line.

This way we get the default behavior, just as if only -q was given, PLUS
the additional . @ ~ ^ characters.


> Hmm.  However, here's something really strange.  Starting from zsh -f
> with compinit loaded and tab bound to complete-word ...
> 
> With the original code:
> 
>     compset -S '..*' || suf=( -qS .. -r '.@~ ^:' )
> 
> the trailing ".." is not boldfaced like an autoremovable suffix is by
> default, and indeed it is not removed upon accept-line, though it is
> auto-removed by e.g. a space.
> 
> With this:
> 
>     compset -S '..*' || suf=( -qS .. -r '.@~ ^:\-' )
> 
> (note that the only change is to add '\-' to the -r string), the ".." IS
> shown in boldface and is auto-removed by accept-line.
> 
> I have no idea why that would make a difference.

I noticed that too. The part that makes the boldface work seems to be
the '\-'.
Accoding to the man-page the only thing it does is

  `\-' stands for all characters that insert nothing.

which is exactly what is needed to make it work with accept-line, but I
can't see how this is related to the boldface.

Re: [PATCH] _git: auto-removable '..' suffix: remove at the end of lines

[Bart Schaefer]

On Mar 23,  4:41am, m0viefreak wrote:
}
}    Thus `-S "=" -q' is the same as `-S "=" -r "= \t\n\-"'.
} 
} Giving -q AND -r is superfluous, so I removed -q.

Ah!  Looking at the code in compresult.c and zle_misc.c, I believe it's
the case that -q and -r are not merely superfluous, they ought to be
mutually exclusive:  -q is for all practical purposes ignored if -r is
also given.

It appears that -r also causes $ZLE_SPACE_SUFFIX_CHARS to be ignored (it
is probably obvious that -r supplants $ZLE_REMOVE_SUFFIX_CHARS).

The part about (not) boldfacing remains a mystery.

In addition to _git, _nslookup also passes both -q and -r to compadd, so
it presumably has similar breakage.

[PATCH] zle/completion: fix auto-removable suffix highlighting

[m0viefreak]

The variable suffixnoinslen, intended for use related to the
\- suffix specifier, was also used for the length of the active
suffix in the highlighting code. This broke highlighting in cases
where \- was NOT specified.

Semantically two variables are needed:

Introduce a new variable that only reflects *IF* the suffix
should be removed on uninsertable characters and set the length
variable independant from that.
---
 Src/Zle/compresult.c  |  2 +-
 Src/Zle/zle_misc.c    | 28 ++++++++++++++--------------
 Src/Zle/zle_refresh.c |  4 ++--
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/Src/Zle/compresult.c b/Src/Zle/compresult.c
index c0e5ff3..fcceb67 100644
--- a/Src/Zle/compresult.c
+++ b/Src/Zle/compresult.c
@@ -1131,7 +1131,7 @@ do_single(Cmatch m)
 	    /* If a suffix was added, and is removable, let *
 	     * `,' and `}' remove it.                       */
 	    if (isset(AUTOPARAMKEYS))
-		addsuffix(SUFTYP_POSSTR, 0, ZWS(",}"), 2, suffixnoinslen);
+		addsuffix(SUFTYP_POSSTR, 0, ZWS(",}"), 2, suffixlen);
 	} else if (!menucmp) {
 	    /*{{*/
 	    /* Otherwise, add a `,' suffix, and let `}' remove it. */
diff --git a/Src/Zle/zle_misc.c b/Src/Zle/zle_misc.c
index 7be0ebb..9bc1cf6 100644
--- a/Src/Zle/zle_misc.c
+++ b/Src/Zle/zle_misc.c
@@ -1249,10 +1249,14 @@ static char *suffixfunc;
 /* Length associated with the suffix function */
 static int suffixfunclen;
 
-/* Length associated with uninsertable characters */
+/* Whether to remove suffix on uninsertable characters */
+/**/
+int suffixnoinsrem;
+
+/* Length of the currently active, auto-removable suffix. */
 /**/
 mod_export int
-suffixnoinslen;
+suffixlen;
 
 /**/
 mod_export void
@@ -1309,7 +1313,8 @@ makesuffix(int n)
     if ((suffixchars = getsparam("ZLE_SPACE_SUFFIX_CHARS")) && *suffixchars)
 	addsuffixstring(SUFTYP_POSSTR, SUFFLAGS_SPACE, suffixchars, n);
 
-    suffixnoinslen = n;
+    suffixlen = n;
+    suffixnoinsrem = 1;
 }
 
 /* Set up suffix for parameter names: the last n characters are a suffix *
@@ -1358,15 +1363,10 @@ makesuffixstr(char *f, char *s, int n)
 	s = metafy(s, i, META_USEHEAP);
 	ws = stringaszleline(s, 0, &i, NULL, NULL);
 
-	if (z)
-	    suffixnoinslen = inv ? 0 : n;
-	else if (inv) {
-	    /*
-	     * negative match, \- wasn't present, so it *should*
-	     * have this suffix length
-	     */
-	    suffixnoinslen = n;
-	}
+	/* Remove suffix on uninsertable characters if  \- was given *
+	 * and the character class wasn't negated -- or vice versa.  */
+	suffixnoinsrem = z ^ inv;
+	suffixlen = n;
 
 	lasts = wptr = ws;
 	while (i) {
@@ -1444,7 +1444,7 @@ iremovesuffix(ZLE_INT_T c, int keep)
 	struct suffixset *ss;
 
 	if (c == NO_INSERT_CHAR) {
-	    sl = suffixnoinslen;
+	    sl = suffixnoinsrem ? suffixlen : 0;
 	} else {
 	    ZLE_CHAR_T ch = c;
 	    /*
@@ -1538,5 +1538,5 @@ fixsuffix(void)
 	suffixlist = next;
     }
 
-    suffixfunclen = suffixnoinslen = 0;
+    suffixfunclen = suffixnoinsrem = suffixlen = 0;
 }
diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index 2bedbc4..8ce6787 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -1046,8 +1046,8 @@ zrefresh(void)
 	region_highlights[1].start = region_highlights[1].end = -1;
     }
     /* check for an active completion suffix */
-    if (suffixnoinslen) {
-	region_highlights[2].start = zlecs - suffixnoinslen;
+    if (suffixlen) {
+	region_highlights[2].start = zlecs - suffixlen;
 	region_highlights[2].end = zlecs;
     } else {
 	region_highlights[2].start = region_highlights[2].end = -1;
-- 
1.9.1.286.g5172cb3