From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Can we make set_point_both less expensive? Date: Sat, 21 Mar 2015 09:59:35 -0400 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1426946407 16634 80.91.229.3 (21 Mar 2015 14:00:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 14:00:07 +0000 (UTC) Cc: rudalics@gmx.at, dancol@dancol.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 21 14:59:57 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 1YZJwR-0004hQ-Dm for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 14:59:55 +0100 Original-Received: from localhost ([::1]:47879 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZJwQ-0006Se-9U for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 09:59:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZJwN-0006SZ-5H for emacs-devel@gnu.org; Sat, 21 Mar 2015 09:59:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZJwI-0002zj-2W for emacs-devel@gnu.org; Sat, 21 Mar 2015 09:59:51 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:60090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZJwH-0002zd-TH; Sat, 21 Mar 2015 09:59:46 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t2LDxZfJ006369; Sat, 21 Mar 2015 09:59:35 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4ADB6127B; Sat, 21 Mar 2015 09:59:35 -0400 (EDT) In-Reply-To: <83a8z6vlyn.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 21 Mar 2015 09:38:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5252=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5252> : inlines <2455> : streams <1409168> : uri <1886386> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:184093 Archived-At: >> > 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". > 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. pre-redisplay-function will be called at the beginning of every redisplay, so it can't assume anything about where point is. On the contrary, it's pre-redisplay-function which would be in charge of changing point (if needed) to take `cursor-intangible' into account. > 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. > 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'. Stefan