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

Isn't there a need for a "keyword list convention" or a contribution guide? #56

Open
Davoodeh opened this issue Nov 21, 2020 · 1 comment
Labels
is:docs Pertains to the project's manual, output of help commands, or API documentation
Milestone

Comments

@Davoodeh
Copy link
Contributor

Lately, I was browsing the repo to get a gist of naming conventions.

For example, what to name my class snippet? class? Perhaps cls?

With a quick search, I realized that there is no conventions here.
Every contributor gets to make their own snippets the way they want.

This happens while there are tons of similar structures in different languages like the very class I mentioned before.
Why not to name them all cls instead of having all cls, class, cl, etc?
Should we use _ or - in snippet keys?

The other issue was with naming conventions. Some named their snippets like: class ... { ... } and others just class and other notations.

I believe this repo (unlike other repos) needs a convention/robust contribution guide.
It may not seem like a big deal but it is.
As an Emacs newbie, I know it's a turn off that every language has it's own snippet style and every mode has it's own key bindings. When I use cls in VSC, in every language it's cls. I bother myself with remembering every snippet for every langauge.

For me, Doom stood out among other configs because it managed these issues to some extent, most of things "just work" convinently.
However, most is not enough. Starting from this repo I think it would be fantastic if there were more common ground between different modes, languages, binds and snippets.

I assume a refactor + a contribution guide can fix the issue before it's too big and there are too many snippets to edit.
Although, there is the issue that probably old users are used to the old snippets and a changes in them won't be pleasing to them.


Anyways, I thought I need to share my idea on this issue here in the issue tracker rather than discord or somewhere else so it will remain intact and prevent further questions once concluded.

Pardon me for my bad English and if I'm propusing this in a wrong place or my argument is invalid I couldn't find related arguments in closed issues.

@hlissner
Copy link
Member

It does need a contributors guide, but my todo pile is impressive enough as is. It'll be some time before I can get around to it.

I do intend to convert this repo over to org files that are tangled at compile time (and to allow users to define their snippets in org, if they choose). This would make them better organized, easier to optimize+byte-compile, and easier to document. That is my first priority.

@hlissner hlissner added the is:feature Adds or requests new features, or extends existing ones label Nov 21, 2020
@hlissner hlissner moved this to Unreviewed in Triage Apr 21, 2022
@hlissner hlissner added this to Triage Apr 21, 2022
@hlissner hlissner moved this from Unreviewed to Confirmed in Triage May 2, 2022
@hlissner hlissner added this to the Backlog milestone May 2, 2022
@hlissner hlissner added is:docs Pertains to the project's manual, output of help commands, or API documentation and removed is:feature Adds or requests new features, or extends existing ones labels May 2, 2022
@hlissner hlissner removed this from Triage Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
is:docs Pertains to the project's manual, output of help commands, or API documentation
Projects
None yet
Development

No branches or pull requests

2 participants