New (incomplete) LSP client plugin
-
This sounds like Rust is not part of your Notepad++ setup because keyword coloring is done by Npp/Scintilla and is not part of the language server protocol and if that is the case, then the NppLspClient plugin will not work with Rust files.
So what does the NppLspClient plugin do?
When loading the plugin, it checks if the configuration file is available and if not, it creates the minimal version where no servers are available. Currently, users have to manually configure the servers they want to use.
When activating a buffer, the plugin checks whether the language of the current buffer is configured in the configuration file. If it finds a corresponding section, it checks whether the FolderAsWorkspace (FAW) dialog has entries, and if it finds something, it remembers its root node. If the server is to be started automatically, it checks whether the current file belongs to one of the root nodes of the FAW dialog. If this is the case, this root node path is used to initialize the configured server; if this is not the case, the current directory is used instead. An attempt is then made to start the process. That’s it, and the success or failure can be displayed in the console dialog.
If this does not solve your problem, you are welcome to open a request in the NppLspClient github repo and attach the log entries together with your configuration for further investigation.
-
May I ask that one of the moderators change the title of this post to
New (incomplete) LSP client pluginSince version v.0.0.30 a 32bit plugin is also available.
Thank you very much.
-
Thank you for renaming the title.
-
P PeterJones forked this topic on
-
-
I am looking for the reason for a phenomenon where I am slowly running out of ideas and would be grateful for any ideas.
Background: It can happen that Notepad++ does not start when the NppLspClient plugin is used and Notepad++ is run in dark mode. In light mode I, and also the user who reported this, can never see this. Even my normal Npp installation, which I use daily and has always run in dark mode, does not show this behavior. I can currently only reproduce this with a separate Npp installation and even then not always. It also only seems to occur when an Npp release version is used, I have also not been able to reproduce the problem via the Visual Studio debugger. I have implemented a stack tracer in the plugin but unfortunately I cannot recognize any pattern. The error that is reported is 0xc0000374 (heap corruption) which doesn’t make it any easier to find the reason as the heap was probably already corrupted long before the exception. And with two traces I have several DllMain calls in different frames (???).
If my plugin corrupts the heap, why only when dark mode is active? And why can’t I see this at least sometimes with my normal npp installation?
I’m confused. :( -
Issue solved in version v.0.0.33
-
(in reply to this post)
I do not experience such a problem.
Beware that while the WINAPIs in your callstack screenshot seem to be decoded properly (is it the PH SW?), the N++ calls are not. So the immediate calls visible are response for calling the GetProp, but the N++ source origin (callstack frame No. 4) is most probably wrong. You need to build your own N++ (Debug or Release, it does not matter, but with the PDB-symbols generated!) and then repeat your callstack revealing steps.
-
Hello @xomx,
Thank you for the response.The screenshot shows the sysinternals Process Explorer with symbol files loaded from a recent Notepad++ release build.
The tldr is that I need to figure out why my plugin is suddenly receiving a bunch of
5001 (SC_WIN_IDLE) messages in 2 of 4 dialogs that have the Scintilla control embedded.The more detailed version.
The LspPlugin has 4 dock-able dialogs that all use the Scintilla control.
None of them currently have a lexer active, but are colored via the SCI_ADDSTYLEDTEXT message.
2 Dialogs, Diagnostics and References show the unusual behavior that theya) receive SC_WIN_IDLE messages and
b) relatively much in a short timeIn a 20 second test, starting from the start of Npp,
I received approx. 3800 dialog messages for all 4 dialogs, of which approx. 3000 were SC_WIN_IDLE messages.
Only received from the two dialogs mentioned. But only if something was added in the two dialogs.
A single letter was sufficient for this. If the letter was deleted again, the messages also stopped and the CPU load decreased again.The two dialog groups, Diagnostics/References on one side and Symbols/Console on the other, differ in one detail.
Symbols/Console use the initial document create by Scintilla and that is always overwritten,
Diagnostics/References use a separate document (SCI_SETDOCPOINTER, SCI_CREATEDOCUMENT, SCI_RELEASEDOCUMENT …) for each LSP server.I can’t say at the moment whether this is the actual trigger but I am confident that I will find out in the next few days.
-
@Ekopalypse said in Notepad++ v8.7.6 Release Candidate:
with symbol files loaded from a recent Notepad++ release build.
These are 100% wrong (missing).
Let’s stop here and continue in more appropriate place.–
moderator: moved the tangential posts from the v8.7.6-RC topic to here -
X xomx referenced this topic on
-
Continue from: https://community.notepad-plus-plus.org/post/99308
Below I will show you what you will see with the correct PDBs loaded for the just launched N++ (none of its func invoked), the two N++ base threads will be its main thread and the backup-snapshots worker one:
@Ekopalypse said in New (incomplete) LSP client plugin:
Diagnostics and References show the unusual behavior that they
a) receive SC_WIN_IDLE messages and
b) relatively much in a short timeI can confirm with Debug N++ v8.7.6rc2 & your plugin binary. I simply launched the N++, invoke your
Toggle diagnostic windowand then any action in it (even a mouse click inside that Diagnostics wnd) invokes theSC_WIN_IDLE:
So I suppose that if you use this wnd a lot in a real plugin work, there will be one such message for every, even a small, change.
Edit: This behavior is not dependent on your plugin, it is there even without it. -
Thank you very much for having a look and trying to help me solving this. I managed to confirm that the issue is because of using multiple views.
See here for more details.@PeterJones - thanks for moving the topic to the right place.
I will follow up on this tomorrow.
EDIT: I forgot to mention that you are right, I copied the npp.pdb to the wrong directory :-(, but when I saw notepad++!SetLibraryProperty … it was enough confirmation for me to believe that the symbol file was found and loaded.
-
There is a change in IdleStyling
execute(SCI_SETIDLESTYLING, SC_IDLESTYLING_ALL, 0);now the whole document is styled at startup instead of what is visible. So more CPU usage.
-
Thank you very much - and disabling it again in my init routine seems to solve the current problem, but I’m not sure if there isn’t an underlying issue here. I mean, why does this only happen when multiple documents are used in a single window? I will do some tests in the next few days.
