GNU bug report logs - #15045
Point jumps inappropriately around time of Semantic lexing

Previous Next

Full log

Message #89 received at 15045 <at> debbugs.gnu.org (full text, mbox):

From: "Eric M. Ludlam" <eric <at> siege-engine.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gundaetiapo <at> gmail.com, 15045 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 David Engster <deng <at> randomsample.de>
Subject: Re: bug#15045: Point jumps inappropriately around time of Semantic
 lexing
Date: Fri, 09 Aug 2013 07:50:19 -0400

On 08/09/2013 03:53 AM, Eli Zaretskii wrote:
>> AFAICS, any function that calls things like
>> `accept-process-output', `input-pending-p' or `sit-for' inside a
>> `save-excursion' might get an unwanted scrolling effect if point is
>> temporarily moved to some invisible location.
>
> You mean, because of timers that might get run and cause redisplay?
> Yes, that's possible.  But the way to avoid this is to never call
> these when point is in a place the user won't expect.  Forcing the
> Emacs community not to trigger redisplay inside timers is IMO _not_
> the right way, because this is unnecessarily restrictive, and would
> disallow a whole bunch of useful features for no good reason.
>
> IOW, it's the caller of input-pending-p etc. that is the fault here,
> not the timers that it inadvertently lets run.

In my mind, to anyone using input-pending-p to deal with responsiveness 
in long running code, a timer that causes a redisplay is the source of 
the problem.  In addition, it is clear that anyone with a sit-for in 
their timer will think that moving the point and calling input-pending-p 
is a bug.

Even if we resolve which is the real bug, or at least the proposed 
solution here, people will still cause redisplays in timeres, and call 
input-pending-p in long running code, and those problems will need to be 
debugged again in the future.

It seems like it would be more developer friendly for Emacs to enforce 
some kind of behavior with timers so as to remove this class of 
collision.  Here are some random options:

* In a timer, disallow dispatch of other timers until done.
* Record redisplay requests in timers, and force redisplay when the
  timer exists.
* In input-pending-p, dont' allow new timers to run,
  doc only talks about command input, not timers.
* In timers, redisplay always assumes you don't want to move point and
  puts it back before the draw.

It is clear to me that there are valid use cases for both redisplay in a 
timer, and input-pending-p being used in long-running programs.  Adding 
funky restrictions to either seems untenable with the size of the Emacs 
dev community.  It would be better to tackle the problem at its source.

Eric

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.