chore: Ignore compiled and autoloads Emacs-Lisp files

[kaushalmodi]

Hello,

I don't know if you would accept patches at GitHub PRs too. So I thought of trying that.

[I do have my copyrights assigned to FSF.]

[protesilaos]

Merged. Thank you!

[kaushalmodi]

Meta: I like to follow the Conventional Commits format when writing commit messages. Let me know if you don't prefer that.

Main advantage is that by glancing the first word, people have a quick idea about what this commit category is. And also, auto changelog generation becomes much easier.

[protesilaos]

I like it, though I have not used it before. Will give it a try.

[kaushalmodi]

I like it because I don't need to remember to write CHANGELOGs :)

• commits
• Tool used to convert git commits to CHANGELOG.org: https://github.com/orhun/git-cliff
• changelog converted to HTML

[protesilaos]

• commits

Looks nice and is informative.

• Tool used to convert git commits to CHANGELOG.org: https://github.com/orhun/git-cliff
• changelog converted to HTML

That makes things easier. Whereas my change logs are verbose.

My concerns are:

1. It links to commits on the forge's website, which makes it a bit more
   difficult to read.

2. How do you handle cases where you need to explain some change in
   further detail. Maybe the change spans multiple commits, or there is
   some discussion surrounding it which is not obvious in the underlying
   diff. Do you edit the generated CHANGELOG?

3. Do you enforce Conventional Commits on contributors?

[kaushalmodi]

It links to commits on the forge's website, which makes it a bit more difficult to read.

I see a forge as the most accessible way to view changelogs (for most users) as their primary way to access my project will be a forge and not through a local cloned git repo. The way I see it is that a user clicks on a Issue or PR hyperlinks and get further details about the commit from there.

How do you handle cases where you need to explain some change in further detail.

If it's a single commit with verbose details, the CHANGELOG links to that commit where the user can read the entire commit log. I truncate the commit log in the CHANGELOG for brevity (the truncation char count is derived empirically).

Maybe the change spans multiple commits, or there is some discussion surrounding it which is not obvious in the underlying diff.

In those case, I link the GitHub Issue or PR where the user can learn more details.

Do you edit the generated CHANGELOG?

No.

Do you enforce Conventional Commits on contributors?

I haven't had to face that problem as my project doesn't receive many PRs. But yes, if you expect a lot of external contributions, and also plan to do auto CHANGELOG generation, you'll need to document the commit writing rules and enforce them (kind of how the commit log style is enforced in Emacs).

The good thing is that I have seen quite a bit of awareness about Conventional Commits in many projects. So this concept might not be alien to many of the contributors.

[protesilaos]

I see. Thank you for the explanation!