On Sun, Dec 11, 2011 at 07:35:01PM +0100, Raphaël wrote: > this attempts to explain why $split && return
...messing-up with git branches, attached a patch against master + raw text below: $split && return ---------------- Should be used in completions using the -s flag of _init_completion, after $prev has been managed but before $cur is considered. Rationale: -s flag calls _split_longopt() which attempt to split $cur. $split = 0 means: - $cur was actually split (during _init_completion()) - _split_longopt() actually split $cur into $prev=--* and $cur=<something> - the value of $cur within the completion is rather non-significant outside the context of $prev.
diff --git a/doc/styleguide.txt b/doc/styleguide.txt index 12b224f..ed0d3db 100644 --- a/doc/styleguide.txt +++ b/doc/styleguide.txt @@ -75,6 +75,17 @@ appended after the equal sign. Calling compopt -o nospace makes sense in case completion actually occurs: when only one completion is available in COMPREPLY. +$split && return +---------------- +Should be used in completions using the -s flag of _init_completion, +after $prev has been managed but before $cur is considered. +Rationale: -s flag calls _split_longopt() which attempt to split $cur. +$split = 0 means: +- $cur was actually split (during _init_completion()) +- _split_longopt() actually split $cur into $prev=--* and $cur=<something> +- the value of $cur within the completion is rather non-significant +outside the context of $prev + ///////////////////////////////////////// case/esac vs if ---------------
_______________________________________________ Bash-completion-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
