| Age | Commit message (Collapse) | Author |
|---|
|
These complains about style issues in turn cause some users to complain.
I didn't change anything until now because I thought that users would
either appreciate the warnings or at least not mind them much, or else
they would just turn them off and be done with it. But some complaining
seems to be necessary before or instead of just disabling the undesired
style check features.
Increase `git-commit-summary-max-length' from 50 to 68. The old value
was chosen a long time ago by someone other than me after having read a
blog post that made the case for that limit. I completely agree, that
this limit is far to restrictive. Locally I set it to 64 a long time
ago and I regularly go over that limit by a few characters.
Add a new option `git-commit-style-convention-checks' to allow choosing
which violations cause `git-commit-check-style-conventions' to complain.
This adds a bit of indirection. We could just have split that function
into two, but that would inconvenient those users who have already
removed it from `git-commit-finish-query-functions' and would then have
to remove the two functions (actually just one) again to accomplish the
same.
By default `git-commit-check-style-conventions continues to complain
about `non-empty-second-line'. But it no longer complains about
`overlong-summary-line', because it's perfectly okay to occasionally go
over the limit by a few characters and the highlighting still makes the
user aware of that.
|
|
|
|
|
|
Add a function to font-lock-extend-region-functions to correctly
identity the multiline git-commit-summary-regexp to font-lock, as
suggested in `(elisp) Multiline Font Lock'. This causes the
git-commit-nonempty-second-line face to be applied immediately, instead
of having to run font-lock-fontify-block manually to trigger it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
36be43d (use font-lock-flush instead of font-lock-ensure, 2015-08-15)
changed this to use font-lock-flush. However, based on tests with a
somewhat recent build of the emacs-25 branch (cf79616) and on this
discussion [1], I don't think font-lock-flush will reliably highlight
the diff. Also, the initial issue that 36be43d was addressing is, I
think, due to a bug in Emacs's font-lock-ensure (bug#22399) that has now
been fixed (21beb19, 2016-01-25).
[1]: https://lists.gnu.org/archive/html/emacs-devel/2016-02/msg01481.html
|
|
* Start diff highlighting at beginning of diff line rather than after
"diff --git".
* Highlight last change.
Fixes #2616.
|
|
Fixes #2612.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replace the old magit-specific auto-revert implementation with the
mode `magit-auto-revert-mode', a globalized variant of the built-in
`auto-revert-mode'. By default Magit still explicitly triggers the
reverts after running git for side-effects. Automatic reverts are
still enabled by default, and Magit is less verbose about it. The
behavior can be tuned using `magit-auto-revert-' and `auto-revert-'
options.
The main benefit of this change is that this implementation caches
whether a file is tracked or not. The old implementation determined
this on every revert cycle, which did not perform well when there
were many open buffers and/or many tracked files.
|
|
|
|
|
|
|
|
|
|
|
|
Most importantly depend on a snapshot of `dash', because *any* snapshot
is larger than 2.MM.S but we really do need v2.8 at the very least (for
`-let'). Actually depend on a snapshot corresponding to v2.12.1 because
that fixes magnars/dash.el#130.
|
|
|
|
Rely on the output from mount to tell us how to map cygwin paths into
native Windows paths.
This is also needed in git-commit; avoid a hard dependency on magit by
only loading magit-git in the case where we receive a bad path to
foo_EDITMSG (and falling back to the standard "/cygdrive" prefix if we
fail to load).
|
|
Cygwin git passes paths like /cygdrive/c/foo/.git/COMMIT_EDITMSG which
causes windows-nt Emacs to look for the non-existent
c:/cygdrive/c/foo/.git/COMMIT_EDITMSG. We now attempt to switch to
c:/foo/.git/COMMIT_EDITMSG in thise case.
Re https://github.com/magit/magit/issues/2284#issuecomment-143927798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The previous implementation sometimes did not succeed in keeping
flyspell from checking certain parts of the instructions comment.
|
|
The latter does not actually refresh the buffer.
|
|
When `package.el' is used to update a package whose libraries have
already been loaded in the current session, then parts of the loaded
version can leak into the new version during byte-compilation.
This can be avoided by compiling the libraries in a separate Emacs
instance. The library `async-bytecomp', which is part of the package
`async', does just that by advising the function `package--compile'.
So add `async' as an Elpa dependency, soft-require `async-bytecomp', and
if that succeeds, then turn on `async-bytecomp-package-mode' to activate
the advice. Because it is undefined which package is updated first, and
which library is loaded first, we have to this in both possible
candidates `with-editor' and `magit-popup'.
Users may update `magit' without updating the dependencies, so we have
to further force the updates of all the Elpa packages that are build
from the Melpa repository. To do so we depend on "20150808" snapshot
versions instead of "2.2.0".
When installing Magit manually, then `async-bytecomp' is not required,
because Magit is then compiled using the Makefile which already uses a
separate, untainted Emacs instance.
|
|
|
|
Users are allowed to use `add-hook' et al. to add hook functions to hook
variables which have not yet been declared. That means that the default
value of hook variables should not be set inside `defvar' and defcustom'
forms, because those definitions are only evaluated if the variable has
no value yet (in case of `defcustom' it would be used to get the default
value though). When the user used `add-hook' earlier, then it obviously
has a value. So we are supposed to set the default value outside of the
declaration form, using `add-hook'. But that has a few downsides too.
If we set the default value outside of `defcustom', then Custom would
think that the default value is `nil' (and would be right about that)
and tell the user about it, which could confuse her a lot.
So we set the default value inside `defcustom' *and* outside using
`add-hook'. Sight. That's still not good enough though. Re-evaluating
the file or buffer containing these `add-hook' forms would override all
user customization.
So we place the calls to `add-hook' before that to `defcustom' and
additionally wrap the calls to `add-hook' to make sure they are only
ever run once. Sight.
(unless (find-lisp-object-file-name 'HOOK-VARIABLE 'defvar) ...)
(add-hook 'HOOK-VARIABLE ...) ...)
(defcustom HOOK-VARIABLE '(...)
:options '(...)
...)
Double sight.
We *don't* do the above for section hooks, which users are supposed to
modify using `magit-add-section-hook'. Instead we teach that function
to raise an error when the user attempts to add a hook function to a
hook variable which has not been defined yet.
Re #2004.
|
|
It's available starting with Emacs v25.1.
|
|
Starting with Emacs v25.1 `looking-back' requires two arguments.
But the second argument LIMIT may still be nil.
|
