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 16:42:54 +0200 Message-ID: <83bnjmtnrl.fsf@gnu.org> References: <5505E34C.4000106@dancol.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> <83a8z6vlyn.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1426949010 23743 80.91.229.3 (21 Mar 2015 14:43:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 14:43:30 +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 15:43:20 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 1YZKcM-0004Vw-Mq for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 15:43:14 +0100 Original-Received: from localhost ([::1]:47995 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZKcH-000183-3E for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 10:43:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZKcE-00017v-CV for emacs-devel@gnu.org; Sat, 21 Mar 2015 10:43:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZKcB-0007vP-70 for emacs-devel@gnu.org; Sat, 21 Mar 2015 10:43:06 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:40667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZKcA-0007v3-QT for emacs-devel@gnu.org; Sat, 21 Mar 2015 10:43:03 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NLK00300GAAT600@mtaout25.012.net.il> for emacs-devel@gnu.org; Sat, 21 Mar 2015 16:38:01 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLK00LO7GNDDK70@mtaout25.012.net.il>; Sat, 21 Mar 2015 16:38:01 +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.181 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:184098 Archived-At: > From: Stefan Monnier > Cc: rudalics@gmx.at, dancol@dancol.org, emacs-devel@gnu.org > Date: Sat, 21 Mar 2015 09:59:35 -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. > > I think I don't understand what you're saying: > pre-redisplay-function is called at the beginning of redisplay, so of > course it's called "after the previous command". But in the course of this discussion, you suggested it to be called in other places as well. > > 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. > > Again I don't understand. My concern is again for your suggestions to call it under additional circumstances. > > Overall, it sounds like a non-trivial deviation from the original > > purpose of pre-redisplay-function, as I understand it. > > I assure you it isn't: `cursor-intangible' was very much in my mind > while I was implementing this new feature. Maybe so, but are you sure it is used for purposes that are similar to to what you envisioned? I am not, based on discussions since its introduction where it was suggested to use it. > > What I _am_ saying is that only redisplay, in its last part, knows > > where the cursor will be positioned. > > Of course: pre-redisplay-function only has control of `point', not over > the cursor. So it should move point away from the `cursor-intangible' > property. The difference between point and the place where the cursor > is drawn on screen is not really relevant to `cursor-intangible'. If I now mention, again, that redisplay can move point, we would be going in circles. Is that what you want?