From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master fd8f724: * src/xdisp.c (overlay_arrows_changed_p): Fix last change. Date: Wed, 01 Mar 2017 19:03:06 +0200 Message-ID: <83bmtlnd4l.fsf@gnu.org> References: <83y3wqnvol.fsf@gnu.org> <83tw7enq58.fsf@gnu.org> <83r32inna5.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1488388027 18876 195.159.176.226 (1 Mar 2017 17:07:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Mar 2017 17:07:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 01 18:07:03 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cj7iO-0004Fe-CQ for ged-emacs-devel@m.gmane.org; Wed, 01 Mar 2017 18:07:00 +0100 Original-Received: from localhost ([::1]:47802 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj7iU-0001fz-GC for ged-emacs-devel@m.gmane.org; Wed, 01 Mar 2017 12:07:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj7f1-00089o-MX for emacs-devel@gnu.org; Wed, 01 Mar 2017 12:03:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cj7ey-00035h-JA for emacs-devel@gnu.org; Wed, 01 Mar 2017 12:03:31 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj7ey-00035d-Gg; Wed, 01 Mar 2017 12:03:28 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1026 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cj7ex-00054p-Pm; Wed, 01 Mar 2017 12:03:28 -0500 In-reply-to: (message from Stefan Monnier on Tue, 28 Feb 2017 15:02:35 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:212682 Archived-At: > From: Stefan Monnier > Date: Tue, 28 Feb 2017 15:02:35 -0500 > > (with-current-buffer A > (setq-local overlay-arrow-position (copy-marker 10))) > (with-current-buffer B > (setq-local overlay-arrow-position (copy-marker 5))) > > after redisplay, what should be the value of > > (get 'overlay-arrow-position 'last-arrow-position) > > ? If it's 5 and we perform a redisplay, will buffer A be refreshed even > if no changes occurred in it? I'd expect the value to be nil, actually, since the buffer from which you evaluate the above is most probably neither A nor B. In any case, if you expect a buffer shown in a non-selected window to be redisplayed just because its overlay-arrow was modified, this never worked in Emacs. You can see that clearly by trying the reproducer file at the end of this message: load it into "emacs -Q" and then type F9 -- you will see that the overlay-arrow is not updated. But as soon as you type "M-x", which enforces a more thorough redisplay, the updates become visible. And your recent changes make this worse, because previously it was enough to type F9 from a window displaying one of the two buffers which have overlay-arrows, whereas now the display is not updated in that case. > The way I look at it, this code fundamentally assumes that the variables > on that list are not buffer-local (not only because of the use of > global symbol properties but also because it only considers > the value of those vars in the buffer which happens to be current). I think it assumes that at most one buffer changes its overlay-arrows between two redisplay cycles. To fix this thoroughly, we probably need to add overlay-arrow-position, overlay-arrow-string, and overlay-arrow-bitmap to the list of variables at the end of frame.el which trigger redisplay of their respective buffers. But that is not enough, because redisplay also wants to know whether a buffer whose window is about to be redisplayed has changed one of these, in order to disable certain redisplay optimizations. So maybe we should add a flag to the buffer object where this could be recorded. > % grep -l local.\*overlay-arrow-position **/*.el > calc/calc.el > gnus/gnus-sum.el > mpc.el > net/rcirc.el > progmodes/compile.el > progmodes/python.el > % > > And from my understanding of how this code works, we can both end up > redisplaying unnecessarily, as well as fail to redisplay when needed. Changes in overlay-arrows always triggered a thorough redisplay. Here's the reproducer I promised: (switch-to-buffer-other-window "A") (insert "a\na\na\na\na\na\na\na\na\na\na\na\na\na\na\na\na\na\na\na\n") (goto-char (point-min)) (split-window-vertically) (switch-to-buffer-other-window "B") (insert "b\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\nb\n") (goto-char (point-min)) (switch-to-buffer-other-window "*scratch*") (setq cur-line 1) (defun my-move-arrow () (interactive) (with-current-buffer "A" (set (make-local-variable 'overlay-arrow-position) (copy-marker (1+ (line-end-position cur-line))))) (with-current-buffer "B" (set (make-local-variable 'overlay-arrow-position) (copy-marker (1+ (line-end-position cur-line))))) (setq cur-line (1+ cur-line))) (define-key global-map [f9] 'my-move-arrow)