Diagnostic float: Split event handling flow

[illia-bobyr]

As different events actually need to trigger different actions, it is easier to follow the logic when each event has its own sequence of actions.

It also reduces the amount of work, as only |CursorMoved| can cause the float to appear.

Restore |CursorHold| functionality disabled by

commit 10fac72582a7f95ec3a0bf6715aaf0a7eb997bec
Author: suguruwataru <23465321+suguruwataru@users.noreply.github.com>
Date:   Thu Jan 1 19:09:58 2026 +0800

    Stop `CursorHold` events from updating diagnostic floating window (#1624)

    Closes #1620

    Co-authored-by: mattn <mattn.jp@gmail.com>

It is still nice to have an option of hiding the float when cursor did not move long enough. A subsequent commit adds a configuration option to control this behavior.

---

It is part of a sequence of changes to fix #1510.
Previous change was #1629.
This and subsequent commits in the sequence: 474c656...illia-bobyr:vim-lsp:9372cfc2f69443d5c907e4e59124595f8689160c

[mattn]

I don't make sure but it this can use merge & pipe like: #1551 (comment) ?

[illia-bobyr]

I don't make sure but it this can use merge & pipe like: #1551 (comment) ?

I think it makes is much harder to understand the logic when we merge events from 3 unrelated sources.
There seems to be no gain in doing that.
Yet it produces code that is pretty hard to follow for the reader.
You need to keep in mind all the possibilities and consider what happens in each of 3 cases at the same time.

This PR main goal is to remote the merge call.
There are actual bugs in this logic, that, I think, are very hard to see, exactly because three unrelated event flows were combined into one.

When we combine unrelated things, it also makes it harder to make changes.
The reason I'm fixing 1 bug in 7 commits is because I need to untangle these combined flows first.
And I'm trying to be very careful not to break existing logic.
Because it is so hard to follow, it is also hard to make sure that when I make a change to the insert mode behavior I would not break something in the normal mode behavior.

Moving to separate definitions of events for each case enables me to actually start fixing things with any level of confidence :)

[illia-bobyr]

Maybe I missed your point.
Are you suggesting that it would allow us to dispose of the pipeline in one call if we combine them all with merge at the top level?
I would agree to that.
But I'm a bit worried that it would make it tempting to start merging things further, as was done in the previous version :)

I can do it if you insist. But I'll be a little hesitant to do it myself.

[mattn]

@prabirshrestha What do you think about this?