[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delay with close tab
- From: "Jose A. Ortega Ruiz" <jao@xxxxxxx>
- Date: Tue, 15 Oct 2013 19:03:18 +0200
- X-ml-name: emacs-w3m
- X-mail-count: 12181
- References: <87y55wpt9m.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <b4mtxgje1mx.fsf@xxxxxxx> <87txgj457m.fsf@xxxxxxx> <b4miowzdrnn.fsf@xxxxxxx>
On Tue, Oct 15 2013, Katsumi Yamaoka wrote:
(B>> Something i don't fully understand is why you need to rely on a
(B>> background process to update the tab line in this case: couldn't
(B>> w3m-delete-buffer just trigger an immediate refresh of the tab line right
(B>> after killing the buffer? (it knows for sure that it's been modified).
(B> That would be a good idea. Does this advice do the trick?
(B> (defadvice w3m-delete-buffer (after update-tab-bar activate)
(B> "Update tab bar right after deleting a tab."
(B> (when (eq major-mode 'w3m-mode)
(B> (setq w3m-tab-timer nil)
(BHmm... not really: i still can see the old tab for a fraction of a
(Bsecond there, after the buffer is gone and a new one selected. I
(Bcouldn't tell for sure if it's faster than before, but maybe it is. So
(Bit seems that that time is spent by `w3m-tab-line` to do its job (i have
(B~20 tabs open, in case that matters), not waiting on idle timers...
(BThe folly of mistaking a paradox for a discovery, a metaphor for a proof, a
(Btorrent of verbiage for a spring of capital truths, and oneself for an
(Boracle, is inborn in us.
(B -Paul Valery, poet and philosopher (1871-1945)