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

Previous Next

Full log

View this message in rfc822 format

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

> Date: Fri, 09 Aug 2013 07:50:19 -0400
> From: "Eric M. Ludlam" <eric <at> siege-engine.com>
> CC: David Engster <deng <at> randomsample.de>, gundaetiapo <at> gmail.com, 
>  monnier <at> iro.umontreal.ca, 15045 <at> debbugs.gnu.org
> 
> > 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.

Emacs is a complex piece of software.  We cannot remove that
complexity no matter how hard we try.  And yes, this requires
developers to be aware of what can happen when they call certain
APIs.  There's nothing new here.

> 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.

Again, nothing new.  It's okay to propose solutions to these issues,
but a "solution" which tells timers not to force redisplay is a
non-starter, IMO, because some of them cannot do their thing without
displaying something at specific times.

> * In a timer, disallow dispatch of other timers until done.

Sounds not a good idea to me, as too many useful features use timers,
and users will be surprised to see them sometimes unable to run.

> * Record redisplay requests in timers, and force redisplay when the
>    timer exists.

Not good for timers that must display at certain times, with minimal
delays.

> * In input-pending-p, dont' allow new timers to run,
>    doc only talks about command input, not timers.

What if input arrives because of a timer?

> * In timers, redisplay always assumes you don't want to move point and
>    puts it back before the draw.

Redisplay doesn't have any idea where is "back".  When redisplay is
entered, it finds point at a certain location.  It has no idea where
it was before, all it knows (in some cases, not all of them) is where
point was in each window during the last redisplay cycle, which could
be 5 msec ago or 5 min ago.

> 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.

I'm sorry, but I don't see "the source" here.  What is the source of
the problem, in your opinion?

In my opinion, the source of the problem is that application code
moves point to a place it didn't intend the user to see, and then
calls some APIs that trigger redisplay and reveal that location of
point (and potentially even cause a scroll).  The solution could be
(a) avoid triggering redisplay, or (b) restore point before calling
something that could cause redisplay.  What other solutions do you
envision that don't limit the basic features involved in this?

Previous Next

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