From: "Eric M. Ludlam" <eric@siege-engine.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org,
David Engster <deng@randomsample.de>
Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing
Date: Fri, 09 Aug 2013 07:50:19 -0400 [thread overview]
Message-ID: <5204D77B.2040900@siege-engine.com> (raw)
In-Reply-To: <83zjsrs3k2.fsf@gnu.org>
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
next prev parent reply other threads:[~2013-08-09 11:50 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-07 17:59 bug#15045: Point jumps inappropriately around time of Semantic lexing Barry OReilly
2013-08-07 18:30 ` Stefan Monnier
2013-08-07 18:42 ` David Engster
2013-08-07 19:31 ` Barry OReilly
2013-08-07 19:44 ` Eli Zaretskii
2013-08-07 20:39 ` Barry OReilly
2013-08-08 2:41 ` Eli Zaretskii
2013-08-08 17:07 ` Barry OReilly
2013-08-08 17:46 ` Eli Zaretskii
2013-08-07 21:23 ` Stefan Monnier
2013-08-08 17:21 ` David Engster
2013-08-08 18:06 ` Stefan Monnier
2013-08-08 18:13 ` David Engster
2013-08-08 21:39 ` Eli Zaretskii
2013-08-08 22:51 ` Stefan Monnier
2013-08-09 7:56 ` Eli Zaretskii
2013-08-09 14:03 ` Stefan Monnier
2013-08-09 14:16 ` Eli Zaretskii
2013-08-09 17:34 ` Stefan Monnier
2013-08-09 18:23 ` Eli Zaretskii
2013-08-08 20:03 ` Barry OReilly
2013-08-08 20:30 ` David Engster
2013-08-08 21:49 ` Eli Zaretskii
2013-08-09 5:36 ` David Engster
2013-08-09 7:53 ` Eli Zaretskii
2013-08-09 11:50 ` Eric M. Ludlam [this message]
2013-08-09 13:31 ` Eli Zaretskii
2013-08-09 14:04 ` Stefan Monnier
2013-08-09 14:19 ` Eli Zaretskii
2013-08-09 18:08 ` Stefan Monnier
2013-08-09 18:38 ` Eli Zaretskii
2013-08-09 18:41 ` David Engster
2013-08-09 20:49 ` Eli Zaretskii
2013-08-09 21:36 ` Stefan Monnier
2013-08-10 9:42 ` David Engster
2013-08-09 21:46 ` Stefan Monnier
2013-08-09 16:10 ` David Engster
2013-08-09 18:31 ` Eli Zaretskii
2013-08-10 9:54 ` David Engster
2013-08-10 10:22 ` Eli Zaretskii
2013-08-10 18:06 ` Barry OReilly
2013-10-14 19:32 ` Barry OReilly
2013-10-14 19:51 ` Eli Zaretskii
2013-10-15 13:42 ` Stefan Monnier
2013-10-15 14:12 ` Barry OReilly
2013-10-15 16:28 ` Eli Zaretskii
2013-10-15 17:08 ` Barry OReilly
2013-10-15 18:48 ` Eli Zaretskii
2013-10-15 19:19 ` Barry OReilly
2013-10-16 2:57 ` Stefan Monnier
2013-10-16 14:57 ` Barry OReilly
2013-10-16 17:50 ` Stefan Monnier
2013-10-16 18:32 ` Barry OReilly
2013-10-17 15:03 ` Barry OReilly
2013-10-17 18:18 ` Stefan Monnier
2013-10-17 20:01 ` Barry OReilly
2013-10-18 0:27 ` Stefan Monnier
2013-10-18 14:03 ` Barry OReilly
2013-10-25 19:15 ` Barry OReilly
2013-11-14 18:21 ` Barry OReilly
2013-11-16 4:14 ` Stefan Monnier
2013-11-16 4:54 ` Barry OReilly
2013-11-16 17:37 ` Stefan Monnier
2013-11-16 20:33 ` Barry OReilly
2013-11-16 21:29 ` Stefan Monnier
2013-08-09 18:50 ` Stefan Monnier
2013-08-09 9:12 ` martin rudalics
2013-08-09 16:27 ` David Engster
2013-08-09 17:10 ` martin rudalics
2013-08-09 18:51 ` Stefan Monnier
2013-08-08 21:26 ` Stefan Monnier
2013-08-08 21:57 ` Eli Zaretskii
2013-08-08 22:50 ` Stefan Monnier
2013-08-09 7:54 ` Eli Zaretskii
2013-08-08 21:47 ` Eli Zaretskii
2013-08-09 3:26 ` Eric M. Ludlam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5204D77B.2040900@siege-engine.com \
--to=eric@siege-engine.com \
--cc=15045@debbugs.gnu.org \
--cc=deng@randomsample.de \
--cc=eliz@gnu.org \
--cc=gundaetiapo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.