Confusing "highlighting" when path argument contains >1 `**`

[0ion9]

Confusing "highlighting" when path argument contains >1 `**`

[faho]

I can't reproduce.

[0ion9]

Hmm. I tested with a few different terminal emulators, including the one I mainly use, kitty 0.33:

Xterm: Doesn't reproduce
Sakura: Doesn't reproduce
Kitty: Reproduces

I guess this is actually a kitty bug then (unless fish does anything different with color codes when kitty is detected).

[faho]

I also cannot reproduce it with kitty.

We do now send a bunch of things to enable functions in kitty, but for the most part they're related to input (key detection etc). They are send unconditional but some of them will only take effect in kitty. It seems unlikely that they would change anything.

To debug this, you'd want to record a fish session with asciinema or script in kitty and a working terminal. You would also check kitty's shell integration.

[0ion9]

I guess I can do an asciinema, it may provide slightly more detailed information.
I also just tried upgrading kitty 0.33-> git pre-0.35, which replaces the shell integration too; it didn't change anything about the behaviour I describe, either with my normal config or a clean config. I can confirm at least for 0.35, __ksi_schedule appears to be being called normally (and seems to contain nothing relating obviously to color); I'm not sure what else I should check regarding shell integration.

EDIT: asciinema doesn't seem as if it will help; Making a recording in xterm and a recording in kitty, the kitty recording played back in kitty looks abnormal, but when played back in xterm or sakura it looks totally normal (exactly matching the recording I did in xterm). And the xterm recording is the same (abnormal in kitty, normal in xterm or sakura). So the recording just doesn't seem to capture the relevant information. Perhaps that in itself is useful to know, though. I'm still leaning towards 'this is something kitty is doing' as a theory, given this outcome.

EDIT2: asciinema uploaded here, just in case. This is the kitty recording, and as expected, the asciinema website displays it without any blank areas.

[faho]

EDIT2: asciinema uploaded here, just in case. This is the kitty recording, and as expected, the asciinema website displays it without any blank areas.

I cannot see any blank areas playing this back in kitty (0.35.0, no configuration) either.

There is also nothing special in the recording. The * are drawn like

\u001b[96m*\u001b[30m\u001b(B\u001b[m\r\u001b[30C

That's \e[96m (bright cyan), the *, return to black, reset styling, return to column 0, move to column 30.

Which is wasteful and can be optimized, but there's nothing wrong here. The color is always set when we print a *, so it should be shown in that color.

So if that recording shows blanks in your kitty, the most likely explanation is a misconfiguration (e.g. you set a color in the palette to the color of the background) or bug in kitty.

[0ion9]

True. I concluded it was the line font_family Fantasque Sans Mono Regular. Which is weird because that font appears to exist, and the other settings (bold_font, italic_font, bold_italic_font) do not cause problems (they were already set to the corresponding styles of Fantasque Sans Mono).

I'll close this. Maybe I'll open a kitty bug if I ever figure out why that particular setting is somehow different from the others.

EDIT: Haven't made any progress there, but I did note that this behaviour just applies to chains of **/ in general (so for example it showed up when I was editing the config file to make a note about this behaviour)