-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New contributions for KDE/Plasma software? #984
Comments
I also have many hand-crafted completions but I think hand-crafted is not a good idea. Many languages has their own library to generate zsh completion script automatically: I think generate shell completion script is better. However, a not good solution is better than nothing 😄 |
Actually, this will improve chances for it to be accepted here, as "not being in upstream" is exactly the requirement for completions to be accepted here |
True. And if the upstream accepts them later, they will be deleted here like this. |
Hi, it's nice to know you, and thanks for your feedback! Sounds like it's pretty much settled then. I'll double-check on my side to make sure everyone is OK with this, before making final decision. |
Hi,
I'm an active KDE developer, and I recently wrote a lot of zsh completions for the commands I use often, and I hope more are to come. Those completions are as intelligent and integrated as my level of understanding compdef features allowed me to write.
However, at some point we had a disagreement between our visions on how to proceed forward. On one side, I firmly believe that hand-crafted completions are the best quality one can provide, and that worth the effort of some periodic maintenance to keep them in sync with apps. On the other side, the rest of the team is convinced that either parsing
--help
output is a good idea, or investing time in a sky-blue research will lead to some silver-bullet discovery that would allow generating both app's CLI logic code (C++, no less!) and completions for any shells in a generic way. Seems like diplomacy has failed, which leaves me with the only reasonable option: submit my work elsewhere, so it won't rot in my personal dotfiles repo.Question: will this project accept my work (under GPL-2.0-or-later terms), even though knowing that it was rejected upstream and has little chances of ever moving there?
-- ivan (@ratijas)
The text was updated successfully, but these errors were encountered: