While `range-diff` output doesn't display with any syntax highlighting,
it's still in a buffer with a filetype of 'git' and thus fugitive
attaches the standard jump mappings. However, those mappings work
inconsistently for `range-diff` output due to some accidental matching
in `s:cfile()`. For lines like these:
1: aaaaaaa = 1: bbbbbbb My subject
2: aaaaaaa = -: ------- My other subject
Depending on the position of the cursor, we sometimes hit the `<cword>`
fallback and open the commit. This can happen when the cursor is over a
commit hash, or even on one of the `:`. However, for a line like this:
-: ------- > 2: aaaaaaa My subject
We end up hitting the block intended to catch +/- lines in diff output,
and fail to identify a commit.
Add a special set of handling for range-diff header lines. In cases
where only one commit is present in the line, open that commit
automatically regardless of cursor position. For cases where the line
represents a different commit on each side, fall back to a `<cword>`
approach to allow opening either commit based on cursor position.
Fix#2315: Gedit strips newlines when commit lacks a blank line
%B is the "raw body (unwrapped subject and body)". Since we're
displaying both, we can use that to avoid any changes to the message
content. %B was added to git in 1.7.2 (2010) in commit
1367b12ad623e28546ba40c435015d94e7fbb248, and fugitive requires 1.8.5 so
it's safe to use.
I think matching the Magit interface is probably a better use of P than
wrapping --patch. As a baby step in that direction, allow P to invoke
the same experimental behavior as "s" or "-".
Put all the stuff that actually updates the buffer together, so we can
soft reload without triggering autocommands or doing redundant work.
The reason for the previous ordering was to allow a bit of parallelism
while the diff commands ran in the background. Let's try to preserve
that for map definitions by running them in parallel to the status
command instead.
I'm not sure why 'nomodifiable' was set after BufReadPost. Let's try
the more natural ordering and see if anything breaks.
Ran into an issue where a running Vim (Neovim 0.9.5) consistently
treated a relative path not as the file in the current directory, but as
a different open buffer that matched the file name. The relative path
was just for cosmetics; let's switch to absolute so Vim doesn't butcher
it.
Due to a regex not capturing (and concealing) all the spaces behind
the current file's line numbers, the close parentheses after the line
numbers are misaligned, and the blame buffer is made too wide.
