Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Then Geany should not tell Scintilla to highlight local type names.
In general the majority of C++ types are in header files so they are not local to my mind. But i'm not sure what you mean by local type names? And simply removing semantic information from some names isn't really a helpful solution if that makes them look different when semantically they are not.
Seems like they aren't keywords in the Scintilla sense.
Yes, the Scintilla sense does not match what C++ does, thats the point.
Maybe too difficult for Scintilla to fix?
It is with the current (ab)use of global word lists as typenames yes.
Although compiler support might not be there yet.
IIUC MSVC does most of the modules spec, gcc and clang do the majority (but different majorities) so not all the fancy details are available yet, but the basics are there. Thats why not much is in the wild with modules yet.
The preprocessor is the source of so many headaches with parsing. I expect supporting modules would be much more straightforward than supporting includes.
Certainly things like #defines can't cause changes to modules, so thats a blessing, but there is still the issue of getting the declarations that are exported in the module interface into where the module is imported. And there is still the issue of the module lookup path that is specified on the compiler command line (for clang at least) so the build system interaction is still needed to find them.
And of course the dear olde STL is still there, so includes won't be going away anytime soon.
A LSP does sound like the way to go for all things related to parsing
It does seem to be the flavour of the day for IDE/Editors yes, and that means that if there is a LSP for one IDE it can be used by others, thats the idea. Google finds at least one for D.
One thing that would be good is to support an external ctags program
That would be slower than the current system of course, but then if its a separate process, not inline with the UI, it can be more thorough. The LSP is of course an external program too, and the method the editor/IDEs I have seen that use LSPs handle the delay by having a syntax colouring that runs fast inline with typing, and the semantic colouring is provided later from the parallel process of the language server. It would require some adjustment of the syntax lexers to not overwrite "semantic" styles, or an adjustment of Scintilla to store two sets of styling and use the semantic styling first and fallback to the syntax styles if its not present.
A LSP does sound like the way to go for all things related to parsing though I'm not sure that syntax highlighting needs to be too sophisticated. The latter means we can stick with Scintilla.
I suspect that integrating the styling as outlined above would be not too hard, what would be difficult would be to find all uses of tagmanager within Geany and redirect the queries to the LSP given that tagmanager is synchronous, but the LSP is asynchronous.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.