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: show-enclosing-scopes Date: Thu, 17 May 2018 18:07:29 +0300 Message-ID: <83wow2iamm.fsf@gnu.org> References: <5cb3e5a6-310f-1f2a-ceb8-01b929158ebb@gmail.com> <594F9BDF-F041-4B8D-8425-0BE2AABAA448@gnu.org> <258be7dd-0bf6-f5b1-20d1-08ea65a177e8@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1526569561 31732 195.159.176.226 (17 May 2018 15:06:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 May 2018 15:06:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 17 17:05:57 2018 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 1fJKTc-00089A-Tl for ged-emacs-devel@m.gmane.org; Thu, 17 May 2018 17:05:57 +0200 Original-Received: from localhost ([::1]:59984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fJKVi-0006Ym-FB for ged-emacs-devel@m.gmane.org; Thu, 17 May 2018 11:08:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fJKV1-0006YB-7l for emacs-devel@gnu.org; Thu, 17 May 2018 11:07:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fJKUx-0008VM-8F for emacs-devel@gnu.org; Thu, 17 May 2018 11:07:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fJKUx-0008VH-2K; Thu, 17 May 2018 11:07:19 -0400 Original-Received: from [176.228.60.248] (port=2434 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fJKUw-0004tH-Eb; Thu, 17 May 2018 11:07:18 -0400 In-reply-to: (message from Stefan Monnier on Thu, 17 May 2018 10:31:44 -0400) 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:225368 Archived-At: > From: Stefan Monnier > Date: Thu, 17 May 2018 10:31:44 -0400 > > > (progn (scroll-up 1) (beginning-of-buffer)) > > So you have here an ambiguous specification: on the one hand you > specified the window-start via scroll-up, on the other you specified > point with beginning-of-buffer. Since point needs to be within the > visible part of the buffer, the redisplay engine has to choose which of > the two requests to override. Right. And using scroll commands forces redisplay to obey the window-start setting. > Now the question is why does your package end up in situations with such > ambiguous specifications? I don't understand that, either. I looked at the relevant code in the package, and my interpretation is this: . scroll-up/down is used to prevent text in the window from moving vertically when the window showing the scopes is deleted: without the scroll, text would move up, since the window to be deleted is above the window showing the current buffer. (Why the scopes window needs to be deleted and recreated anew each command, and why is it shown above and not below, are two other relevant questions, but let's assume it's indeed required.) . goto-char is called in the same function that calls scroll-up/down so that point is kept where it was before Assuming that my interpretation is accurate, I have two questions: . why is there a need to call goto-char at all? Since all the text that was visible before the scroll will also be visible after it, point should be visible as well, and there should be no need to move it. . if indeed there is a need to move point due to some factor I'm missing, that goto-char should bring point back into the window, in which case redisplay will not need to move point again. IOW, using beginning-of-buffer in the short recipe posted to explain the problem does not seem to be representative of the real-life use, and I again don't understand the need for calling 'redisplay' to avoid something. > Assuming you don't have any control over the scroll-up part and you want > to override it via beginning-of-buffer, there is indeed currently no > easy way to get that, AFAICT: this is controlled by the `force_start` > field in the window which will have been set by scroll-up (and can be > set via set-window-start) but can't be "unset" directly. > Maybe you can try > > (defun my-unset-window-force-start () > (cl-assert (eq (current-buffer) (window-buffer))) > (save-excursion > (let ((buf (current-buffer))) > (with-temp-buffer > (set-window-buffer (selected-window) (current-buffer) 'keep-margins) > (set-window-buffer (selected-window) buf 'keep-margins))))) > > since it seems that set-window-buffer does unset `force-start`. > It will also cause undesirable side-effects, but maybe in your case they > will be less annoying than those of `redisplay`. I'd say if it is known that the goal point is not inside the visible portion of the buffer after scrolling, don't scroll at all; instead, just move point to the goal. But as I said above, I don't think I understand the details well enough yet.