doomemacs
Isn't there a need for a "keyword list convention" or a contribution guide?
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.
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.
