But I'd leave the Geany refactoring (which I think is a good idea) to a separate PR that comes afterwards.

Agreed.

Even if it means we run into something that requires the API modification - in any case, in it's documentation I'd write that the API isn't stable in case we run into something in the next Geany releases.

Again, me attempting to implement the Geany features using it was driven by the impression that it would give me more hands-on reviews, and show me whether the API was "good enough" to support this use case as well as what you need in the LSP plugin.
I'm not saying we must get it perfect here, but it's a good opportunity to review it :)

I know Thomas won't like the absence of the symbols tree here, but IIUC pros/cons are not so clear with the reality of things. And we can always add this later if wanted.

I don't want to make the impression that I want to monopolize the LSP stuff for this plugin only. Of course there could be something like […]

Again, we can add something for this at a later point if somebody actually has a use case (s)he likes. I understand both POVs: in a perfect world it sounds (to me) like a LSP server should be able to give a "better" TOC-style symbols tree; but I get that in reality it's not what we get, and what we get is not better than TM -- if not undoubtedly worse.

But if at some point there's actually a useful alternative people want, we could add the extension point that works best (possibly adding more abstraction if needed). But I don't think it has to be now.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.