From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.bugs Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing Date: Fri, 09 Aug 2013 07:50:19 -0400 Message-ID: <5204D77B.2040900@siege-engine.com> References: <87pptptk9n.fsf@engster.org> <87eha4t7xz.fsf@engster.org> <8738qksz6l.fsf@engster.org> <837gfvua2r.fsf@gnu.org> <87y58bs9x4.fsf@engster.org> <83zjsrs3k2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1376049081 619 80.91.229.3 (9 Aug 2013 11:51:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Aug 2013 11:51:21 +0000 (UTC) Cc: gundaetiapo@gmail.com, 15045@debbugs.gnu.org, David Engster To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 09 13:51:21 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V7lE0-0001ij-Pb for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2013 13:51:21 +0200 Original-Received: from localhost ([::1]:39822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7lE0-0001u4-D1 for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2013 07:51:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7lDq-0001tj-2r for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 07:51:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7lDi-000307-Q2 for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 07:51:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7lDi-000302-MA for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 07:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V7lDi-0000K2-Ai for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2013 07:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Eric M. Ludlam" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2013 11:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15045 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15045-submit@debbugs.gnu.org id=B15045.13760490301158 (code B ref 15045); Fri, 09 Aug 2013 11:51:02 +0000 Original-Received: (at 15045) by debbugs.gnu.org; 9 Aug 2013 11:50:30 +0000 Original-Received: from localhost ([127.0.0.1]:49054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7lDB-0000Ib-C5 for submit@debbugs.gnu.org; Fri, 09 Aug 2013 07:50:29 -0400 Original-Received: from mail-vb0-f42.google.com ([209.85.212.42]:51722) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7lD9-0000IL-Ju for 15045@debbugs.gnu.org; Fri, 09 Aug 2013 07:50:28 -0400 Original-Received: by mail-vb0-f42.google.com with SMTP id e12so3995307vbg.1 for <15045@debbugs.gnu.org>; Fri, 09 Aug 2013 04:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3jIYIyrV1S7fyMY8VpAHR1u7/c8d9xEo2lWJKuAg8kQ=; b=LLIY4LQ9BaJdkkpKdZIAmxKHfSACJnOt54KvWV+tVdZmMc/+nJctRNVbVwjg74BcZY wtUflhpdTzu0Cnk1wntpTZ1qHMcgFFyCfy+W1xP7jVjPC9BlY+s//8kISB4iiNhKK1gM i56ET9Jj2X4chy7Gyia1FYMeXTefGc6beDRdRmTCzYMoHhbVkFLpPmqL6ZfNFYHY/Kj2 Ui21VW5FOGYcItNkQxoRfcRUfbVutRJ9jhh/yapLdczEbg4MbpcKSK9mmmCtG2U6Y/9p Y2GP6tRaEiFAysIBGbYTBETnsI5gU9xl8h/HUEC/vX0d9EXevA4So3aTdl+zezUv3VOb 3WCg== X-Received: by 10.52.52.132 with SMTP id t4mr4627616vdo.65.1376049021966; Fri, 09 Aug 2013 04:50:21 -0700 (PDT) Original-Received: from [192.168.1.201] (pool-72-74-140-235.bstnma.fios.verizon.net. [72.74.140.235]) by mx.google.com with ESMTPSA id eg5sm10536163vdc.9.2013.08.09.04.50.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 04:50:20 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <83zjsrs3k2.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:77144 Archived-At: 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