bug#21730: 25.0.50; Random errors in redisplay--pre-redisplay-functions

[Sergio Durigan Junior]

On Wednesday, September 14 2016, Eli Zaretskii wrote:

[ Resending because I have now really unarchived the bug.  Sorry about
  the dup. ]

>> From: Philipp Stephani <p.stephani2@gmail.com>
>> Date: Wed, 14 Sep 2016 19:11:57 +0000
>> 
>>  (with-current-buffer (window-buffer win)
>>  (run-hook-with-args 'pre-redisplay-functions win))
>>  to
>>  (run-hook-wrapped 'pre-redisplay-functions
>>  (lambda (func) (with-current-buffer (window-buffer win)
>>  (funcall func win)
>>  nil))
>>  or so.
>> 
>> I've attached a patch for this. 
>
> Thanks.  But we are going to entertain such changes, I think we really
> should be sure the issue with the current buffer is the culprit.  See
> my other message a few moments ago.

It is pretty hard to diagnose and investigate this issue, but I think
I've managed to progress a bit.

The problem doesn't seem to be on bobp, and I happen to share Philipp's
opinion that the real issue is the assumption that cursor-sensor--detect
will be at the right buffer when it's not.  Here, let me show you.

On my machine, this error always happens when I'm running Gnus in one
buffer (via emacsclient), and while I am visiting a file in another
buffer, and in another window (i.e., another emacsclient).  The
backtrace I get is:

  Debugger entered--Lisp error: (args-out-of-range 0)
    get-char-property(0 cursor-sensor-functions)
    cursor-sensor--detect(#<window 5650 on *Group*>)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^
    run-hook-with-args(cursor-sensor--detect #<window 5650 on *Group*>)
    redisplay--pre-redisplay-functions(t)
    apply(redisplay--pre-redisplay-functions t)
    [ lots of other functions not interesting for us ]

I took the liberty to mark the interesting part above, which is the
argument to cursor-sensor--detect.  As you can notice, it's working on
the *Group* window, from Gnus.  Now, the interesting part that I noticed
and was able to verify is that this only happens when (a) I am not
working in that buffer, (b) the point is at (point-min) at that buffer,
but (c) the point is not (point-min) at the buffer I'm currently in.  In
this case, Emacs does some wrong calculations with point and ends up
with the value of 0, which makes sense if you consider that
(window-point) of that window is 1, but (bobp) is not t (because, as I
explained, I'm working in another buffer, and the value of point there
is not 1).

With all that said, I came to the conclusion that Phillip's rationale
makes sense and therefore his patch seems to be the best shot we have at
fixing this annoying bug.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

signature.asc
Description: PGP signature