There is an issue with NppExec when Notepad++ is used under Wine in Linux: When one double-clicks on a line in the NppExec console which contains a file and line number to be opened (as detected using "Console Output Filters"), the file and line get opened in Notepad++, but Notepad++ crashes immediately afterwards due to an "unhandled exception".
Please enable NppExec's file logging and paste or attach the lines you'll see under the line "; Console's line double-clicked" here. It will help to localize the error.
To enable NppExec's file logging, refer to the file "Notepad++\plugins\doc\NppExec_TechInfo.txt", the description of "LogsDir".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the late reply. I just never got any response notification. Unfortunately, the "; Console's line double-clicked" line does not exist in the log. Here is what is in the log:
Notepad++ gets started:
Log start >>
; CNppExec::ReadOptions - start
; CNppExec::ReadOptions - end
; NPPN_READY - start
; NPPN_READY - end
The command to read in the file content gets executed:
; @Input Command: cmd /c type C:\NppExec\output.txt
; CScriptEngine::Run - start
; command info
Current command item: p = 0xEBC168
{
_item = "cmd /c type C:\NppExec\output.txt"
_prev = 0x0
_next = 0x0
_owner = 0xE9C604
}
; executing ModifyCommandLine
ModifyCommandLine()
{
[in] "cmd /c type C:\NppExec\output.txt"
GetCmdType()
{
[in] "cmd /c type C:\NppExec\output.txt"
CheckCmdAliases()
{
; command aliases enabled
[in] "cmd /c type C:\NppExec\output.txt"
[out] "cmd /c type C:\NppExec\output.txt"
}
[ret] 0x0 (unknown)
}
CheckCmdArgs()
{
[in] "cmd /c type C:\NppExec\output.txt"
[out] "cmd /c type C:\NppExec\output.txt"
}
CheckNppMacroVars()
{
[in] "cmd /c type C:\NppExec\output.txt"
[out] "cmd /c type C:\NppExec\output.txt"
}
CheckPluginMacroVars()
{
[in] "cmd /c type C:\NppExec\output.txt"
[out] "cmd /c type C:\NppExec\output.txt"
}
CheckUserMacroVars()
{
[in] "cmd /c type C:\NppExec\output.txt"
[out] "cmd /c type C:\NppExec\output.txt"
}
CheckEmptyMacroVars()
{
[in] "cmd /c type C:\NppExec\output.txt"
; the function is enabled
[out] "cmd /c type C:\NppExec\output.txt"
}
; command argument(s):
[out] "cmd /c type C:\NppExec\output.txt"
; command type:
[ret] 0x0
}
; starting child process "cmd /c type C:\NppExec\output.txt"
<MSG> cmd /c type C:\NppExec\output.txt
<MSG> Process started >>>
<OUT> C:\NppExec\test.txt:2: whatever
<MSG> <<< Process finished. (Exit code 0)
; child process finished
; CScriptEngine::Run - end
<MSG> ================ READY ================
The "C:\NppExec\test.txt:2: whatever" line gets double-clicked - the "C:\NppExec\test.txt" file gets opened correctly on line 2 in Notepad++, but Notepad++ crashes immediately (an "unhandled exception" crash notification appears):
nppConvertToFullPathName()
{
[in] "C:\NppExec\test.txt"
; already full path
}
; CNppExec::SaveOptions - start
; CNppExec::SaveOptions - end
Log exit.
That's all there is in the log. Does this help in any way, or could I check something else?
P.S.: This is with the current Notepad++ v6.9.1 and NppExec_053_dll_Unicode.zip. It asks if one wants to save a dump file, which I did - see attached. (It can be opened in a hex viewer.)
Do I understand correctly that you don't have strings "; Console\'s line double-clicked" and "; WarningAnalyzer info" in the log?
If so, could you type inside NppExec's Console:
npe_debug 1
and then double-click any line in the Console? I'm wondering whether you'll be able to see "; Console\'s line double-clicked" in that case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please see the response below (just in case you don't get thread update notifications, which is the case with me; although I don't know how it is with direct replies either) :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do I understand correctly that you don't have strings "; Console\'s line double-clicked" and "; WarningAnalyzer info" in the log?
If so, could you type inside NppExec's Console:
npe_debug 1
and then double-click any line in the Console? I'm wondering whether you'll be able to see "; Console\'s line double-clicked" in that case.
Yes, with "npe_debug 1" I now get following in the log file (and the console) when double-clicking on the line to open it in Notepad++:
; Console's line double-clicked
; WarningAnalyzer info
; {
; Input line: "C:\NppExec\test.txt:2: whatever"
; Match result: true
; Active filter: "%FILE%:%LINE%:*"
; * Parsed File Name: "C:\NppExec\test.txt"
; * Parsed Line Number: 2
; * Parsed Char Position: <none>
; }
nppConvertToFullPathName()
{
[in] "C:\NppExec\test.txt"
; already full path
}
And then following when one confirms/denies the Notepad++ dump creation before it closes:
; CNppExec::SaveOptions - start
; CNppExec::SaveOptions - end
Log exit.
Additionally, I now started Notepad++ from within a terminal (command line), to see what Wine reports executing it:
On start (with the NppExec console closed) (those "fixme" messages ususally have no effect, but show what's not yet implemented in Wine, I guess):
Please note the bold point with the assertion failure above. It seems to be related to the issue.
Please let me know if you need more details. Thanks!
P.S.: Attaching a screenshot of the crash (without "npe_debug 1"). As can be seen, the "test.txt" gets opened on the line 2 correctly, after which the crash occurs. (The content of "output.txt" with its "whatever" on line 2 doesn't correspond to "test.txt", but it shouldn't matter - both were created manually for the test.)
Why it could happen, I don't know.
NppExec processes EN_MSGFILTER notification from RichEdit, and what it does for WM_LBUTTONDBLCLK is:
1. opens a file in Scintilla (NPPM_DOOPEN)
2. sets line and pos in Scintilla (SCI_GOTOLINE, SCI_GOTOPOS)
3. sets focus to Scintilla via SetFocus()
4. sets MSGFILTER.msg to 0 and returns 0
Maybe the assertion fails because the focus goes from the RichEdit to Scintilla while processing EN_MSGFILTER from the RichEdit? It would be strange...
Is there a way to debug NppExec under Wine? (I mean, are you aware if it is possible, and could you do it on your side? Because I don't have any Linux or Unix and know very little about it.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe the assertion fails because the focus goes from the RichEdit to Scintilla while processing EN_MSGFILTER from the RichEdit? It would be strange...
Is there a way to debug NppExec under Wine? (I mean, are you aware if it is possible, and could you do it on your side? Because I don't have any Linux or Unix and know very little about it.)
I don't know much about it either, actually. But there is, e.g., https://www.winehq.org/docs/winedev-guide/wine-debugger#AEN307 , which, according to its own help, accepts a "reasonable subset of the commands that gdb accepts". And there is quite a lot of documentation on Wine debugging. I could try that. Could you please point me at the affected part of the NppExec code? (I hope it's DLL contains all the symbols. And I've never debugged a PC program, just some embedded stuff ages ago, so I'll see how it goes. :) )
Update: Never mind, I forgot that you already provided the execution steps. I found that in ConsoleDlg::GoToLineIfWarningAnalyzerMatch() in /NppExec_053_src/NppExec/src/DlgConsole.cpp. I'll check that.
Thanks!
Last edit: MM 2016-04-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. I haven't been able to debug Notepad++ or NppExec properly. I guess I would need to compile them to contain debugger symbols (cross-compiling them on Linux for Windows). That would need time and may go above my head.
I logged a sort of a Wine "trace" with the Wine debugger though, from around the time right before the NppExec console double-click till some time after the appearance of the exception notification. It's a lot of data though - a lot of things are traced. I'm attaching the file. The assertion failure line:
can be found there. As well as the SetFocus() calls some time before it. Although, the calls don't tell me anything, since I have no experience with Windows programming. Maybe someone familiar with it can make sense of it though.
2. On the other hand, Notepad++ has built-in modules which open a file in it in a similar way:
"Find in Files" results pane
"Function List"
"Document Map" (which can be clicked somewhere and the current document will be scrolled to the affected area)
The latter two don't switch focus to the main Notepad++ pane though, I guess by design - e.g. the keyboard keys can be used to jump to functions beginning with the respective letter. All of those work fine in Wine as far as file opening is concerned (although the "Document Map" doesn't show the minified file content in itself - just a white background).
P.S.: It looks like the "Document Map" was a bad example. It does show the minified file content in it, but it seems to be done after some trigger (tab switching works) instead of right on opening the "Document Map". But then the orange "current position" band disappears and its pane works just like a text pane, without the ability to switch file position by clicking on it. Anyway, it's a different topic and I've never used it.
The "Find in Files" results pane works without problems though. I use it quite often. The search is just slow under Wine, compared to native tools. Which is exactly why I wanted to use NppExec: To use the native "grep" command line tool (ca. 10 times faster) for search, and process its output with NppExec, like one does, e.g., with a compiler output.
Last edit: MM 2016-04-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I logged a sort of a Wine "trace" with the Wine debugger though, from around the time right before the NppExec console double-click till some time after the appearance of the exception notification. It's a lot of data though - a lot of things are traced. I'm attaching the file. The assertion failure line:
can be found there. As well as the SetFocus() calls some time before it. Although, the calls don't tell me anything, since I have no experience with Windows programming. Maybe someone familiar with it can make sense of it though.
I'm attaching another Wine trace log. While the previous one was created (using a pipe) with:
WINEDEBUG=+relay,+snoop wine notepad++.exe
this one logs all debug channels (i.e. including Richedit, etc.) as follows:
WINEDEBUG=+all wine notepad++.exe
To 2:
This point is probably moot, because the failure seems to be due to a wrapping issue in Richedit, not in Scintilla.
Sorry for being non-replying, I'm in the process of migrating to a new hardware. I think I'll provide a debug version of NppExec for these experiments - maybe it will help to identify the exact call stack that corresponds to the issue. The Wine logs show a lot of WinAPI calls, but I don't understand what is the connection between these WinAPI calls and the code within NppExec.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem at all as far as reply time is concerned and thank you very much for the debug version!
I've been able to log the exception stack trace containing the symbols (and affected file and line numbers) of both, Wine and NppExec (stack frames 14 and 30). Please find it attached. (Wine's files and line numbers refer to the current Wine 1.9.8 release.) Please let me know if you need more details.
I other news, I've been pointed out a work-around in the above Wine bug report: There is a script called Winetricks, which can be used to replace Wine's implementation of Windows DLLs with original ones by Microsoft. So that, when that is done for RichEdit ("riched20"), the issue disappears.
So, I don't know. Given the workaround, I would say that, if there could be a change to NppExec, which would fix this issue while improving NppExec's overall stability (also on Windows), then feel free to make it and I would be glad to test it. Otherwise, if the fix would be a "hack" you woudn't be happy about, then I could go with the workaround instead. (And wait for it to be fixed in Wine maybe.)
Hmm, it looks like the issue is related to RichEdit itself and not to NppExec then. Other plugins or the "Find In Files" results pane differ from NppExec by simply by that fact they do not use a RichEdit control. (NppExec includes a lot of code around RichEdit control that is a part of its Console window. Basically all the Console's window output and input is controlled by deep interaction with RichEdit control. I was weighing if it would be worth to try to replace RichEdit control in the Console window with Scintilla... but it will require a lot of changes - and I'm also not sure I would get the same level of control over Scintilla as I have with RichEdit. So I wouldn't consider such change.) I'm not sure if there can be any other "hacks" to do...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for the analysis and all the feedback. I would say that such a change (or search for other "hacks") for the sake of Wine is not worth it. Especially because there is an easy workaround available. We've been able to localize the issue in the Wine's RichEdit implementation - that has been a great support by you already!
Thank you again for all that and for your work on the NppExec plugin! I truelly appreciate it and consider this thread closed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is an issue with NppExec when Notepad++ is used under Wine in Linux: When one double-clicks on a line in the NppExec console which contains a file and line number to be opened (as detected using "Console Output Filters"), the file and line get opened in Notepad++, but Notepad++ crashes immediately afterwards due to an "unhandled exception".
The detailed issue description and backtrace dumps (as attachments) can be found in https://bugs.winehq.org/show_bug.cgi?id=39293 .
Could this be an issue related to some non-standard API or DLL handling by NppExec?
Notepad++ itself works fine under Wine. The only issue with it I personally have come across is "Notepad++ freezes if native application changes a file it has open" reported in https://bugs.winehq.org/show_bug.cgi?id=11595 , but there is a workaround described in https://bugs.winehq.org/show_bug.cgi?id=11595#c32 . A general compatibility overview can be found in https://appdb.winehq.org/objectManager.php?sClass=version&iId=25722 .
Last edit: MM 2016-04-22
Please enable NppExec's file logging and paste or attach the lines you'll see under the line "; Console's line double-clicked" here. It will help to localize the error.
To enable NppExec's file logging, refer to the file "Notepad++\plugins\doc\NppExec_TechInfo.txt", the description of "LogsDir".
Sorry for the late reply. I just never got any response notification. Unfortunately, the "; Console's line double-clicked" line does not exist in the log. Here is what is in the log:
; @Input Command: cmd /c type C:\NppExec\output.txt ; CScriptEngine::Run - start ; command info Current command item: p = 0xEBC168 { _item = "cmd /c type C:\NppExec\output.txt" _prev = 0x0 _next = 0x0 _owner = 0xE9C604 } ; executing ModifyCommandLine ModifyCommandLine() { [in] "cmd /c type C:\NppExec\output.txt" GetCmdType() { [in] "cmd /c type C:\NppExec\output.txt" CheckCmdAliases() { ; command aliases enabled [in] "cmd /c type C:\NppExec\output.txt" [out] "cmd /c type C:\NppExec\output.txt" } [ret] 0x0 (unknown) } CheckCmdArgs() { [in] "cmd /c type C:\NppExec\output.txt" [out] "cmd /c type C:\NppExec\output.txt" } CheckNppMacroVars() { [in] "cmd /c type C:\NppExec\output.txt" [out] "cmd /c type C:\NppExec\output.txt" } CheckPluginMacroVars() { [in] "cmd /c type C:\NppExec\output.txt" [out] "cmd /c type C:\NppExec\output.txt" } CheckUserMacroVars() { [in] "cmd /c type C:\NppExec\output.txt" [out] "cmd /c type C:\NppExec\output.txt" } CheckEmptyMacroVars() { [in] "cmd /c type C:\NppExec\output.txt" ; the function is enabled [out] "cmd /c type C:\NppExec\output.txt" } ; command argument(s): [out] "cmd /c type C:\NppExec\output.txt" ; command type: [ret] 0x0 } ; starting child process "cmd /c type C:\NppExec\output.txt" <MSG> cmd /c type C:\NppExec\output.txt <MSG> Process started >>> <OUT> C:\NppExec\test.txt:2: whatever <MSG> <<< Process finished. (Exit code 0) ; child process finished ; CScriptEngine::Run - end <MSG> ================ READY ================nppConvertToFullPathName() { [in] "C:\NppExec\test.txt" ; already full path } ; CNppExec::SaveOptions - start ; CNppExec::SaveOptions - end Log exit.That's all there is in the log. Does this help in any way, or could I check something else?
P.S.: This is with the current Notepad++ v6.9.1 and NppExec_053_dll_Unicode.zip. It asks if one wants to save a dump file, which I did - see attached. (It can be opened in a hex viewer.)
Last edit: MM 2016-04-22
Do I understand correctly that you don't have strings "; Console\'s line double-clicked" and "; WarningAnalyzer info" in the log?
If so, could you type inside NppExec's Console:
and then double-click any line in the Console? I'm wondering whether you'll be able to see "; Console\'s line double-clicked" in that case.
This is what expected to be seen in the Console in that case:
npe_debug 1 NPE_DEBUGLOG: 1 Debug Log is On (1) ; CScriptEngine::Run - end ================ READY ================ ; Console's line double-clicked ; WarningAnalyzer info ; { ; Input line: "Debug Log is On (1)" ; Match result: true ; Active filter: "%FILE%(%LINE%)*" ; * Parsed File Name: "Debug Log is On" ; * Parsed Line Number: 1 ; * Parsed Char Position: <none> ; } nppConvertToFullPathName() { [in] "Debug Log is On" }Please see the response below (just in case you don't get thread update notifications, which is the case with me; although I don't know how it is with direct replies either) :)
Yes, with "npe_debug 1" I now get following in the log file (and the console) when double-clicking on the line to open it in Notepad++:
; Console's line double-clicked ; WarningAnalyzer info ; { ; Input line: "C:\NppExec\test.txt:2: whatever" ; Match result: true ; Active filter: "%FILE%:%LINE%:*" ; * Parsed File Name: "C:\NppExec\test.txt" ; * Parsed Line Number: 2 ; * Parsed Char Position: <none> ; } nppConvertToFullPathName() { [in] "C:\NppExec\test.txt" ; already full path }And then following when one confirms/denies the Notepad++ dump creation before it closes:
Additionally, I now started Notepad++ from within a terminal (command line), to see what Wine reports executing it:
Please note the bold point with the assertion failure above. It seems to be related to the issue.
Please let me know if you need more details. Thanks!
P.S.: Attaching a screenshot of the crash (without "npe_debug 1"). As can be seen, the "test.txt" gets opened on the line 2 correctly, after which the crash occurs. (The content of "output.txt" with its "whatever" on line 2 doesn't correspond to "test.txt", but it shouldn't matter - both were created manually for the test.)
Last edit: MM 2016-04-22
This seems to come from Wine (at least, it's definitely not a part of NppExec or Notepad++):
Why it could happen, I don't know.
NppExec processes EN_MSGFILTER notification from RichEdit, and what it does for WM_LBUTTONDBLCLK is:
1. opens a file in Scintilla (NPPM_DOOPEN)
2. sets line and pos in Scintilla (SCI_GOTOLINE, SCI_GOTOPOS)
3. sets focus to Scintilla via SetFocus()
4. sets MSGFILTER.msg to 0 and returns 0
Maybe the assertion fails because the focus goes from the RichEdit to Scintilla while processing EN_MSGFILTER from the RichEdit? It would be strange...
Is there a way to debug NppExec under Wine? (I mean, are you aware if it is possible, and could you do it on your side? Because I don't have any Linux or Unix and know very little about it.)
Thank you very much for the feedback!
I don't know anything about that. But I checked in the Wine sources and the assertion seems to be within Wine's RichEdit implementation, in https://github.com/wine-mirror/wine/blob/wine-1.8/dlls/riched20/caret.c#L231 , which is called in the same file in https://github.com/wine-mirror/wine/blob/wine-1.8/dlls/riched20/caret.c#L277 . While the flag it asserts against is defined in https://github.com/wine-mirror/wine/blob/wine-1.8/dlls/riched20/editstr.h#L143 as follows:
Does that ring a bell by any chance?
On a side note, I tested and the issue occurs on the latest (unstable-branch) Wine 1.9.8 as well. That part didn't change ( https://github.com/wine-mirror/wine/blob/wine-1.9.8/dlls/riched20/caret.c#L230 ).
I don't know much about it either, actually. But there is, e.g., https://www.winehq.org/docs/winedev-guide/wine-debugger#AEN307 , which, according to its own help, accepts a "reasonable subset of the commands that gdb accepts". And there is quite a lot of documentation on Wine debugging. I could try that. Could you please point me at the affected part of the NppExec code? (I hope it's DLL contains all the symbols. And I've never debugged a PC program, just some embedded stuff ages ago, so I'll see how it goes. :) )
Update: Never mind, I forgot that you already provided the execution steps. I found that in
ConsoleDlg::GoToLineIfWarningAnalyzerMatch()in /NppExec_053_src/NppExec/src/DlgConsole.cpp. I'll check that.Thanks!
Last edit: MM 2016-04-22
1.I haven't been able to debug Notepad++ or NppExec properly. I guess I would need to compile them to contain debugger symbols (cross-compiling them on Linux for Windows). That would need time and may go above my head.I logged a sort of a Wine "trace" with the Wine debugger though, from around the time right before the NppExec console double-click till some time after the appearance of the exception notification. It's a lot of data though - a lot of things are traced. I'm attaching the file. The assertion failure line:
can be found there. As well as the
SetFocus()calls some time before it. Although, the calls don't tell me anything, since I have no experience with Windows programming. Maybe someone familiar with it can make sense of it though.2.On the other hand, Notepad++ has built-in modules which open a file in it in a similar way:The latter two don't switch focus to the main Notepad++ pane though, I guess by design - e.g. the keyboard keys can be used to jump to functions beginning with the respective letter. All of those work fine in Wine as far as file opening is concerned (although the "Document Map" doesn't show the minified file content in itself - just a white background).
So, maybe the file opening used in those could be re-used in a plugin like NppExec? E.g., for the "Find in Files" results it seems to be done in
Finder::GotoFoundLine()in https://github.com/notepad-plus-plus/notepad-plus-plus/blob/v6.9.1/PowerEditor/src/ScitillaComponent/FindReplaceDlg.cpp#L442 . That seems to also take care of wrapping problems (according to its comment in https://github.com/notepad-plus-plus/notepad-plus-plus/blob/v6.9.1/PowerEditor/src/ScitillaComponent/FindReplaceDlg.cpp#L193 ), which could be what the Wine exception is about (see theMEPF_REWRAPdefinition in my previous post).Last edit: MM 2016-04-23
P.S.: It looks like the "Document Map" was a bad example. It does show the minified file content in it, but it seems to be done after some trigger (tab switching works) instead of right on opening the "Document Map". But then the orange "current position" band disappears and its pane works just like a text pane, without the ability to switch file position by clicking on it. Anyway, it's a different topic and I've never used it.
The "Find in Files" results pane works without problems though. I use it quite often. The search is just slow under Wine, compared to native tools. Which is exactly why I wanted to use NppExec: To use the native "grep" command line tool (ca. 10 times faster) for search, and process its output with NppExec, like one does, e.g., with a compiler output.
Last edit: MM 2016-04-23
To the two points in my post above:
To 1:
I'm attaching another Wine trace log. While the previous one was created (using a pipe) with:
this one logs all debug channels (i.e. including Richedit, etc.) as follows:
To 2:
This point is probably moot, because the failure seems to be due to a wrapping issue in Richedit, not in Scintilla.
Last edit: MM 2016-04-24
Sorry for being non-replying, I'm in the process of migrating to a new hardware. I think I'll provide a debug version of NppExec for these experiments - maybe it will help to identify the exact call stack that corresponds to the issue. The Wine logs show a lot of WinAPI calls, but I don't understand what is the connection between these WinAPI calls and the code within NppExec.
Please find the debug version of NppExec attached.
No problem at all as far as reply time is concerned and thank you very much for the debug version!
I've been able to log the exception stack trace containing the symbols (and affected file and line numbers) of both, Wine and NppExec (stack frames 14 and 30). Please find it attached. (Wine's files and line numbers refer to the current Wine 1.9.8 release.) Please let me know if you need more details.
I other news, I've been pointed out a work-around in the above Wine bug report: There is a script called Winetricks, which can be used to replace Wine's implementation of Windows DLLs with original ones by Microsoft. So that, when that is done for RichEdit ("riched20"), the issue disappears.
So, I don't know. Given the workaround, I would say that, if there could be a change to NppExec, which would fix this issue while improving NppExec's overall stability (also on Windows), then feel free to make it and I would be glad to test it. Otherwise, if the fix would be a "hack" you woudn't be happy about, then I could go with the workaround instead. (And wait for it to be fixed in Wine maybe.)
Thanks!
Last edit: MM 2016-04-26
Let's try whether the attached version has this problem.
Last edit: DV 2016-04-29
Thanks for the test version!
Yes, it still has. Although NppExec no longer appears in the stack trace. Please find it attached.
Hmm, it looks like the issue is related to RichEdit itself and not to NppExec then. Other plugins or the "Find In Files" results pane differ from NppExec by simply by that fact they do not use a RichEdit control. (NppExec includes a lot of code around RichEdit control that is a part of its Console window. Basically all the Console's window output and input is controlled by deep interaction with RichEdit control. I was weighing if it would be worth to try to replace RichEdit control in the Console window with Scintilla... but it will require a lot of changes - and I'm also not sure I would get the same level of control over Scintilla as I have with RichEdit. So I wouldn't consider such change.) I'm not sure if there can be any other "hacks" to do...
Thank you very much for the analysis and all the feedback. I would say that such a change (or search for other "hacks") for the sake of Wine is not worth it. Especially because there is an easy workaround available. We've been able to localize the issue in the Wine's RichEdit implementation - that has been a great support by you already!
Thank you again for all that and for your work on the NppExec plugin! I truelly appreciate it and consider this thread closed.