OSC 112 Can't Work When IME is Opened

[Johnson9009]

From the change log here, the OSC sequences 110/111/112 are supported from 2.7.5, I have downloaded and compiled version 2.7.5, the OSC sequences 112 work well.
But the OSC sequence 112 can't work at 2.9.0 and 3.0.2, I only test OSC sequence 112, I don't know whether 110/111 work well or not.

The test sequences are listed below.

echo -ne "\e]12;Green\a"
echo -ne "\e]112\a"

[mintty]

Works here.
Try PS1=. for testing, to exclude any side effects from escape sequences in the prompt.

[mintty]

Did you set up option SuppressOSC?

[Johnson9009]

@mintty Thanks for quick testing, I have tried PS1=., but the cursor color still can't be reset.
According to your remind, I found OSC 112 work well if I launch mintty directly, it seems the issue is caused by Msys2, I use mintty through Msys2.

if launch msys2\usr\bin\mintty.exe, then OSC 112 work well.
if launch msys2\msys2.exe, then OSC 112 doesn't work.

It seems both of msys2\usr\bin\mintty.exe and msys2\msys2.exe are wrappers of mintty, and all of them are binary not script.

Anyway, it prove that mintty support OSC 112 correctly, if you haven't any other comments I will close this issue, thanks a lot.

[mintty]

I tried in Msys2 and could not reproduce the issue there either.

[Johnson9009]

@mintty Above phenomenon is found on my company laptop(Win10).
Just now, I test on my home PC(Win10) and my home laptop(Win7).

PC(Win10): OSC 112 doesn't work no matter how to launch mintty.
Laptop(Win7): Work well no matter how to launch mintty.

[mintty]

Retried with Msys2 on Windows 10; not reproduced.
Please provide your config file.

[Johnson9009]

Strange, my config file is listed below.

BoldAsFont=yes
ThemeFile=dracula
Font=Monaco for Powerline
FontHeight=14
Locale=en_US
Charset=UTF-8
Scrollbar=none
Term=xterm-256color
BellType=0
AllowBlinking=yes
BoldAsColour=yes
Columns=82
CursorColour=255,175,0

[Johnson9009]

dracula theme file is listed below.

ForegroundColour=248,248,242
BackgroundColour=40,42,54
Black=0,0,0
BoldBlack=104,104,104
Red=255,85,85
BoldRed=255,110,103
Green=80,250,123
BoldGreen=90,247,142
Yellow=241,250,140
BoldYellow=244,249,157
Blue=202,169,250
BoldBlue=202,169,250
Magenta=255,121,198
BoldMagenta=255,146,208
Cyan=139,233,253
BoldCyan=154,237,254
White=191,191,191
BoldWhite=230,230,230

[Johnson9009]

And the font is download from https://gist.githubusercontent.com/kevinis/c788f85a654b2d7581d8/raw/5be6ef0e44a3427fdb8343b4dacc29716449c59e/Monaco%2520for%2520Powerline.ttf

[mintty]

That answers my question about a SuppressOSC setting (assuming you have no other config file that also gets loaded, e.g. in $APPDATA/mintty).
The only remaining explanation is that echo -ne "\e]112\a" somehow gets mangled in your environment, which could be checked by a terminal log.
Also, echo -ne "\e[2 q" allows easier visual control.

[Johnson9009]

Maybe like you said, it is caused by my environment, today I can't reproduce it on my company laptop(Windows 10), I found the --log option of mintty, I will check it by myself first, thank your for your quick responses and analyses.
Thanks a lot.

[Johnson9009]

I have done 2 tests it again on my home PC(Windows 10).

1. Log Output of mintty

Prerequisite

• Just use default bash and without any rc file(no ~/.bashrc, profile...)
• PS1=.
• launch mintty by mintty -l a.txt
• Just type below 2 commands.

  echo -ne "\e]12;Green\a"
  echo -ne "\e]112\a"

Log File Content

2. Install Msys2 Freshly and Test

Prerequisite

• Downloaded and installed msys2-x86_64-20190524.exe freshly.
• Remove the environment variable HOME to avoid Msys2 use my config
• Just type below 2 commands.

  echo -ne "\e]12;Green\a"
  echo -ne "\e]112\a"

Result

The green cursor color still can't be reset.

Summary

On my home PC, this issue can be reproduced stably no matter how to launch the mintty, if anyone have the same OS version, please help to confirm.

[mintty]

You seem to be having a wider cursor, maybe by system configuration. Could that have an impact?
Please try Cursor style "Block" from the Options dialog.

[mintty]

As it occurs only in Msys2 for you, and they have a patched version, there is one more idea to suggest:
Please download mintty sources and compile yourself (i.e. without Msys2 patches).
You could also try to trace mintty functions (use printf and run compiled version from a command line), in file wintext.c, colour setting in function set_win_colour, cursor drawing near the end of function win_text. There is nothing more I can do as long as the issue does not reproduce.

[Johnson9009]

@mintty Thanks for the detailed instruction, I have setup the compile and debug environment, I can debug mintty using gdb now.

According to your instructions, I change macro "dont_debug_cursor" to "debug_cursor", from the printed information, after command echo -ne "\e]112\a", the cursor color isn't changed indeed, the color is still "Green".

set cursor (colour 00FF00) @(row 2 col 0) cursor_on 1
set cursor (colour 00FF00) @(row 2 col 0) cursor_on 1
set cursor (colour 00FF00) @(row 2 col 0) cursor_on 1

I step into the function "do_cmd", OSC 12 escape sequence is received and parsed correctly, and below line are called.

mintty/src/termout.c

Line 3195 in 43a0593

when 112: do_colour_osc(false, CURSOR_COLOUR_I, true);

mintty/src/wintext.c

Line 4150 in 1bc1b70

cc(i, cfg.cursor_colour);

I think it is not very difficult to find the root cause of this issue, because

mintty/src/wintext.c

Line 2715 in 1cf71c7

printf("set cursor (colour %06X) @(row %d col %d) cursor_on %d\n", bg, (y - PADDING) / cell_height, (x - PADDING) / char_width, term.cursor_on);

won't get the correct color, so just check the codes between cursor reset and cursor drawing may can find the root cause, but today I haven't more time, maybe I will do it tomorrow or next week.

[Johnson9009]

The root cause is the IME, drawing code of cursor will get IME_CURSOR_COLOUR_I instead of CURSOR_COLOUR_I if the IME is opened.

mintty/src/wintext.c

Line 2690 in 1cf71c7

cursor_colour = colours[ime_open ? IME_CURSOR_COLOUR_I : CURSOR_COLOUR_I];

But the OSC 112 only reset the CURSOR_COLOUR_I.

mintty/src/termout.c

Line 3195 in 1cf71c7

when 112: do_colour_osc(false, CURSOR_COLOUR_I, true);

mintty/src/termout.c

Line 3099 in 1cf71c7

win_set_colour(i, (colour)-1);

mintty/src/wintext.c

Line 4150 in 1cf71c7

cc(i, cfg.cursor_colour);

@mintty Many methods can fix this issue, do you think which is the best?
Add do_colour_osc(false, IME_CURSOR_COLOUR_I, true); in when 112: do_colour_osc(false, CURSOR_COLOUR_I, true); or reset IME_CURSOR_COLOUR implicitly in function win_set_colour like below?

    else if (i == CURSOR_COLOUR_I)
      cc(i, cfg.cursor_colour);
      cc(IME_CURSOR_COLOUR_I, cfg.cursor_colour);

It seems that IME_CURSOR_COLOUR is set implicitly when process OSC 12.

      when CURSOR_COLOUR_I: {
        // Set the colour of text under the cursor to whichever of foreground
        // and background colour is further away from the cursor colour.
        colour fg = colours[FG_COLOUR_I], bg = colours[BG_COLOUR_I];
        cc(CURSOR_TEXT_COLOUR_I, colour_dist(c, fg) > colour_dist(c, bg) ? fg : bg);
        cc(IME_CURSOR_COLOUR_I, c);
      }

[mintty]

Thanks for the analysis.
I think for symmetry the fix inside win_set_colour will be the best:

    else if (i == CURSOR_COLOUR_I) {
      cc(i, cfg.cursor_colour);
      cc(IME_CURSOR_COLOUR_I, cfg.cursor_colour);
    }

Also the global variable should get an explicit initial value:

static bool ime_open = false;

[mintty]

Patch applied, thank you.
It might also be considered whether it is proper at all to change IME cursor colour in the first place on OSC 12 if it has a customized value. Or maybe it should be adjusted, keeping a similar difference from the regular cursor colour as configured for IME colour.

[mintty]

And even the current patch seems to be wrong. Sorry for not noticing earlier.
Colour should be reset to cfg.ime_cursor_colour if that is != DEFAULT_COLOUR.

[mintty]

Uploaded a tweak about interaction with setting -o IMECursorColour=.... Please test.

[Johnson9009]

@mintty Thank you for helping change it to cfg.ime_cursor_colour, I should search whether there is a colour that dedicated used by IME cursor or not, before change the code.
I have test your newest change list with -o IMECursorColour=blue, and result is nice.

• [IME Open]Before Any Change
  
• [IME Close]Before Any Change
  
• [IME Open]After OSC 12
  
• [IME Close]After OSC 12
  
• [IME Open]After OSC 112 Reset
  
• [IME Close]After OSC 112 Reset
  

Just curiosity, have anybody really have a requirement that use another different colour for cursor when IME is open? For me, maybe there is only one possible benefit to use a different colour for IME cursor, that is reminding me I forgot close the IME, because there isn't situation which will need input Chinese in terminal.

[mintty]

I am not familiar with using input methods but I guess not all do display an overlay input area as in your screenshot, so the cursor colour may be a useful indication.

[Johnson9009]

@mintty Got it, I don't know other language input methods, but basic each Chinese input methods have these overlay input area.
Do you think we can close this issue?

[mintty]

I have the habit to close issues after the next release, for better documentation. Thank you.

[mintty]

Released 3.0.3.