> I mean with TM we have all data required to implement the features locally > available. We can do smart things before the user triggers things or after > based on that. With your LSP proposal we ask the external entity only when > the user triggers the action and we have to hope for the best.
Do we really do "smart things"? The whole TM is pretty dumb - we just don't have the necessary information to do the right thing. clangd does the "smart things", not we. And we don't have the development resources or knowledge to implement something like that - have a look at how complex clang's AST is: https://clang.llvm.org/docs/IntroductionToTheClangAST.html We really don't want to have such a representation directly in Geany; moreover, such a representation is language to language specific and we couldn't have one for all languages. Asking external entity is what the idea of LSP is all about - LSP servers are typically implemented by the people who develop the compiler itself and who know _much_ better what to do. And best, it will all be work-free for us, we just need to implement the protocol itself and it will work with an arbitrary language. This is like why we wanted the ctags parsers to be maintained outside of Geany - that we don't have to care about them ourselves. And similarly to LSP, if you are not satisfied with some ctags parser or a LSP server, you can submit patches upstream and the great thing is that not only Geany, but all other editors using them will benefit from the work. > I would rather see that we mix-in LSP data (even if that overrides TM) > beforehand/in the background. AFAIK you can get all symbols in a document > through LSP. Then we can import that to our local data storage and implement > goto-definition on-top of that (and here LSP may replace TM's document > parsing or we invent some smart combination). But we won't get the information necessary to implement that - you need the AST for it which you won't get through the LSP interface. LSP just returns e.g. the symbols of the current document but there's no information about symbol types, their visibility, or anything other related. And again, why we should re-invent the wheel when the compiler people did it for us? > Basically I'm saying: TM can use LSP data, either exclusively (instead of > parsing the file itself) or as an extra data source. Rest of Geany and > plugins still interface with TM (may require changes here and there if LSP > provides less data and someone was depending on that missing pieces, but I > hope not). Once again, you misunderstand how LSP servers work and what information they provide - while one could grab the symbols from the LSP `documentSymbols`, they provide less information than what we get from ctags parsers as they are only meant to be displayed in the GUI and aren't meant to provide the necessary information for any advanced processing. In addition, all the communication with LSP servers is asynchronous and we'd really complicate our lives having to worry if all the TM-related structures contain valid data or if there's some LSP request pending. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3571#issuecomment-1793389792 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/pull/3571/[email protected]>
