| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Re #2949.
|
|
This fixes a regression introduced by commit
084182e8e7dc82550543a4933c082a2a188d7faf.
According to the docstring (and the code) of 'normal-mode', when it is
called without argument, 'enable-local-variables' is ignored, so if
there are unsafe local variables, a user will be prompted about them
every time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Third-party hooks should not be defined as options, at least not when
they have a non-nil value, because otherwise an early `add-hook' would
not add to the hook but initialize it to just the added function. But
users expect to be able to customize hooks, so we do it anyway.
Previously each `defcustom' form that defines a hook was preceded by a
form which made sure that the default functions got added to the hook
even when users added their own functions earlier. Unfortunately, and
surprisingly long undiscovered, that had the side-effect of overriding
any customization made using the Custom interface.
Now we use an approach that works in both cases, obviously.
Fixes #2902.
|
|
JќL is the name I have given to my (for now) personal key bindings,
which replace "bpnf" with "jikl" for navigation (similar to how vi
uses "hjkl", but non-modal). Maintaining such changed key bindings
across all the packages I use has proven to be challenging to say the
least. Recently I have decided to try a new approach - just patch the
packages that I use. That might seem like bad idea, and maybe it is,
but all the others didn't really scale either. (And considering that
I have written a package manager, Epkg, that is supposed to help with
exactly this sort of thing, I ought to try that approach.)
However for Magit patching is not feasible, because I work on that all
the time, and sometimes when I work on a feature branch I do have to
restart Emacs. I need my key bindings even when I am on a feature
branch and not by own personal key bindings branch.
Sometimes I add some optional functionality to Magit for the benefit
of a very small number of users, sometimes consisting of a single
user, who manages to convince me how very important a change is, even
though nobody else seems to have the same need. Well, this time that
user is me.
|
|
Some of the rearrangement is a bit strange. These changes prepare
for those that come in the next commit. Look at that if you want
to know why some binding definitions have moved to the beginnings
of their respective definition blocks.
|
|
|
|
|
|
|
|
|
|
We used to set the buffer-local value of `fill-column' in commit
message buffers to the value of option `git-commit-fill-column',
which overrides settings in ".dir-locals.el" and is surprising.
Change `git-commit-turn-on-auto-fill' to only do so if `fill-column'
does not already have a buffer-local value and if our option's value
actually is an integer. Also change the options default value to be
nil. The default value of `fill-column' is 70 and that of our option
used to be 72.
|
|
This ensures file and directory local variables are setup in the
standard way.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
