bug#63595: 30.0.50; ERC 5.6: Add buffer-list and nick-list modules

["J.P." <jp@neverwas.me>]

"J.P." <jp@neverwas.me> writes:

> It's also been reported that the dframe timer can signal a
>
>   (wrong-type-argument window-live-p nil)
>
> which then gets trapped by the
>
>   (with-demoted-errors "DFRAME TIMER ERROR: %S"...)
>
> in `dframe-timer-fn'. Unfortunately, remediation is trickier here
> because we've got to inspect calls to `window-live-p' stemming from
> `speedbar-timer-fn', possibly via `erc-speedbar-insert-user'. (What we
> really need is a backtrace from the bug reporter.)

Actually, I think my initial "analysis" is flawed. Of the two obvious
paths to `window-live-p' from `speedbar-timer-fn', namely

  internal--after-save-selected-window
  save-selected-window
  speedbar-center-buffer-smartly
  erc-speedbar-expand-channel
  erc-speedbar-buttons
  speedbar-update-special-contents
  speedbar-timer-fn
  dframe-timer-fn
  timer-event-handler

and

  window-normalize-window
  unrecord-window-buffer
  replace-buffer-in-windows
  kill-buffer
  format-spec
  erc-nicks--gen-key-from-format-spec and let*
  erc-nicks--highlight save-current-buffer and let* let
  erc-speedbar--compose-nicks-face apply
  speedbar-make-tag-line
  erc-speedbar-insert-user
  erc-speedbar-expand-channel
  erc-speedbar-buttons
  speedbar-update-special-contents
  speedbar-timer-fn
  dframe-timer-fn
  timer-event-handler

neither seems capable of producing a `wrong-type-argument' error for
`window-live-p' (especially not directly, since that function appears to
accept any lisp object without protest).

Rather, I think the error may originate from some other function that
tests for `window-live-p' and signals a `wrong-type-argument' somehow,
possibly via something like CHECK_LIVE_WINDOW, which appears in a
handful of related definitions, such as `set-frame-selected-window'. In
any case, because this line of reasoning may also be nonsense, I think
we need a reliable repro recipe before proceeding further.