Don't add new diagnostics during the diagnostics_delay_ms period

[fredcallaway]

I've had a really good experience with sublimelsp so far, with basically one exception. I find it really annoying/distracting when my code gets highlighted as I'm writing it. In principle, this could be addressed by diagnostics_delay_ms but in practice, there are always some diagnostics that I don't intend to fix, so the setting is always ignored.

The ideal solution (for me) would be to modify the behavior of diagnostics_delay_ms such that new diagnostics would not be added during the delay period but a fixed diagnostic should immediately disappear. This would require tracking diagnostics though, and I'm not sure that this is feasible.

EDIT: on reflection, the solution below doesn't make sense.

An easier solution would be to hide all the diagnostics while the user is typing and then show them again after diagnostics_delay_ms. I guess there would need to be a new setting like "diagnostics_hide_on_edit". I tried to implement this myself, but I got a bit stuck when I found that this function (added in SessionBuffer.publish_diagnostics_to_session_views) does not actually remove the diagnostics. Any hints?

def hide() -> None:
    print('LSP hiding')
    self._present_diagnostics_async(
        diagnostics_version,
        [],
        data_per_severity,
        total_errors,
        total_warnings,
        False
    )

[rchl]

Diagnostics are cleared in

LSP/plugin/session_view.py

Lines 288 to 289 in 0267a1a

	for key_tag in key_tags.values():
	self.view.erase_regions(key_tag)

, before being created later in that method.

I'm skeptical about hiding diagnostics on typing though. Would IMO be distracting and potentially confusing.

[fredcallaway]

Yeah I think you're probably right. Hiding all diagnostics while typing is a lose-lose compromise.

But I hope you agree that the ideal behavior of diagnostics_delay_ms would be to prevent new diagnostics from appearing (regardless of whether there happens to be other existing diagnostics). I've changed the title to reflect this.

If someone (perhaps future me) does decide to take this on, I think the trickiest part is identifying if two diagnostics are "the same". To do this, I think you'd want to match on text rather than region because the region will be changed by input earlier in the file. Does the diagnostic data structure include the matching text already? If so, then this is easy. Otherwise, the plugin would need to have require file-specific persistent state—not sure what is the "correct" way to do this, but I would probably just use a global dict mapping file names to (text, diagnostic) tuples.

[rchl]

Only message and range are required in diagnostic structure.

As for whether I agree... Well, I'm not really bothered by current behavior and I know there are people who would even not want any artificial delays. But your suggestion doesn't sound bad, I'm just not sure whether it's worth extra complexity (depends how much extra complexity is required).