From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Can we make set_point_both less expensive? Date: Sat, 21 Mar 2015 10:58:01 +0100 Message-ID: <550D40A9.7060905@gmx.at> References: <5505E34C.4000106@dancol.org> <838uex1u1m.fsf@gnu.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1426931920 32586 80.91.229.3 (21 Mar 2015 09:58:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 09:58:40 +0000 (UTC) Cc: dancol@dancol.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 21 10:58:26 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 1YZGAg-0006LP-OJ for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 10:58:23 +0100 Original-Received: from localhost ([::1]:47195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZGAf-00059Y-Qn for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 05:58:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZGAc-00059G-8P for emacs-devel@gnu.org; Sat, 21 Mar 2015 05:58:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZGAb-0001lX-DK for emacs-devel@gnu.org; Sat, 21 Mar 2015 05:58:18 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:60187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZGAX-0001lB-LW; Sat, 21 Mar 2015 05:58:13 -0400 Original-Received: from [178.190.165.16] ([178.190.165.16]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MTSrf-1Yyo3q3er9-00SSLo; Sat, 21 Mar 2015 10:58:10 +0100 In-Reply-To: <83egojv02r.fsf@gnu.org> X-Provags-ID: V03:K0:m9QQzDZMuognnEJCwJ87cZGlf8/XVjpbl/rheq9pvMHfFbi1uaR 1ruDZyQ/OL8EnRNGqoMkltIhgKQKAsXYOGZmyMI8SU8TUoiRHv1Iv1ckBaqV+tktBDv04Hx ll/QbergxfePnbrSnd9jnFCrmadqpsEPa1JriCXcoRJi4bzfLPQecT197DMdO7Im8tsOAbz K5QMwURLWHLo5Vqhd2siA== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.15.18 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:184076 Archived-At: > It could, but AFAIU, this is not the only situation that is being > 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. That's not a scrolling scenario you > describe. Stefan will tell us whether he has any additional issues in mind. Here I'm only concerned about the scrolling scenario. >> > And cursor is always set where point is, we have no other strategy for >> > positioning the cursor. >> >> After `scroll-left'? > > Yes, after scroll-left, too. We simply put the cursor as close to > point as possible. But not necessarily _where point is_. >> Isn't adjust_point_for_property some sort of redisplay revisited? > > No. It does nothing that is related to display. Can't it trigger a new redisplay? >> They would determine the position of the cursor when an intangible area >> starts or ends within them. > > Sorry, too much "they" in this sentence, I don't really understand > what you are sayin, or how it is relevant to the issue at hand. Consider the following scenario: (1) Using the scrollbar thumb, the user scrolls window text thus implicitly establishing a new window start position WS. (2) Respecting WS, redisplay puts window point at some position WP. (3) A function on `pre-redisplay-function' decides that WP would end up within intangible text and moves WP to a position WT. (4) Redisplay notices that WT would end up in the scroll margin and scrolls the window invalidating WS. As a result windw text would not scroll as intended by the user in (1). But if redisplay were aware of intangible text, it would handle both - the intangible property and the scroll margin - in (2) and there would be no need to enter the (3)-(4) rigmarole. Note that (3) means we have to search all text/overlay properties of every window that gets redisplayed for the sole purpose of detecting the presence of intangible text. In my estimate 99.99% of our windows don't contain such text. martin