With show_panel_on_save panel continues to reopen when results fly in even if the user closed the panel inbetween
#1623
Labels
Comments
|
So, when the user closes the panel, it should stay closed until the buffer changes, or when the user switches views... I.e. until a new sweep. Shouldn’t be too hard to figure out I think. |
Merged
kaste
added a commit
that referenced
this issue
Nov 11, 2019
Generally, we can only apply such broad cache layers if the render functions are "pure", i.e. only draw the highlights if we actually have different errors from before, otherwise they're already in place. This breaks for the highlights often because of #1617 or rather the underlying sublimehq/sublime_text#2877 I.e. whenever Sublime invalidates all drawn regions (usually because a file gets reloaded), we can retrigger a lint but still get the same results as before. In that case we *need* to draw because all regions are actual dangles but the cache would prevent this. Basically our error store and the view state are out-of-sync. This is solvable if we can solve #1617. For the panel, the cache is just not applicable at all. The intention was to solve #1623 "for free" in a pragmatic way. But that's just not the case, and actually we're breaking the `show_panel_on_save` feature. The usage in `status_bar_view` was never important performance wise so we can, for now, just revert the whole thing. Partially reverts 816904c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With
show_panel_on_saveand multiple linters running on the same view. The panel opens automatically as soon as 'negative' results fly in which works as intended.If you now immediately close the panel, slow linters from the same "sweep/trigger" still re-open the panel. We must respect the decision the user made ("Not now, go away").
The text was updated successfully, but these errors were encountered: