Skip to content
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

Open
ratijas opened this issue Jan 12, 2023 · 4 comments
Open

New contributions for KDE/Plasma software? #984

ratijas opened this issue Jan 12, 2023 · 4 comments

Comments

@ratijas
Copy link

ratijas commented Jan 12, 2023

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)

@Freed-Wu
Copy link
Contributor

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 😄

@msva
Copy link
Contributor

msva commented Jan 16, 2023

even though knowing that it was rejected upstream and has little chances of ever moving there

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

@Freed-Wu
Copy link
Contributor

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

@ratijas
Copy link
Author

ratijas commented Jan 21, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants