Elision with escape seq #1494
Elision with escape seq #1494
Conversation
|
Fixes #713. |
mathstuf
force-pushed
the
elision-with-escape-seq
branch
2 times, most recently
from
3b85c01 to
bb5782e
Compare
|
|
||
| TEST(ElideMiddle, ElideMiddleWithEscape) { | ||
| string input = "0\33[m1234567890123456789"; | ||
| EXPECT_EQ("0\33[m123...\33[m789", ElideMiddle(input, 10)); |
There was a problem hiding this comment.
What happens when the ANSI escape is inside the elided part?
There was a problem hiding this comment.
All ANSI escapes are always output.
There was a problem hiding this comment.
Hence the duplicate \33[m part on the second half.
There was a problem hiding this comment.
It grabs the escape sequences from the elided part. I haven't dug into the issue I'm seeing here yet, but fixing it will probably make doing it better easier.
This will be reused in order to do proper elision with ANSI sequences.
mathstuf
force-pushed
the
elision-with-escape-seq
branch
from
bb5782e to
9580168
Compare
|
I'm seeing some issues with this when using it on projects locally. Will debug and figure out what's missing and add a testcase for it. |
|
What do you think about #1600? |
|
Sure, that offers another frontend to be able to do what I want, but the thing is that today elision logic in ninja itself is broken with color (though this is also related to #1584). If #1600 is accepted, should color just be outright rejected from |
|
Good questions. We probably should also fix this in Ninja itself. Btw: Did you have a look at my take on ANSI-aware elide_middle (in Python though)? https://github.com/jhasse/ja/blob/da264576a85d4d8b1de4517487bfe501b6337915/ja/native.py#L258 |
|
Yes, I had looked at it. I started the code from my old |
|
Or consider using my frontend, comes with other awesome features, too ;) |
|
I had another go at it in #2428. |
Fixes #713.
Cc: @jhasse