Custom/user adapters for autocompletion
-
Current solution have many minuses:
- slow parsing of big xml files
- outdated and incomplete function list
- inconvenient customization
- ignores current context/scope (namespace, class and etc.)
I suggest adding support for custom/user auto-completion adapters.
simple solution is customization byautocompletionAdapters.xml
file:<?xml version="1.0" encoding="UTF-8"?> <NotepadPlus> <AutocompletionAdapters> <!-- name: adapter ID language: NPP language name command: pattern CLI command, placeholders $(WORD) text to search $(FILE_PATH) full path to active file $(LINE) current line $(COLUMN) current line position bgcolor: optional background color of adapter's items in autocompletion list --> <AutocompletionAdapter name="php7" language="php" command="php -f nppAutocomplete.php $(WORD) $(FILE_PATH) $(LINE) $(COLUMN)"/> </AutocompletionAdapters> </NotepadPlus>
Adapter
command
must return XML with custom list:<?xml version="1.0" encoding="UTF-8"?> <NotepadPlus> <AutocompletionAdapterResults> <!-- value: autocompletion value to insert label: optional label display in list instead value hint: optional hint/description --> <AutocompletionAdapterResult value="..." label="..." hint="..."/> <AutocompletionAdapterResult value="ClassName" label="Namespace\ClassName" hint="Internal PHP class"/> <AutocompletionAdapterResult value="ClassName2" label="Namespace\ClassName2" hint="Extend ClassName class"/> <AutocompletionAdapterResult value="ClassName3"/> </AutocompletionAdapterResults> </NotepadPlus>
-
I am not sure if this makes sense, as the “whole world of programming languages” has allowed itself to be pushed towards an LSP solution.
-
@ekopalypse My solution based on current implementation of autocompletion in NPP /Scrilla. It’s easy to realize/integrate to NPP unlike LSP. You can add adapter for language server too.
-
The problem I see is that this would mean that every “language adapter” would have to provide this new protocol, and I don’t see that happening anytime soon now that there is this defacto standard called LSP, but who knows …
-
@wintersilence said in Custom/user adapters for autocompletion:
I suggest adding support for custom/user auto-completion adapters.
Есть обходные варианты:
https://github.com/sieukrem/jn-npp-plugin/wiki/Direct-calls-to-Scintilla
см. “How to show autocompletition list box” -
@troshindv thanks man
-
@troshindv yes, I’m
jn-npp-scripts
contributor (: -
@ekopalypse protocol is protocol, adapter is… adapter. I don’t vote to extending text editor into IDE. It’s just simple solution to customize autocompletion - add to NPP will not so long. You can writes adapters not only for languages - it’s useful to insert paths or snippets.
External tools in PhpStorm IDE as example of adapters implementation.
-
Please don’t get me wrong, I have no objections to your idea, it sounds reasonable.
The problem I see is that none of the “existing(?)” adapters know about an Npp-related interface yet, so they would have to adapt to it. Why would they be interested in doing this?
Or is this already some kind of standard that I haven’t heard about?
Btw, if you want this to happen at all, I would suggest opening a feature request at github, that should increase the likelihood, though I’m still skeptical about such a solution. -
The problem I see is that none of the “existing(?)” adapters know about an Npp-related interface yet, so they would have to adapt to it. Why would they be interested in doing this?
Adapter is bridge between NPP and third party software. User write adapter locally or copy existed adapter from some repository.
Example of adapter of implementation in Ace editor:
https://gist.github.com/yuvalherziger/aa48782568c6914b55066d290ff88360 -
-
External tools in PhpStorm IDE as example of adapters implementation.
too can help you discover how it’s can work and plug to editor
-
@donho what do you think about this?