lsp-treemacs-symbols shouldn't break as code is being edited

[betaprior]

I am observing that the contents of lsp-treemacs-symbols window often disappears (or parts of it disappear) as I am editing the code, I am assuming due to the fact that while I am typing, the code is not always in a syntactically valid state. (gif illustration attached)

If this is what leads to breakage, it would be far less intrusive for lsp-treemacs-symbol to simply keep the last known good set of symbols (maybe with a visual indicator that current state cannot be parsed).

[yyoncho]

How can we understand that the new state with fewer elements is not a "good state"?

[betaprior]

How can we understand that the new state with fewer elements is not a "good state"?

In my experience the "fewer elements" state always correlates with a lot of flycheck errors, and, in particular, the following message from LSP:

LSP :: Error from the Language Server: computing fix edits: <....>: expected operand, found '}' (and 18 more errors) (Unknown error) 

Thinking about it, I suppose it would be incorrect to assume that any time there's a flycheck error that means the state is invalid and therefore should not be updated. But to a human, if, for example, we observe going from 0 errors to 10 errors to 0 errors in the span of 20 seconds it takes to type out a syntactically valid construct, it is obvious that the intermediate state can be considered "bad".

Here's one possible heuristic that would produce an improved experience: if the number of reported syntax errors goes up by some threshold, let's say 5, then ignore this state change and set a 20s timeout (i.e. after 20 seconds, continue as normal).

[yyoncho]

And what happens if the user has actually deleted those elements and they are selected? We will show a stale view for 20 seconds clicking on which will yield an error because the positions are no longer valid? Also, the errors might be reported after 10-20 seconds as well for servers that perform slow compilation(e. g. rust/c++).

[betaprior]

If we know the buffer is in an error state, then maybe just don't let the user click. Or reset the timer and update the state right then.

Feel free to close this as wontfix if you think implementation difficulties aren't worth the benefit, but I think it's worth pointing out that (from a user perspective) the behavior of "the sky is falling, bajillion errors" simply because you are in the middle of typing out a struct or a hash table is suboptimal (I'm talking more broadly about flycheck, not just treemacs-symbols). It is probably an unavoidable part of "fly" in flychecking though.