| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Emacs 31.1 adds variable `lisp-indent-local-overrides'.
|
|
|
|
|
|
|
|
|
|
I've only recently implemented these forms, but before that I have
been hoping they would be added to Emacs for a decade or so. Even
so, I do not yet have any practice using them, and so my sense of
when to use them, and when not, has yet to evolve.
|
|
Using the "other elements of VARLIST have access to SYMBOLs from
earlier elements" variant is IMHO _wrong_ when there are in fact
no other elements.
|
|
Cond-Let's `if-let', `if-let*', `when-let', `when-let*' and `and-let*'
implementations behave differently from the built-in implementations,
but because I have been careful not to depend on the idiosyncrasies,
switching over should be mostly safe.
Also add shorthands for the other `cond-let--...' macros. We will
start using those (and `cond-let' and `cond-let*') in later commits.
|
|
|
|
Almost always would it be better to use `match-string-no-properties'
instead of `match-string', but because the name of the former is
excruciatingly long for a function that one often wants to use in
tight spaces and because it usually "does not really matter", I
usually went for the latter.
The problem is, it does matter. For example, even strings that are
usually only used by code may end up obfuscating debug statements.
So let's start doing the right thing, even though there surely will
be people frowning at the use of a shorthand.
The fake ("match-string" "match-string") shorthand is necessary to
protect literal `match-string' and `match-string-no-properties' from
being corrupted by interpreted as shorthand for the non-existent
`match-stringing' and `match-string-no-propertiesing'.
Unfortunately the shorthands have to be specified in each library
individually. Using "dir-locals.el" only works if the libraries
are compiled. At least this additional noise is neatly tucked away
at the end of the files.
It might turn out that out of the more than two hundred instances
where this replaces `match-string' with `match-string-no-properties'
we should have stuck with the former in an instance or two. That's
the price of progress and can be fixed once such regressions are
reported.
|
|
Use this face for branch names in "# Branch" and "merge" lines, but
do not use it in "label" lines. The former two mark the points were
a branch is created and merged, while the latter is an implementation,
needed for technical reasons.
Relocate the keyword for "# Branch", so that it is placed among the
action line keywords instead of after the keywords for the comments
that optionally follow the action lines.
|
|
In "merge" lines the description was always prefixed with "# ".
Since Git v2.50.0 that is also done for other action lines.
To support older releases, "# " has to be optional for these other
action lines. While that isn't necessary, make it optional for
"merge" lines as well.
Note that Git always uses "#"; `core.commentChar' does not control
the character used here.
Never-the-less start using `font-lock-comment-face' for this inline
"#"; frankly it is unnecessary noise that is best diminished.
|
|
|
|
Tweak the merge regexp in `git-rebase-line-regexps' so that it can be
used for merge lines with and without a description.
|
|
|
|
|
|
|
|
|
|
Closes #5388.
|
|
Previously, if `git-rebase-show-instructions' was non-nil, it was
possible that a line containing usage information was mistaken for
a rebase action.
Alternatively we could use `with-editor-pre-finish-hook' to flush the
usage information after the user has seen them, just like we flush them
earlier in `git-rebase-mode', iff `git-rebase-show-instructions' is nil.
|
|
|
|
Closes #4690.
|
|
|
|
Now that this isn't used for the selection anymore, just section
highlighting, rename it accordingly. Do not use "region" in the
name to avoid confusing it with `magit-section--highlight-region'
which highlights *the* region.
Make FACE optional and default to `magit-section-highlight'.
|
|
|
|
|
|
|
|
|
|
In regular expressions, duplicated the exclamation mark for increased
grepability.
|
|
It would have been better to define them in "magit-base.el",
but then we couldn't use them in "magit-section.el".
|
|
|
|
|
|
These modes are enabled automatically and never have to be enabled
manually.
|
|
|
|
|
|
|
|
|
|
I haven't done a full 180 on anaphoric conditionals; if a builtin
equivalent existed, I would use that in some instances.
However, having looked at all the existing uses of `if-let', it
turns out there are way fewer such cases than I had anticipated.
|
|
In a few cases use `when-let*' or `and-let*' instead.
I haven't done a full 180 on anaphoric conditionals; if a builtin
equivalent existed, I would use that in some instances.
However, having looked at all the existing uses of `when-let', it
turns out there are way fewer such cases than I had anticipated.
|
|
We already do this in Transient's documentation because that's what
is being done in Emacs' documentation and Transient is part of Emacs.
Let's be consistent even at the cost of making the English unhappy.
Also add a comma before "e.g." and "i.e.", if not inside parentheses,
which is the correct thing to do, regardless which style guide one
chooses to follow.
|
|
Five years ago in [1: 5f407a29ac] we took the first step toward this.
1: 2018-10-15 5f407a29ac63b338c3c75e30b4633b44d5745036
magit-gitdir: New function
Previously we cached the wrong thing. `expand-file-name' is cheap but
"git rev-parse --git-dir" is not. Because `magit-git-dir' is where we
cached, rev-parse was still needlessly called multiple times with the
same arguments during a refresh. The effect should be most noticeable
during a rebase.
|
|
|
|
|
|
This action is new in Git 2.38.
Closes #4776.
|
|
This is a regression from 5ddf251 which addressed a font lock change in
Emacs 28.1. That commit routed `git-rebase-command-descriptions' through
`substitute-command-keys' to propertize them but commands (and therefore
the keys) in `git-rebase-*' were then rendered, for example, as \'c'.
This patch routes all the mapped commands through
`substitute-command-keys' so that users have a consistent rendering:
either all of the keys are not font locked (Emacs 27) or they are font
locked (Emacs 28 and beyond).
|
|
|
|
|
|
|
|
|
