Documentation, contribution and code style guidelines

[AndersonTorres]

We need some form of code style and contribution guidelines in general.

Edit 2022-11-07:

Some useful links

https://github.com/alphapapa/emacs-package-dev-handbook

https://github.com/bbatsov/emacs-lisp-style-guide

https://gnu.org/software/emacs/manual/html_node/elisp/Tips.html

Another good thing to do is study and reuse the code of GNU APL Mode

Edit 2022-11-20:

Take notes on guidelines for MELPA compliance

Edit 2023-02-14

I am interested in using conventional commits, but with my own twist: I don't like abbreviations as "feat", "chore" etc.

https://www.conventionalcommits.org/en/v1.0.0/

[ilohmar]

This issue seems to be focused on formal processes and "best practices". I have a more general question regarding the development of this package: It seems to me to break a lot of emacs conventions, some minor issues, some with broader consequences. This is very common in language-mode packages, because the authors are often experts with a lot of experience in environments that are quite different from Emacs.

My natural reaction is to go ahead and just change a lot of stuff, but that precludes any possibility of merging things later.

Is there interest to bring this package more in line with Emacs conventions (including, but not limited to, drastically reducing the number of files, not changing global Emacs settings, using more standard facilities for keymaps, dropping "-face" suffixes etc)?

The reason why I am asking is that

1. directly preparing such intrusive changes as PRs is tedious, and it can easily appear hostile to the people who put work and effort into the package, which is useful as it is.

2. I have absolutely no problem maintaining my own mode, but I do not want to be irreverent to the existing one.

Any hints are appreciated!

EDIT: After browsing the commit history some more, I realize that many of the things I would try to change were deliberate decisions. I surely do not want to interfere with that, so (barring other developments) I will simply maintain a separate mode.

[AndersonTorres]

Disclaimer: I am far from being an Emacs expert.

Is there interest to bring this package more in line with Emacs conventions (including, but not limited to, drastically reducing the number of files, not changing global Emacs settings, using more standard facilities for keymaps, dropping "-face" suffixes etc)?

Yes it is. The more it integrates with Emacs, the better.

The reason why I am asking is that directly preparing such intrusive changes as PRs is tedious, and it can easily appear hostile to the people who put work and effort into the package, which is useful as it is.

In the worst case I can just do a huge revert :) Bring your ideas on.

I have absolutely no problem maintaining my own mode, but I do not want to be irreverent to the existing one.

I am interested in not to split the community. If there is a competition between bqn-modes, it becames harder to justify one mode above the other, and I would just close the repo and contribute with the newer one.

EDIT: After browsing the commit history some more, I realize that many of the things I would try to change were deliberate decisions.

More or less. Many of them made sense on that time, however there are other than I would easily regret.

[ilohmar]

Ok great, then I'll start with the most intrusive one. I will create a PR merging most files later today.