| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
For now only `turn-on-flyspell' is obsolete in Emacs 31.1.
Get it over with and stop using `turn-on-auto-fill' as well.
|
|
Suggested-by: Stefan Kangas <stefankangas@gmail.com>
|
|
|
|
The `git-commit--trailer-regexp' regex is written so that either groups
1 and 2 will match or groups 3 and 4 will match, but it is impossible
for all 4 groups to match.
This patch updates the font-lock regex checker to be lax about whether
or not the group matched. Without this patch we have errors like:
Error during redisplay: (jit-lock-function 77) signaled
(error "No match 3 in highlight (3 'git-commit-trailer-token)")
Signed-off-by: Curt Brune <curt@brune.net>
Make-it-so: Jonas Bernoulli <jonas@bernoul.li>
|
|
The sequel. Part 1 was [1: 7f47299581].
1: 2025-01-05 7f47299581abb6f77870cb5abdae159fcd35b3d5
Let the byte-compiler check more function references
|
|
There is a circular dependency between `magit-git' and `magit-process',
which we break by declaring some functions from the latter in the
former. This usually works out fine because loading `magit' loads both
libraries.
However, when someone only loads `git-commit', then this broke and to
fix it we have to explicitly require `magit-process' in that library
as well.
Also explicitly require `magit-git', even though that isn't strictly
necessary because `magit-mode' requires `magit-git'. Finally also
update the dependency declaration in "lisp/Makefile".
Closes #5280.
|
|
We already did that, just not consistently.
|
|
|
|
This version was released more than four years ago and Emacs 30.1 is
around the corner. This is the release available on Debian Bullseye
(oldstable).
|
|
|
|
|
|
Now that "git-commit.el" is part of the `magit' package, we can add
all the bindings up front. But we cannot #'quote. Well, we could,
but then we would also have to `declare-function' and wouldn't that
just be silly?
|
|
|
|
|
|
|
|
|
|
`font-lock-ensure' exists since Emacs 25.1.
|
|
|
|
|
|
|
|
The coloring of the overflowing characters makes sure we notice that
we have gone over the limit, and should be enough to make us consider
other options. If we decide to go ahead and violate the limit anyway,
we should not have to manually revert the effect of the auto-filling.
|
|
Or one typo, which ended up being copy-pasted.
|
|
|
|
This restores the useful part of the functionality removed in
[1: 150eed71b9], while making it possible to disable even that,
in case there is disagreement on its usefulness (and to move it
out of sight and to have an obvious place to document it).
1: 2024-04-29 150eed71b98597018cc4a47d1c50c3f56b747eef
git-commit-setup: Remove a mildly questionable tweak
|
|
|
|
|
|
This reverts commit 463a3550e27ab1cb0dc53afb0199f2e50660f24c.
We can use `format-prompt' now because it is provided by the `compat'
package.
|
|
The removed code was added in [1: fb66888fcd]. If the buffer is
completely empty, this changes it to instead contain a single empty
line. This does not seem desirable, without further justification.
Unfortunately that was not provided in the commit and the mentioned
issue is from the old "git-commit-mode" repository, which does not
exist anymore.
I assume that this was either done because some user enabled
`indicate-buffer-boundaries' and then didn't like how that looks for
empty buffers, or because this once was necessary for our font-lock to
work properly. If it was the latter, that is not the case anymore.
This does not affect the outcome of Git porcelain commands. (And if
it did there would be nothing to prevent the user from removing the
trailing newline again.) It is Github, which produces corrupted commit
messages that lack the trailing newline by default, not Git.
I am removing this because it makes an already long function even longer
and it is yet another thing one has to consider when reasoning about
this function. If someone really wants this for some reason, then a
hook function can be used. If it turns out there is some real benefit
to this, then we can revert the removal.
1: 2013-09-14 fb66888fcdeb334f183e67d26b58a98c6ad2124c
`git-commit-mode': insert a newline after commit summary line
|
|
It makes sense for the usage message to be handled last and for the
header-line setup (which also provides usage information), to be placed
next to that (but not after that, as was the case before).
Doing these thing *after* running the hook (as we already did) makes
sense, since that makes it possible to use the hook to tweak the
information.
|
|
`git-commit-mode' is a minor-mode, as opposed to being the major-mode
used in commit message buffers (as its name may suggest, and many users
seem to assume).
We therefore decided a long time ago that `git-commit-hook-mode' should
not be used and provided `git-commit-setup-hook' as an alternative.
Despite that, users keep trying to use it anyway, and often that leads
to issues. It doesn't help that this hook has a generic generated
docstring, which does nothing to discourage its use.
Instead of continuing to tell users not to use this hook, one by one, or
taking more drastic measures to prevent its use, just make it an alias
for `git-commit-setup-hook'. (It is also too late to instead remove
*that* hook.)
Prevent `git-commit-mode-hook' from being run when `git-commit-mode' is
enabled. It is now run a bit later under the `git-commit-setup-hook'
name, while also demoting errors. Demoting errors is important, because
errors that occur here, are (1) hard to debug (because there is no
backtrace), (2) common (due to user errors), and (3) they outright
prevent committing.
It also makes a difference that the hook is run slightly later now.
Some things that would fail at the earlier time, actually work at the
later time. For example, functions that rely on font-lock being setup
(which is reasonable to do if you wrongly assume that `git-commit-mode'
is a major-mode), as many seem to do, only works at the later time.
Also move the call to `git-commit-mode' itself further down.
In summary, it seems safest *and* most convenient, to just let users
add to the same hook under two different names, and to run it at the
appropriate time, while demoting errors.
|
|
|
|
Closes #4973.
|
|
At this point this makes no difference, but it makes the diff for
the next commit more readable.
|
|
|
|
|
|
When `commit.verbose' is set to true in git's configuration, a special
line will be added to the (temporary) commit message. All content below
this will be ignored by git when constructing the eventual commit
message. This is defined as `cut_line' in wt-status.c in git's source:
https://github.com/git/git/blob/3e0d3cd5c7def4808247caf168e17f2bbf47892b/wt-status.c#L38-L39
I noticed that, for exceptionally large commits, magit was triggering
a commensurately large flyspell operation. This appears to be a small
oversight in the logic of `git-commit-turn-on-flyspell'.
This commit attempts fix the performance issue by instructing flyspell
to ignore all lines after `cut_line'.
|
|
Unlike face and function aliases, variable aliases should be declared
before the actual definition.
|
|
|
|
|
|
|
|
That was the intention in [1: 546071e888].
Closes #5038.
1: 2023-10-27 546071e888db4e4fd2baff116438e8d57b6f127b
git-commit-mode-map: Factor out redundant bindings
|
|
|
|
|
|
|
|
|
|
I.e., consistently use the [NAME CALLBACK ENABLE] form, instead
of randomly mixing that with [NAME CALLBACK [KEYWORD ARG]...].
|
