Re: delay with close tab

[Katsumi Yamaoka <yamaoka@xxxxxxx>]

In [emacs-w3m : No.12189] Michael Heerdegen wrote:
[...]
>> (run-at-time 0.1 nil
>>            (lambda (buffer)
>>              (when (buffer-live-p buffer)
>>           (with-current-buffer buffer
>>             (setq w3m-tab-timer nil)
>>             ;; (when (and (eq (selected-window)
>>             ;;      (get-buffer-window buffer))
>>             ;;       w3m-process-queue)
>>             ;;   (inline (w3m-force-window-update)))
>>             (w3m-force-window-update))))
>>            current)
>>
>> with the one line (second last) added and the four old
>> removed (commentated out)?

> Indeed!

>> In that case, *YES*, that seems to have done it!

> That's good news.  Then we have at least a hint what the problem is.  I
> think the mistake is that the code assumes that there has already a
> redisplay being performed.  Hoping Yamaoka has an idea how to fix this
> cleanly.

Uhm, so far I didn't reproduce the tabs persisting problem.
Moreover `w3m-force-window-update' there seems unnecessary at
least for Emacs 24.3.50 on Cygwin (office) and Fedora 19 (home).
But that's ok.  I've applied Michael's patch.  Thanks.  Let us
test it.

Though I don't recall why I added `w3m-force-window-update' there
(ten years ago!), it was probably for fixing a similar problem.
Michael's patch might hint a redisplay problem of Emacs.  I mean,
a function, that sees the appearance of buffer and window, might
not necessarily work as expected if it runs a bit earlier than
the next Emacs's redisplay period or a process runs then.  Using
(sit-for 0) was an old trick for such a case, though it can't be
readily used since it likely stops an asynchronous process.
Perhaps all might have already been fixed in Emacs of the bleeding
edge, though. ;)