| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`magit-section-goto-successor' no longer runs
`magit-section-movement-hook', so we don't have to suppress it in
`magit--refresh-buffer-set-positions'. Since that hook was why we
wanted to handle the selected window last, when it displayed the
buffer being refreshed, we can also stop changing the order of the
windows returned by ``magit--refresh-buffer-get-positions'.
|
|
|
|
|
|
|
|
|
|
|
|
This variable is also reset in `magit-section-pre-command-hook' but that
only affects the current buffer. We also have to reset this cache when
refreshing a buffer, otherwise it would continue to track sections from
the previous generation, which no longer exist.
For example, if point is on an unstage hunk in the status and the user
invokes a commit command, then the commit message buffer is current when
the commit is finalized. In that case `magit-section-update-paint' was
called for two section in the status buffer; the previous generation
hunk (which ended up being a noop) and the actually focused hunk (which
was not included in the value returned by `magit-focused-sections',
because that cache had not been invalidated yet, and thus got painted
as unfocused).
|
|
There appears to be a change in Emacs 31 compared to 28.2, which makes
this unnecessary, but on the older release we otherwise get an error
about the `##' forms being invalid functions. Even for newer releases
it's better to use code instead of data.
Closes #5399.
|
|
|
|
|
|
Inform the user that the process buffer contains the full error
(and other output), regardless of whether `message' or `signal'
is used to show a short error message in the echo area.
Closes #5396.
|
|
|
|
|
|
|
|
We don't know since when "--grep" and "--graph" are no longer
mutually exclusive, but it is since before Git v2.25.0, which
is the minimal version required by Magit.
Closes #5391.
|
|
Closes #5394.
|
|
When we navigate to a collapsed hunk, whose body is secretly already
highlighted and expand it, we can (and already do) avoid painting it
again. However, we failed to register it as painted again, which is
necessary to cause it to be unhighlighted once we move away from it,
regardless of how far back the painting as highlighted occurred.
We do not just leave the section registered as painted, after collapsing
it and then moving away, because `magit-section-update-highlight' would
then have to consider its state after every command.
Closes #5393.
Suggested-by: Eliza Velasquez
|
|
Since v4.3.7 the overlays used for section highlighting and section
selection conflicted, if both of these faces relied on the same face
property (likely the foreground color). The usual way to theme these
faces is to use the background for highlighting and the foreground for
the selection.
Closes #5389.
|
|
Closes #5388.
|
|
This makes it possible to use Magit's bookmark support in Forge.
|
|
|
|
Applying the region used to fail, even if the changes withing would
apply but some other part of the hunk, outside the region, conflicts
with the target.
|
|
The old variant broke with [1: 95ee9d8c51], which cannot be fixed simply
be reverting that commit, because it was in preparation of subsequent
changes, which heavily refactored section highlighting making it both
simpler and more generic, and also to improve performance. Delayed hunk
refinement conflicts with the former, and due to the latter it might not
be necessary anymore.
This commit does not fully restore the old behavior. Previously
delayed refinement meant that only the current hunk was ever refined;
when another section became current, the refinement of the previously
current section was removed again. Now, once a hunk has been refined,
it remains refined, until the buffer is refreshed.
The reason any form of delayed hunk refinement was implemented in the
first place, was to avoid the upfront cost of completely refining a
large diff. I never considered this a desirable feature; just a kludge
that was sadly necessary for performance reasons. IMO the new behavior
is an improvement; though always refining all hunks is of course even
better, unless it is too slow of course.
Closes #5385.
1: 2025-04-26 95ee9d8c5102bc5619f0e2c6d50104cae17b2009
magit-diff-paint-hunk: Only refine if actually painting
|
|
|
|
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.
|
|
|
|
|
|
|
|
The first default/future-history-element is also *the* default.
|
|
|
|
Hunks are still the only sections whose bodies have to painted when
they are highlighted and unhighlighted. The reason this is necessary
is that highlighting is done by using (an) overlay(s) to change the
background color of selected sections, which shadows an significant
background color used in section bodies.
Hunks use different background colors to indicate added and removed
lines. Instead of using overlays, the background colors of these
lines (and also of context lines) are changed using text properties,
when a hunk gains or loses focus. I.e., they are "painted".
Such painting is more expensive than merely removing or adding one
or more overlays, because the text has to be parsed again, so we have
to avoid doing it unless actually necessary.
We do not only want to avoid needlessly painting hunks when moving
around in the buffer, we also want to avoid it for (hunk) sections
whose bodies are not visible yet. To accomplish that the `washer'
section slot was added. Its purpose is to delay "washing" until
the section is expanded.
This slot was originally added specifically for hunk sections, but
by now it is used by many other sections too. In most cases it is
even used to not only delay washing (~= "parsing" and "painting")
but to even delay inserting any section content until that time.
With this commit, we *stop* using the function from the `washer'
slot for hunk painting, and replace that with a new mechanism that
is inspired by the old washer mechanism, but incorporates lessons
learned since.
The two drivers are still `magit-section-update-highlight' and
`magit-section-show'. These two functions are the main driving
forces behind the two events that make *might* make it necessary
to repaint.
Replace the hook `magit-section-unhighlight-hook' with a new generic
function `magit-section-paint'. Create such a method for diffs, using
the hunk-specific parts of removed `magit-diff-paint-hunk'. The parts
that function are not hunk-specific, are replaced with similar logic
in new `magit-section-update-paint'.
`magit-section-update-paint' is where we now decide whether repainting
is actually necessary.
|
|
Most sections are highlighted using a single overlay that covers the
complete section, including child sections, if any. Nearly as simple
to highlight are sections that use two overlays, one for its own
heading and the other for its body (again covering all children).
Selective highlighting is necessary when the headings of child sections
ought to like different from their body, or when their bodies use faces
that set the background and that should not be shadowed by highlighting.
Until recently both was only needed for diff-related sections, the
later only for hunks. So the implementation was also diff-specific
and treated this problem as a collection of special cases.
Add a new implementation that can be used by other sections as well.
The section slots `heading-highlight-face' already existed, but some
sections did not used it and instead propertized their headings using
custom code. Now this slot should be used, as that makes it possible to
detect when selective highlighting is necessary. If that is undesirable
for some reason the new `selective-highlight' can be set to a non-nil
value instead.
The new `magit-section-selective-highlight-p' function is used to detect
the need for selective highlighting. Its implementation should be
trivial to understand.
For consistency add a new slot `heading-selection-face', similar to
`heading-highlight-face'. Note that the value of this option does
not influence the decision whether selective highlighting is needed.
Add a third new slot `painted', which is unbound by default. If it is
bound to any value, that indicates that the section has to be painted.
Starting with the next commit the actual value will indicated whether
it has already been painted, and if so, what kind of paint was used.
|
|
Replace the hook `magit-section-highlight-hook' with a
generic function `magit-section-highlight'.
To preserve the ability to disable highlighting of the current
section and/or section selection highlighting, add new options,
`magit-section-highlight-current' and
`magit-section-highlight-selection'.
Do not replace the related `magit-section-unhighlight-hook' just
yet. In two commits that will also be replace with a generic
function (though in that case its not an exact replacement).
|
|
`magit-post-create-buffer-hook' is called right after
`magit-refresh-buffer' returned, i.e., after that called
`magit-section-update-highlight'.
Move `magit-status-goto-initial-section' from that hook to the new
`magit--initial-section-hook', which `magit-refresh-buffer' calls,
but only when the buffer is being created, not merely refreshed.
This avoids highlighting the wrong section before highlighting the
correct one.
Using such a hook is a bit of a hack. It might be better to instead
add an option that maps modes to initial sections, instead of a hook,
but let's not commit to that just yet.
|
|
After refreshing a buffer, and thus (re-)creating all sections,
`magit-section-show' has to be called on the root section to set the
correct visibility of all sections. That function may also highlight
the current section. But when called at this time, point is at the
beginning of the buffer, so the wrong section gets highlighted.
Then, back in `magit-refresh-buffer' point is moved to the correct
section, before `magit-section-update-highlight' is called, and since
a different section is current now, highlighting has to be updated.
Avoiding to highlight twice was the motivation for this change, but a
later commit prevents it differently. Despite that making this change
not strictly necessary, it feels right to move the `magit-section-show'
call to `magit-refresh-buffer'.
|
|
1. When a buffer is refreshed, section highlighting has to be updated.
2. More than one buffer may be refreshed at the same time and the
current buffer may or may not be among them.
3. Therefore highlighting has to happen during the refresh phase.
4. However, re-highlighting can also be necessary when not refresh
took place (or at least the current buffer wasn't refreshed.
5. Therefore re-highlighting has to happen during the post-command
phase, which happens after every command in a Magit buffer.
We may therefore end up refreshing the same buffer twice. To avoid that
record when a buffer is refreshed and during the post-command phase skip
highlighting such buffers before zpping the list of refreshed buffers.
A weaker attempt to accomplish this was already in place, but checking
whether `this-command' is a refresh command does not cast a wide enough
net.
Instead of recording buffers that have been refreshed and highlighted,
we could not highlight during the refresh phase and instead record
buffers as needing to be highlighted during the post-command phase.
|
|
|
|
|
|
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'.
|
|
That isn't actually necessary but is conceptually cleaner.
|
