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:59:28 +0100 Message-ID: <550D4100.6030500@gmx.at> 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> <83a8z6vlyn.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 1426932035 2182 80.91.229.3 (21 Mar 2015 10:00:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 10:00:35 +0000 (UTC) Cc: dancol@dancol.org, emacs-devel@gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 21 11:00: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 1YZGCc-0008Jl-Vj for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 11:00:23 +0100 Original-Received: from localhost ([::1]:47205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZGCc-000733-GQ for ged-emacs-devel@m.gmane.org; Sat, 21 Mar 2015 06:00:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZGCE-0006rg-8I for emacs-devel@gnu.org; Sat, 21 Mar 2015 06:00:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZGC6-0002Dc-NC for emacs-devel@gnu.org; Sat, 21 Mar 2015 05:59:58 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:58012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZGC6-0002DY-BY; Sat, 21 Mar 2015 05:59:50 -0400 Original-Received: from [178.190.165.16] ([178.190.165.16]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LjZhg-1Z6P9I02xs-00bYRK; Sat, 21 Mar 2015 10:59:40 +0100 In-Reply-To: <83a8z6vlyn.fsf@gnu.org> X-Provags-ID: V03:K0:80NT27Pc8ZCQ6dd0cza/KDcXuKmzxlcV2+Dzqf3CG0QOSs2yCc9 FfipevBNhUs/BJUQ4I/FVq8PhNm/qsO+6rItQw4TVjK3jfZqEBQF/DIs3eqf0U54uKrAW7t BUQaMOkJotHB6QOJJAHJpANUe3XSgw08kQSenVWqoU5sW19L8HfI0MBlh5d5WMBYufyrcDg jcCgXEzXkQWzlpack98Uw== 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.15 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:184080 Archived-At: > 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. This command, I presume. > 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? > 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. Redisplay happens in cycles where a subsequent cycle (and maybe also some input that arrived in between) can invalidate what happened before. And IMO certain things that happen at top level like making the selected window's buffer current or adjusting point in adjust_point_for_property are part of redisplay too. Here we disagree, obviously. > What I _am_ saying is that only redisplay, in its last part, knows > where the cursor will be positioned. Precisely; provided it runs to completion. >> 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. And sometimes even after a first redisplay, if I can trust my eyes. martin