Korean IME set CS_NOMOVECARET and CS_INSERTCHAR but not GCS_CURSORPOS, caret need be moved back to the beginning of input string.
Chinese IME and Japanese IME in input mode GetImeCaretPos() returns the length of input string, thus IME caret can be kept at end of input string without moving.
Japanese IME after pressing Tab replaces input string with first candidate item (target string); when selecting other candidate item, previous item will be replaced with current one.
After candidate item been added, it's looks like been full selected, it's better to keep caret at end of "selection" (end of input) instead of jump to beginning of input / "selection".
See related discussions on [feature-requests:#1300]
https://sourceforge.net/p/scintilla/feature-requests/1300/?page=2&limit=25#c3aa
https://sourceforge.net/p/scintilla/feature-requests/1300/?page=3&limit=25#866a
Diff:
Related
Feature Requests:
#1300Patch as previous discussed use std::all_of().
Committed as [124907].
Related
Commit: [124907]
Fix typo.
Committed as [c7557a], [1bcb91], [a5aecf].
Related
Commit: [1bcb91]
Commit: [a5aecf]
Commit: [c7557a]
I see this patch too late.
I for korean do not care aboutCS_NOMOVECARET
What is it in need for?
for japanese or korean?
For japanese IME.
Mainly for Japanese IME. it not affect Korean IME, which set CS_NOMOVECARET, so move back to the front of composition string.
What benefits does japanese ime get from csnomovecaret?
Committed as [124907].
Related
Commit: [124907]
This is not related the code impmented.
I just leave a fact check for after runners.
"Korean IME set CS_NOMOVECARET and CS_INSERTCHAR but not GCS_CURSORPOS, caret need be moved back to the beginning of input string."
No, Korean need not to be moved back. see Qt and Gtk.
"Chinese IME and Japanese IME in input mode GetImeCaretPos() returns the length of input string, thus IME caret can be kept at end of input string without moving."
No, GetImeCaretPos() returns GCS_CURSORPOS, and GCS_CURSORPOS is not always the entire length, IME caret should be located at GCS_CURSORPOS, NOT the end of composition string.
Japanese IME after pressing Tab replaces input string with first candidate item (target string); when selecting other candidate item, previous item will be replaced with current one.
After candidate item been added, it's looks like been full selected, it's better to keep caret at end of "selection" (end of input) instead of jump to beginning of input / "selection".
NO, keep ime caret at GCS_CURSORPOS.
We should just take into consideration whether it is normal input of block input.
NOT japanese, chinese or korean.
** Ignore CS_NOMOVECARET, Keep ime caret at GCS_CURSORPOS.**
your imeWin32.patch at https://sourceforge.net/p/scintilla/feature-requests/1300/?page=4#b33a doesn't work as expected:
for
katana刀 example from https://sourceforge.net/p/scintilla/feature-requests/1300/?page=2&limit=25#c3aa/221a/30b7/f0caon Win 10 with MS Japanese IME, after press Space (not Tab, which only generates
IndicatorInput, so the comment may needs update:pressing Space or Tab replaces),imeIndicatoronly containsIndicatorTarget, current code keeps caret after 刀 character (same at Windows Notepad), your patch move the caret to the front of 刀.If there is any block input, caret position get meaningless. so drop and hide caret.
You can not see caret. This is a rule or principle.
They does not follow Ime protocol.
You do not have to follow them.
It is enough to take it into consideration
You can see their own inconsitency on MS edge :
1. address window : following the rule. no caret indicating block input
2. search window : break the rule. last caret shown confusing which mode input is in : normal or block input?
address window : legacy Ime
search window : using TSF
There is no unnecessary ime caret moving!
How complicated, inefficent!
There add two buggy if check and one unnecessary if check.
Without the change Japanese IME on complete, caret will jump from start to end.
please be specific.
I want to reproduce the case.
With imeWin32.patch on Win10 with MS Japanese IME:
1. type
katana2. press Space (caret move to front of 刀)
3. press Enter (caret jump to end of 刀)
in Windows Notepad, caret is always kept at end of 刀.
scintillaWin ime seems to suffer seriously recent japanese ime with TSF.
Caret position is very important for debugging visually.
I will put off this force until I know of something about TSF.
I forgot leaving comment.
Do you move Ime caret based on other app?
Ime Caret should be moved based on caret position pointed by IME.
More or less Windows Notepad.
Today I installed IME again.
Now It seems TSF to be synchronize with IMM32.
Scitilla works as expected as it follows IMM32.
1. no partial commit.
2. no inBlock input.
Here is my report.
https://groups.google.com/g/scintilla-interest/c/iJGRJacb8zI