Christoph Anton Mitterer

> FYI, Ville's reply to the customizability: #539 (comment). Well.. what exactly does that say in the end? It seems his point was, accept such customisations if it makes sense?!...

> At least, we need to think hard whether there are any other solutions before adding extra customizability. Well, the more generalised you want such system to have, the more...

> 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...

> The ability to switch between BRE/ERE/PCRE most definitely is, but I'm not making any promises I'd accept this even with it removed. I had already put it in a...

> It's not "really just a few lines" -- it's 25 lines of code, 3 configuration variables, 60 lines of related documentation. Well documentation barely counts as complexity... and if...

What you could perhaps do, beyond the general framework, was adding a `examples/` dir to the documentation, were things like the "actual" code, e.g. such a filtering function based on...

Just one more thing that comes to my mind. I remembered @akinomyoga’s idea about the opposite to my use-case (adding hostnames). It would would be nice if it was possible...

And if you reeeeaally want it generalised: Why not changing `_comp_return_hook` to `_comp_hook` and make even the point in which the hook is called a value? So `_known_hosts_real()` could get...

It just came to my mind, that if such framework would make the hook dependent on completed command for which it was invoked by a function (like `_known_hosts_real()`), as indicated...

Just noted one further thing, that would be specific to an example exclusion hook function when that is to be used with `scp` .. there it would need to exclude...