From: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
To: git@vger.kernel.org, Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Subject: (Some?) control codes not escaped when using `git add -p`
Date: Thu, 12 Oct 2017 12:59:06 -0500 [thread overview]
Message-ID: <CACcTrKctqAWeWWrc9Q+Y7ewXGc_o+uJoeHS83LDw5O_s1-3Nug@mail.gmail.com> (raw)
Hello list,
Running git 2.7.4, I’ve run into an issue where control codes that would
normally be escaped when using `git diff` are not similarly escaped when using
`git add -p`.
As a concrete example, I have a text file including the following "text":
:map ^[[H <Home>
:map ^[[5~ ^B "page up
:map ^[[6~ ^F "page down
Except each ^x above is the literal ctrl+x (i.e. ctrl+v followed by ctrl+x).
These are not lines that have been added or removed from the document, they're
just context lines.
Using `git diff`, these special characters are elided from the diff output
(though the latter two lines cause special coloring in the diff output so
perhaps they're not being entirely escaped?), but when using `git add -p` upon
reaching the chunk in question my terminal interprets a literal "page up" input
and corrupts the output.
Here's a screenshot of what I see when I use `git diff`:
https://i.imgur.com/FOXWEIi.png
And here's what I see when use `git add -p`:
https://i.imgur.com/i5hqhFX.png
As you can see, in the second example the cursor is a few lines from the top of
the screen, as the text output started midway down and then jumped to the start
and continued from there on encountering the literal 'Page Up' sequence in the
diff'd text.
I'm not sure _what_ the correct approach would be here (does git faithfully
print whatever it finds in the file or does it attempt to escape it instead?)
but it seems to me that the lack of consistency between the two commands is a
bug as whichever approach is taken, a context line in `git diff` should surely
be output to the terminal in the same way as a context line in `git add -p`?
The obvious solution is to embrace isatty(2) religiously, but I'm not
sure how the
everyone else feels about that (or if it's already used elsewhere).
Anyway, I'm sure I'm not the only one to run into this. Seeking options and
interested in the various viewpoints on how this should be correctly handled
(or explanations for why it's already correct as-is).
Cheers,
Mahmoud Al-Qudsi
NeoSmart Technologies
next reply other threads:[~2017-10-12 17:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 17:59 Mahmoud Al-Qudsi [this message]
2017-10-12 18:47 ` (Some?) control codes not escaped when using `git add -p` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACcTrKctqAWeWWrc9Q+Y7ewXGc_o+uJoeHS83LDw5O_s1-3Nug@mail.gmail.com \
--to=mqudsi@neosmart.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).