What if both compStr and resultStr come into Ime?

[johnsonj]

just ignore compStr!

#2137 Win32: Clear IME state in ScintillaWin::ImeEndComposition()

https://sourceforge.net/p/scintilla/bugs/2137/

tentativeUndo should be a pair with tentativeActive in HandleCompositionInline().

view.imeCaretBlockOverride also should be in HandleCompositionInline().

If they are in outside some where,

it means a bug is hidden in scintilla ime.

I find the bug, and can cope with the case which  both compStr and resultStr comes in.

[johnsonj]

while WM_IME_COMPOSITION:              resultStrcompStr

           WM_IME_ENDCOMPOSITION:      resultStr

We can not see  compStr

Since as soon as it is inserted, instantly deleted by TentativeUndo.

The rest text after it have to move back and forth.

So this patch should be commited.

While WM_IME_COMPOSITION:              resultStr

           WM_IME_ENDCOMPOSITION:      resultStr

Do not TentativeUndo. Do nothing.

2023년 5월 10일 수요일 오후 1시 19분 19초 UTC+9에 johnsonj님이 작성:

[johnsonj]

If both compStr and resultStr come in and they are differnt each other,

Nobody knows how to handle that.

They should be the same string.

And in this case compStr indicates last composition

so it means we have a chance to clear ime states.

If Ime intends to cancel composition, resultStr will be  "" with length.

If Ime wants to complet composition, it will be "resultStr" with length.

In any case it is safe to handle resultStr and ignore compStr.

There is no imeStart and imeEnd call for Qt

 imeStart and imeEnd is not written into Gtk yet.

TentativeUndo should not depend upon them.

2023년 5월 11일 목요일 오후 8시 59분 31초 UTC+9에 johnsonj님이 작성:

[johnsonj]

sptr_t ScintillaWin::HandleCompositionWindowed(uptr_t wParam, sptr_t lParam) {
if (lParam & GCS_RESULTSTR) {
IMContext imc(MainHWND());
if (imc.hIMC) {
AddWString(imc.GetCompositionString(GCS_RESULTSTR), CharacterSource::ImeResult);

// Set new position after converted
const Point pos = PointMainCaret();
COMPOSITIONFORM CompForm {};
CompForm.dwStyle = CFS_POINT;
CompForm.ptCurrentPos = POINTFromPoint(pos);
::ImmSetCompositionWindow(imc.hIMC, &CompForm);
}
return 0;
}
return ::DefWindowProc(MainHWND(), WM_IME_COMPOSITION, wParam, lParam);
}

take note of return 0;

if both compStr and resultStr come in,

firstly insert resultStr

and ignore compStr.

I think flattenning "if structure" causes undifind behaviors.

2023년 5월 13일 토요일 오후 1시 41분 54초 UTC+9에 johnsonj님이 작성:

[johnsonj]

Scintilla ime is  different from cromium.

Flattend if structure of cromium cause a bug when both resultStr and compStr come in.

It is silly to insert compStr in composition and the momonent to delete it in end.

We should not introduce the inefficency.

Never process both resultStr and compStr at the same time.

since we use undo mechanism.

2023년 5월 19일 금요일 오후 5시 38분 32초 UTC+9에 johnsonj님이 작성:

[Neil Hodgson]

johnsonj:

> Scintilla ime is different from cromium.
> Flattend if structure of cromium cause a bug when both resultStr and compStr come in.

Under what circumstances do you see both GCS_RESULTSTR and GCS_COMPSTR?

I added the following and put a breakpoint on the trace and tried all
my installed CJK IMEs and there were no hits.

diff -r ac6858df2aac win32/ScintillaWin.cxx
--- a/win32/ScintillaWin.cxx Sun May 14 09:44:14 2023 +1000
+++ b/win32/ScintillaWin.cxx Fri May 26 17:24:19 2023 +1000
@@ -1260,6 +1260,9 @@
}

view.imeCaretBlockOverride = false;
+ if ((lParam & GCS_RESULTSTR) && (lParam & GCS_COMPSTR)) {
+ OutputDebugStringA("Both!\n");
+ }

if (lParam & GCS_RESULTSTR) {
AddWString(imc.GetCompositionString(GCS_RESULTSTR),
CharacterSource::ImeResult);

Neil

[johnsonj]

Here starts imeWin go wrong way.

#2137 Win32: Clear IME state in ScintillaWin::ImeEndComposition()

Hide "if structure" bug,  the effect is "cancel composition"".
Bug [#2137]. Clear IME state when switching language.

Here introduced the behavior of chromium for "complete composition."

Flatten "If structure" and change the order. the effect is "complete composition".
Handle Japanese IME input when both GCS_COMPSTR and GCS_RESULTSTR set.

The title copyed from chromium seems wrong,  I have not seen the case in japanese ime.
Japanese ime is a model reference which is delicate and refined.
That is the case with chinese ime when last wm_ime_composition right after wm_ime_endcomposition.


I do not accept "If structure" is flattened. since its behavior is not defined.
We have no choice to choose cancel or complete composition when both compstr and resultstr come in.
We should select to complete composition,  since the order is important due to TentativeUndo.

I do not depend on wm_ime_startcomposition and wm_ime_endcomposition.
Here behaves Korean ime abnormaly.

2023년 5월 26일 금요일 오후 4시 28분 25초 UTC+9에 Neil님이 작성:

[johnsonj]

I revoke all the above comments.

I find the worst case recent Japnese ime with TSF working sends both compStr and resultStr at the same time, and they are different each other.

so scintill ime has to flatten if structure, needs TentativeUndo in ime_end_composition.

Win ime implementor must be an adroit but idiot.

He scatters the order of ime world.

I would like to close this thread.

Thank you for your instructions!

2023년 5월 27일 토요일 오후 12시 41분 10초 UTC+9에 johnsonj님이 작성:

[Neil Hodgson]

There are some relevant links not mentioned before.

The Scintilla change for both compStr and resultStr at the same
time comes from this message.
https://groups.google.com/g/scintilla-interest/c/3I0i0hiEumg/m/Z8eQ8quvAQAJ
and is based on this Notepad2 change
https://github.com/zufuliu/notepad2/commit/f75470d5be2dd27c8e05d87adf19fbf7197c87c0
simplified by maboroshin to
https://github.com/maboroshin/Notepad3/commit/dc0172bcb6225117ba3a55cffcfd1a3583111ebc

Neil

[johnsonj]

I have already studied all the links above.

But I made a mistake I concentrated on chinese ime.

I did not think Recent japnese ime with TSF becomes worst.

I am afraid It is possible Qt IME also behaves bad

.

2023년 6월 1일 목요일 오후 8시 58분 27초 UTC+9에 Neil님이 작성:

[johnsonj]

I have had a hard time tring to figure out recent changes of scitilla ime.

Here are TSF behaviors introduced.
1. partial commit -> solved  

flatten if structure for japanese.
https://sourceforge.net/p/scintilla/code/ci/92d3ec5798695db9da797028ea7b3cc701b3270d/

clear ime states for chinese.
https://sourceforge.net/p/scintilla/code/ci/9e086fbcc7561f808d2a8d4a1752fa77dd412745/

2. inBlock input -> abnormal
This is a real problem.
TSF does not syncronize internally with IMM32.
Caret can move into block input internally.
But users can not see caret moving visually.
It still stucks at the start of block.

All of problemes sorces out from TSF.
I presummed the culprit to be TSF.

Today my system happens to update IME.
Abruptly All problems solves.
Scitilla ime behaves as old days according to IMM32.

My hard time ,  My agonies fly away!

Here reports Scite 5.3.6 working correctly on windows10.

https://www.youtube.com/watch?v=6WaoyR7QdrI

2023년 6월 1일 목요일 오후 10시 43분 4초 UTC+9에 johnsonj님이 작성: