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

Previous Next

Package: emacs;

Reported by: Barry OReilly <gundaetiapo <at> gmail.com>

Date: Wed, 7 Aug 2013 18:00:02 UTC

Severity: normal

Done: Barry OReilly <gundaetiapo <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Barry OReilly <gundaetiapo <at> gmail.com>, 15045 <at> debbugs.gnu.org, deng <at> randomsample.de, eric <at> siege-engine.com
Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing
Date: Tue, 15 Oct 2013 09:42:03 -0400
> FWIW, I'm against such changes.  You can never know how many places
> will be subtly broken by changes like that in such a popular
> interface.

Hmm... I kind of agree with both:
- this is a subtle change affecting behavior in a corner case and it's
  difficult to know which code might care about it.
- nothing in input-pending-p indicates this is some kind of
  blocking/waiting operation which might hence correspond to a "yield
  point".  On the contrary, the intuition behind input-pending-p would
  make you think that the whole point of it is to let you find out if
  there's input *without waiting*.

So I tend to agree with Barry that input-pending-p should not run
timers.  Not just based on his particular problem case, but on the basis
of what ideally input-pending-p should do.

Arguably it shouldn't process_special_events either, tho obviously,
removing this call would introduce a known breakage, so we should keep
this for now (until we have a better fix for it).
  
> The original problem is rare enough, and should IMO be fixed in the
> code where it happens.

It can be difficult to "fix" it there, because there's simply no other
operation that lets you detect if there's input in the queue without
running arbitrary code, so it can require non-trivial refactoring.

>> > What if input arrives because of a timer?
>> If this is an issue, I propose input-pending-p return t if a timer is
>> ready to run.
> Likewise: too serious change in behavior for too obscure a reason.

100% agreement.  `input-pending-p' is meant to detect *user input*, and
timers do not count as such (and input generated by timers doesn't
count as "user input" either).


        Stefan




This bug report was last modified 11 years and 193 days ago.

Previous Next


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