If somebody writes the code to do it sure. Pull requests are welcome.

But faced with problem because Geany isn't supported autocompletion callbacks or something like that for plugins.

Yes that would be the code that needs writing, then the plugins could provide their specific language input. The actual language server part would be in a plugin, much of which may be common between languages.

Not that I recall, but my .. erm you know, thingy, erm oh yeah, memory!! is not so good :)

I suspect the main problem is that nobody who had the time and interest had the capability and nobody who had the capability and interest had the time, something many Geany contributors are short of at the moment due to things in the real world.

But if someone comes up with a concrete proposal for an API allowing plugins to provide autocompletes it is likely that it will get some discussion, and a nice implementation will get accepted, especially if you can arrange for a number of testers, thats often the difficulty, if the changes require using a plugin to test it takes too much of a potential committers time to test.

@codebrainz thats a good idea, even if initially the user had to manually turn off Geany autocompletes in prefs it would allow the plugin to be developed fully standalone to show its usability, and then a later improvement could allow the plugin to shut down Geany autocompletes.

thats a good idea, even if initially the user had to manually turn off Geany autocompletes in prefs it would allow the plugin to be developed fully standalone to show its usability, and then a later improvement could allow the plugin to shut down Geany autocompletes.

May be just add an ability to replace of autocompletion list by plugin?

Its probably going to be easier to just have your own autocomplete dialog

Ok, but at least it is need to add notify for start of dialog displaying.

the Geany version is provided by Scintilla, but populated by Geany, and is strongly linked to Geany's tags and symbols mechanism that you won't be using. So its likely to be more complicated to modify to allow external input without breaking any existing functionality

Currently I use this code for autocompletion dialog in my own plugin without any problems:

```D /// This is D language scintilla_send_message( doc.editor.sci, Sci.SCI_AUTOCSHOW, cast(uptr_t) alreadyEnteredNum, cast(sptr_t) preparedList.toStringz ); ```

So it is only need some public function pointer inside of Geany what returns list for autocompletion and also another one for tips window. If plugin will be able to replace this pointers by its own it will be very usable.

This is second option if it is impossible to add notify for start of completion/tips dialog displaying. Although it would be more correct to have this notify.

I still don't understand, how can Geany notify the plugin of anything for autocompletion?

I am isn't know. It is possible to emit notify like SCN_CHARADDED? Something like GEANY_DISPLAY_AUTOCOMPLETE? Plugin will be able to listen for this notify and display its own dialog instead of built-in.

Or maybe substitution of function ptr what returns autocompletion list will be more suitable for this: plugin will replace this function by its own.

I meant how can Geany know WHEN to notify the plugin?

Then Geany displays built-in autocompletion window. Or I isn't understand something?

(Topic can be changed to "Autocompletion plugins support"?)

My understanding is that the plugin will get notified of characters the user types by the editor-notify signal, when it has a suitable sequence of identifier characters its sends those to the language server to get what possible autocompletes are available at that position. When the language server returns the list the plugin displays its autocomplete dialog, and if the user selects one, the plugin inserts that using editor_insert_text_block().

But in Geany we already have fine tune settings for autocompletion. And if extrenal autocompletion will be implemented as substitution of internal autocompletion function it will be more comfortably to use.

And, yes, if it is need for autocompletion plugin for some purposes (performance) characters sequencies already can be captured.

So there is no Geany interaction with the autocompletion at all, and as I said Geany autocompletes should be turned off, you don't want two things trying to decide autocompletion at the same time, thats chaos.

So it is need to clearly separate settings of built-in autocomplete and third-party. Because 99% of user isn't distinguish this details. And it will look ugly.

I would strongly suggest that the plugin should be shown to work first, before you worry about interacting with settings in Geany.

Why? Currently it works ok by way similar what I proposed here (except fact that it counts chars, not receives notify like GEANY_DISPLAY_AUTOCOMPLETE)

But actually I am isn't use my own plugin because: 1) in GTK3 version I isn't see gdb debugger plugin support (offtopic) 2) my own autocompletion plugin requires to disable built-in autocompletion but I write not only D code

Making the communication with the language server work, without blocking Geany, and fast enough, is possibly going to be a challenge.

I do not think that complexity should matter here. Alternative - the lack of autocompletion in 2018

To be frank, Geany's autocompletion is very stupid and has no language specific understanding (for example name visibilities and scopes or non-top level names), it should not be the trigger for language specific autocompletions, they should replace the Geany autocompletion. I mostly run with autocompletes off because the things Geany offers for C++ completions are usually so irrelevant as to be a distraction.

On the contrary, I like that it works at least a little on virtually any file, regardless of language(?)

And I'm very impressed with the idea that the settings of autocompletion will be in one place, where they are already now. Design of the window can be changed, user settings too, so it's better to be able to transfer lists to this window than draw plugin-own window.

@denizzzka if your last post means "Is someone working on it?" I am not aware of anyone.

See #3849.