Closed 3v1n0 closed 4 years ago
Thanks for the info, I'll keep it in mind.
80ms is over 10x higher than what I could include by default but it should be easy for z4h users to load your plugin if they want to.
80ms is over 10x higher than what I could include by default but it should be easy for z4h users to load your plugin if they want to.
Ok, fair enough, although the loading time is actually a lot smaller, I probably I computed it wrongly before:
time (source zsh-bash-completions-fallback/zsh-bash-completions-fallback.plugin.zsh)
0,14s user 0,03s system 99% cpu 0,168 tota
And stays the same repeating the value, but this is when I've almost 900 bash completions locally.
And similar is when running it in the zsh4humans docker image:
However, given that these completions include many commands that are not available until installed, I've changed it not to load what is not available on startup and this leads to basically unnoticeable time:
While in a system with many more programs may lead to something like 8-9ms when adding something like 300 completions.
All these without zcompiling
the file.
@romkatv FYI I've added further updates to make the plugin to use lazy-loading all the times, and now the loading time is always unnoticeable, so I hope you could reconsider this decision.
❯ time (source zsh-bash-completions-fallback/zsh-bash-completions-fallback.plugin.zsh)
( source ; ) 0,00s user 0,01s system 93% cpu 0,013 total
13ms is still too much but maybe this is an artifact of measurement.
What are the drawbacks of using your plugin? Can you describe when using your plugin would result in user experience that's worse than not using it?
13ms is still too much but maybe this is an artifact of measurement.
Well as per my configuration using zpmod source-study
, it's never taking more than 3ms.
But in fact as per the recent refactor, and lazy loading is just no overhead:
What are the drawbacks of using your plugin? Can you describe when using your plugin would result in user experience that's worse than not using it?
Well, in a standard unix system, bash provides nowadays more than 900 completions, now, when loading them all in z4h will introduce support for 580+ new completions.
So, this would add support for and tools like snap
, flatpak
other than popular tools as aws
, without much effort or the need to port them.
Given that z4h is a perfect tool for people who are new to zsh (and normally coming from bash), I imagine it's a quick way to make these users feel at home quite easily.
Thanks for the improvements.
What are the drawbacks of using your plugin? Can you describe when using your plugin would result in user experience that's worse than not using it?
Could you answer this?
Just to save me and you some time. I took a look at the source code of https://github.com/3v1n0/zsh-bash-completions-fallback and it doesn't appear it's at the point where I can enable it by default in zsh4humans. Some issues can likely be fixed (see below), others require intelligent fallbacks.
I haven't tried it but it seems like this would fail:
git clon -
, position the cursor after clon
and trigger bash completion. It won't complete.git "$(echo haxor >&2)" /
and trigger bash completion. You'll see "haxor" printed out.zsh-bash-completions-fallback can be manually enabled by zsh4humans if they so desire. If or when it acquires a larger user base and matures, I'll consider enabling it by default. Not yet though.
What are the drawbacks of using your plugin? Can you describe when using your plugin would result in user experience that's worse than not using it? Could you answer this?
Well, I can't imagine something like that honestly, the only thing, when using the lazy loading, could be that the first time you hit the TAB key it may lead to some slowdown (but really, always something under 10-15ms) to load the completions, but other than that, I can't see anything different from normal behavior if not better when a completion is available.
Type git clon -, position the cursor after clon and trigger bash completion. It won't complete.
By default git completion isn't provided if there's a zsh completion available, however, in case it's enabled, however sure, the issues you've mentioned are present as it's not always possible to simulate what a real interactive bash expects. However I have some ideas about those, so maybe I can reiterate.
My whole point however, is better a not-perfect (but reliable) completion than no completion, no?
By default git completion isn't provided if there's a zsh completion available
I realize that. I used it as an example. It's not important that the command is git
.
My whole point however, is better a not-perfect (but reliable) completion than no completion, no?
I think the default completion (that essentially just completes files) is better than incorrect completion.
I realize that. I used it as an example. It's not important that the command is git.
@romkatv sure, I see the point, and now both the issues are fixed. So the completions are per the actual word under cursor, it was in my TODO already but as it started as a draft, I didn't had time to finish it.
Great! Thanks for the speedy fixes.
My point still stands. Get more people to use your plugin. Once others start using your code, you get invaluable feedback and bug reports that allows you to iron out bugs and improve usability.
I've been trying z4h and I quite loved it, maybe given the purpose of it it may also include support for bash completions as fallback, I've written a small plugin that handles it, which you may be interested in including by default, as it will only provide quite a lot more completions without much initialization time (just sourcing it takes something like ~10ms).