Re: git-completion.tcsh

Re: git-completion.tcsh

[SZEDER Gábor]

Quoting Perry Rajnovic <perry.rajnovic@gmail.com>:

> When using the auto-completion included with git for tcsh, several
> commands do directly completion with an additional space appended to
> the end, which defeats the ability to complete to a deeper
> sub-directory.
>
> For example, if I have a git repository including the following:
> basedir/foo/bar/somefile.c
>
> (works as expected, git add)
> $ cd basedir
> $ git add f<tab>
> $ git add foo/
> $ git add foo/b<tab>
> $ git add foo/bar/
> $ git add foo/bar/s<tab>
> $ git add foo/bar/somefile.c
>
> (works not as expected, git rm)
> $ cd basedir
> $ git rm f<tab>
> $ git rm foo
> $ git rm foo<backspace>/b<tab>
> $ git rm foo/bar
> there’s a trailing space after foo and bar in the above lines, which
> means it’s not possible to initiate completion or immediately start
> typing, i must back-space before continuing.
>
> I’m fairly certain i’ve seen this for other commands as  well, but
> i’m not sure to what extent this occurs throughout the commands.
>
> Environment info:
> OS: Darwin 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47
> PST  2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 (OSX 10.10.2)
> Apple Terminal Version 2.5.1 (343.6)
> git version 2.3.2 (via MacPorts)
> tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options
> wide,nls,dl,al,kan,sm,rh,color,filec

The tcsh completion script is just a wrapper, it relies on the bash  
completion script to do the heavy lifting and tunnels its output int  
tcsh's completion infrastructure.
Could you try bash completion in your environment first to see,  
whether it's a bash completion issue that I can't reproduce or an  
issue with the tcsh wrapper?

Cc'ing Marc, author of the tcsh wrapper.


Gábor

Re: git-completion.tcsh

[Perry Rajnovic]

Gábor,

I updated git to include the macports install with bash completion.  under bash it does not exhibit the problem as I described it. To be sure that the completion scripts installed via macports weren’t newer/different (the .bash completion file had a few minor diffs from what I had been using), i reinstalled the tcsh completion using those files, but the same behavior happened.

So i’m seeing what you’re seeing, bash completion works fine, it’s likely to be something in the wrapper handling.

(updated) environment
Darwin 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 (OS X 10.10.3)
Apple Terminal Version 2.5.3 (343.7)
git 2.3.4 (+bash_completion, via MacPorts)
tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options wide,nls,dl,al,kan,sm,rh,color,filec
GNU bash, version 4.3.33(1)-release (x86_64-apple-darwin14.0.0)

Thanks!

Perry

> On Apr 1, 2015, at 20:55, SZEDER Gábor <szeder@ira.uka.de> wrote:
> 
> 
> Quoting Perry Rajnovic <perry.rajnovic@gmail.com>:
> 
>> When using the auto-completion included with git for tcsh, several
>> commands do directly completion with an additional space appended to
>> the end, which defeats the ability to complete to a deeper
>> sub-directory.
>> 
>> For example, if I have a git repository including the following:
>> basedir/foo/bar/somefile.c
>> 
>> (works as expected, git add)
>> $ cd basedir
>> $ git add f<tab>
>> $ git add foo/
>> $ git add foo/b<tab>
>> $ git add foo/bar/
>> $ git add foo/bar/s<tab>
>> $ git add foo/bar/somefile.c
>> 
>> (works not as expected, git rm)
>> $ cd basedir
>> $ git rm f<tab>
>> $ git rm foo
>> $ git rm foo<backspace>/b<tab>
>> $ git rm foo/bar
>> there’s a trailing space after foo and bar in the above lines, which
>> means it’s not possible to initiate completion or immediately start
>> typing, i must back-space before continuing.
>> 
>> I’m fairly certain i’ve seen this for other commands as  well, but
>> i’m not sure to what extent this occurs throughout the commands.
>> 
>> Environment info:
>> OS: Darwin 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47
>> PST  2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 (OSX 10.10.2)
>> Apple Terminal Version 2.5.1 (343.6)
>> git version 2.3.2 (via MacPorts)
>> tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options
>> wide,nls,dl,al,kan,sm,rh,color,filec
> 
> The tcsh completion script is just a wrapper, it relies on the bash
> completion script to do the heavy lifting and tunnels its output int
> tcsh's completion infrastructure.
> Could you try bash completion in your environment first to see,
> whether it's a bash completion issue that I can't reproduce or an
> issue with the tcsh wrapper?
> 
> Cc'ing Marc, author of the tcsh wrapper.
> 
> 
> Gábor

Re: git-completion.tcsh

[Marc Khouzam]

Hi,

I did notice the problem a while ago and had traced it back to the
fact that the bash completion scripts no longer adds the trailing '/'
at the end of directories.
Tcsh needs that '/' to know not to add that annoying extra space.

Bash 3 needed to put it that trailing '/' but bash 4 did not.  Two
years ago (!) changes were made in commit
3ffa4df4b2a26768938fc6bf1ed0640885b2bdf1 to allow bash 3 to work
without the trailing '/'.  That caused
the problem in the tcsh script.

The thing is that with master of today, I don't see the problem any
more.  I can't tell you when it started working again.
What is interesting is that the reason it now works is that the
git-completion.bash script no longer returns anything
for the case you mention:
  git add f<tab>
Instead, it seems to rely on file completion only.  File completion is
simulated by the tcsh script, so things work.

I tried with both git add and git rm and didn't see the problem as you
described it.

You can troubleshoot the git-completion.tcsh script by running the
generated final script directly.  For example, to see the completions
for a command line like:
    git rm f<tab>
you can run:
  bash ~/.git-completion.tcsh.bash git 'git rm f'

I plan on posting a patch to add debug printouts to make this process simpler.

Marc

On Thu, Apr 9, 2015 at 12:41 AM, Perry Rajnovic
<perry.rajnovic@gmail.com> wrote:
> Gábor,
>
> I updated git to include the macports install with bash completion.  under bash it does not exhibit the problem as I described it. To be sure that the completion scripts installed via macports weren’t newer/different (the .bash completion file had a few minor diffs from what I had been using), i reinstalled the tcsh completion using those files, but the same behavior happened.
>
> So i’m seeing what you’re seeing, bash completion works fine, it’s likely to be something in the wrapper handling.
>
> (updated) environment
> Darwin 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 (OS X 10.10.3)
> Apple Terminal Version 2.5.3 (343.7)
> git 2.3.4 (+bash_completion, via MacPorts)
> tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options wide,nls,dl,al,kan,sm,rh,color,filec
> GNU bash, version 4.3.33(1)-release (x86_64-apple-darwin14.0.0)
>
> Thanks!
>
> Perry
>
>> On Apr 1, 2015, at 20:55, SZEDER Gábor <szeder@ira.uka.de> wrote:
>>
>>
>> Quoting Perry Rajnovic <perry.rajnovic@gmail.com>:
>>
>>> When using the auto-completion included with git for tcsh, several
>>> commands do directly completion with an additional space appended to
>>> the end, which defeats the ability to complete to a deeper
>>> sub-directory.
>>>
>>> For example, if I have a git repository including the following:
>>> basedir/foo/bar/somefile.c
>>>
>>> (works as expected, git add)
>>> $ cd basedir
>>> $ git add f<tab>
>>> $ git add foo/
>>> $ git add foo/b<tab>
>>> $ git add foo/bar/
>>> $ git add foo/bar/s<tab>
>>> $ git add foo/bar/somefile.c
>>>
>>> (works not as expected, git rm)
>>> $ cd basedir
>>> $ git rm f<tab>
>>> $ git rm foo
>>> $ git rm foo<backspace>/b<tab>
>>> $ git rm foo/bar
>>> there’s a trailing space after foo and bar in the above lines, which
>>> means it’s not possible to initiate completion or immediately start
>>> typing, i must back-space before continuing.
>>>
>>> I’m fairly certain i’ve seen this for other commands as  well, but
>>> i’m not sure to what extent this occurs throughout the commands.
>>>
>>> Environment info:
>>> OS: Darwin 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47
>>> PST  2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 (OSX 10.10.2)
>>> Apple Terminal Version 2.5.1 (343.6)
>>> git version 2.3.2 (via MacPorts)
>>> tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options
>>> wide,nls,dl,al,kan,sm,rh,color,filec
>>
>> The tcsh completion script is just a wrapper, it relies on the bash
>> completion script to do the heavy lifting and tunnels its output int
>> tcsh's completion infrastructure.
>> Could you try bash completion in your environment first to see,
>> whether it's a bash completion issue that I can't reproduce or an
>> issue with the tcsh wrapper?
>>
>> Cc'ing Marc, author of the tcsh wrapper.
>>
>>
>> Gábor
>

Re: git-completion.tcsh

[SZEDER Gábor]

Hi,

Quoting Marc Khouzam <marc.khouzam@gmail.com>:
> Hi,
>
> I did notice the problem a while ago and had traced it back to the
> fact that the bash completion scripts no longer adds the trailing '/'
> at the end of directories.
> Tcsh needs that '/' to know not to add that annoying extra space.
>
> Bash 3 needed to put it that trailing '/' but bash 4 did not.  Two
> years ago (!) changes were made in commit
> 3ffa4df4b2a26768938fc6bf1ed0640885b2bdf1 to allow bash 3 to work
> without the trailing '/'.  That caused
> the problem in the tcsh script.
>
> The thing is that with master of today, I don't see the problem any
> more.  I can't tell you when it started working again.
> What is interesting is that the reason it now works is that the
> git-completion.bash script no longer returns anything
> for the case you mention:
>   git add f<tab>
> Instead, it seems to rely on file completion only.

I can't reproduce it with git-completion.bash from current master on  
its own on with bash 3.1.20(4) from MSysGit, it seems to work as  
intended here wrt tracked-file-aware file completion.

Set up test repo with these commands:

   git init
   >tracked
   git add tracked
   >non-tracked
   mkdir -p foo/bar
   >foo/bar/somefile.c

Now let's see what happens with 'git add':

   $ git add <TAB>
   foo/         non-tracked

Note, that the file 'tracked' is not offered, so this is clearly not  
standard bash file completion, but our completion script.  Also note  
the trailing '/' in 'foo/'.

   $ git add f<TAB>

Just completes to 'git add foo/', no space after '/'.
Add the file:

   $ git add foo/bar/somefile.c

Now let's see 'git rm':

   $ git rm <TAB>
   foo/     tracked

Note, that the file 'non-tracked' is not offered, so again this comes  
from our bash completion script.

Did you test the bash completion script on its own, or only through  
the tcsh wrapper?
I'm on MSysGit now, so no tcsh or bash v4 at hand, and no time either,  
so can't dig further at the moment.


Gábor

Re: git-completion.tcsh

[Marc Khouzam]

On Fri, Apr 24, 2015 at 7:30 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> Hi,
>
> Quoting Marc Khouzam <marc.khouzam@gmail.com>:
>>
>> Hi,
>>
>> I did notice the problem a while ago and had traced it back to the
>> fact that the bash completion scripts no longer adds the trailing '/'
>> at the end of directories.
>> Tcsh needs that '/' to know not to add that annoying extra space.
>>
>> Bash 3 needed to put it that trailing '/' but bash 4 did not.  Two
>> years ago (!) changes were made in commit
>> 3ffa4df4b2a26768938fc6bf1ed0640885b2bdf1 to allow bash 3 to work
>> without the trailing '/'.  That caused
>> the problem in the tcsh script.
>>
>> The thing is that with master of today, I don't see the problem any
>> more.  I can't tell you when it started working again.
>> What is interesting is that the reason it now works is that the
>> git-completion.bash script no longer returns anything
>> for the case you mention:
>>   git add f<tab>
>> Instead, it seems to rely on file completion only.
>
>
> I can't reproduce it with git-completion.bash from current master on its own
> on with bash 3.1.20(4) from MSysGit, it seems to work as intended here wrt
> tracked-file-aware file completion.
>
> Set up test repo with these commands:
>
>   git init
>   >tracked
>   git add tracked
>   >non-tracked
>   mkdir -p foo/bar
>   >foo/bar/somefile.c
>
> Now let's see what happens with 'git add':
>
>   $ git add <TAB>
>   foo/         non-tracked
>
> Note, that the file 'tracked' is not offered, so this is clearly not
> standard bash file completion, but our completion script.  Also note the
> trailing '/' in 'foo/'.
>
>   $ git add f<TAB>
>
> Just completes to 'git add foo/', no space after '/'.
> Add the file:
>
>   $ git add foo/bar/somefile.c
>
> Now let's see 'git rm':
>
>   $ git rm <TAB>
>   foo/     tracked
>
> Note, that the file 'non-tracked' is not offered, so again this comes from
> our bash completion script.
>
> Did you test the bash completion script on its own, or only through the tcsh
> wrapper?
> I'm on MSysGit now, so no tcsh or bash v4 at hand, and no time either, so
> can't dig further at the moment.
>

Thanks Gábor, I can see the behaviour you describe now.  I was running
the new bash completion with an old git and that had an impact.
With a recent git installation I can see the problem, which includes
that with tcsh, the / at the end of foo is missing.
I had a patch for that a while ago that I can revive and post soon.

Thanks again!

Marc

git-completion.tcsh

[Perry Rajnovic]

When using the auto-completion included with git for tcsh, several commands do directly completion with an additional space appended to the end, which defeats the ability to complete to a deeper sub-directory.

For example, if I have a git repository including the following:
basedir/foo/bar/somefile.c

(works as expected, git add)
$ cd basedir
$ git add f<tab>
$ git add foo/
$ git add foo/b<tab>
$ git add foo/bar/
$ git add foo/bar/s<tab>
$ git add foo/bar/somefile.c

(works not as expected, git rm)
$ cd basedir
$ git rm f<tab>
$ git rm foo 
$ git rm foo<backspace>/b<tab>
$ git rm foo/bar 
there’s a trailing space after foo and bar in the above lines, which means it’s not possible to initiate completion or immediately start typing, i must back-space before continuing.

I’m fairly certain i’ve seen this for other commands as well, but i’m not sure to what extent this occurs throughout the commands.

Environment info:
OS: Darwin 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47 PST 2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 (OSX 10.10.2)
Apple Terminal Version 2.5.1 (343.6)
git version 2.3.2 (via MacPorts)
tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options wide,nls,dl,al,kan,sm,rh,color,filec

Thanks!

Perry Rajnovic