Koichi Murase

> It seems his point was, accept such customisations if it makes sense?! Ah, yes, I think so (though that sounds like a tautology, i.e., *accept acceptable customizations*). I think...

After all, @scop will decide what should enter in this project and what not. This is just based on my guess about the policy of this project from my experience,...

> Sure,... I'd find it a pity if such nice functionality wasn't accepted but life goes on. Ah, wait. Maybe I have confused you, but the suggested functionality has not...

I think the proposed `_comp_return_hook` is an interesting and powerful idea that can be used for general customization although I tend to avoid traps as traps have some non-trivial behavior...

> Well documentation barely counts as complexity... and if you just take the main commit, remove comment and whitespace lines, than it's 6 lines, two of them closing `fi`s. >...

> One could simply call the hook-handler like: > > ``` > _comp_user_hook ${FUNCNAME[0]} "return" > ``` > > e.g. in `_known_hosts_real()` just before the `return` Are you suggesting adding...

> Hmm.. couldn't one workaround that by some naming convention? Like on key for the associate array, of the form `function-phase`. `-` cannot be part of function names, so that...

The problem of newlines is related to the design of the Bash interface for the completions, (i.e., that of `compgen`), so there is actually nothing we can do to solve...

> > ``` > > * Option 2: Make the completion results independent of `COMP_TYPE`? > > ``` > > > This sounds good to me in principle, but I...

I'm going to update this PR after another PR #548, which the new commits for this PR would depend on, is processed. > > > * Option 2: Make the...