Remove redraw_listener if callback throw error.

[mao-yining]

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

9.2.976

[h-east]

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.

[mao-yining]

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?

[h-east]

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.