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: Sat, 21 Mar 2015 20:28:07 +0200 Message-ID: <831tkitdc8.fsf@gnu.org> References: <5505E34C.4000106@dancol.org> <5508800E.3070600@gmx.at> <55092AE0.1080206@gmx.at> <5509CC67.5010207@gmx.at> <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> <550D4100.6030500@gmx.at> <83k2yatypj.fsf@gnu.org> <83a8z6tnoq.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1426962531 18287 80.91.229.3 (21 Mar 2015 18:28:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 18:28:51 +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 Sat Mar 21 19:28:43 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 1YZO8Y-0007aG-93 for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 19:28:42 +0100 Original-Received: from localhost ([::1]:48616 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZO8X-0002Nt-EC for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 14:28:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZO8F-0002Kp-6q for emacs-devel@gnu.org; Sat, 21 Mar 2015 14:28:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZO8C-0001ZO-0d for emacs-devel@gnu.org; Sat, 21 Mar 2015 14:28:23 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:39656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZO8B-0001YU-PE for emacs-devel@gnu.org; Sat, 21 Mar 2015 14:28:19 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NLK00000R8JMW00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 21 Mar 2015 20:28:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLK000HIRB6IL20@a-mtaout22.012.net.il>; Sat, 21 Mar 2015 20:28:18 +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.172 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:184109 Archived-At: > From: Stefan Monnier > Date: Sat, 21 Mar 2015 13:28:18 -0400 > Cc: rudalics@gmx.at, dancol@dancol.org, emacs-devel@gnu.org > > >> >> > Another, related, requirement is that we never call > >> >> > pre-redisplay-function when point is in a position that is not > >> >> > supposed to be visible by the user. > >> >> Do you mean invisible text here? > >> > No, I mean positions traversed while "this command" is executed. The > >> > position shown to the user is the last one of those, but how do we > >> > ensure that pre-redisplay-function is never run for those? > >> Ah, I see what you mean now: the command ensures this by not causing > >> redisplay during its execution. > > Commands don't have full enough control to ensure that, I think. > > Various features and customizations could trigger redisplay behind > > their back. > > Of course, but if redisplay is triggered, then the state is > made visible. > So if the state has "a position that is not supposed to be visible by > the user" it's an error for the code to cause redisplay. > The existence and use of pre-redisplay-function doesn't affect this. I understand the theory, but I think in practice doing that in pre-redisplay-function will not do a perfect job, perhaps not even a good enough job. The position of point/cursor shown to the user is known _at_the_end_ of redisplay, not at its beginning. the latter can approximate the former, but only approximate.