Re: git-completion.tcsh
On Fri, Apr 24, 2015 at 7:30 AM, SZEDER Gábor sze...@ira.uka.de wrote: Hi, Quoting Marc Khouzam marc.khou...@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 ftab 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 fTAB 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-completion.tcsh
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 ftab 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 ftab 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.rajno...@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 sze...@ira.uka.de wrote: Quoting Perry Rajnovic perry.rajno...@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 ftab $ git add foo/ $ git add foo/btab $ git add foo/bar/ $ git add foo/bar/stab $ git add foo/bar/somefile.c (works not as expected, git rm) $ cd basedir $ git rm ftab $ git rm foo $ git rm foobackspace/btab $ 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Completion: Cleanup tcsh script and add debug flag
Remove overriding of __git_index_file_list_filter
since that method is no longer used in git-completion.bash.
Overriding that method was needed before to get
git-completion.bash to append a '/' to the end
of directories; this does not seem to be needed anymore since
that script no longer provides completions of directories/files.
Also add -d/--debug flag support to help troubleshoot
the script.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
I thought this would help when for people that experience issues with
the script.
Thanks!
Marc
contrib/completion/git-completion.tcsh | 50 +---
1 file changed, 40 insertions(+), 10 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index 6104a42..fd0b906 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -1,6 +1,6 @@
# tcsh completion support for core Git.
#
-# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Copyright (C) 2012, 2015 Marc Khouzam marc.khou...@gmail.com
# Distributed under the GNU General Public License, version 2.0.
#
# When sourced, this script will generate a new script that uses
@@ -22,6 +22,25 @@
# add the following line to your .tcshrc/.cshrc:
#set autolist=ambiguous
# It will tell tcsh to list the possible completion choices.
+#
+# To debug this script one can use the -d flag by running the
+# generated final script directly. For example, to see the completions
+# generated when pressing tab for the command line:
+# git co
+# one should run:
+# bash ~/.git-completion.tcsh.bash -d git 'git co'
+# and will obtain:
+# =
+# git-completion.bash returned:
+# commit config
+# =
+# Completions including tcsh additions:
+# commit config
+# =
+# Final completions returned:
+# commit
+# config
+#
set __git_tcsh_completion_version = `\echo ${tcsh} | \sed 's/\./ /g'`
if ( ${__git_tcsh_completion_version[1]} 6 || \
@@ -48,20 +67,17 @@ cat EOF ${__git_tcsh_completion_script}
# Do not modify it directly. Instead, modify git-completion.tcsh
# and source it again.
+# Allow for debug printouts when running the script by hand
+if [ \$1 == -d ] || [ \$1 == --debug ]; then
+ __git_tcsh_debug=true
+ shift
+fi
+
source ${__git_tcsh_completion_original_script}
# Remove the colon as a completion separator because tcsh cannot handle it
COMP_WORDBREAKS=\${COMP_WORDBREAKS//:}
-# For file completion, tcsh needs the '/' to be appended to directories.
-# By default, the bash script does not do that.
-# We can achieve this by using the below compatibility
-# method of the git-completion.bash script.
-__git_index_file_list_filter ()
-{
- __git_index_file_list_filter_compat
-}
-
# Set COMP_WORDS in a way that can be handled by the bash script.
COMP_WORDS=(\$2)
@@ -83,6 +99,12 @@ fi
# Call _git() or _gitk() of the bash script, based on the first argument
_\${1}
+if [ \$__git_tcsh_debug == true ]; then
+ echo =
+ echo git-completion.bash returned:
+ echo \${COMPREPLY[@]}
+fi
+
IFS=\$'\n'
if [ \${#COMPREPLY[*]} -eq 0 ]; then
# No completions suggested. In this case, we want tcsh to perform
@@ -108,6 +130,14 @@ if [ \${#COMPREPLY[*]} -eq 0 ]; then
fi
fi
+if [ \$__git_tcsh_debug == true ]; then
+ echo =
+ echo Completions including tcsh additions:
+ echo \${COMPREPLY[@]}
+ echo =
+ echo Final completions returned:
+fi
+
# tcsh does not automatically remove duplicates, so we do it ourselves
echo \${COMPREPLY[*]} | sort | uniq
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [QUERY] How do you sort completions?
-Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Ramkumar Ramachandra Sent: Friday, May 24, 2013 12:19 PM To: SZEDER Gábor Cc: Git List; Felipe Contreras Subject: Re: [QUERY] How do you sort completions? SZEDER Gábor wrote: I don't know who does the sorting (Bash or readline), and I don't know any way to disable it. Damn; so it's impossible to have a custom-sorted completion list in bash. Any idea about zsh? I know that there are completion groups, but I'd really like custom sorting. You could do that with tcsh :)-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Handle path completion and colon for tcsh script
The problem is, if the directory name *already* has a slash, Bash adds another slash! So bash users do see the trailing slash because bash adds one to what we compute and return, which we do strip the trailing slash exactly because we know bash will add one. The problem is slightly more obscure than that, and I wonder if it should be documented somewhere in the bash script? Manlio explained in a previous exchange with me, that bash will properly deal with an existing trailing slash when doing the completion on the command-line, but will screw it up by adding a second slash when dealing with multiple possible completions and printing those for the user to choose from. For example: $ git status # On branch tcsh_next # Untracked files: # (use git add file... to include in what will be committed) # # fish/ # fishing/ nothing added to commit but untracked files present (use git add to track) $ git add fishtab fish//fishing// notice the double slashes $ git add fishitab # will complete the command line properly to the below, with a single slash. $ git add fishing/ Because tcsh completion uses what we compute directly, without bash massaging our output to add the trailing slash, it needs some magic. Yes, that is right. OK, that makes sense. It was this part from the originally proposed log message: ... Such completions do not add the '/' at the end of directories for recent versions of bash. However, the '/' is needed by tcsh, ... with a large gap between the two sentences that fooled me, and the explanation in your message helped to fill the gap to understand the situation better. Sorry about the lack of details. I'm see more and more the importance of these commit messages :) Perhaps ... for recent versions of bash, which will then add the trailing slash for paths that are directory to the result of our completion. The completion for tcsh however uses the result of our completion directly, so it either needs to add the necessary slash itself, or needs to ask us to keep the trailiing slash. This patch does the latter. or something? How about the following, which gives a little more detail about the solution for tcsh? I think it is worth putting the below extra details because I feel a mistake could easily be made about this trailing slash issue, which I had gotten wrong for my own version of the script for a couple of weeks, before figuring out the mistake. Handle path completion and colon for tcsh script Recent enhancements to git-completion.bash provide intelligent path completion for git commands. Such completions do not provide the '/' at the end of directories for recent versions of bash; instead, bash itself will add the trailing slash to directories to the result provided by git-completion.bash. However, the completion for tcsh uses the result of the bash completion script directly, so it either needs to add the necessary slash itself, or needs to ask the bash script to keep the trailing slash. Adding the slash itself is difficult because we cannot easily tell if an entry of the output of the bash script is a directory or something else. For example, assuming there is a directory named 'commit' in the current directory, then, when completing git add committab we would need to add a slash, but for git help committab we should not. Figuring out such differences would require adding much intelligence to the tcsh completion script. Instead, it is simpler to ask the bash script to keep the trailing slash. This patch does this. Also, tcsh does not handle the colon as a completion separator so we remove it from the list of separators. Signed-off-by: Marc Khouzam marc.khou...@ericsson.com Thanks Marc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [feature request] git add completion should exclude staged content
-Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo Sent: Monday, January 28, 2013 3:16 PM To: Junio C Hamano Cc: Michael J Gruber; wookietreiber; git@vger.kernel.org Subject: Re: [feature request] git add completion should exclude staged content -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 28/01/2013 18:52, Junio C Hamano ha scritto: [...] Thanks both for commenting. I'll find time to read it over again and perhaps we can merge it to 'next' and advertise it in the next issue of What's cooking report to ask for wider testing to move it forward. Thanks. I will try to update the patch, with your latest suggestions (avoid tricky POSIX shell syntax, and CDPATH issue - if I remember correctly), and with an update for the t/t9902-completion.sh test (that I completely missed). Hi Manlio, I'm trying to update git-completion.tcsh to work properly with your nice new completion feature. But I'm having trouble with the missing '/' at the end of directories. The new logic in git-completion.bash tells bash that 'filenames' completion is ongoing so bash will add a '/' after directories. Sadly, tcsh won't do that, so it would be simpler if git-completion.bash added the '/' itself. I looked at the git-completion.bash script changes and I noticed that for bash version 4, you have to add the '/' yourself. I also noticed the following comment: # XXX if we append a slash to directory names when using # `compopt -o filenames`, Bash will append another slash. # This is pretty stupid, and this the reason why we have to # define a compatible version for this function. So I gather you would rather add a '/' all the time to deal with older bash version transparently. This would be great for tcsh also. I'm trying to figure out when bash mis-behaves when you add the '/' all the time? When I try it (I have bash 4.1.5(1)-release) I didn't run into the double slash problem you mention in the comment. I'm hoping we can straighten this out and have git-completion.bash add the '/' all the time. Could you explain when the problem happens? Thanks Marc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [feature request] git add completion should exclude staged content
-Original Message-
From: git-ow...@vger.kernel.org
[mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo
Sent: Wednesday, January 30, 2013 1:24 PM
To: Marc Khouzam
Cc: 'Junio C Hamano'; 'Michael J Gruber'; 'wookietreiber';
'git@vger.kernel.org'
Subject: Re: [feature request] git add completion should
exclude staged content
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 30/01/2013 15:06, Marc Khouzam ha scritto:
[...]
I will try to update the patch, with your latest suggestions (avoid
tricky POSIX shell syntax, and CDPATH issue - if I remember
correctly),
and with an update for the t/t9902-completion.sh test (that I
completely
missed).
Hi Manlio,
Hi.
I'm trying to update git-completion.tcsh to work properly with
your nice new completion feature. But I'm having trouble with
the missing '/' at the end of directories.
The new logic in git-completion.bash tells bash that 'filenames'
completion is ongoing so bash will add a '/' after directories.
Sadly, tcsh won't do that, so it would be simpler if
git-completion.bash added the '/' itself. I looked at the
git-completion.bash script changes and I noticed that for
bash version 4, you have to add the '/' yourself.
The compatible version is not only required for Bash; you can
use it for
other shells.
Try to redefine the __git_index_file_list_filter function to use the
version that adds a slash to directory names.
I hadn't thought of that!
Although I would prefer not to have special cases like that,
it does work well.
Thanks!
I also noticed the following comment:
# XXX if we append a slash to directory names when using
# `compopt -o filenames`, Bash will append another slash.
# This is pretty stupid, and this the reason why we have to
# define a compatible version for this function.
So I gather you would rather add a '/' all the time to deal
with older bash version transparently. This would be great
for tcsh also. I'm trying to figure out
when bash mis-behaves when you add the '/' all the time?
When I try it (I have bash 4.1.5(1)-release) I didn't run
into the double slash problem you mention in the comment.
I'm using the same version: 4.1.5(1), on Debian stable.
I'm hoping we can straighten this out and have
git-completion.bash add the '/' all the time.
Could you explain when the problem happens?
Bash 4.1.5(1) always adds an additional slash for directories.
I have tested it right now: change the filter function to use the
compatible version:
__git_index_file_list_filter ()
{
# Default to Bash = 4.x
__git_index_file_list_filter_compat
}
Then running `git add TAB` inside the git repository, I get
this file
completion list:
$ git add TAB
contrib//
Ok, I see. The double-slash is visible in the completion list
but it does not appear on the command-line when bash automatically
adds it. So if you typed
git add contritab
you will properly get
git add contrib/
That is the case I was looking at.
I understand why you cannot put that second slash in the code now.
Thanks
Thanks
Thanks to you
Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEJZUMACgkQscQJ24LbaUQUGACgkMG/bZrJKBzlZ8toEQwmggQX
m9kAn2ATJbSp87kOkoCCc00eHmh71r3y
=D9iu
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-completion.tcsh and git-completion.zsh are broken?
-Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo Sent: Wednesday, January 09, 2013 2:17 PM To: git@vger.kernel.org Subject: git-completion.tcsh and git-completion.zsh are broken? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I have finally resolved all the problems with my path completion in git-completion.bash and, in order to avoid regressions, I'm checking the git-completion.zsh and git-completion.tcsh scripts, since they use the bash completion support. I have installed (Debian 6.0.6): * zsh 4.3.10 (i686-pc-linux-gnu) * tcsh 6.17.02 (Astron) 2010-05-12 (i586-intel-linux) options wide,nls,dl,al,kan,rh,nd,color,filec Note that I'm using my modified git-completion.bash script. zsh compatibility support in git-completion.bash seems to work (I just get a segmentation fault ...), however I have problems with the .zsh and .tcsh scripts. $zsh synapsis% source contrib/completion/git-completion.zsh (anon):6: command not found: ___main _git:11: command not found: _default I have disabled compinit autoload (since, I don't know how, it is able to find the git completion script) $tcsh synapsis:~/projects/git/contrib/git source ~/.git-completion.tcsh synapsis:~/projects/git/contrib/git git show HEAD:TAB does not show the file list for the tree object in the HEAD Hm. That doesn't work for me either. I'll look into it. It is not caused by your changes. another problem is that a space is added after a directory name. The lastest version of git-completion.tcsh in the pu branch should fix that problem. It was committed yesterday so you may not have it. Another problem with zsh: $zsh synapsis% git show HEAD:TAB569GPXZims I don't know where that 569GPXZims came from. Can someone else confirm these problems? Thanks Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDtwjcACgkQscQJ24LbaURpuACfVQnoBC3tzvxB0JYxQ5aL3rmN 8GEAnA7OjVtPqz+aq/PGtNtTHWgFqhKK =3UdZ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4] git-completion.bash: add support for path completion
-Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo Sent: Monday, January 07, 2013 8:43 AM To: Marc Khouzam Cc: Junio C Hamano; git@vger.kernel.org; sze...@ira.uka.de; felipe.contre...@gmail.com Subject: Re: [PATCH v4] git-completion.bash: add support for path completion -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 05/01/2013 21:23, Marc Khouzam ha scritto: [...] Below are two suggestions that are in line with this effort but that are not regressions. A) It would be nice if git commit -a TAB also completed with untracked files $ git commit -a foo fatal: Paths with -a does not make sense. So git commit -a TAB should not suggest untracked files; instead it should suggest nothing. You are right, I was confused. git commit --all TAB should also suggest nothing then. Thanks Marc-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Prevent space after directories in tcsh completion
If git-completion.bash returns a single directory as a completion,
tcsh will automatically add a space after it, which is not what the
user wants.
This commit prevents tcsh from doing this.
Also, a check is added to make sure the tcsh version used is recent
enough to allow completion to work as expected.
Signed-off-by: Marc Khouzam marc.khou...@ericsson.com
---
This update is meant to have tcsh completion work better if the
feature git-completion.bash: add support for path completion
is accepted.
See http://www.mail-archive.com/git@vger.kernel.org/msg14137.html
This commit does not depend on that other feature though and can
be applied right away.
Furthermore, based on feedback I received, some users are running
versions of tcsh that are over 5 years old and don't provide the
proper support for this script. I've added a check to let the user
know of such (sad) situation nicely.
Thanks
Marc
contrib/completion/git-completion.tcsh | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index 8aafb63..3e3889f 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -13,6 +13,7 @@
#
# To use this completion script:
#
+#0) You need tcsh 6.16.00 or newer.
#1) Copy both this file and the bash completion script to ${HOME}.
# You _must_ use the name ${HOME}/.git-completion.bash for the
# bash script.
@@ -24,6 +25,15 @@
#set autolist=ambiguous
# It will tell tcsh to list the possible completion choices.
+set __git_tcsh_completion_version = `\echo ${tcsh} | \sed 's/\./ /g'`
+if ( ${__git_tcsh_completion_version[1]} 6 || \
+ ( ${__git_tcsh_completion_version[1]} == 6 \
+ ${__git_tcsh_completion_version[2]} 16 ) ) then
+ echo git-completion.tcsh: Your version of tcsh is too old, you need
version 6.16.00 or newer. Git completion will not work.
+ exit
+endif
+unset __git_tcsh_completion_version
+
set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
@@ -64,9 +74,7 @@ fi
_\${1}
IFS=\$'\n'
-if [ \${#COMPREPLY[*]} -gt 0 ]; then
- echo \${COMPREPLY[*]} | sort | uniq
-else
+if [ \${#COMPREPLY[*]} -eq 0 ]; then
# No completions suggested. In this case, we want tcsh to perform
# standard file completion. However, there does not seem to be way
# to tell tcsh to do that. To help the user, we try to simulate
@@ -85,19 +93,20 @@ else
# We don't support ~ expansion: too tricky.
if [ \${TO_COMPLETE:0:1} != ~ ]; then
# Use ls so as to add the '/' at the end of directories.
- RESULT=(\`ls -dp \${TO_COMPLETE}* 2 /dev/null\`)
- echo \${RESULT[*]}
-
- # If there is a single completion and it is a directory,
- # we output it a second time to trick tcsh into not
adding a space
- # after it.
- if [ \${#RESULT[*]} -eq 1 ] [ \${RESULT[0]: -1} ==
/ ]; then
- echo \${RESULT[*]}
- fi
+ COMPREPLY=(\`ls -dp \${TO_COMPLETE}* 2 /dev/null\`)
fi
fi
fi
+# tcsh does not automatically remove duplicates, so we do it ourselves
+echo \${COMPREPLY[*]} | sort | uniq
+
+# If there is a single completion and it is a directory, we output it
+# a second time to trick tcsh into not adding a space after it.
+if [ \${#COMPREPLY[*]} -eq 1 ] [ \${COMPREPLY[0]: -1} == / ]; then
+ echo \${COMPREPLY[*]}
+fi
+
EOF
# Don't need this variable anymore, so don't pollute the users environment
--
1.8.1.367.g8e14972.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4] git-completion.bash: add support for path completion
Junio C Hamano gits...@pobox.com writes: Marc Khouzam marc.khou...@ericsson.com writes: I've been playing with it but I'm not getting the expected behavior when I cd to a sub-directory. Thanks for testing. Manlio? Can you try the attached patch? Thanks for this, it improves the situation dramatically. I did further testing with your patch and found some less obvious issues. I didn't debug the script myself as I'm not that familiar with it either, but I think the testcases below should help Manlio or someone else look into some regressions. 1- Using .. or . breaks completion when after the '/': cd git/contrib git rm ../contrib/completion/tab ../contrib/completion/ion.bash ../contrib/completion/ion.tcsh ../contrib/completion/ion.zsh ../contrib/completion/sh It looks like the space taken by the path where we are located, eats up the same number of characters from the file name, e.g., ../contrib/completion/ion.bash ../contrib/git-completion.bash 2- Maybe related to problem 1. Using .. breaks completion in other ways: cd git/contrib git rm ../contab ../config.c ../config.mak.in ../configure.ac ../connect.c ../connected.c../connected.h../convert.c ../convert.h Notice that 'contrib' is not proposed. Don't be fooled by the fact that git rm ../conttab will complete to git rm ../contrib as it is only because the completion script returned nothing, and bash file-completion kicked-in instead (it fooled me :)). 3- Also probably related to problems 1 and 2. Using absolute paths behaves wierdly and worse than before: git rm /home/marc/git/git/contab will give git rm /home/marc/git/git/config- although there is the 'contrib' dir that should be shown, amongst others. Seems like the same problem as above with 'git rm ../contab' In my opinion, the above three cases are regressions. 4- Completion choices include their entire path, which is not what bash does by default. For example: cd git/contrib ls completion/git-tab git-completion.bash git-completion.tcsh git-completion.zsh git-prompt.sh but git rm completion/git-tab completion/git-completion.bash completion/git-completion.tcsh completion/git-completion.zsh completion/git-prompt.sh notice the extra 'completion/' before each completion. This can get pretty large when completing with many directory prefixes. The current tcsh completion has the same problem which I couldn't fix. However, I am not sure if it can be fixed for bash. I personally don't think this is regression, just an slight annoyance. 5- With this feature git-completion.bash will return directories as completions. This is something git-completion.tcsh is not handling very well. I will post a patch to fix that. Below are two suggestions that are in line with this effort but that are not regressions. A) It would be nice if git commit -a TAB also completed with untracked files B) Now that, for example, 'git rm' completion is smart about path completion it would be nice to somehow not trigger bash default file completion when 'git rm' does not report any completions. For example, if I have a file called zz.tar.gz (which is an ignored file) and I do 'git rm tab', I will get the proper list of files that can be removed by git, excluding zz.tar.gz. But if I complete 'git rm zz.tar.tab' then the completion script will return nothing, since git cannot remove that ignored file, but we will then fall-back to the bash default completion, which will complete the file to zz.tar.gz. Although there are some issues, I think this feature will greatly benefit the user and is worth the time needed to fix. Thanks! Marc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4] git-completion.bash: add support for path completion
-Original Message-
From: git-ow...@vger.kernel.org
[mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo
Sent: Friday, December 21, 2012 11:55 AM
To: git@vger.kernel.org
Cc: sze...@ira.uka.de; felipe.contre...@gmail.com; Manlio Perillo
Subject: [PATCH v4] git-completion.bash: add support for path
completion
The git-completion.bash script did not implemented full, git aware,
support to complete paths, for git commands that operate on
files within
the current working directory or the index.
I think this is a great improvement! Very nice.
I've been playing with it but I'm not getting the expected
behavior when I cd to a sub-directory. Instead I get all files
in the repo as proposals. I'm trying it in the git git-repository
itself. Here is a sample:
git status
# On branch pu
nothing to commit, working directory clean
source contrib/completion/git-completion.bash
touch contrib/test1
touch contrib/test2
git status
# On branch pu
# Untracked files:
# (use git add file... to include in what will be committed)
#
# contrib/test1
# contrib/test2
nothing added to commit but untracked files present (use git add to track)
git add TAB # this works as expected and I get: contrib/test1
contrib/test2
cd contrib/
git add TAB
Display all 387 possibilities? (y or n) # That is not right. Shouldn't I get
# the same two files only?
Maybe I mis-understood what should happen?
Besides that, without looking at the patch in detail, I put just a couple
of minor points below.
As an example:
git add TAB
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Support path completion, for git commands where the
non-option arguments
always refer to paths within the current working directory or
the index, as the follow:
s/as the follow/as follows/
* the path completion for the git rm and git ls-files
commands will suggest all cached files.
* the path completion for the git add command will suggest all
untracked and modified files. Ignored files are excluded.
* the path completion for the git clean command will suggest all
untracked files. Ignored files are excluded.
* the path completion for the git mv command will suggest all cached
files when expanding the first argument, and all untracked
and cached
files for subsequent arguments. In the latter case, empty
directories
are included and ignored files are excluded.
* the path completion for the git commit command will suggest all
files that have been modified from the HEAD, if HEAD
exists, otherwise
it will suggest all cached files.
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
Changes from version 3:
* Fixed quoting issues
* Fixed default parameters handling
* Fixed a typo in the commit message: the affected
command was ls-files,
not ls-tree.
* Fixed incorrect behavior when expanding a path in git commit
command, for a newly created repository (when HEAD does not
exists).
* Make sure to always execute git commands with stderr
redirected to
/dev/null.
* Improved path completion for the git mv command.
This required a small refactorization of the __git_index_files
function, in order to support multiple options for ls-files.
contrib/completion/git-completion.bash | 140
+
1 file changed, 124 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..c8c6464 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
#*) .git/remotes file names
#*) git 'subcommands'
#*) tree paths within 'ref:path/to/file' expressions
+#*) file paths within current working directory and index
#*) common --long-options
#
# To use these routines:
@@ -233,6 +234,62 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 --
${3-$cur}))
}
+# Process path list returned by ls-files and diff-index
--name-only
+# commands, in order to list only file names relative to a specified
+# directory, and append a slash to directory names.
+# It accepts 1 optional argument: a directory path. The
path must have
+# a trailing slash.
+__git_index_file_list_filter ()
+{
+ local pfx=${1-} offset=${#pfx} path
+
+ while read -r path; do
+ path=${path:$offset}
+
+ case $path in
+ ?*/*) echo ${path%%/*}/ ;;
+ *) echo $path ;;
+ esac
+ done
+}
+
+#
[PATCH] Add file completion to tcsh git completion.
For bash completion, the option '-o bashdefault' is used to indicate
that when no other choices are available, file completion should be
performed. Since this option is not available in tcsh, no file
completion is ever performed. Therefore, commands like 'git add ',
'git send-email ', etc, require the user to manually type out
the file name. This can be quite annoying.
To improve the user experience we try to simulate file completion
directly in this script (although not perfectly).
The known issues with the file completion simulation are:
- Possible completions are shown with their directory prefix.
- Completions containing shell variables are not handled.
- Completions with ~ as the first character are not handled.
Signed-off-by: Marc Khouzam marc.khou...@ericsson.com
---
Beyond the described fix, this commit also improves minor aspects
of the script. Normally I would submit these things in different
commits, but I felt it would be wasting the reviewers/maintainer
time as they are very minor. If you do prefer different commits,
just let me know. The minor improvements are:
- update header to recommend setting a tcsh variable
- all missing tabs have been added
- use ',' instead of '/' in 'complete' command for users that
prefer to hard-code the path which also contains a '/' and
would cause a conflict.
- unset a variable to avoid polluting the user's env.
Thanks
Marc
contrib/completion/git-completion.tcsh | 69 ++
1 file changed, 54 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index 471f47b..8aafb63 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -19,23 +19,26 @@
# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
#2) Add the following line to your .tcshrc/.cshrc:
#source ~/.git-completion.tcsh
+#3) For completion similar to bash, it is recommended to also
+# add the following line to your .tcshrc/.cshrc:
+#set autolist=ambiguous
+# It will tell tcsh to list the possible completion choices.
set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
# Check that the user put the script in the right place
if ( ! -e ${__git_tcsh_completion_original_script} ) then
- echo git-completion.tcsh: Cannot find:
${__git_tcsh_completion_original_script}. Git completion will not work.
- exit
+ echo git-completion.tcsh: Cannot find:
${__git_tcsh_completion_original_script}. Git completion will not work.
+ exit
endif
cat EOF ${__git_tcsh_completion_script}
#!bash
#
# This script is GENERATED and will be overwritten automatically.
-# Do not modify it directly. Instead, modify the git-completion.tcsh
-# script provided by Git core.
-#
+# Do not modify it directly. Instead, modify git-completion.tcsh
+# and source it again.
source ${__git_tcsh_completion_original_script}
@@ -47,22 +50,58 @@ COMP_WORDS=(\$2)
# tell us that the previous word is complete and the cursor
# is on the next word.
if [ \${2: -1} == ]; then
- # The last character is a space, so our location is at the end
- # of the command-line array
- COMP_CWORD=\${#COMP_WORDS[@]}
+ # The last character is a space, so our location is at the end
+ # of the command-line array
+ COMP_CWORD=\${#COMP_WORDS[@]}
else
- # The last character is not a space, so our location is on the
- # last word of the command-line array, so we must decrement the
- # count by 1
- COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
+ # The last character is not a space, so our location is on the
+ # last word of the command-line array, so we must decrement the
+ # count by 1
+ COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
fi
# Call _git() or _gitk() of the bash script, based on the first argument
_\${1}
IFS=\$'\n'
-echo \${COMPREPLY[*]} | sort | uniq
+if [ \${#COMPREPLY[*]} -gt 0 ]; then
+ echo \${COMPREPLY[*]} | sort | uniq
+else
+ # No completions suggested. In this case, we want tcsh to perform
+ # standard file completion. However, there does not seem to be way
+ # to tell tcsh to do that. To help the user, we try to simulate
+ # file completion directly in this script.
+ #
+ # Known issues:
+ # - Possible completions are shown with their directory prefix.
+ # - Completions containing shell variables are not handled.
+ # - Completions with ~ as the first character are not handled.
+
+ # No file completion should be done unless we are completing beyond
+ # the git sub-command. An improvement on the bash completion :)
+ if [ \${COMP_CWORD} -gt 1 ]; then
+ TO_COMPLETE=\${COMP_WORDS[\${COMP_CWORD
Re: [PATCH] Support for git aliasing for tcsh completion
On Tue, Nov 27, 2012 at 12:16 PM, Junio C Hamano gits...@pobox.com wrote: The patch was linewrapped so I had to fix it up; Sorry about that. I don't know if it is gmail, or the fact that I use its web interface that causes these problems. please double check what will be queued on 'pu' to make sure that I did not miss necessary whitespaces or added unnecessary ones when I rejoined long lines. I just checked it and it looks great. I'm working on another improvement to the script but I don't have it working yet. But I should not bother you much after that. Thanks again! Marc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Support for git aliasing for tcsh completion
tcsh users sometimes alias the 'git' command to another name. In
this case, the user expects to only have to issue a new 'complete'
command using the alias name.
However, the tcsh script currently uses the command typed by the
user to call the appropriate function in git-completion.bash, either
_git() or _gitk(). When using an alias, this technique no longer
works.
This change specifies the real name of the command (either 'git' or
'gitk') as a parameter to the script handling tcsh completion. This
allows the user to use any alias for the 'git' or 'gitk' commands,
while still getting completion to work.
A check for the presence of ${HOME}/.git-completion.bash is also
added to help the user make use of the script properly.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
This issue was reported by someone already making use of the tcsh
completion script.
Thanks for considering this fix.
Marc
contrib/completion/git-completion.tcsh | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index dc5678c..44bd544 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -23,6 +23,12 @@
set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+# Check that the user put the script in the right place
+if ( ! -e ${__git_tcsh_completion_original_script} ) then
+ echo git-completion.tcsh: Cannot find:
${__git_tcsh_completion_original_script}. Git completion will not work.
+ exit
+endif
+
cat EOF ${__git_tcsh_completion_script}
#!bash
#
@@ -34,13 +40,13 @@ cat EOF ${__git_tcsh_completion_script}
source ${__git_tcsh_completion_original_script}
# Set COMP_WORDS in a way that can be handled by the bash script.
-COMP_WORDS=(\$1)
+COMP_WORDS=(\$2)
# The cursor is at the end of parameter #1.
# We must check for a space as the last character which will
# tell us that the previous word is complete and the cursor
# is on the next word.
-if [ \${1: -1} == ]; then
+if [ \${2: -1} == ]; then
# The last character is a space, so our location is at the end
# of the command-line array
COMP_CWORD=\${#COMP_WORDS[@]}
@@ -51,13 +57,12 @@ else
COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
fi
-# Call _git() or _gitk() of the bash script, based on the first
-# element of the command-line
-_\${COMP_WORDS[0]}
+# Call _git() or _gitk() of the bash script, based on the first argument
+_\${1}
IFS=\$'\n'
echo \${COMPREPLY[*]} | sort | uniq
EOF
-complete git 'p/*/`bash ${__git_tcsh_completion_script}
${COMMAND_LINE}`/'
-complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
${COMMAND_LINE}`/'
+complete git 'p/*/`bash ${__git_tcsh_completion_script} git
${COMMAND_LINE}`/'
+complete gitk 'p/*/`bash ${__git_tcsh_completion_script} gitk
${COMMAND_LINE}`/'
--
1.8.0.1.g9fe2839
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Completion must sort before using uniq
The user can be presented with invalid completion results when trying to complete a 'git checkout' command. This can happen when using a branch name prefix that matches multiple remote branches. For example if available branches are: master remotes/GitHub/maint remotes/GitHub/master remotes/origin/maint remotes/origin/master When performing completion on 'git checkout ma' the user will be given the choices: maint master However, 'git checkout maint' will fail in this case, although completion previously said 'maint' was valid. Furthermore, when performing completion on 'git checkout mai', no choices will be suggested. So, the user is first told that the branch name 'maint' is valid, but when trying to complete 'mai' into 'maint', that completion is no longer valid. The completion results should never propose 'maint' as a valid branch name, since 'git checkout' will refuse it. The reason for this bug is that the uniq program only works with sorted input. The man page states uniq prints the unique lines in a sorted file. When __git_refs uses the guess heuristic employed by checkout for tracking branches it wants to consider remote branches but only if the branch name is unique. To do that, it calls 'uniq -u'. However the input given to 'uniq -u' is not sorted. Therefore, in the above example, when dealing with 'git checkout ma', __git_refs '' 1 will find the following list: master maint master maint master which, when passed to 'uniq -u' will remain the same. Therefore 'maint' will be wrongly suggested as a valid option. When dealing with 'git checkout mai', the list will be: maint maint which happens to be sorted and will be emptied by 'uniq -u', properly ignoring 'maint'. A solution for preventing the completion script from suggesting such invalid branch names is to first call 'sort' and then 'uniq -u'. Signed-off-by: Marc Khouzam marc.khou...@gmail.com --- The solution is to first call 'sort' and then 'uniq -u'. The solution to what? This seems to be the right thing indeed, but you don't explain what is the actual problem that is being solved. What does the user experience? What would (s)he experience after the patch? I have re-worked the commit message to be more clear about the user impacts. Thanks for the feedback. Marc contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index bc0657a..85ae419 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -321,7 +321,7 @@ __git_refs () if [[ $ref == $cur* ]]; then echo $ref fi - done | uniq -u + done | sort | uniq -u fi return fi -- 1.8.0.1.g9fe2839 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] Completion must sort before using uniq
The user can be presented with invalid completion results when trying to complete a 'git checkout' command. This can happen when using a branch name prefix that matches multiple remote branches. For example, if available branches are: master remotes/GitHub/maint remotes/GitHub/master remotes/origin/maint remotes/origin/master When performing completion on 'git checkout ma' the user will be given the choices: maint master However, 'git checkout maint' will fail in this case, although completion previously said 'maint' was valid. Furthermore, when performing completion on 'git checkout mai', no choices will be suggested. So, the user is first told that the branch name 'maint' is valid, but when trying to complete 'mai' into 'maint', that completion is no longer valid. The completion results should never propose 'maint' as a valid branch name, since 'git checkout' will refuse it. The reason for this bug is that the uniq program only works with sorted input. The man page states uniq prints the unique lines in a sorted file. When __git_refs uses the guess heuristic employed by checkout for tracking branches it wants to consider remote branches but only if the branch name is unique. To do that, it calls 'uniq -u'. However the input given to 'uniq -u' is not sorted. Therefore, in the above example, when dealing with 'git checkout ma', __git_refs '' 1 will find the following list: master maint master maint master which, when passed to 'uniq -u' will remain the same. Therefore 'maint' will be wrongly suggested as a valid option. When dealing with 'git checkout mai', the list will be: maint maint which happens to be sorted and will be emptied by 'uniq -u', properly ignoring 'maint'. A solution for preventing the completion script from suggesting such invalid branch names is to first call 'sort' and then 'uniq -u'. Signed-off-by: Marc Khouzam marc.khou...@gmail.com --- Mostly cosmetic suggestions, but it looks OK to me. Thanks for the suggestions, I updated the commit message. With this explanation the patch looks good to me. Thanks for the quick review. Marc contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index bc0657a..85ae419 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -321,7 +321,7 @@ __git_refs () if [[ $ref == $cur* ]]; then echo $ref fi - done | uniq -u + done | sort | uniq -u fi return fi -- 1.8.0.1.g9fe2839 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcsh-completion re-using git-completion.bash
On Sat, Nov 17, 2012 at 1:01 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I gather that using a wrapper for zsh causes concerns about
backwards-compatibility.
I don't see any concerns.
if [[ -n ${ZSH_VERSION-} ]]; then
# replace below by zsh completion commands calling `bash
${HOME}/.git-completion.bash`
complete git 'p/*/`bash ${HOME}/.git-completion.bash ${COMMAND_LINE}`/'
complete gitk 'p/*/`bash ${HOME}/.git-completion.bash ${COMMAND_LINE}`/'
That doesn't work in zsh. It might be possible to do something
similar, but it would probably require many more lines.
Hi,
since there doesn't seem to be an agreement that the approach to achieve tcsh
git-completion would be useful for zsh (the other possible shell that could use
it is ksh, but I haven't looked into that), maybe the simplest thing
is to keep the
tcsh solution contained in a tcsh-only script. This is the latest solution as
proposed here:
[1] http://www.mail-archive.com/git@vger.kernel.org/msg12192.html
For reference, the more general solution was proposed here:
[2] http://www.mail-archive.com/git@vger.kernel.org/msg12122.html
If there is interest in merging [1], please let me know and I'll post another
version which adds a check to make sure that the user properly copied
git-completion.bash to be used by the new git-completion.tcsh.
Thanks for your input.
Marc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 4:56 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Nov 16, 2012 at 10:20 PM, Junio C Hamano gits...@pobox.com wrote:
The point is not about the quality of zsh's emulation
of (k)sh when it is run under that mode, but is about not having to
have that logic in bash-only part in the first place.
As I said, that logic can be moved away _if_ my wrapper is merged. But
then again, that would cause regressions to existing users.
Please forgive me as I don't know the background of the efforts for
zsh git-completion or
the syntax for zsh completion, but I thought I'd mention another
approach I tried for tcsh
which may work for zsh.
I gather that using a wrapper for zsh causes concerns about
backwards-compatibility.
So, what could be done is have the bash script do both jobs: setup the
zsh completion
commands, and output the git completion using bash itself. At the top
of git-completion.bash
(or it could be even pushed at the bottom using if/else) we could use:
if [[ -n ${ZSH_VERSION-} ]]; then
# replace below by zsh completion commands calling `bash
${HOME}/.git-completion.bash`
complete git 'p/*/`bash ${HOME}/.git-completion.bash ${COMMAND_LINE}`/'
complete gitk 'p/*/`bash ${HOME}/.git-completion.bash ${COMMAND_LINE}`/'
exit
fi
That way the zsh user would still simply do 'source
~/.git-completion.bash' which would
only execute the two zsh completion setup commands. Then, when completion is
triggered, it calls `bash ${HOME}/.git-completion.bash ${COMMAND_LINE}` and
processes the output like tcsh does. This limits the zsh-specific
code to 2 lines for
the entire script.
I got this to work for tcsh (solution (B)) adding the following a the top of
git-completion.bash:
test $tcsh != \
complete git 'p,*,`${HOME}/.git-completion.sh
${COMMAND_LINE}|\sort|\uniq`,' \
complete gitk 'p,*,`${HOME}/.git-completion.sh
${COMMAND_LINE}|\sort|\uniq`,' \
exit
but I didn't think people would go for that since those lines have to
work in both bash
and tcsh syntax. I thought this made the script a bit brittle.
Just a thought.
Marc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcsh-completion re-using git-completion.bash
On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam marc.khou...@gmail.com wrote:
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by executing (versus sourcing) the bash script and
outputting the completion result for tcsh consumption.
Three solutions were looked at to implement this approach with (A)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
As I said, I don't think this is needed. It can be done in a single
stand-alone script without modifications to git-completion.bash.
This works:
Thank you for taking the time to try things out.
What you suggest below is an improvement on solution (C).
I had chosen (A) instead because (C) creates a third script
which gets generated each time a new shell is started.
It should be safe, but it felt a little wrong.
But I have to admit I was on the fence between the two
solutions.
If you guys don't think it is bad to generate a third script
(that the user may notice in his ${HOME}),
I'll post a new patch (and try once more to get gmail not to
replace the tabs with spaces), using your improved
solution (C).
set called = ($_)
I fought with this a lot before posting to the list.
It seems that $_ is not set when a double sourcing
happens. Testing the solution as an actual user
showed me that when I start a new shell it
sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
and then $_ is empty for some reason.
I couldn't find another way to figure out where the script
is located, which is why I had to force the user to use
${HOME} for everything.
set script = ${called[2]}.tmp
cat \EOF $script
source $HOME/.git-completion.sh
This is nice. Shame on me not to have thought about it.
In my version I actually 'cat' the entire bash script into $script
instead of simply sourcing it.
# Set COMP_WORDS in a way that can be handled by the bash script.
COMP_WORDS=($1)
# Set COMP_CWORD to the cursor location as bash would.
if [ -n ${2-} ]; then
COMP_CWORD=$2
else
Since this code will be part of a tcsh-only script, I don't think
we need to prepare for a possible $2. tcsh won't provide it.
So, I'll remove that logic, which will simplify things slightly.
# Assume the cursor is at the end of parameter #1.
# We must check for a space as the last character which will
# tell us that the previous word is complete and the cursor
# is on the next word.
if [ ${1: -1} == ]; then
# The last character is a space, so our location is at the end
# of the command-line array
COMP_CWORD=${#COMP_WORDS[@]}
else
# The last character is not a space, so our location is on the
# last word of the command-line array, so we must decrement
the
# count by 1
COMP_CWORD=$((${#COMP_WORDS[@]}-1))
fi
fi
# Call _git() or _gitk() of the bash script, based on the first
# element of the command-line
_${COMP_WORDS[0]}
IFS=$'\n'
echo ${COMPREPLY[*]}
\EOF
complete git 'p/*/`bash ${script} ${COMMAND_LINE} | sort | uniq`/'
complete gitk 'p/*/`bash ${script} ${COMMAND_LINE} | sort | uniq`/'
I am worried about 'sort' and 'uniq' being aliased by the user, so I was
thinking of using '\sort | \uniq'
I'll work on the new version of the solution.
Thanks again
Marc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Nov 16, 2012 at 3:39 PM, Marc Khouzam marc.khou...@gmail.com wrote:
On Thu, Nov 15, 2012 at 8:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Nov 15, 2012 at 12:51 PM, Marc Khouzam marc.khou...@gmail.com
wrote:
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by executing (versus sourcing) the bash script and
outputting the completion result for tcsh consumption.
Three solutions were looked at to implement this approach with (A)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
As I said, I don't think this is needed. It can be done in a single
stand-alone script without modifications to git-completion.bash.
This works:
Thank you for taking the time to try things out.
What you suggest below is an improvement on solution (C).
I had chosen (A) instead because (C) creates a third script
which gets generated each time a new shell is started.
We could generate the script only when it's not already present. The
disadvantage is that if this script is updated, the helper one would
not.
I didn't like that too much either.
One way to solve the problem would be to append the current
version of git, and figure a way to query it out. Another would be to
checksum it. But then again, maybe it's more expensive to check the
version or checksum than just write the file again.
Yeah, I'm also thinking that re-generating the script is not bad enough
to introduce this complexity.
Is it possible to just check if this is a login shell?
I think it would be nice to allow the user to manually
source git-completion.tcsh, in case they want to make
manual modifications to it.
I think the most user-friendly option is to actually re-generate the
script each time. It feels wrong, but it works well :)
set called = ($_)
I fought with this a lot before posting to the list.
It seems that $_ is not set when a double sourcing
happens. Testing the solution as an actual user
showed me that when I start a new shell it
sources ~/.tcshrc, which then sources ~/.git-completion.tcsh
and then $_ is empty for some reason.
I couldn't find another way to figure out where the script
is located, which is why I had to force the user to use
${HOME} for everything.
Ah :(
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] tcsh-completion re-using git-completion.bash
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by sourcing the bash script and outputting the completion
result for tcsh consumption.
Three solutions were looked at to implement this approach with (C)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
The modification to git-completion.bash is made not to be
tcsh-specific, but to allow future users to also re-use its
output. Therefore, to be general, git-completion.bash accepts a
second optional parameter, which is not used by tcsh, but could
prove useful for other users.
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that generates another script
which extends git-completion.bash. This new script can be
used by tcsh to perform completion.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (C) was selected avoid any modification to git-completion.bash.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
Here's another version which adds contrib/completion/git-completion.tcsh but
does not modify contrib/completion/git-completion.bash at all.
(Sorry, but I still can't get gmail to stop changing the tabs for spaces)
Thanks in advance.
Marc
contrib/completion/git-completion.tcsh | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100644
index 000..76395f9
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,63 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Distributed under the GNU General Public License, version 2.0.
+#
+# When sourced, this script will generate a new script that uses
+# the git-completion.bash script provided by core Git. This new
+# script can be used by tcsh to perform git completion.
+# The current script also issues the necessary tcsh 'complete'
+# commands.
+#
+# To use this completion script:
+#
+#1) Copy both this file and the bash completion script to ${HOME}.
+# You _must_ use the name ${HOME}/.git-completion.bash for the
+# bash script.
+# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
+#2) Add the following line to your .tcshrc/.cshrc:
+#source ~/.git-completion.tcsh
+
+set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
+set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+
+cat EOF ${__git_tcsh_completion_script}
+#!bash
+#
+# This script is GENERATED and will be overwritten automatically.
+# Do not modify it directly. Instead, modify the git-completion.tcsh
+# script provided by Git core.
+#
+
+source
Re: [PATCH] tcsh-completion re-using git-completion.bash
On Fri, Nov 16, 2012 at 12:18 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Nov 16, 2012 at 4:48 PM, Marc Khouzam marc.khou...@gmail.com wrote: On Fri, Nov 16, 2012 at 10:33 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Is it possible to just check if this is a login shell? I think it would be nice to allow the user to manually source git-completion.tcsh, in case they want to make manual modifications to it. Yeah, they could still do that... because they would be running in a login shell. What I meant is that if the user does: tcsh my_script_that_has_nothing_to_do_with_completion.sh, they would not be executing this whole script. Oh, I see now. I can put a check in the script for the existence of the $prompt variable. This will indicate if it is a login shell or not. However, a good .cshrc file should already have such a check to avoid sourcing a bunch of useless things. So, I personally think that we should not add it to the git-completion.tcsh script but let the tcsh user decide to do it herself. But I don't mind being overruled :) I think the most user-friendly option is to actually re-generate the script each time. It feels wrong, but it works well :) I'm not too strongly opposed to add that function to the bash completion, but to do it only for tcsh doesn't sound right, specially when there are other alternatives. I agree, and this is why I made the proposed __git_complete_with_output () generic. That way it could be used by other shells or programs. But at this time, only tcsh would make use of it. If you think having __git_complete_with_output () could be useful for others, I think we should go with solution (A). If you don't think so, or if it is better to wait until a need arises first, then solution (C) will work fine. Correct me if I'm wrong, but very few people use tcsh. Less than I originally thought, when I started working on this patch :-\ But I'm still hoping that the those people will be a little happier with their git completion. Marc -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] tcsh-completion re-using git-completion.bash
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by sourcing the bash script and outputting the completion
result for tcsh consumption.
Three solutions were looked at to implement this approach with (C)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
The modification to git-completion.bash is made not to be
tcsh-specific, but to allow future users to also re-use its
output. Therefore, to be general, git-completion.bash accepts a
second optional parameter, which is not used by tcsh, but could
prove useful for other users.
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that generates another script
which extends git-completion.bash. This new script can be
used by tcsh to perform completion.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (C) was selected avoid any modification to git-completion.bash.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
As suggested, I put the 'sort | uniq' inside the script.
In that case, I don't need to worry about aliases since 'sort |uniq' will
be executed in bash, for which the tcsh user surely doesn't have aliases setup.
Thanks
Marc
contrib/completion/git-completion.tcsh | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100644
index 000..f0327fc
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,63 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Distributed under the GNU General Public License, version 2.0.
+#
+# When sourced, this script will generate a new script that uses
+# the git-completion.bash script provided by core Git. This new
+# script can be used by tcsh to perform git completion.
+# The current script also issues the necessary tcsh 'complete'
+# commands.
+#
+# To use this completion script:
+#
+#1) Copy both this file and the bash completion script to ${HOME}.
+# You _must_ use the name ${HOME}/.git-completion.bash for the
+# bash script.
+# (e.g. ~/.git-completion.tcsh and ~/.git-completion.bash).
+#2) Add the following line to your .tcshrc/.cshrc:
+#source ~/.git-completion.tcsh
+
+set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
+set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+
+cat EOF ${__git_tcsh_completion_script}
+#!bash
+#
+# This script is GENERATED and will be overwritten automatically.
+# Do not modify it directly. Instead, modify the git-completion.tcsh
+# script provided by Git core.
+#
+
+source ${__git_tcsh_completion_original_script
[PATCH] tcsh-completion re-using git-completion.bash
The current tcsh-completion support for Git, as can be found on the
Internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by executing (versus sourcing) the bash script and
outputting the completion result for tcsh consumption.
Three solutions were looked at to implement this approach with (A)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
The modification to git-completion.bash is made not to be
tcsh-specific, but to allow future users to also re-use its
output. Therefore, to be general, git-completion.bash accepts a
second optional parameter, which is not used by tcsh, but could
prove useful for other users.
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that converts git-completion.bash
into an executable script suitable to be used by tcsh.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (A) was selected to keep the tcsh completion support well
isolated without introducing excessive complexity.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
---
Here is the updated version of the patch.
I got git send-email to work, so I hope the formatting will be correct.
Thanks in advance.
Marc
contrib/completion/git-completion.bash | 47
contrib/completion/git-completion.tcsh | 29 +++
2 files changed, 76 insertions(+), 0 deletions(-)
create mode 100644 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e0..d71a016 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2481,3 +2481,50 @@ __git_complete gitk __gitk_main
if [ Cygwin = $(uname -o 2/dev/null) ]; then
__git_complete git.exe __git_main
fi
+
+# Method that will output the result of the completion done by
+# the bash completion script, so that it can be re-used in another
+# context than the bash complete command.
+# It accepts 1 to 2 arguments:
+# 1: The command-line to complete
+# 2: The index of the word within argument #1 in which the cursor is
+#located (optional). If parameter 2 is not provided, it will be
+#determined as best possible using parameter 1.
+__git_complete_with_output ()
+{
+ # Set COMP_WORDS in a way that can be handled by the bash script.
+ COMP_WORDS=($1)
+
+ # Set COMP_CWORD to the cursor location as bash would.
+ if [ -n ${2-} ]; then
+ COMP_CWORD=$2
+ else
+ # Assume the cursor is at the end of parameter #1.
+ # We must check for a space as the last character which will
+ # tell us that the previous word is complete and the cursor
+ # is on the next word.
+ if [ ${1: -1} == ]; then
+ # The last character is a space, so our
Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
Thanks for the review.
On Tue, Nov 13, 2012 at 6:14 AM, SZEDER Gábor sze...@ira.uka.de wrote:
Hi,
On Mon, Nov 12, 2012 at 03:07:46PM -0500, Marc Khouzam wrote:
Hi,
[...]
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
[...]
Thanks
Marc
---
contrib/completion/git-completion.bash | 53
+++-
contrib/completion/git-completion.tcsh | 34
2 files changed, 86 insertions(+), 1 deletions(-)
create mode 100755 contrib/completion/git-completion.tcsh
Please have a look at Documentation/SubmittingPatches to see how to
properly format the commit message, i.e. no greeting and sign-off in
the commit message part, and the S-o-b line should be the last before
the '---'.
Sorry about that, since I should have noticed it in the doc.
I will do my best to address all submission issues mentioned
when I post the next version of the patch.
Your patch seems to be severely line-wrapped. That document also
contains a few MUA-specific tips to help avoid that.
Other than that, it's a good description of the changes and
considerations. I agree that this approach seems to be the best from
the three.
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e0..6d4b57a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1,4 +1,6 @@
-#!bash
+#!/bin/bash
+# The above line is important as this script can be executed when used
+# with another shell such as tcsh
See comment near the end.
Great suggestion below. I removed the above change.
+ # Set COMP_WORDS to the command-line as bash would.
+ COMP_WORDS=($1)
That comment is only true for older Bash versions. Since v4 Bash
splits the command line at characters that the readline library treats
as word separators when performing word completion. But the
completion script has functions to deal with both, so this shouldn't
be a problem.
I've updated the comment to be more general and left the code
the same since it is supported by the script.
+ # Print the result that is stored in the bash variable ${COMPREPLY}
Really? ;)
Removed :)
+ for i in ${COMPREPLY[@]}; do
+ echo $i
+ done
There is no need for the loop here to print the array one element per
line:
local IFS=$'\n'
echo ${COMPREPLY[*]}
Better. Thanks.
+if [ -n $1 ] ; then
+ # If there is an argument, we know the script is being executed
+ # so go ahead and run the _git_complete_with_output function
+ _git_complete_with_output $1 $2
Where does the second argument come from? Below you run this script
as '${__git_tcsh_completion_script} ${COMMAND_LINE}', i.e. $2 is
never set. Am I missing something?
This second argument is optional and, if present, will be put in
$COMP_CWORD. If not present, $COMP_CWORD must be computed
from $1. Also see comment above _git_complete_with_output ().
tcsh does not provide me with this information, so I cannot make use of it.
However, I thought it would be more future-proof to allow it for other shells
which may have that information.
It is not necessary for tcsh, so I can remove if you prefer?
+# Make the script executable if it is not
+if ( ! -x ${__git_tcsh_completion_script} ) then
+ chmod u+x ${__git_tcsh_completion_script}
+endif
Not sure about this. If I source a script to provide completion for a
command, then I definitely don't expect it to change file permissions.
However, even if the git completion script is not executable, you can
still run it with 'bash ${__git_tcsh_completion_script}'. This way
neither the user would need to set permissions, not the script would
need to set it behind the users back. Furthermore, this would also
make changing the shebang line unnecessary.
Very nice! Done.
+complete git 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
+complete gitk 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
Is the 'sort | uniq' really necessary? After the completion function
returns Bash automatically sorts the elements in COMPREPLY and removes
any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
completion.
On my machine, tcsh does not remove duplicates. It does sort the results
but that is done after I've run 'uniq', which is too late. I'm not
happy about this
either, but the other option is to improve git-completion.bash to
avoid duplicates,
which seemed less justified.
Does the git completion script returns any duplicates at all?
It does. 'help' is returned twice for example.
Also, when completing 'git checkout ' in the git repo, I can see multiple
'todo' branches, as well as 'master', 'pu', 'next', etc.
You can actually try it without tcsh by running my proposed version of
git-completion.bash like this:
cd git/contrib/completion
bash git-completion.bash git checkout | sort
Re: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
Thanks for the review. I wasn't aware that you were doing
a similar effort for zsh.
On Tue, Nov 13, 2012 at 1:31 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Nov 12, 2012 at 9:07 PM, Marc Khouzam marc.khou...@gmail.com wrote:
this patch allows tcsh-users to get the benefits of the awesome
git-completion.bash script. It could also help other shells do the same.
Maybe you can try to take a look at the same for zsh:
http://article.gmane.org/gmane.comp.version-control.git/208173
Cool. The major difference is that (as Gábor mentioned) zsh understands bash
syntax but tcsh does not. tcsh doesn't even allow to define
functions. So we have
to take a different approach to get the bash completion script to be
used by tcsh.
---
contrib/completion/git-completion.bash | 53
+++-
contrib/completion/git-completion.tcsh | 34
2 files changed, 86 insertions(+), 1 deletions(-)
create mode 100755 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e0..6d4b57a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1,4 +1,6 @@
-#!bash
+#!/bin/bash
+# The above line is important as this script can be executed when used
+# with another shell such as tcsh
#
# bash/zsh completion support for core Git.
#
@@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
if [ Cygwin = $(uname -o 2/dev/null) ]; then
__git_complete git.exe __git_main
fi
+
+# Method that will output the result of the completion done by
+# the bash completion script, so that it can be re-used in another
+# context than the bash complete command.
+# It accepts 1 to 2 arguments:
+# 1: The command-line to complete
+# 2: The index of the word within argument #1 in which the cursor is
+#located (optional). If parameter 2 is not provided, it will be
+#determined as best possible using parameter 1.
+_git_complete_with_output ()
+{
+ # Set COMP_WORDS to the command-line as bash would.
+ COMP_WORDS=($1)
+
+ # Set COMP_CWORD to the cursor location as bash would.
+ if [ -n $2 ]; then
+ COMP_CWORD=$2
+ else
+ # Assume the cursor is at the end of parameter #1.
+ # We must check for a space as the last character which will
+ # tell us that the previous word is complete and the cursor
+ # is on the next word.
+ if [ ${1: -1} == ]; then
+ # The last character is a space, so our
location is at the end
+ # of the command-line array
+ COMP_CWORD=${#COMP_WORDS[@]}
+ else
+ # The last character is not a space, so our
location is on the
+ # last word of the command-line array, so we
must decrement the
+ # count by 1
+ COMP_CWORD=$((${#COMP_WORDS[@]}-1))
+ fi
+ fi
+
+ # Call _git() or _gitk() of the bash script, based on the first
+ # element of the command-line
+ _${COMP_WORDS[0]}
You might want to use __${COMP_WORDS[0]}_main instead.
+
+ # Print the result that is stored in the bash variable ${COMPREPLY}
+ for i in ${COMPREPLY[@]}; do
+ echo $i
+ done
+}
+
+if [ -n $1 ] ; then
+ # If there is an argument, we know the script is being executed
+ # so go ahead and run the _git_complete_with_output function
+ _git_complete_with_output $1 $2
+fi
Why do you need this function in this file? You can very easily add
this function to git-completion.tcsh.
tcsh does not allow to define functions, so it is not aware of any
of the git-completion.bash functions. So, git-completion.tcsh
cannot call anything from git-completion.bash.
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
new file mode 100755
index 000..7b7baea
--- /dev/null
+++ b/contrib/completion/git-completion.tcsh
@@ -0,0 +1,34 @@
+#!tcsh
+#
+# tcsh completion support for core Git.
+#
+# Copyright (C) 2012 Marc Khouzam marc.khou...@gmail.com
+# Distributed under the GNU General Public License, version 2.0.
+#
+# This script makes use of the git-completion.bash script to
+# determine the proper completion for git commands under tcsh.
+#
+# To use this completion script:
+#
+#1) Copy both this file and the bash completion script to your
${HOME} directory
+# using the names ${HOME}/.git-completion.tcsh and
${HOME}/.git-completion.bash.
+#2) Add the following line to your .tcshrc/.cshrc:
+#source ${HOME}/.git-completion.tcsh
+
+# One can change the below line to use a different location
+set __git_tcsh_completion_script = ${HOME}/.git-completion.bash
+
+# Check that the user
Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
On Tue, Nov 13, 2012 at 6:46 PM, SZEDER Gábor sze...@ira.uka.de wrote:
Hi,
On Tue, Nov 13, 2012 at 03:12:44PM -0500, Marc Khouzam wrote:
+if [ -n $1 ] ; then
+ # If there is an argument, we know the script is being executed
+ # so go ahead and run the _git_complete_with_output function
+ _git_complete_with_output $1 $2
Where does the second argument come from? Below you run this script
as '${__git_tcsh_completion_script} ${COMMAND_LINE}', i.e. $2 is
never set. Am I missing something?
This second argument is optional and, if present, will be put in
$COMP_CWORD. If not present, $COMP_CWORD must be computed
from $1. Also see comment above _git_complete_with_output ().
tcsh does not provide me with this information, so I cannot make use of it.
However, I thought it would be more future-proof to allow it for other shells
which may have that information.
It is not necessary for tcsh, so I can remove if you prefer?
I see. I read those comments and understood what it is about. I was
just surprised that the code is there to make use of it, yet it's not
specified when invoking that function.
Since it's a trivial piece of code, I would say let's keep it. Could
you please add a sentence about it (that it's for possible future
users and it's not used at the moment) to the commit message for
future reference?
Will do.
+complete git 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
+complete gitk 'p/*/`${__git_tcsh_completion_script} ${COMMAND_LINE}
| sort | uniq`/'
Is the 'sort | uniq' really necessary? After the completion function
returns Bash automatically sorts the elements in COMPREPLY and removes
any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
completion.
On my machine, tcsh does not remove duplicates. It does sort the results
but that is done after I've run 'uniq', which is too late. I'm not
happy about this
either, but the other option is to improve git-completion.bash to
avoid duplicates,
which seemed less justified.
Ok. Then keep it for the time being, and we'll see what we can do to
avoid those duplicates.
Thanks.
Does the git completion script returns any duplicates at all?
It does. 'help' is returned twice for example.
Right. Now that you mentioned it, I remember I noticed it a while
ago, too. I even wrote a patch to fix it, but not sure what became of
it. Will try to dig it up.
Thanks for already posting the patch.
Also, when completing 'git checkout ' in the git repo, I can see multiple
'todo' branches, as well as 'master', 'pu', 'next', etc.
You can actually try it without tcsh by running my proposed version of
git-completion.bash like this:
cd git/contrib/completion
bash git-completion.bash git checkout | sort | uniq --repeated
Interesting, I can't reproduce. Are the duplicates also there, if you
start a bash, source git-completion.bash, and run __git_refs ?
Running __git_refs does not show the duplicates, but running
__git refs '' 1
does show them.
That second parameter causes __git_refs to
use the guess heuristic employed by checkout for tracking branches
I don't quite understand this, but what I can see is that my remote
branches GitHub/master and origin/master each cause another
'master' to be listed:
$ __git_refs '' 1|grep master
master
GitHub/master
origin/master
master
master
All fixes are done and I'll post a second version of the patch
as soon as I can figure out the formatting properly.
Thanks again
Marc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
Hi,
this patch allows tcsh-users to get the benefits of the awesome
git-completion.bash script. It could also help other shells do the same.
==
The current tcsh-completion support for Git, as can be found on the
internet, takes the approach of defining the possible completions
explicitly. This has the obvious draw-back to require constant
updating as the Git code base evolves.
The approach taken by this commit is to to re-use the advanced bash
completion script and use its result for tcsh completion. This is
achieved by executing (versus sourcing) the bash script and
outputting the completion result for tcsh consumption.
Three solutions were looked at to implement this approach with (A)
being retained:
A) Modifications:
git-completion.bash and new git-completion.tcsh
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash.
When being executed, the script will output the result of the
computed completion to be re-used elsewhere (e.g., in tcsh).
Pros:
1- allows the git-completion.bash script to easily be re-used
2- tcsh support is mostly isolated in git-completion.tcsh
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
B) Modifications:
git-completion.bash
Modify the existing git-completion.bash script to support
being sourced using bash (as now), but also executed using bash,
and sourced using tcsh.
Pros:
1- only requires the user to deal with a single file
2- maintenance more obvious for tcsh since it is entirely part
of the same git-completion.bash script.
Cons:
1- tcsh support could affect bash support as they share the
same script
2- small tcsh section must use syntax suitable for both tcsh
and bash and must be at the beginning of the script
3- requires the user to explicitly make the script executable
when using tcsh (for tcsh users only)
4- requires script to have a fixed name and location:
${HOME}/.git-completion.sh (for tcsh users only)
C) Modifications:
New git-completion.tcsh
Provide a short tcsh script that converts git-completion.bash
into an executable script suitable to be used by tcsh.
Pros:
1- tcsh support is entirely isolated in git-completion.tcsh
2- new tcsh script can be as complex as needed
Cons (for tcsh users only):
1- requires the user to copy both git-completion.tcsh and
git-completion.bash to ${HOME}
2- requires bash script to have a fixed name and location:
${HOME}/.git-completion.bash
3- sourcing the new script will generate a third script
Approach (A) was selected to keep the tcsh completion support well
isolated without introducing excessive complexity.
Signed-off-by: Marc Khouzam marc.khou...@gmail.com
==
With the changes applied, tcsh users should:
#1) Copy both this file and the bash completion script to your
${HOME} directory
# using the names ${HOME}/.git-completion.tcsh and
${HOME}/.git-completion.bash.
#2) Add the following line to your .tcshrc/.cshrc:
#source ${HOME}/.git-completion.tcsh
The code can be found on GitHub.
Option (A):
https://github.com/marckhouzam/git/commit/86d3a8e740ae85b4b4462c997a0fd969b1b2d24c
Option (B):
https://github.com/marckhouzam/git/commit/e64606541682eaf66c0a56aceff279ca6e1d06cd
Option (C):
https://github.com/marckhouzam/git/commit/59792455f1e6a98d3ffeb828f4cff1ded0e4ed37
Thanks
Marc
---
contrib/completion/git-completion.bash | 53 +++-
contrib/completion/git-completion.tcsh | 34
2 files changed, 86 insertions(+), 1 deletions(-)
create mode 100755 contrib/completion/git-completion.tcsh
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index be800e0..6d4b57a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1,4 +1,6 @@
-#!bash
+#!/bin/bash
+# The above line is important as this script can be executed when used
+# with another shell such as tcsh
#
# bash/zsh completion support for core Git.
#
@@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
if [ Cygwin = $(uname -o 2/dev/null) ]; then
__git_complete git.exe __git_main
fi
+
+# Method that will output the result of the completion done by
+# the bash completion script, so that it can be re-used in another
+# context than the bash complete command.
+# It accepts 1 to 2 arguments:
+# 1: The command-line to complete
+# 2: The index of the word within argument #1 in which the cursor is
+#located (optional). If parameter 2 is not provided, it will be
+#determined as best
