Most of the included files are meant to be output literally, without any
macro processing. Using `undivert` in place of `include` achieves that.
This is a safety net against unsanitized input generated during the
build. Also, developers editing the shell code stub shouldn't be
constantly alert about triggering accidental macro expansion.
In order that `undivert` mimics GNU behaviour on BSDs, the `-g` flag is
used for the m4 invocation.
This way we can easily edit m4 in m4-mode and the shell script stub
in sh-mode and prevent subtle errors coming from accidental quoting
issues or macros (mis)interpreted by m4.
Get rid of manually listing unhandled long options:
Instead of listing options requiring an argument one by one in the
case statement in _hledger_compreply_optarg(), the option completion
lists are searched and if the option does require an argument an
empty COMPREPLY is send. Short options are uncounted for and still
need a manual entry.
This necessitated setting $subcommandOptions beforehand, so it is
moved back where it was -- in the sub-command loop in main().
Similarly to long options treatment, suspend space only when
completing what looks like a query or account prefix i.e. something
ending with a colon (:).
Make it obvious that the option expects an argument by appending
the equal sign on completion. Suspend space in this case. The
regular expression in `output-options.sh` is adjusted to take into
account this on processing option strings.
I was looking at how other programs that have an overwhelming
number of sub-commands and options deal with completion, namely
how git does it, and I liked the clean workflow not spitting every
available option until asked for. Hledger's main workflow is:
> hledger COMMAND QUERY
so I have tried to reproduce this with this change. Options are of
course still there, but not shown until you ask for them by entering
a dash on the command line. Also, the `acct:` filter proposes only top
level accounts until there is some input from the user because accounts
tend to be numerous as well.
Commit #64282f3f broke that somehow so I need to force the match on
an empty string after the equal sign, not the equal sign itself.
I think that _init_completion() does a bit more than I need...
This is about the looks of the completion list -- if we have a
directory with the name of a subcommand it will be presented with
a trailing slash. This avoids that.
This allows more flexibility when generating completion candidates
and we don't need to resort to external help from `sed` or others.
_hledger_compgen's arguments become:
$1 -> $wordlist:
a newline separated wordlist with completion cadidates
$2 -> $prefix:
(optional) a prefix string to add to generated completions
$3 -> $match:
(optional) a word to match instead of $cur, the default.
If $match is null and $prefix is defined the match is done against $cur
stripped of $prefix. If both $prefix and $match are null we match against
$cur and no prefix is added to completions. Of course you can also pass
an empty string as $prefix and set $match to whatever you wish.
This handles a lot that we have to do manually otherwise. Without
this we need to handle e.g. redirections to get completion for say:
> hledger payees > <TAB>
Also because this function assumes that we use `cur`, `prev`, `words`
and `cword` and sets them up for us, `wordToComplete`, `COMP_WORDS`
and `COMP_CWORD` are renamed accordingly. Those names are pretty much
hard-coded in bash completion so it is easier to follow the lead than
go with custom variable names.
