| Age | Commit message (Collapse) | Author |
|---|
|
|
|
`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]...].
|
|
|
|
|
|
Until now we only highlighted trailers that end with "<mail>" to
avoid false-positives. Now we additionally look for the known
trailers listed in `git-commit-trailers', which doesn't increase
the risk by much.
|
|
|
|
This allows inserting trailers with values that don't involve an
email address.
Re #5031.
|
|
It is more convenient than the direct bindings in the minor-mode
keymap, because who can remember those?
|
|
Nothing about "pseudo header" is accurate, while "trailer" makes
perfect sense and happens to be the term Git uses.
|
|
It is suggested in several places on the internet to use a git
commit template, for instance here [1]. These often include a
header comment:
# Title: Summary, imperative, start upper case, don't end with a period
# No more than 50 chars. #### 50 chars is here: #
[1]: https://gist.github.com/lisawolderiksen/a7b99d94c92c6671181611be1641c733
This change ensures that headers are inserted after this leading
comment (meaning there are no empty lines before it), instead of
above it. Headers are still inserted before the comments added
by Git itself.
|
|
For older Emacs releases we depend on an updated `seq' release from
GNU ELPA, for `seq-keep'. Unfortunately something else may already
have required `seq', before `package' had a chance to put the more
recent version earlier on the `load-path', and thus the outdated
built-in version might be loaded. If that is the case, unload it
and require `seq' again, to load the new version.
If you are wondering whether it is worth the trouble, keep in mind
that going forward we might want to use other additions in the future.
Also I really want to use this function. I was the one who suggested
its addition because it was one of the few significant gaps in `seq'
and `cl-lib' in comparison to `dash'.
Closes #5011.
|
|
In [1: 84eaa203f3] we only did this for `magit' itself.
1: 2023-09-21 84eaa203f3c70d55f29fbe6a8d6d9d5334cb6818
Use seq-keep instead of delq and mapcar
This is not strictly necessary for `git-commit' because there we don't
*currently* use `seq-keep', but in the future we might very well start
using it there as well, without remembering that a dependency has to
be added. So let's just do it now.
|
|
Closes #5005.
|
|
Closes #4998.
|
|
|
|
|
|
Some major-modes used while editing commit messages, may set that
variable and other `comment-*' variables to values that are not
compatible with Git's understanding of comments, which always only
uses a comment character at the beginning, either the default "#" or
what is specified using `core.commentchar'. Git's understanding of
how comments are delimited takes precedence over the major-modes
style, because it is Git that strips the comments.
`markdown-mode', for example, sets `comment-start' to "<!--" and
`comment-end' to "-->"; and we failed to override the latter until
now.
Furthermore, `markdown-fill-paragraph' does not handle Git-style
comments, which is to be expected, but forces us neutralize it when
called on a comment. This is not necessary for any of the other
modes we suggest for `git-commit-major-mode'.
Closes #4990.
Replaces #4991.
|
|
Use `when' instead of (or rather in a addition to) `and', because the
value does not matter. These functions are called for side-effects.
|
|
The filename added to `auto-mode-alist' must be stripped of the remote
part, if any, because that is what `set-auto-mode--apply-alist') does
when it matches filenames.
Fixes #4987.
|
|
|
|
|
