bash completion fix

Fix bash completion of "git annex" to propertly handle files with spaces
and other problem characters. (Completion of "git-annex" already did.)

This commit was sponsored by Jake Vosloo on Patreon.

CHANGELOG

@@ -5,6 +5,9 @@ git-annex (7.20181106) UNRELEASED; urgency=medium
     two different objects.)
   * Fixed some other potential hangs in the P2P protocol.
   * Fix build with persistent-sqlite older than 2.6.3.
+  * Fix bash completion of "git annex" to propertly handle files with
+    spaces and other problem characters. (Completion of "git-annex"
+    already did.)
 
  -- Joey Hess <id@joeyh.name>  Tue, 06 Nov 2018 12:44:27 -0400
 

bash-completion.bash

@@ -1,6 +1,6 @@
 # Use git-annex's built-in bash completion
-# This bash completion is generated by the option parser, so it covers all
-# commands, all options, and will never go out of date!
+# This is the same code output by git-annex --bash-completion-script git-annex
+# This covers all commands, all options, and will never go out of date!
 _git-annex()
 {
     local CMDLINE
@@ -17,8 +17,9 @@ _git-annex()
 complete -o bashdefault -o default -o filenames -F _git-annex git-annex
 
 # Called by git's bash completion script when completing "git annex"
+# Translate to the "git-annex" completion above.
 _git_annex() {
-    local cmdline
+    local CMDLINE
     CMDLINE=(--bash-completion-index $(($COMP_CWORD - 1)))
 
     local seen_git
@@ -34,5 +35,10 @@ _git_annex() {
 	fi
     done
 
+    # This is the same as __gitcomp_file_direct in git-completion.bash;
+    local IFS=$'\n'
     COMPREPLY=( $(git-annex "${CMDLINE[@]}") )
+    compopt -o filenames +o nospace ||
+    compgen -f /non-existing-dir/ >/dev/null ||
+    true
 }

doc/bugs/Bash_completion_of_filenames_with_spaces.mdwn

@@ -51,3 +51,4 @@ However, it doesn't correctly handle escape characters. Typically, a filename co
 
 Many times over! I use git-annex to manage my hundreds of pdfs, images, video files etc! It essentially enables *exactly* the work flow I like, since I live in the command line and appreciate fine-grained control over my tools. So, yes, thank you very much for this excellent too!
 
+> [[fixed|done]] --[[Joey]]

doc/bugs/Bash_completion_of_filenames_with_spaces/comment_1_03146fdf32b16c9f3398c5a9c3ab32f6._comment

@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-11-12T16:13:26Z"
+ content="""
+I see this too. Note that it only affects tab
+completing "git annex"; tab completing "git-annex"
+works correctly for filenames with spaces and AFAICS
+other problem characters.
+
+It used to be that git-annex's tab completion for "git annex" was only used
+after the user tab completed "git-annex" which loaded the function.
+That has changed; git now loads the git-annex completion. Which is good;
+I asked the git devs a long time ago to add that. But the change means this
+problem is more visible. I don't think the problem is new though.
+
+[[!commit 07c108e70e2df354d1478cbbec3630d2409d9d32]]
+dealt with the same problem affecting "git-annex" tab completion.
+The underlying problem is a bug in optparse-applicative, which
+completes filenames without escaping them.
+So that commit made the "git-annex" completion use "-o bashdefault -o default"
+which bypasses the optparse-applicative completion for filenames and lets
+bash handle them. It didn't seem to deal with "git annex" completion.
+
+I see that git uses `__gitcomp_file_direct` when using eg `git ls-files`
+to list filenames. It seems that "compopt -o filenames" along with
+IFS=newline fixes it. I'll put the same approach into the git-annex script.
+"""]]