Activity for johnsonj
-
johnsonj posted a comment on ticket #1561
for scite
-
it defaults false
-
for scintilla
-
SPI_GETMOUSEVANISH reflected!
-
for scite
-
I prefer SCI_SETTYPINGWITHOUTCURSOR.
-
also needed!
-
I managed to build scite working. + Set or Get whether hiding mouse cursor or not while typing text. + Blank cursor is set (hidden) when any character is typed in. + Either mouse moving or buffer switching restores cursor to be normal (shown).
-
Avoding spurious mouse move event on win32, I bind "cursorIsVisible" with keyboard modifiers. To my surprise, GTK can show cursor between tabs. but I gave up mouse leave event, which is too elusive to catch. Hide cursor while typing for scintilla on GTK https://youtu.be/yQl-mf3XC9w
-
I realize hidden cursor does not depend on visibility. It depends on character added and whether in or out of edit pane. (it triggers when character added and only if within edit pane.) My plan is moving win32 code to Editor, so that make it work for all platforms. I'd like to expose typingWithoutCursor to user option. but I did not work on this yet. Respond spurious event of mouse moving on win32 Ctrl+N, Ctrl+Tab etc revives cursor to be normal. https://youtu.be/4itLcZUkN9o Hide cursor while typing...
-
Semantics changed: cursorIsHidden -> cursorIsVisible -> cursorIsIn Win32 behaves as your instruction for ctrl+tab, ctrl+N and so forth. Gtk does keep its cursor state as is. I am not sure Qt and macOS since I have no tab-featured test application. But I guess they also behaves as Gtk.
-
it works well on all platforms. naming refined.
-
I have tried noCursurTyping feature of Win32 to be moved into Editor for supporting all platforms. macOS gives no blank cursor. This diff uses setHiddenUntilMouseMoves instead of custom blank cursor for macOS style But I saw custom blank cursor with transparent image works perfect either.
-
I'd like to implement noCursorTyping for Win, Gtk and Qt. I find it is simple to implement the feature in Editor.cxx.
-
Map invalid cursor to blank cursor.
-
Thank you for your instructions. Gtk patch attached according your instructions.
-
Thank you for your testing. I am sorry I did not catch it. patch attached:
-
code simplified. easier reading!
-
code simplified
-
reconvert key triggers CandidateBox to show up when quick phrase input on fcitx (or maybe accented input on mac) Demo: https://www.youtube.com/watch?v=2WfqPA9rHiI
-
We can handle preedit string in line as it is. Surrounding deleted should be blocked from reviving. bug : surrounding deleted revives https://youtu.be/H_XtMgslYcM solve : tentativeUndo in advance https://youtu.be/rlXIKl4CW7g
-
We can handle preedit string in line as it is. Surrounding deleted should be blocked from reviving. bug : surrounding deleted revives https://youtu.be/H_XtMgslYcM solve : tentativeUndo in advance https://youtu.be/rlXIKl4CW7g
-
surrounding code serialized. To do : 1. handle preedit string 2. set candidate box position 3. handle selection
-
update for 5.5.5
-
update for 5.3.6
-
This is different from what I have learned your instruction since. It is OK to close this thread.
-
Since the entire composition is a single target, the caret will be at the end with the onlyTarget branch but at the start if the patch is applied and the onlyTarget code removed. That is not true. https://youtu.be/Gc_jzPzVoyo Pressing reconvert (VK_HANJA) before the first character, EscapeHanja is called which selects the next character and shows the candidate box. That is just conversion, not reconversion. but this is not needed more discussion any more, unless the ime caret positon is respecte...
-
GCS_CURSORPOS is primary. but CS_NOMOVECARET is secondary. it really breaks the rule to ignore GCS_CURSORPOS.
-
the start of compStr by CS_NOMOVECARET. the start of the last character by no CS_NOMOVECARET. the position pointed by IME regardless of CS_NOMOVECARET. IME knows at which ime caret should be located. so for one caracter input, it must be the start of one compStr by CS_NOMOVECARET. for clause input, it must be the start of the last character by no CS_NOMOVECARET. But for korean ime, current code implement as this. If (CS_NOMOVECARET) { // do nothing } else { imeEndToImeCaretU16 += imc.GetImeCaretPos();...
-
The reason why I want reverting is exactly for There are a wide variety of IMEs and some may produce these cases now or with future updates. It is desirable to implement ime codes as simple as possible. We do not use GCS_COMPCLAUSE for ime attributes. We do not CS_INSERTCHAR to insert characters.
-
from https://github.com/ONLYOFFICE/desktop-sdk/blob/master/ChromiumBasedEditors/lib/src/cef/windows/tests/cefclient/browser/osr_ime_handler_win.cc ..... // **Retrieve the selection range information**. If CS_NOMOVECARET is specified // it means the cursor should not be moved and we therefore place the caret at // the beginning of the composition string. **Otherwise we should honour the // GCS_CURSORPOS value if it's available.** // TODO(suzhe): Due to a bug in WebKit we currently can't use selection...
-
from https://github.com/ONLYOFFICE/desktop-sdk/blob/master/ChromiumBasedEditors/lib/src/cef/windows/tests/cefclient/browser/osr_ime_handler_win.cc ..... // Retrieve the selection range information. If CS_NOMOVECARET is specified // it means the cursor should not be moved and we therefore place the caret at // the beginning of the composition string. Otherwise we should honour the // GCS_CURSORPOS value if it's available. // TODO(suzhe): Due to a bug in WebKit we currently can't use selection range...
-
if (!(lParam & CS_NOMOVECARET) && (lParam & GCS_CURSORPOS)) { imeEndToImeCaretU16 += imc.GetImeCaretPos(); } equals to : if (KoreanIME) { //do nothing } esle { imeEndToImeCaretU16 += imc.GetImeCaretPos(); } Why does it adopt discrimination? The comments does not give clear explanations.
-
if (!(lParam & CS_NOMOVECARET) && (lParam & GCS_CURSORPOS)) { imeEndToImeCaretU16 += imc.GetImeCaretPos(); } equals to : if (KoreanIME) { //do nothing } esle { imeEndToImeCaretU16 += imc.GetImeCaretPos(); } Why does it adopt discrimination?
-
A user can not see any actual problem. But an implementer should catch hidden problems. Here are same effect for korean on imm32. ime caret is located at: 1. the start of compStr. 2. the start of the last charecter. 3. the position pointed by imm32. I think 3 is right behavior. Previous code 3 did show any actual problem to user neither. but current code selects 1 with a discriminative cause. This is not simplication, but reverting with a right cause.
-
Candidate window position gets now related with user's preference. I feel it looks not bad visually while playing with japannes input. In addition, less code feels me comfortable.
-
Your question confirms current code should be reverted. It compromises readability. On korean ime, imc.GetImeCaretPos() should return the start position of the last character for imeblokcaretoverride regardless of CS_NOMOVECARET. If CS_NOMOVECARET, then imc.GetImeCaretPos() returns 0 which is the start position of the last character. Even If not CS_NOMOVECARET, it also returns the start position of the last character. Current code exploits imc.GetImeCaretPos() absolutely is 0 when CS_NOMOVECARET...
-
Fix candidate window position at the start of preedit string. remove2ndCand.patch was submitted.
-
I am sorry I missed the if(onlyTarget) check. It is a really headache. While I have struggled with TSF, I have realized fixing candidate window position is practically not bad. TSF appears to adopt this policy. Some imes such as chinese or korean may use block indicator for normal input. In this case, chinese input might suffers. the less code, the more stable code. So I would like to suggest fixing once at the start of preedit string. But If you want dynamic moveing, I will follow your policy.
-
patch for win32 attached
-
Thank you for allowing to change the signature. I follow your instruction. patch attached.
-
I will follow your policy. Scintilla ime has a policy to fix candidate window position at the start of preedit string. So remove 2nd SetCandidateWindowPos() on win32 and Qt to follow Scintilla Gtk. patch attached
-
If there is no rebuke, I will continue on reverting.
-
I do not use anthy which behaviors abnormaly. fcitx5-anthy always returns 0 for ime caret position. I am sorry I give up ibus. Now my model reference is scintilla ime itself. On lubuntu23.04 Xorg. fcitx5-Mozc japanese on current code, Fix candidate position at the start of preedit string for chinese https://www.youtube.com/watch?v=OToK3i7jA58 on patch code, Set again candidate position at the start of block input for japanese. https://www.youtube.com/watch?v=5QfQ7v1_Otc
-
Korean Ime reconversion can not syncronize with the internal state of IMM32.
-
Now 2nd SetCandidateWindowPos() moves ut of "if check" Let us take a close look at "if check" inside. What if imeEndToImeCaretU16 is 0 ? Then pdoc->GetRelativePositionUTF16(currentPos, 0); So currentPos equals to imeCaretPosDoc And then MoveImeCarets(0); There is no moving, just addition and subtraction!. In addition, Within void ScintillaWin::MoveImeCarets(Sci::Position offset) if offset is 0, then there is still no caret moving. I do not check if offset is 0. since benifits of speed is negligible....
-
My blob is making Gtk Ime input style be consistent with win32 But I do not insist. I will follow your policy.
-
Candidate window should be located at ime caret. 2nd SetCandidateWindowPos follows ime caret. You should not try to control the ime caret. It breaks scintilla ime from syncronizing with the internal state of IMM32. I have had a hard time catching up with the recent bugs with TSF. On the while, I managed to figure out what the purpose of 3 if checks is. I wll continue on reverting the rest if (!onlyTarget) block with causes.
-
The above link has no discussion why 2nd SetCandidateWindowPos() should be inside "if (imeEndToImeCaretU16 != 0) block".
-
https://sourceforge.net/u/madpilot78/scintilla/ci/59f3c5ced2e22c4ab05082ada5cd356e13c16633/ 1. The above commit cases another bug to candidate box position. There is no handling for target input by just moving SetCandidateWindowPos(). The SetCandidateWindowPos() moved into not relevant position between - if (initialCompose) ClearBeforeTentativeStart(); pdoc->TentativeStart(); // TentativeActive() from now on I intentionaly do not use { } for another statments not to be inserted since they are closely...
-
Move SetCandidateWindowPos() out of if (imeEndToImeCaretU16 != 0) block.
-
One line code expects any value IMM32 can return. If CS_NOMOVECARET is intruduced, it should depends on that imc.GetImeCaretPos() return zero when (lParam & GCS_CURSORPOS) is zero.
-
The more if checks, the more difficult to debug, the less we are sure that we are right. One liner can give sure that we are right.
-
This is not about simplication, but about reverting. Why does one line need to expand five lines? Maybe the cause is what the comments give. But the comments do not give any excuse and is deceptive to code readers. The real behivor of the codes expanded I found is to filter korean ime out and to discriminate it. Currntly korean ime is blind not to know its ime caret position while other imes do. The codes expanded are very rude for korean.
-
It is too bad you assume the original code as wrong. what can I say about?
-
Korean Ime move its caret blindly.
-
Korean Ime move its caret blindly.
-
Korean Ime move its caret blindly.
-
Korean Ime move its caret blindly.
-
What a good idea! How can you do that?
-
**It turns out visual flashing is not a bug, ** Only Notify save point while first composition turns out to be a correct behavior. The purpose of delayedSavePoint is not fixing visual flashing while first composition. So It is desirable to create a theread with a relevant title and continue on.
-
Here is my report. https://groups.google.com/g/scintilla-interest/c/iJGRJacb8zI
-
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.
-
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.
-
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.
-
please be specific. I want to reproduce the case.
-
There is no unnecessary ime caret moving! How complicated, inefficent! There add two buggy if check and one unnecessary if check.
-
What benefits does japanese ime get from csnomovecaret?
-
I appreciate you for your hard works. I submit a patch for Qt.
-
So I follow your idea redrawPendingText.
-
I use SciTEGtk to test this. Is this something different? --- preeditStr:'w' --- savePoint: 0, currentAction: 0 savePoint: 0, currentAction: 2 savePoint: 0, currentAction: 0 tentativeSteps: 0, startSavePoint: 0, endSavePoint: 1 :Tentative NotifySavePoint: --- preeditStr:'wo' --- savePoint: 0, currentAction: 0 savePoint: 0, currentAction: 2 savePoint: 0, currentAction: 3 savePoint: 0, currentAction: 0 tentativeSteps: 0, startSavePoint: 0, endSavePoint: 1 :Tentative NotifySavePoint: --- preeditStr:'wo...
-
do not redraw while TentativeActive as redrawPendingText. patch proposed
-
It turns out NotifySavePoint() never be performed except for initial TentativeUndo. It seems Ok to Remove NotifySavePoint() from TentativeUndo(). initial TentativeUndo() compStr should not influence on title bar since that is tentative and should be treated none.
-
Composing 'ㅎ' tentativeSteps: 0, startSavePoint: 0, endSavePoint: 1 :::NotifySavePoint::: Composing '하' tentativeSteps: 0, startSavePoint: 0, endSavePoint: 1 :::NotifySavePoint::: Composing '한' tentativeSteps: 0, startSavePoint: 0, endSavePoint: 1 :::NotifySavePoint::: Composing '한ㄱ' tentativeSteps: 0, startSavePoint: 0, endSavePoint: 1 :::NotifySavePoint::: Composing '한그' tentativeSteps: 0, startSavePoint: 0, endSavePoint: 1 :::NotifySavePoint::: Composing '한글' -----------------------Commit :'한글'----------------------...
-
It seems reasonable that pendingUpdate be renamed to IsCompStrExist. You apply !pendingUpdate so NotifySavePoint(endSavePoint) always is performed only when !IsCompStrExist. That is, while in composition No NotifySavePoint except for empty compStr.
-
sorry! Test to be required patch attached
-
A function Shoud have only one function according its name.
-
Is it already fixed? Try it without your patch.
-
tidy up
-
tidy up links
-
I revoke the patch. sorry! misunderstood.
-
Respect SPI_GETMOUSEVANISH from OS
-
Inspired from sakura editor. patch added:
-
add link to english site
-
correct translated links
-
translate lexilla site to korean.
-
update for 5.3.5
-
address window : legacy Ime search window : using TSF
-
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?
-
add documentation about ime support. patch attached.
-
This bug for geany is solved by selecting inline ime. https://github.com/geany/geany/issues/2760 I would like to add documentation about Ime support for scintilla. Please feel in X for macOS which I have not.
-
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...
-
I did not know https://sourceforge.net/p/scintilla/code/ci/1249076f3f8ee683917afb7cd3570e6faee051f3/ My development enviroment and history went off 5years ago. So I reimplemented this from scratch. It becomes like revert. I have to find problems for Qt, Gtk patches.
-
Now it seems to work good to input thai language.
-
implemented by Colomban Wendling https://sourceforge.net/p/scintilla/feature-requests/1476/
-
I can not tell the difference. same as Neil. https://groups.google.com/g/scintilla-interest/c/A6Rhbg7JP7c
-
Code simplified.
-
add ime history for gtk
1 >
