- 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.
- Remove remaining `EMACS27+` checks, since the whole codebase is
assumed to run at version 27 or above now
- Remove `EMACS27+` definition since it's no longer needed
Emacs 27.x has been the stable version of Emacs for nearly a year, and
introduces a litany of bugfixes, performance, and quality-of-life
improvements that significantly reduce Doom's maintenance burden (like
XDG support, early-init.el, image manipulation without imagemagick, a
native JSON library, harfbuzz support, pdumper, and others).
With so many big changes on Doom's horizon, I like having one less (big)
thing to worry about.
Also reverts bb677cf7a (#5232) as it is no longer needed.
the commit counting introduced in a3df5bf prints `nil` instead of the
empty string when the repo moves from commit A to commit B where A isn't
reachable from B
There are legitimate reasons why a user would want to treat $HOME as a
project. 'doom doctor' now complains about this case in greater detail.
I'll leave it to users to deal with this edge case.
Reduces the amount of "noise" included in bin/doom's output.
Also fixes an issue where warnings during autoloads generation would
sneak into Doom's autoloads file, producing weird void-variable errors,
like
(void-variable . rainbow-delimiters:)
(void-variable . diredfl:)
(void-variable . company:)
With a commit of e2a11d24fd, when it comes to
`doom compile`, modules aren't loaded anymore, which corrupts the compiling process.
What I did is just adding the necessity parts for the doom's byte compiler.
By deleting straight, the latest pinned version will be reinstalled on
the second part of the 'doom upgrade' process.
This is a clumsy fix for a catch 22 where using straight to update
straight would break due to backwards incompatibilities (see #4950).
This will do while we wait for the CLI rewrite.
More in line with Emacs' built-in practice of storing a variable's
standard-value in a symbol property of the same name, with the added
benefit of less global state.
