- Simplify doom-info and doom/info.
- Remove doom/copy-buffer-contents (may be moved later, but atm not very
useful).
- Remove doom/am-i-secure (this will later be replaced with CLI
commands)
Reduce cases where native-comp procedures were executed in
non-native-comp contexts (somehow).
Also:
- Adds a NATIVECOMP constant for statically detecting the feature.
- Remove native-comp-* -> comp-* aliases (Emacs HEAD has long since
moved on from these).
- Add 'no-native-compile: t' to autoloads file.
The message simply test for the "not-a-version-yet" patch number and
displays an explanation to prepare users for raised error frequency and
having a backup version of Emacs if they do not want to deal with
issues.
This generalizes and cleans up the linter API so that it can be used in
other Doom projects (or CLI commands, like our WIP changelog generator).
Besides that, our git's commit conventions saw two changes:
- A new 'Amend' keyword, for indicating a commit corrects an earlier,
recent one. This should be used to omit (or merge) commits in the eyes
of the changelog generator.
- Trailers must now follow the 'KEY: VALUE' format, which is supported
OOTB by 'git interpret-trailers' and makes scraping them much eacher.
Before, omitting the colon was mandatory, this is no longer the case.
Other highlights:
- For linter rules: replaced :footer and :refs keys with :trailers (a
string->string alist). Invalid trailers will be left in BODY's tail.
- Added a linter for colon delimiters in commit trailers (along with
other formatting checks, like capitalization and one-per-line checks).
There weren't enough checks that we were truly in a native-comp build of
Emacs. Not the most elegant solution, but the CLI rewrite handles this
far better so it'll do for now.
Fix#5131
- Now counts and reports all commit references that aren't the correct
length, not just the first.
- Now reports all incorrect references, not just the first on each line.
- Linter wasn't failing on any invalid scopes due to logic error.
- Linter was failing to recognize module categories as valid
scopes (e.g. :lang, :ui, etc).
- Adds 'ci' and 'lib' as valid scopes.
This is more predictable, and is safe as a global default in CLI
sessions (but not in interactive ones). This indirectly fixes case
insensitivity in our commit linter rules.
- Conform commit linter to 50/72 rule
- Add linter rule for body line length; excludes the footer and lines
with long URLs.
- Add linter rule for validating scopes are in lexical order.
- Add linter rule for validating footer refs.
Footer references should reference one thing per line. That thing can
be one of:
- An URL.
- An issue or PR reference (local or remote).
- A 12-character commit hash (local or remote).
- Extend linter to detect new scopes for docs:
- Commits of type 'docs' can now use these additional scopes (in
addition to other possible scopes):
- docs(install) -> for changes to our installation guide(s). It is
expected for this to change so often that it has its own scope.
- docs(X) -> where X is the basename of any org file in docs/*.org.
e.g.
- docs(index): ...
- docs(modules): ...
- docs(faq): ...
- Modify the scope checker to consider *any* parenthetical scope given
for bump, revert, merge, module, or release commits to be invalid.
- Update bump commit linter for 12c hashes (see 3bedae38dd).
- Fix language in imperative ref linter warning.
Ref https://discourse.doomemacs.org/how2commit
Ref 3bedae38dd
- Was formerly processing the internal merge commit, which never conforms
to our conventions, but is also unrelated to the work at hand.
- Now lints the range of commits applicable to the event, and not just
the latest commit.
- Fix rules that weren't working due to faulty logic.
- Revise linter messages for clarity and concision.
- Use conventional commit nomenclature: summary -> subject
- case-fold-search = nil, to ensure case sensitive searches
- Exclude bump type from length checks
Recently added 'module' to our list of git commit types to represent
changes to our module list. These events are important enough to
Doom (and users) to track separately.
Experimenting with an internal linter. Only trouble is, if Doom's CLI is
ever in a broken state, a contributor will have to know about
--no-verify option for git commit. This can be improved post CLI
rewrite.
