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 09:38:56 +0200 Message-ID: <83a8z6vlyn.fsf@gnu.org> References: <5505E34C.4000106@dancol.org> <8361a029p2.fsf@gnu.org> <83vbi0zukw.fsf@gnu.org> <55080104.9070606@gmx.at> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1426923578 13051 80.91.229.3 (21 Mar 2015 07:39:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 07:39:38 +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 08:39:28 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 1YZE0E-000420-Qn for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 08:39:27 +0100 Original-Received: from localhost ([::1]:46893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZE09-0007az-0Y for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 03:39:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZDzr-0007af-Ok for emacs-devel@gnu.org; Sat, 21 Mar 2015 03:39:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZDzm-0003Vd-Vg for emacs-devel@gnu.org; Sat, 21 Mar 2015 03:39:03 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:37811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZDzm-0003VY-NY for emacs-devel@gnu.org; Sat, 21 Mar 2015 03:38:58 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NLJ00500WU5X600@mtaout26.012.net.il> for emacs-devel@gnu.org; Sat, 21 Mar 2015 09:39:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLJ000L4XADV150@mtaout26.012.net.il>; Sat, 21 Mar 2015 09:39:49 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 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:184073 Archived-At: > From: Stefan Monnier > Cc: martin rudalics , dancol@dancol.org, emacs-devel@gnu.org > Date: Fri, 20 Mar 2015 17:53:22 -0400 > > > discussed. Stefan wants redisplay to move point also in the case > > where some Lisp moved point and entered a region of buffer positions > > that has a certain text property. > > Yes and no: I want pre-redisplay-function to do that. This will only work if pre-redisplay-function is called in a way that guarantees it will catch the position of point after the previous command. 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. Overall, it sounds like a non-trivial deviation from the original purpose of pre-redisplay-function, as I understand it. > Whether you consider it as "redisplay" or not is another question, I don't consider pre-redisplay-function part of redisplay. Martin was clearly talking about redisplay, so I answered in kind. What I _am_ saying is that only redisplay, in its last part, knows where the cursor will be positioned. > but when I say "redisplay" in this thread I mean the C part that > fills & uses the glyph matrices That part of redisplay doesn't yet know where the cursor will be. Cursor positioning happens after that.