Make @elextr switch to Geany for his C++ projects

[techee]

@elextr Just curious - would the LSP plugin be enough for you to switch back to Geany for your C++ projects? I know you mentioned bad autocompletion, symbol goto and symbol highlighting as the main problems of the tag manager but these should be much better with the LSP plugin. Is there anything else? (After ironing-out possible bugs and usability problems of the plugin.)

Right now there are various LSP features unimplemented by the plugin (code formatting, refactoring support, auto-fixes, etc.) which I plan to add in the future - I just concentrated on the features that affect the API between Geany and LSP plugins.

On the other hand, I don't want to do some things like managing the build process (will have to be done externally) and I'm not sure if all the "workspace" features of LSP could be implemented with Geany not really knowing what files are part of the project.

Is there anything outside of what LSP provides that you'd miss and what LSP features currently unimplemented by the plugin you'd need most?

[elextr]

Oh dear, not LSP related, but I have become addicted to two or more split windows that work properly, C++ has code in headers and seeing header and body is reeeeeely useful. So you may ultimately be thwarted by non-LSP things.

The type highlighting is more of an issue with situations where the typename matches a function name, there is somewhere in STL that get is seen as a type, and of course its a function everywhere. So it may not be a common issue, but its pretty annoying when it happens. Edit: but then again with the LSP being better with scopes maybe the problem won't happen much (if at all).

Otherwise refactoring (or at least "rename symbol" that changes the declaration and all the references) is something that is not used every day, but is reeeeeeeely useful when its needed.

Anyway I will see if I can try it for a few days on my real project and see if if there is anything else.

[techee]

Oh dear, not LSP related, but I have become addicted to two or more split windows that work properly, C++ has code in headers and seeing header and body is reeeeeely useful. So you may ultimately be thwarted by non-LSP things.

OK, yeah, I'm afraid "fixing" the split window plugin just means making it part of core Geany and exposing it to plugins somehow. So this bug report should be opened against Geany, right? :-)

For now, ProjectOrganizer's keybindingable "swap header/source" is probably the best alternative. And you can disable whole-project symbol parsing in the project properties dialog because it's not needed with LSP (though everything works if enabled, you can even mix Geany's TM stuff with LSP if you disable the corresponding LSP feature).

The type highlighting is more of an issue with situations where the typename matches a function name, there is somewhere in STL that get is seen as a type, and of course its a function everywhere. So it may not be a common issue, but its pretty annoying when it happens. Edit: but then again with the LSP being better with scopes maybe the problem won't happen much (if at all).

That should happen only if get is defined or used as a type in the file you are editing. From what I have seen just a declaration like Foo *bar; makes Foo color-highlighted even though Foo isn't defined anywhere - but it may depend on what semantic tokens are used - I currently use these:

https://github.com/techee/geany-lsp/blob/fa5ab6f2eafc5c9e1f08532f36452da2d7f3017e/plugins/lsp/lsp-server.c#L338-L344

Anyway I will see if I can try it for a few days on my real project and see if if there is anything else.

That would be really great. I think there might be various small annoyances that could be improved or things that could be made configurable and someone else's experience would really help.

[elextr]

OK, yeah, I'm afraid "fixing" the split window plugin just means making it part of core Geany and exposing it to plugins somehow. So this bug report should be opened against Geany, right? :-)

Correct, it has to be done in core Geany, it can't be done in a plugin because all of Geany's action code needs to understand that there can be more than one window to apply an action to "current document". If Scintilla's document/view capabilities were used all editing actions could just address the single shared document for each file, but styling and view stuff would have to be able to apply to multiple views.

And yes the plugin API would change to reflect that and plugins would have to be changed.

[elextr]

That should happen only if get is defined or used as a type in the file you are editing.

I can't remember clearly exactly what the situation was, but it was the last straw that sent me looking at other C++ IDEs.

What I meant was that "hopefully" the LSP ability to understand visibility will reduce the problem to only files that #include the offending declaration so it will happen less. Given the difficulty of changing this I was suggesting it was not worth fixing in the short term.

[elextr]

Given the difficulty of changing this I was suggesting it was not worth fixing in the short term.

Oooooh, I just had a idea, use INDIC_TEXTFORE to change the colour of semantic tokens so overriding the lexer :-)

And using indicators means its possible to avoid the majikal highlightingmappings.h :-)

[techee]

What I meant was that "hopefully" the LSP ability to understand visibility will reduce the problem to only files that #include the offending declaration so it will happen less.

Note that even when you include a file with the offending (e.g. get) declaration, it's still not a sufficient condition for get functions to be colored incorrectly. You'd have to have get in the current file used as a type, such as get *foo = NULL; - only afterwards all get functions will be colored incorrectly because get will be added as a type keyword to Scintilla.

Oooooh, I just had a idea, use INDIC_TEXTFORE to change the colour of semantic tokens so overriding the lexer :-)

Yeah, good idea, I could try to experiment with that.

[elextr]

Oooooh, I just had a idea, use INDIC_TEXTFORE to change the colour of semantic tokens so overriding the lexer :-)

Yeah, good idea, I could try to experiment with that.

And if it works no more need to pass lists of types to the lexer, so the whole problem goes away.