(as far as I can see there's no other way to dig the alias portion out of a symbol?).

Unfortunately, yes

I'll see if I can work out what's going on with the timing issue, but I'm still very unsure whether the relatively little value added by linked edits for Clojure is worth the trouble? 🤷

I think the problem is the analysis we lost when we change the buffer, when we edit anything, clojure-lsp sends to clj-kondo the whole text to get new analysis, changing its internal db (atom), I believe there is some issue while the analysis was not saved to the db, but that usually means the request are in some weird order

I think the problem is the analysis we lost when we change the buffer, when we edit anything, clojure-lsp sends to clj-kondo the whole text to get new analysis, changing its internal db (atom), I believe there is some issue while the analysis was not saved to the db, but that usually means the request are in some weird order

That makes sense: I can see that find-element-under-cursor is sometimes returning nil if it's called "soon" after an edit. What can I do about this?

@ericdallo I've pushed changes which should fix the integration tests.

In the process, I discovered that assert-submap is sensitive to the order of the maps, which surprised me (and feels a bit fragile?). But anyway, I think this should now be good to go.

That makes sense: I can see that find-element-under-cursor is sometimes returning nil if it's called "soon" after an edit. What can I do about this?

@paulbutcher I think I have the fix for this, we need to wrap in handlers.clj the linkedEdit call with process-after-all-changes, this may fix the concurrence issue, could you try?