From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#35860: Delayed window positioning after buffer display Date: Sun, 16 Jun 2019 10:16:20 +0200 Message-ID: References: <87o93ucjsi.fsf@mail.linkov.net> <83ef4p7prf.fsf@gnu.org> <87a7fc51qm.fsf@mail.linkov.net> <83k1eg5pmx.fsf@gnu.org> <87k1efhkgp.fsf@mail.linkov.net> <2347769f-9ab3-c1b6-699e-4e89a7d8eb1c@gmx.at> <875zpb4zdw.fsf@mail.linkov.net> <878su5i67f.fsf@mail.linkov.net> <87muik3svu.fsf@mail.linkov.net> <4d0733b1-4ee0-222b-395a-8f26ff76f2da@gmx.at> <87imt6jva7.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="8460"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35860@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 16 10:17:19 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hcQLl-000260-RG for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Jun 2019 10:17:18 +0200 Original-Received: from localhost ([::1]:38084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcQLk-0004tu-KI for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Jun 2019 04:17:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57168) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcQLa-0004rd-Pw for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2019 04:17:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hcQLZ-0002aH-9I for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2019 04:17:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54350) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hcQLW-0002YA-1i for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2019 04:17:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hcQLV-00077J-R9 for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2019 04:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Jun 2019 08:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35860 X-GNU-PR-Package: emacs Original-Received: via spool by 35860-submit@debbugs.gnu.org id=B35860.156067299827306 (code B ref 35860); Sun, 16 Jun 2019 08:17:01 +0000 Original-Received: (at 35860) by debbugs.gnu.org; 16 Jun 2019 08:16:38 +0000 Original-Received: from localhost ([127.0.0.1]:39658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hcQL6-00076J-JS for submit@debbugs.gnu.org; Sun, 16 Jun 2019 04:16:36 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:48109) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hcQL3-000763-KS for 35860@debbugs.gnu.org; Sun, 16 Jun 2019 04:16:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1560672981; bh=nWSJR1yzxB+7TVO0NdJm7szuoOEhC10oOFLS8gD0YJI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=HHDTdf201gNk+60KHa6hmpeVKF08ddlkbZ4ADybluLl+OjscbMz2ZCSrZ+9LxEzwE 5EbcXP1MwTo2F1njgysmml+TrzRVa6qVVJYGXdoobjc4FlRQE3YTmWxClAi3KQWBDK vMqLL47MqzgA2GLiDimFz6Wo5HTf6GjDP3rlOPm0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.103]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M1zFf-1iVTjS2X9f-00u1Vd; Sun, 16 Jun 2019 10:16:21 +0200 In-Reply-To: <87imt6jva7.fsf@mail.linkov.net> Content-Language: de-DE X-Provags-ID: V03:K1:uDMPGfeEjSZJG0x8qE0PPv9OKha/nKKXsAkb7MxqX2jfhrOSumz mmV8DZ7YH8ncA/RoHcwBSeIhFZpm9tY7JnlkBzsn7fpJw9ruZO7qBpqlR1vFoh45CeDGVHE aNiypIrPdDh07XWarL9HpNmXoPhkRr0jC/n9D6//KpGbJCa9408OEYpV3iBPYO5e1ORTjkL cUzfXvrdL0yQE0Za7REMg== X-UI-Out-Filterresults: notjunk:1;V03:K0:/GrDYyPFw+A=:GSPN/hCeAcMVrnvqk8nT9g dkk1yYS25x0lP+yMCB+qfGq9K9u7d7Y666yAiQQAJg9LAewMHY9wtBwIv+F2kCDUXKW8EGqCi qbhaX4+flvOcFog4ntk+QWNdZUyrmjQ+sLnlZvtMMbjiNPS8qFWCZPW3hbHIbxDHEindxKTS7 8pwMylRxHTLucnACByQBb4U/kTkEYNsPLvYbxs1vT+roUCw4po4/s12YVrLtzL1naF0NEHQB2 7pApiMAiDwYhsmTpMVQksGMBGLJdFfdrppo/orl4sZ8Yv2v2ujmEVrW+ZpXxgNp+Uw5WPxSct HRP2SbUXH5p2KG6RgDmO9zUcpawSE+v2weyag+CMvHc3inyHslTuRAyg7dZHeZ+VACZxCYJmA Z4kUD6lhAtOhouvUs+x6Z8XzKgWwn6Qvlly3qLHohLsn4P0NyBPKCbaVO3UjzppktXNHgbNIN 7JnsTNUbO/tHBG229/bUNr9vOBv92SLeg3ki/xZNe680T6TDdX7sNthSeXlEUODuf2gDDy0YP T6mPyII2yw73LruGWNUz3STO2CkEwbdB3IGI/NOqWhIZ+BXxREUkc/6/9tjBu+a4SCeVlzuOO Ri80JWShbNrW/wQha+lQHkJLj0FLe8VFWOCI+RNQkztvrYqygpJjQtktl4gtLO2DHEpCzCcFH J0fm3OQiJjCqDb2yAUC7iYz43pjTRpVF0rD2OG/acrIcbQJcH2NSYOZMvi3qF/lt+mwRnYTtq CY1hbcPxRysJ4MTHamhqewwr30FLXaRORj/W1z+p6EmIytibea1reElc40gOPYXx/XKw6WtW X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:160652 Archived-At: > Generalized version does exactly what 'help-window-point-marker' > used to do, i.e.: > > ;; `help-window-point-marker' is a marker you can move to a valid > ;; position of the buffer shown in the help window in order to override > ;; the standard positioning mechanism (`point-min') chosen by > ;; `with-output-to-temp-buffer' and `with-temp-buffer-window'. > ;; `with-help-window' has this point nowhere before exiting. Currently > ;; used by `view-lossage' to assert that the last keystrokes are always > ;; visible. > (defvar help-window-point-marker (make-marker) > "Marker to override default `window-point' in help windows.") > > but for all windows instead of only help windows, i.e.: > > "Marker to override default `window-point' in all windows." > > So do you think about just removing the prefix `help-' from the name: > `window-point-marker'? Currently 'temp-buffer-window-show' has (goto-char (point-min)) and 'internal-temp-output-buffer-show' has (set-window-start window (point-min) t) ;; This should not be necessary. (set-window-point window (point-min)) For help windows (windows showing *Help*) 'help-window-point-marker' allows to override these assignments by a suitable assignment for that variable. It's hackish but still done in a pretty restricitve fashion as follows. First 'help-window-point-marker' is reset in 'with-help-window' via ;; Make `help-window-point-marker' point nowhere. The only place ;; where this should be set to a buffer position is within BODY. (set-marker help-window-point-marker nil) - a security guard, because that marker should be nil at that time anyway. Then 'help-window-point-marker' may be set by the BODY of 'with-help-window' and 'help-window-setup' will pick that up guarded as (when (eq (marker-buffer help-window-point-marker) help-buffer) (set-window-point window help-window-point-marker) ;; Reset `help-window-point-marker'. (set-marker help-window-point-marker nil)) thus (1) checking whether the marker buffer matches and (2) immediately resetting that marker to nil. Can you provide equivalent security guards when generalizing that variable? For example, you proposed (defun window--display-buffer (buffer window type &optional alist) "Display BUFFER in WINDOW. [...] + + (when window-start + (set-window-start window window-start) + (setq window-start nil)) + + (when window-point + (set-window-point window window-point) + (setq window-point nil)) What happens with these markers when 'display-buffer-no-window' gets called? Or some user provided routine provokes an unhandled error? You don't even check the marker buffer of these variables so some old, completely unrelated marker could get reused here. The *Help* buffer is special because it's used in a centralized way for any help Emacs provides (that's also why it has a browsable history). Buffers displayed by 'display-buffer' OTOH don't obey any such restricitions. They don't even have a BODY as the only place where markers as the ones you propose can be set. Also 'temp-buffer-window-show' and 'internal-temp-output-buffer-show' are special because they explicitly wants to set window point to BOB. So there's some predefined mechanism we (1) are aware of and (2) want to override deliberately. So we'd carefully have to examine first how the mechanism you propose could be abused, how to handle any errors in using and failing to reset these markers and last but not least tell why we don't provide 'window-point' and 'window-start' action alist entries instead of such global variables. martin