-
-
Notifications
You must be signed in to change notification settings - Fork 972
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
Compatible with input methods that commit text with alphabets under macOS #4219
Comments
I doubt there is a good way to handle this given the limitations of the Cocoa API available to us. What we need is for Cocoa to tell us to commit the current word and start the next one. hasMarkedtext is obviously insufficient for this. Later down in that file look for "unmarkText" if that is called by cocoa then we can use that instead. And it would help if you posted some instructions for how to setup this IME so I can test it for myself. |
In keyDown, unmark is called every time: I noticed that:
Perhaps this should also be a clear indication of the confirmation? Here is how to configure this input method. Click to expand ...InstallationDownload and double-click the unzipped pkg from GitHub Release to install. Open open /System/Library/PreferencePanes/Keyboard.prefPane If it does not work, you may need to log out of the current user and log in again. UninstallationRemove the input method from the above (Input Sources) and delete the following directory. Log out of the user account and log in again.
In case you are using QEMU to run the macOS VM, you can also use Configure the input schemeDelete all files under default.custom.yaml patch:
schema_list:
- schema: table-auto-select
ascii_composer/switch_key: {}
key_binder/bindings: {}
switcher/hotkeys: {} demo.dict.yaml ---
name: demo
version: "0.1"
sort: original
...
# the following is separated by tab "\t"
# so be careful when copying
kitty kitt
kitten kitt
terminal t table-auto-select.schema.yaml schema:
schema_id: table-auto-select
name: table-auto-select
switches:
- name: ascii_mode
reset: 0
- name: ascii_punct
reset: 0
engine:
processors:
- ascii_composer
- speller
- selector
- navigator
- express_editor
segmentors:
- ascii_segmentor
- abc_segmentor
- fallback_segmentor
translators:
- table_translator
speller:
alphabet: 'zyxwvutsrqponmlkjihgfedcba'
initials: 'abcdefghijklmnopqrstuvwxyz'
max_code_length: 4
auto_select: true
auto_select_pattern: ^\w{4}$
auto_clear: max_length
translator:
dictionary: demo
db_class: stabledb
enable_charset_filter: false
enable_sentence: false
enable_completion: false
enable_user_dict: false
style:
horizontal: true |
I know unmarkText is called by keyDown itself. I meant is it also called by cocoa when you pass it the third t key (and more generally on pre-edit completion. If cocoa calls it when any pre-edit sequence completes we can use it. Even if we call it ourselves, we can detect when cocoa calls it too. In order to use text != NULL and marked_text != NULL as a signal to send commit pre-edit message we have to know if that combination does not ever occur with other IME methods during normal operation. I cant find any documentation on it, which is typical for Apple, so that leaves experimentation. |
Try this: ca9fdad it will show us if we can use unmarkText as a signal. |
I think I'm experiencing the breakage now. After typing
When |
yeah, not clearing the markedtext on keydown causes the last backspace |
I think his patch still applies. |
That is easily fixed by 8644fed unmarkText is not official anymore (it used to be in older cocoa versions) however it is currently called by setMarkedText. I see it called when using the cangjie chines IME for instance. |
Thanks for the clarification, then it seems that this part of the code does need to be updated. This solves the backspace problem. The next step is to see how to solve this problem of getting stuck after selecting a candidate. Not only does the marked text remain, but enter and ctrl+c are not responding. It really does take a lot of experimentation. |
That should be fixed by: f34cc18 |
Yes, it did work out. In the meantime, the problem that was initially raised is still appearing. So I try out this solution. Only the third diff --git a/glfw/cocoa_window.m b/glfw/cocoa_window.m
index 1d84395c..757dd795 100644
--- a/glfw/cocoa_window.m
+++ b/glfw/cocoa_window.m
@@ -1216,6 +1216,9 @@ - (void)updateTrackingAreas
- (void)keyDown:(NSEvent *)event
{
+ // DEBUG
+ const bool previous_has_text = _glfw.ns.text[0] != 0;
+
const bool previous_has_marked_text = [self hasMarkedText];
NSTextInputContext *inpctx = [NSTextInputContext currentInputContext];
if (inpctx && (!input_source_at_last_key_event || ![input_source_at_last_key_event isEqualToString:inpctx.selectedKeyboardInputSource])) {
@@ -1295,6 +1298,19 @@ - (void)keyDown:(NSEvent *)event
format_text(_glfw.ns.text), _glfwGetKeyName(key), unmark_text_called, [[markedText string] UTF8String]);
if (!window->ns.deadKeyState) {
if ([self hasMarkedText]) {
+ // DEBUG
+ if (!previous_has_text && _glfw.ns.text[0] != 0 && previous_has_marked_text) {
+ glfw_keyevent.text = _glfw.ns.text;
+ glfw_keyevent.ime_state = GLFW_IME_COMMIT_TEXT;
+ _glfwInputKeyboard(window, &glfw_keyevent);
+
+ // issue: missing current marked text,
+ // If the pre-edit text is updated here, it will be rendered in the wrong position.
+ glfw_keyevent.text = NULL;
+ glfw_keyevent.ime_state = GLFW_IME_PREEDIT_CHANGED;
+ _glfwInputKeyboard(window, &glfw_keyevent); // clear pre-edit text
+ return;
+ }
glfw_keyevent.text = [[markedText string] UTF8String];
glfw_keyevent.ime_state = GLFW_IME_PREEDIT_CHANGED;
_glfwInputKeyboard(window, &glfw_keyevent); // update pre-edit text |
Can you post the log running from current HEAD and typing kittt |
|
That's two t presses, I need three |
I edited the log above. Pressed the space at the end. |
As we can see after the third t, as I suspected unmark_called: 1 so we can use that as a signal, I think. |
Yes, put |
Thanks for the update. I pulled the latest and tried it. In fish shell, there is a problem. When the third t is entered, the cursor is at the far right of the screen.
In vim, the third |
Run with --dump-commands figure out what commands these programs are And let me just note for posterity, IME is the worlds worst idea. |
The functions involved are the following. diff --git a/kitty/screen.c b/kitty/screen.c
index 8918cb5b..6f219d44 100644
--- a/kitty/screen.c
+++ b/kitty/screen.c
@@ -794,6 +794,7 @@ screen_alignment_display(Screen *self) {
void
select_graphic_rendition(Screen *self, int *params, unsigned int count, Region *region_) {
+ SAVE_OVERLAY_LINE(select_graphic_rendition);
if (region_) {
Region region = *region_;
if (!region.top) region.top = 1;
@@ -1052,6 +1053,7 @@ set_mode_from_const(Screen *self, unsigned int mode, bool val) {
void
screen_set_mode(Screen *self, unsigned int mode) {
+ SAVE_OVERLAY_LINE(screen_set_mode);
set_mode_from_const(self, mode, true);
}
@@ -1062,6 +1064,7 @@ screen_decsace(Screen *self, unsigned int val) {
void
screen_reset_mode(Screen *self, unsigned int mode) {
+ SAVE_OVERLAY_LINE(screen_reset_mode);
set_mode_from_const(self, mode, false);
}
@@ -1329,6 +1332,7 @@ screen_reverse_scroll_and_fill_from_scrollback(Screen *self, unsigned int count)
void
screen_carriage_return(Screen *self) {
+ SAVE_OVERLAY_LINE(screen_carriage_return);
if (self->cursor->x != 0) {
self->cursor->x = 0;
} Also in programs like vim, the IME position changes along with the text for obvious reasons as the cursor needs to be moved to other positions (status bar) to update the text. Hope everything is working fine.
This is no joke. I've debugged some IMEs before and had a ton of issues on Linux, Windows as well. As mentioned in the previous issue, if contributors implement "IME" (keystrokes to Unicode Text) in kitty, it will be a very smooth development experience. Users wouldn't have to suffer so much. |
I dont think all those are necessary, I have committed a slightly |
If it is not handled in Also in the screenshot below, I see draw s/, not sure where it comes from at the moment, but it's probably fish's auto-complete, auto-color marker, which is the text underneath the marked text. After updating to the latest, vim shows the third t as marked text and it works fine. Also I found that during IME input, if I switch to another window and switch back, it doesn't work properly. |
On Fri, Nov 12, 2021 at 06:23:40AM -0800, page-down wrote:
> I dont think all those are necessary, I have committed a slightly different version, please let me know if it works.
If it is not handled in `select_graphic_rendition`, it will come out using the color of the previous text. For example, a command that does not exist in fish is red, causing the background color of the marked text to be red as well. So this may have to be handled elsewhere.
OK, have added it.
Also in the screenshot below, I see draw s/, not sure where it comes from at the moment, but it's probably fish's auto-complete, auto-color marker, which is the text underneath the marked text.
![](https://user-images.githubusercontent.com/57713011/141481927-6ecf86ab-570a-4ab1-8dcf-ba4e0eb6b713.png)
After updating to the latest, vim shows the third t as marked text and it works fine.
Also I found that during IME input, if I switch to another window and switch back, it doesn't work properly.
![](https://user-images.githubusercontent.com/57713011/141482041-2c96ccc8-8bf8-420d-8892-69b92bad5d48.gif)
I'm afraid I dont care enough to debug this, the answer is, dont do
that. But if you care, patches are welcome.
|
Is your feature request related to a problem? Please describe.
There is a text input method in which the first candidate will be confirmed when there is no match for the last entered character. The last character will immediately be used as the pre-edit text for the next word.
This type of text input is very efficient and widely used, and is commonly used in fixed-length table input methods.
However, in kitty, there will be a misalignment at this point. After the first candidate word is submitted, the last character is rendered in its original position as pre-edit text. I found this compatibility issue in kitty today while occasionally working with multilingual documents.
The following
kitt
has two candidates, kitty and kitten.After entering
t
,kitty
is automatically submitted since there are nokittt
matches.However, at this point
t
is rendered in the original position when the input method state was entered.Describe the solution you'd like
After submitting the text, render the pre-edit text with the latest cursor position.
Describe alternatives you've considered
n/a
Additional context
This is reproduced using
rime
, an open source input engine mentioned in another IME issue thread.Screen recording
Use the
space
to confirm the candidate, everything works fine.Enter the initial
t
of the next word and let the first candidate confirm automatically. At this point the pre-edit text is not at the latest cursor position. It looks like this is because the pre-edit text is updated first in a keypress event, and then the text is output to the child.I'm looking at cocoa_window.m keyDown.
I'm not quite sure if there is the most appropriate way to handle this situation, any help is greatly appreciated.
The text was updated successfully, but these errors were encountered: