-
-
Notifications
You must be signed in to change notification settings - Fork 977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IME: put cursor after rendered text #4937
Conversation
The cursor position could be used for determinating the ime popup position. For the sake of consistent (possible) popup position, we should update cursor position after rendered text.
The popup window is implemented for sway (and will be accepted later), I found this bug under sway with this pull request applied: After debugging cursor update mechinism, I confirm that we should make code change in the client side (kitty). |
I don't know what sway has done and can't understand what problem you are trying to fix.
The left side of the IME candidate box should be aligned with the last entered pre-edit text. Whatever you are trying to fix, you should make sure to test it under macOS/Linux(DEs) and in different IMEs and should not break the others. |
On Fri, Apr 08, 2022 at 01:51:19AM -0700, page-down wrote:
I don't know what sway has done and can't understand what problem you are trying to fix.
```text
CONFIRMED_PREEDDITpending
------------------[ Candidates Here (IME) ]
```
The left side of the IME candidate box should be aligned with the last entered pre-edit text.
So when kitty receives the pre-edit text update event, it should update the IME position first, and then draw the overlay text.
Hmm, yes I think you are right, I am reverting my merge.
|
In the discussion thread you mentioned someone mentioned the problem of typing at the edge of the window. @kovidgoyal |
Logically you are right. Assume sway is drawing the popup windows, it needs to know the cursor position, which is suppose to be exactly after the rendered text. |
In my opinion, the cursor position specified by the program running in the terminal should not be changed at all when drawing an overlay line. (The program does not know about this.)
The position of the input method should not be specified by the cursor position, and any attempt to lay out the input method by reading the cursor position inside the terminal is a hack. |
Well, kitty does update the cursor position, unlike other programs under wayland as an xdg-shell.
Currently, kitty updates the cursor position since pre-edit function is called. |
On Fri, Apr 08, 2022 at 02:27:19AM -0700, page-down wrote:
In the discussion thread you mentioned someone mentioned the problem of typing at the edge of the window.
I found that when the pre-edit text exceeds the window width (e.g. at the very end), it doesn't wrap the line and only renders the last character at the end of the cursor line.
@kovidgoyal
Should we add overlay line ystart and then wrap the line?
You mean render the overlay line over the next terminal line? I doubt
that will work given how the overlay line tracks its position.
|
Steps to Reproduce:
OK, note down as a known issue. |
The cursor position could be used for determinating the ime popup position.
For the sake of consistent (possible) popup position, we should update
cursor position after rendered text.