Johannes Schindelin [off-list ref] writes:
Maybe a better approach would be to hide the `save_term()` dance behind a
new config option, and then have it turned on automatically if the
`editor` _happens_ to be `vi` or `vim`.
Why 'vi' and 'vim' are so special? Is this an attempt to paper over
a bug in 'vim' on the caller side?
That would help the problem reported in the Windows Terminal project.
Ciao,
Dscho
On Wed, Nov 24, 2021 at 11:34 AM Junio C Hamano [off-list ref] wrote:
Why 'vi' and 'vim' are so special? Is this an attempt to paper over
a bug in 'vim' on the caller side?
not sure if the bug is on vi/vim, cygwin's pty or the new conPTY that
Windows Terminal uses; but in Git for Windows, using an MSYS vim (that
uses cygwin's pty) within Windows Terminal (and other terminals that
use conPTY most likely) leads to this terminal output corruption, that
bash "fixes" when it gets the control back, but that git does not
(unless something like what I am proposing is done), and that is
specially disruptive when doing several commits in a series (ex: an
interactive rebase).
you could say it is an attempt to paper over that bug, but IMHO it is
also a way for git to protect itself from a "rogue" editor, as it is
now just trusting that the editor wouldn't mess with its terminal
settings after being invoked and it returns control to git.
Carlo
Hi Junio,
On Wed, 24 Nov 2021, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Maybe a better approach would be to hide the `save_term()` dance behind a
new config option, and then have it turned on automatically if the
`editor` _happens_ to be `vi` or `vim`.
Why 'vi' and 'vim' are so special?
Git's default editor is `vi`. That's what makes it special.
Is this an attempt to paper over a bug in 'vim' on the caller side?
While this works around a concrete bug reported at
https://github.com/microsoft/terminal/issues/9359, the mere fact that this
bug was possible indicates that Git needs to be able to deal with such
bugs, whether the bug is in the editor, in a POSIX emulation layer, in the
used shell or in the terminal. It is all the more important to have such a
knob because there are so many potential sources for buggy behavior that
users are unlikely to have the expertise to even identify which component
is at fault.
Ciao,
Dscho