Git send-email by default uses multi-file edit mode
(sendemail.multiEdit) when more than one patch file requires editing an
associated email message and/or cover-letters. Multi edit mode spawns
one editor instance with multiple files in argument list. This behavior
is supported by creating multiple splits for a running vim instance when
`:G send-email` is called. When the user sets sendemail.multiEdit to
false in the local or global config, if multiple files need editing then
they are processed sequentially in a single split at a time.
Closes#2352
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.
The Include directive behaves very literally. The old implementation
assumed a level of encapsulation that just doesn't match the actual
implementation.
