Input method preedit position

[h-youhei]

With preeditType OverTheSpot(xterm's default), preedit area is located same position regardless cursor position in kakoune.

While preedit area is located near the cursor position in at least zsh, less and vi.

I tested on

• xterm + ibus
• xterm + fcitx

[h-youhei]

On mlterm, that handle input method on its own, preedit area located near the cursor even in kakoune.

xterm uses xim.

[mawww]

That is strange, although Kakoune does not use the terminal cursor for display, it does position it at the position of it's main cursor. According to the xterm man page I read, xterm should use that cursor position.

I have seen recently iterm2 with Kakoune displaying the emoji box correctly anchored at kakoune's cursor, so if that got broken its very recent, and I do not recall any changes in that area.

Seems something fishy is going on, maybe xterm is confused because the cursor is hidden.

[h-youhei]

Writing Japanese in kakoune on xterm first time is today.

[mawww]

Hello,

I did some experiments, and I believe this is actually an xterm bug. ibus-anthy preedit position works fine on rxvt-unicode, and works fine in xterm if I disable cursor hiding in Kakoune. It seems that xterm only uses the cursor position for OverTheSpot preedit when the cursor is set to visible, which is incompatible with how Kakoune draws (as it does not use the terminal to display cursors, as we have often have more than one cursors).

I am not sure why xterm does that, I cant think of a good reason not to respect cursor position when it is hidden, as it still seems to be the best guess the terminal can make.

I suggest to contact xterm developpers to see if they can fix that.

[h-youhei]

Thank you very much.

I've contacted xterm developer.

[ThomasDickey]

I took a look at the package for kakoune in Debian/testing, and keeping the comment about the "cursor" in mind, can see that kakoune is leaving the actual cursor position in other places (such as
the bottom row of the screen) while the apparent input position (indicated by a white-on-black cell drawn by kakoune) is near the top of the screen.

xterm can't guess that the cells drawn by kakoune are intended as the "real" cursor position:

https://github.com/mawww/kakoune/blob/master/src/face_registry.cc#L131

Instead, it uses the actual cursor position. Normally that "just works" in a curses program by setting the current position before doing wgetch. But (reading the debug-traces for xterm and ncurses), kakoune is updating its status line as one inserts text, leaving the actual cursor position there.

Given all of that, the bug which was reported is in kakoune.

[mawww]

@ThomasDickey hello, thanks a lot for taking a look.

Unfortunately the debian/testing version of Kakoune is very old (it is from 2016), and does not have the 91bfd71 commit which takes care of placing the hardware cursor at the correct position. Newer Kakoune do place the hardware cursor, but it is hidden (we call ncurses curs_set(0) at startup).

According to my tests, in xterm, I get correct positioning if I disable that call, and wrong positioning if I keep it. Which led me to believe xterm might not take the cursor position into account if it is hidden.

[ThomasDickey]

I also took a look at the source for rxvt-unicode, which doesn't maintain a separate cursor position for the SpotLocation, in case you were considering some feature of that program. But since it doesn't do that, there's nothing to imitate there.

It gets the position here:

https://github.com/exg/rxvt-unicode/blob/master/src/screen.C#L3547

and uses it here:

https://github.com/exg/rxvt-unicode/blob/master/src/main.C#L1259
https://github.com/exg/rxvt-unicode/blob/master/src/main.C#L1531

xterm does the same thing:

https://github.com/ThomasDickey/xterm-snapshots/blob/master/charproc.c#L4981

Whether the cursor is visible (or blinking or whatever attribute), as one moves around the screen writing text, it moves the cursor that these terminals use for input.

[mawww]

@ThomasDickey I am not very familiar with Xterm code base, but wouldn't the following condition prevent the PreeditPosition from being updated when the cursor is hidden ?
https://github.com/ThomasDickey/xterm-snapshots/blob/7968f903eb7b97d024188fb10612bd49134fec43/charproc.c#L4755

[ThomasDickey]

thanks - I'll make the indicated change :=)

[h-youhei]

Thank you, Thomas and Maxime.