So the settings in the Geany dialogs should not affect the plugins, the plugins should have their own language specific settings. I mostly run with autocompletes off because the things Geany offers for C++ completions are usually so irrelevant as to be a distraction. 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. Which is why first it should be made to work. And it will look ugly.Īlternative - the lack of autocompletion in 2018 Because 99% of users isn't distinguish this details. So it is need to clearly separate settings of built-in autocomplete and third-party. 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. And if extrenal autocompletion will be implemented as substitution of internal autocompletion function it will be more comfortably to use.Īnd, yes, if it is need for autocompletion plugin for some purposes (performance) characters sequencies already can be captured. 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().īut in Geany we already have fine tune settings for autocompletion. 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.
0 Comments
Leave a Reply. |