New (incomplete) LSP client plugin
-
@Mark-Olson said in New (incomplete and x64 only) LSP client plugin:
It definitely does not work reliably without using Folder as Workspace. If you use Folder as Workspace, it’s definitely more reliable.
Reply
Ahh, I have that exact config (with my paths of course) and it’s not doing anything. I never use Folder as Workspace though, wonder if that’s my issue? I’ll try …
Cheers.
-
@Michael-Vincent
Yes, currently FAW must be used, and the logic is as followsIf the current file starts with a root path, then send the root path to the language server, otherwise do nothing.
The next version will use the current directory of the current file instead of doing nothing.
@Mark-Olson - what do you mean by “more reliable”?
Have you encountered a situation where it didn’t work with FAW? Reproducible?
Personally, I don’t like using the FAW dialog as it introduces some difficulties and even performance issues. But I didn’t want to create another “explorer-like” dialog either. But that would have its advantages, one could create a TreeList, then it could be used to see which files contain errors. Hmm … maybe I should go that way anyway … I’m still undecided.
Does anyone have any other ideas?
-
@Ekopalypse said in New (incomplete and x64 only) LSP client plugin:
Have you encountered a situation where it didn’t work with FAW? Reproducible?
Reproducible? I doubt it. I think what probably happened is that I opened of FAW, then closed it, then opened up a file.
I keep a lot of one-off scripts in my Python directory (the same directory as the executable) because it’s convenient to do so (can run
python -m whateverfrom anywhere), but of course that’s a terrible place to open FAW because theLib/site-packagessubdirectory can have tens of thousands of files. -
@Ekopalypse said in New (incomplete and x64 only) LSP client plugin:
The next version will use the current directory of the current file instead of doing nothing.
Sounds good. I did get it working with FAW - and that makes sense why.
One thing to think about and not seeing the code I’m just assuming based on the previous V version, you should just do autocompletes. Don’t bother checking if one is active. Maybe it’s my personal preference, but if I’m using a Language Server, I want those completions to be foremost presented, and then if that can’t find any, the “default” Notepad++ ones would show up based on the language or current text in the doc - depending on how it’s configured.
I see currently, you check:
I don’t bother with any of the autocomplete plugin stuff I do - I just present it and Scintilla autocomplete is “smart enough” that when there is no match, the autocomplete window no longer shows - freeing up Notepad++ default autocomplete (if configured) to do it’s thing through Scintilla.
I hope this is making sense. I just noticed when I was typing, I was getting all the Notepad++ autoComplete XML stuff and local doc stuff showing until there were no more options that matched, and then the Language Server started showing me its suggestions - which is what I wanted to see first.
Cheers.
-
@Michael-Vincent said in New (incomplete and x64 only) LSP client plugin:
which is what I wanted to see first.
… yeah, and I thought, what’s he talking about, I always get the completions from the language server first … and then ahh - because I disabled Npp’s autocomplete - - another doh moment :-D
v.0.0.16 puplished
Changes:
- The root directory is set to the current file directory if it cannot be found in the root directories of the workspace…
New:
- Format document support
Note that symbols and reference dialogs are not usable at the moment - I haven’t bothered to disable these functions.
-
v.0.0.17 has been released and has thus reached the functional scope of the former Vlang version.
New:
- Support for symbols and references
- Provision of a help function for reloading the current file
-
@Ekopalypse said in New (incomplete and x64 only) LSP client plugin:
ahh - because I disabled Npp’s autocomplete
Not really an option for me. I use languages that I won’t have language servers for and I want autocomplete to work for them too. Turning it on and off would also be a pain.
Could there be a setting to skip the check?
Cheers.
-
Do you have any idea how to name such a flag?
I was thinking of a boolean value namedsend_completion_request_alwaysand it should be available in both the global and lspserver sections.The absence would mean `false" and has the current behavior, i.e. if a completion list is active, it will be used and not canceled.
If the boolean value is present in the global section, each lspserver inherits its value unless it explicitly overrides it.Other ideas?
-
I think that’s brilliant and flexible - to be globally and “locally” (per LS) override.
Cheers.
-
v.0.0.18 has been released
The new (experimental) flag
complete_alwayshas been introduced.
To be honest, I’m not very happy with it - quite a bit of flickering. I’m still thinking about whether other solutions are possible/useful.
-
@Ekopalypse said in New (incomplete and x64 only) LSP client plugin:
quite a bit of flickering
Yes, that’s because every time a character is typed, autocompletion is called. The way you had it was “nicer” in that autocompletion was just called once and further typing didn’t “filter” (i.e., shorten and redisplay) the list, it just “narrowed” (i.e. moved to the closest match).
This is a symptom of a rather immature autocomplete feature and the Notepad++ implementation and probably other “stuff”. Meaning, there can only be one active autocomplete list at a time, but there is no way to add to that list. So type a character and Notepad++ creates its own list based on the ‘autoComplete/LANG.xml’ file and any current words in the doc (depending on settings of course) and my QuickText plugin creates its list for the language if you match a snip and my TagLEET plugin creates a list based on all the CTags in the project and now your LSPClient creates a list, and on and on … last list wins? or maybe not?
Of course, if you don’t have any of those plugins, you don’t see the issue, but it would be nice (not for you to solve) if Notepad++ / Scintilla had a sort of universal autocomplete where you don’t create the list, just submit your items to add to the list and the universal autocomplete compiles a consolidated list of all the available completions before displaying. That way, you can get the goodness of Notepad++ default fallback for non-LSP languages and the useful “other words in document” (great for typing documentation or README files where words / phrases are repeated) plus any plugin could make use of autocomplete sending suggestions (like the plugins I previously mentioned above) without conflicting with each other - rather cooperatively creating a curated list of the possible completions for the user.
FOR NOW: definitely keep this “feature” disabled by default and maybe document the “issues” with enabling it. And if ultimately you don’t like it or it makes the maintenance difficult - you can remove it. I do appreciate you adding it in so quickly for me to test / play with. I’ve sorta gotten used to this subpar autocomplete experience (read: flickering and somewhat not reliable) so I may be a bad judge of how “well” this
complete_alwaysmode works.
I also cannot stress enough how AWESOME it is that you are tackling LSP for Notepad++!! I have tried some quick Python frameworks running with PythonScript to no avail - which is also why your dockable-dialogs-from-PythonScript piqued my interest. LSP plugin is a daunting task - again, thank you!
Cheers.
-
@Michael-Vincent said in New (incomplete and x64 only) LSP client plugin:
it would be nice [. . .] if Notepad++ / Scintilla had a sort of universal autocomplete where you don’t create the list, just submit your items to add to the list and the universal autocomplete compiles a consolidated list of all the available completions before displaying.
-
@rdipardo said in New (incomplete and x64 only) LSP client plugin:
#2403 Add an autocomplete popup mode doing no processing
Indeed - that describes the problem rather well. I see the proposed solution is a new autocomplete mode. So maybe that would help with LSP type flickering described, but I don’t think it address the “universal autocomplete” I’m talking about where other plugins (other than the Language Server) and Notepad++ itself could all create a list that gets displayed.
Cheers.
-
It seems to me that the basic workflow for getting Notepad++ - style autocomplete alongside LSP autocomplete would be something like this:
- Whenever the current buffer is updated, make a list of words in the file
- Get a list of autocompletions from the language server
- filter the words in the file for ones that could be autocompletions
- Display language server autocompletions in lexicographic order with an icon to distinguish them, and then normal word-in-file autocompletions (with no icon) in lexicographic order.
Obviously the devil is in the details, but implementing Notepad++ - style autocompletion is surely a lot easier than implementing a general-purpose LSP client.
It might even be possible to provide autocompletions from all other open buffers from the FAW (similar to VSCode) if you did something like this:
- On
NPPM_BUFFERACTIVATED, check if the activated buffer is in the FAW, and if its lexer language matches the LSP, list the words in that buffer. - When a buffer from the FAW is navigated away from (but not closed), cache the words in that buffer in a data structure like a trie, so that they can easily be used for autocompletions.
My idea of using a trie only really works for static, unchanging word lists (like the buffers that are open but not currently being edited), because constructing a trie is pretty expensive and doesn’t pay for itself until you’ve done a lot of searches.
-
@Mark-Olson said in New (incomplete and x64 only) LSP client plugin:
Obviously the devil is in the details, but implementing Notepad++ - style autocompletion is surely a lot easier than implementing a general-purpose LSP client.
I could be misunderstanding your numbered workflow, but I don’t think the LSP client should be responsible for getting all word autocompletes from the current buffer.
What I think needs to happen is Notepad++ provides an autocompletion collection point if you will. It dumps its ‘autoComplete/LANG.xml’ entries, current document words and anything else it’s configured for. The collection point is also the place where my QuickText plugin would send possible autocompletes and my TagLEET plugin would send possible autocompletes and @Ekopalypse 's LSP Client would send possible autocompletes. After collecting them all, Notepad++ sorts, filters dups, appends icons, … whatever … then makes the Scintilla call to
SCI_AUTOCSHOWto display the list. Then we do it again for the next typed character.Of course this idea is fraught with issues like the race conditions of how quickly a plugin can submit its autocomplete partial list to the collection point before the collection point says - “I’ve had enough, we’ve waited to long, time to display before the user falls asleep”.
There’s probably a proper software design pattern with a callback or an observable or something far to abstract for me to articulate that handles this exact thing - but I think that has to be put in Notepad++ for the plugins to make use of. Otherwise, we’re where we currently are, with plugins offering autocomplete directly to Scintilla, bypassing Notepad++, which results in stepping on each other and Notepad++, and a poor user experience.
Cheers.
-
First of all, thanks to everyone for participating in this topic.
The more I think about it, the more I feel that implementing a custom completion dialog is the way to go … but … hmm … I don’t know
-
@Ekopalypse said in New (incomplete and x64 only) LSP client plugin:
The more I think about it, the more I feel that implementing a custom completion dialog is the way to go … but … hmm … I don’t know
Reply
For example, see @pnedev NppGTags. Also, I think 3P, though I’ve never used that plugin (I have the former).
Cheers.
-
Just a quick info
It can happen that Npp blocks when multiple language servers are running and a message is received from an inactive one, i.e. one that is not used by the current buffer.
-
v.0.0.19 has been released which should address the aforementioned issue.
-
I am thinking about whether it is necessary to create a “dockableDialog” for symbols of the current buffer.
On the one hand Npp already offers the FunctionList dialog,
on the other hand Lsp-Symbols offers not only functions, but also constants, structures, classes …
But is a “dockableDialog” really needed for this?
I was just thinking that a kind of “search bar” would be sufficient, if not better, for this.
In my case, I usually know the approximate name of the symbol
and then either just want to take a quick look at it or jump there.
In other words, you could use a search bar, which would be sorted alphabetically,
to display the symbols and possibly open another dialog next to it, which, for example, shows the complete function.
Or what do you think? How would you use/prefer a symbol dialog?
