bug#23777: 25.0.95; Throwing (error "Selecting deleted buffer") in timer

[Jiege Chen <jiegec@qq.com>]

Noam Postavsky <npostavs@users.sourceforge.net> wrote:
> On Mon, Jun 27, 2016 at 10:08 AM, Jiajie Chen <jiegec@qq.com> wrote:
>> 
>> I have found the bug -- it comes from nlinum.el:
> [...]
>> 
>> It seems that when the timer is ran, the (current-buffer) no longer
>> exists. That buffer may be a temp buffer.
>> 
>> And my init code includes:
>> 
>> (add-hook 'nlinum-mode-hook
>> (lambda ()
>> (when nlinum-mode
>> (setq nlinum--width
>> (1+ (length (number-to-string
>> (count-lines (point-min) (point-max))))))
>> (nlinum--flush))))
>> 
>> A fix would be:
>> 
>> (defun nlinum--flush ()
>> (nlinum--setup-windows)
>> ;; (kill-local-variable 'nlinum--ol-counter)
>> (remove-overlays (point-min) (point-max) 'nlinum t)
>> (run-with-timer 0 nil
>> (lambda (buf)
>> (when (buffer-live-p buf)
>> (with-current-buffer buf
>> (with-silent-modifications
>> ;; FIXME: only remove `fontified' on those parts of the
>> ;; buffer that had an nlinum overlay!
>> (remove-text-properties
>> (point-min) (point-max) '(fontified)))))
>> (current-buffer)))
> 
> Perhaps it makes more sense to put that buffer-live-p check in your
> nlinum-mode-hook lambda? Actually I wonder why you need to call
> nlinum--flush at all? Though I admit I don't really understand the
> nlinum code either, e.g. what is the use of (run-with-timer 0 ...),
> why not run the thing immediately?
> 
> 
> 
> 
> 

I removed that call in my init code, and the error is gone,
at the price of some display inconsistency which is acceptable.
There is room for improvement in nlinum--flush. 

-- 
Jiegec