From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Can we make set_point_both less expensive? Date: Mon, 23 Mar 2015 17:31:40 +0200 Message-ID: <834mpbspb7.fsf@gnu.org> References: <5505E34C.4000106@dancol.org> <550A7FFB.7040502@gmx.at> <550BD579.9040804@gmx.at> <550C3335.4070405@gmx.at> <83zj77vh87.fsf@gnu.org> <550C7AD1.4080806@gmx.at> <83egojv02r.fsf@gnu.org> <83a8z6vlyn.fsf@gnu.org> <838ueqtnjb.fsf@gnu.org> <834mpetgri.fsf@gnu.org> <83wq29so1g.fsf@gnu.org> <83lhiprktr.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427124964 31408 80.91.229.3 (23 Mar 2015 15:36:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Mar 2015 15:36:04 +0000 (UTC) Cc: rudalics@gmx.at, dancol@dancol.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 23 16:35:54 2015 Return-path: Envelope-to: ged-emacs-devel@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 1Ya4OO-0003Rx-2J for ged-emacs-devel@m.gmane.org; Mon, 23 Mar 2015 16:35:52 +0100 Original-Received: from localhost ([::1]:56651 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya4ON-0002Zb-G6 for ged-emacs-devel@m.gmane.org; Mon, 23 Mar 2015 11:35:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya4Kd-0005KA-Pl for emacs-devel@gnu.org; Mon, 23 Mar 2015 11:32:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ya4KZ-0000uV-PH for emacs-devel@gnu.org; Mon, 23 Mar 2015 11:31:59 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:42367) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya4KZ-0000uL-HS for emacs-devel@gnu.org; Mon, 23 Mar 2015 11:31:55 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NLO0040088VV800@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 23 Mar 2015 17:31:54 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLO004ZE8H5JU80@a-mtaout20.012.net.il>; Mon, 23 Mar 2015 17:31:54 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:184142 Archived-At: > From: Stefan Monnier > Cc: rudalics@gmx.at, dancol@dancol.org, emacs-devel@gnu.org > Date: Sun, 22 Mar 2015 18:23:24 -0400 > > >> It's right after an incomplete redisplay, and right before the > >> next redisplay. I count this as still "before redisplay" since it's > >> immediately followed by redisplay. > > It is "during redisplay" in the sense that the position of cursor was > > not yet finalized, and you already move it, perhaps for no good > > reason. > > I don't deny it can be described differently. I.e. sometimes it > happens during redisplay, sometimes it happens in a sit-for, sometimes > it happens at the end of a command. But always it happens right > before a redisplay. I don't understand what you are trying to say. Every single moment in Emacs is before _some_ redisplay, that's true, but I don't believe you meant that. Otherwise, running the function before redisplay finished its job and returned after marking the window up-to-day is bound to catch incorrect position of point/cursor sometimes. > > Ah, I misunderstood your question. The answer for your question is > > "abort redisplay cycle after moving point out of intangible". > > In which case you risk inf-looping (and hence need to detect/prevent > it), same as with pre-redisplay-function. No, because the code to abort redisplay was written long ago and is well tested, by time if nothing else.