dandavison
avoid the display issue with git add -p without losing CR
Solve https://github.com/dandavison/delta/pull/664 without losing CRs in delta's output.
This will also show other control characters in the output of git add-p.
It partially fixes https://github.com/dandavison/delta/issues/754 There remains a problem on preserving CRs in delta's input.
I found that git diff --color=always does not guarantee the escape sequence between CR and LF on each line.
So this It wasn't enough for #754.
I think we should deal with it by extending bytelines or not using bytelines.
is needed...
Ho @yoichi, I think patching bytelines, or not using bytelines, are good ideas. The bytelines author was very helpful when I contacted them about an issue.
Not using it does make sense though, since it's not a mainstream library. I think the reason I started using it was to support non-utf8 encoded input. I'll find the relevant issues.
See https://github.com/dandavison/delta/issues/188 for encoding discussion. I think I never finished the work discussed.
bytelines allows us to output lossy decoding. Before bytelines I was doing this, which meant an error message would appear in the middle of user's output: https://github.com/dandavison/delta/commit/9d1aafee2465b3b89de09ae72e1b8b8fbda4a981
We should look how other Rust projects deal with non utf8 input; do they not use stdin.lock().lines()?
There seems need to a new issue (or #754 probably) to discuss how to preserve CR.
I have to say my instinct is that this doesn't feel like the right solution. But I don't think I have the problem clear in my mind so I'm sorry to say something vague like that. I don't really want to make delta's instructions for git add -p more complicated (that's my fault because the name --color-only was never a very good name!)
What is this there about this problem that is specific to git add -p?
The problem specfic to git add -p is that if we preserve CRs (and other control characters) and want to show them,
we must translate them to something printable (e.g. caret notation), since bare control characters will be handled
by the terminal.
After I've read the following comment from @dandavison on #754
I do think it's worth bearing in mind that delta's output is for humans to look at, not for machines to parse
then I came up with an idea: we can choose delta's bahavior that it always translate control characters in its output
to printables, without introducing new option, and not limited to git add -p.
In 4ac5035, I've removed the option caret-encode added in this PR.
Note
- The replacement process can be placed earlier, but it makes the input caret notation and control characters indistinguishable.
- This change allows us to use reverse video to distinguish between them.