Closed ProgerXP closed 4 years ago
There were some changes in Scintilla engine related to processing of SCI_WORDSTARTPOSITION and SCI_WORDENDPOSITION messages which caused different result values comparing current Scintilla v3.11.2 vs previous versions.
These results are utilized in n2e_SelectionGetWord()
to initializing the length of currently selected word.
if (0 == sel_len)
{
trEditSelection.chrg.cpMin = SendMessage(hwndEdit, SCI_WORDSTARTPOSITION, cpos, TRUE);
trEditSelection.chrg.cpMax = SendMessage(hwndEdit, SCI_WORDENDPOSITION, cpos, TRUE);
sel_len = trEditSelection.chrg.cpMax - trEditSelection.chrg.cpMin;
bEditSelectionWholeWordMode = TRUE;
}
What exactly changed with these two messages?
What exactly changed with these two messages?
N/A. This is a part of internal logic related to how different chars should be treated as a part of word:
These messages return the start and end of words using the same definition of words as used internally within Scintilla
PS It looks like there were some changes of word definition in terms of Scintilla engine.
PS It looks like there were some changes of word definition in terms of Scintilla engine.
I see. Are we using any functions that rely on Scintilla's definition of "word" outside of the Highlight Word feature?
Are we using any functions that rely on Scintilla's definition of "word" outside of the Highlight Word feature?
Find Next/Previous Word
command rely on the same calls. At this point I see no other word dependent features.
Highlight Word has a hardcoded limit to only highlight words longer than 1 byte (not 1 character). As a result, in the previously released version, words consisting of a single multibyte character (e.g. dash "—" in UTF-8, as opposed to "z") were highlighted. In the new version some of them are no longer highlighted ("—" is not, "я" is) which is double strange.
This was not explicitly required by any task as far as I remember. Please determine what caused this change.
Related: #286