doomemacs / doomemacs/snippets

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

Open
#56 1 comment 0 reactions 0 assignees View on GitHub
is:docs
Dominant language
YASnippet
Stars
313
Forks
98
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

No contributing guide indexed for this repository

Research direction

No specific files, tests, or entry points are named. Start by surveying existing snippet keys and contribution practices across the repository, then establish the scope and acceptance criteria for a convention or guide; done means an agreed standard is documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
emacs
Domain
developer-experience, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.