[vim/vim] Remove listener if callback throw error. (Issue #21121)

[Mao-Yining]

mao-yining created an issue (vim/vim#21121)

timer_start() 'repeat' has this feature. I believe listener and redraw_listener need it too.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/21121@github.com>

[h_east]

h-east left a comment (vim/vim#21121)

A timer that stops only means something no longer happens. A listener is how a
plugin keeps state outside the buffer in step with the text, so one that Vim
quietly takes away leaves the plugin running with a model that drifts from the
buffer. An LSP client is the plain case: the server would go on answering
about a document it no longer has, and nothing would say why. Errors on every
change are loud, but they do say what is wrong.

There is no way to find out that it happened, either: timers have
timer_info(), listeners have nothing of the sort and no event. If Vim is to
drop one, it should say so and offer a way to see what is left.

The errors worth counting here tend to be the plugin's own. textlock is set
while the callbacks run (invoke_listener_set() in change.c), so a callback
that touches the buffer gets E565 every time, which its author wants to keep
seeing. A try / catch in the callback is one line, and the plugin is the
one that knows what to fall back to.

Aside: timer_start() is documented as cancelling the repeat when the timer
"causes an error three times in a row", but tr_emsg_count is never reset
after a call that goes well, so what it counts is three errors in total.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/21121/5394283295@github.com>

[Mao-Yining]

mao-yining left a comment (vim/vim#21121)

A timer that stops only means something no longer happens. A listener is how a plugin keeps state outside the buffer in step with the text, so one that Vim quietly takes away leaves the plugin running with a model that drifts from the buffer. An LSP client is the plain case: the server would go on answering about a document it no longer has, and nothing would say why. Errors on every change are loud, but they do say what is wrong.

There is no way to find out that it happened, either: timers have timer_info(), listeners have nothing of the sort and no event. If Vim is to drop one, it should say so and offer a way to see what is left.

The errors worth counting here tend to be the plugin's own. textlock is set while the callbacks run (invoke_listener_set() in change.c), so a callback that touches the buffer gets E565 every time, which its author wants to keep seeing. A try / catch in the callback is one line, and the plugin is the one that knows what to fall back to.

Aside: timer_start() is documented as cancelling the repeat when the timer "causes an error three times in a row", but tr_emsg_count is never reset after a call that goes well, so what it counts is three errors in total.

Thank you for your reply. The motivation for this issue came from developing redraw_listener — if there is an inadvertent error, it throws an error on every redraw, which is very difficult to deal with. What are your thoughts on this situation?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/21121/5394339224@github.com>

[h_east]

h-east left a comment (vim/vim#21121)

That is a fair distinction, and a stronger case than the buffer listener one:
the message an error prints tends to bring on the next redraw, which calls the
failing callback again, and while that goes round you cannot get to a prompt
to remove the listener. Noise on every change is a nuisance; this can leave
Vim unusable.

I would still not want it dropped without a word: it should say which listener
it gave up on, and there should be a way to ask what is still registered, the
way timer_info() does for timers.

In the meantime the callback can do it and say so while it does:

def OnStart()
  try
    ...
  catch
    redraw_listener_remove(id)
    echomsg 'redraw listener removed: ' .. v:exception
  endtry
enddef

Removing from inside the callback is fine: the id is only set to zero, and the
entry is freed once the redraw is over.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/21121/5394831001@github.com>