From unknown Mon Jun 23 20:16:32 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#19576 <19576@debbugs.gnu.org> To: bug#19576 <19576@debbugs.gnu.org> Subject: Status: 24.4; Broken function in `window-size-change-functions' cause `write-file' to write the wrong buffer Reply-To: bug#19576 <19576@debbugs.gnu.org> Date: Tue, 24 Jun 2025 03:16:32 +0000 retitle 19576 24.4; Broken function in `window-size-change-functions' cause= `write-file' to write the wrong buffer reassign 19576 emacs submitter 19576 Anders Lindgren severity 19576 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 12 18:38:12 2015 Received: (at submit) by debbugs.gnu.org; 12 Jan 2015 23:38:12 +0000 Received: from localhost ([127.0.0.1]:54811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YAoYl-0002fS-Be for submit@debbugs.gnu.org; Mon, 12 Jan 2015 18:38:12 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35923) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YAoYg-0002ew-LF for submit@debbugs.gnu.org; Mon, 12 Jan 2015 18:38:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAoYZ-000271-E4 for submit@debbugs.gnu.org; Mon, 12 Jan 2015 18:38:01 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:50735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoYZ-00026v-BP for submit@debbugs.gnu.org; Mon, 12 Jan 2015 18:37:59 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoYX-0001py-0G for bug-gnu-emacs@gnu.org; Mon, 12 Jan 2015 18:37:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAoYU-00022T-VH for bug-gnu-emacs@gnu.org; Mon, 12 Jan 2015 18:37:56 -0500 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:37254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAoYU-00021Q-KK for bug-gnu-emacs@gnu.org; Mon, 12 Jan 2015 18:37:54 -0500 Received: by mail-wi0-f173.google.com with SMTP id em10so2041412wid.0 for ; Mon, 12 Jan 2015 15:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ya07l5W/+nMlzS1RtHlsMTOu0rcnU28NS3HsujUIUY8=; b=jyCam0i6ThxZanGm4YK9mm6TXD7gSp8JgBgfabWtJfgLoT7VSBr0KdhetNXpBV4pvT Vt2czrby6qiw3st+r4F3oCL+pif9whh4vrWQ5MqyQmyEKj8qGCFOwIbkbdkrMQwXwtzw WNBgWph/yjDQUip6a5MZB6v9rmBG5xWAIgs3vjRRCyvAE2sWw6Wl8rG5x/QwkIZKfWbg IfUhwqWlC2rPu4ThCVKHpawNwp0Xcs1Hcum0ZQnJnfNQpiHyUbM47yz6weoMZH5hgQ9H xJnEC3kk30wPG8gotcKccSwl1O5E4qixaB1lRjpOo/wQMuqHaQhluBE6vIQXel/G7O2s Otfg== MIME-Version: 1.0 X-Received: by 10.194.6.70 with SMTP id y6mr2259418wjy.97.1421105873089; Mon, 12 Jan 2015 15:37:53 -0800 (PST) Received: by 10.216.92.72 with HTTP; Mon, 12 Jan 2015 15:37:53 -0800 (PST) Date: Tue, 13 Jan 2015 00:37:53 +0100 Message-ID: Subject: 24.4; Broken function in `window-size-change-functions' cause `write-file' to write the wrong buffer From: Anders Lindgren To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary=047d7b5d98afc0fc0a050c7cfe75 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --047d7b5d98afc0fc0a050c7cfe75 Content-Type: text/plain; charset=UTF-8 Hi! I have noticed that if a broken window size change function is installed, `write-file' will save the content of the wrong buffer. One such broken windows-size-change-function is `follow-window-size-change' of Follow Mode (a package I wrote many years ago). To verify this, place the following piece of code in a buffer and evaluate it (lets call this the CODE buffer). Call M-x test-write-file RET. The code first creates a new file with the content "Alpha", this works OK. It then tries to overwrite the file with the content "Beta", answer "y" when asked to confirm this. Now, the file contains the content of the CODE buffer, and the CODE buffer is associated with the "test.txt" file name, which clearly is incorrect. What happens is that the `y-or-n-p' triggers a window size change callback. `follow-window-size-change' walks through all buffers to check if anything is needed to be done. It then restores the original frame, the original buffer, and the original window. Unfortunately, when restoring the original window, it also sets the buffer associated with the window as current, this causes `write-file' to write the wrong buffer. This will, most likely, affect other functions also using `y-or-n-p', or otherwise trigger a window change callback. Interestingly, the problem only is visible in Emacs 24.3 and 24.4, even though `follow-window-size-change' has been broken much longer than that. This makes me wonder if there has been a change done to the code that calls the functions in `window-size-change-functions'. Of course, this should be corrected in Follow Mode (maybe a simple reordering of the restore expression would suffice). However, it might be a good idea for Emacs to ensure that the correct frame, window, and buffer is set, in case of other broken size change functions. ;;; write-file-bug.el ;; Works in 24.2, broken in 24.3. (require 'follow) ;; This simulates that there is at least one buffer with Follow Mode ;; enabled. (add-hook 'window-size-change-functions 'follow-window-size-change t) (defvar test-write-file--filename "test.txt") (defun test-write-file--write-to-file (s) (with-temp-buffer (insert s) (write-file test-write-file--filename t))) (defun test-write-file () (interactive) (when (file-exists-p test-write-file--filename) (delete-file test-write-file--filename)) (test-write-file--write-to-file "Alpha") (test-write-file--write-to-file "Beta")) ;;; white-file-bug.el ends here. Sincerely, Anders Lindgren In GNU Emacs 24.4.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21) of 2014-10-21 on builder10-9.porkrind.org Windowing system distributor `Apple', version 10.3.1265 Configured using: `configure --with-ns' Important settings: value of $LC_CTYPE: UTF-8 locale-coding-system: utf-8-unix Major mode: Text Minor modes in effect: tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: x e v a l - b u f x e t e s t - e w y x r e p o o r < return> Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Saving file /Users/anders/emacs/src/bugs/test.txt... Wrote /Users/anders/emacs/src/bugs/test.txt File `test.txt' exists; overwrite? (y or n) y Saving file /Users/anders/emacs/src/bugs/test.txt... Wrote /Users/anders/emacs/src/bugs/test.txt Making completion list... Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils help-mode follow easymenu vc-dispatcher vc-svn time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process cocoa ns multi-tty emacs) Memory information: ((conses 16 74101 5798) (symbols 48 17581 0) (miscs 40 40 159) (strings 32 10646 4637) (string-bytes 1 280871) (vectors 16 9360) (vector-slots 8 377207 14310) (floats 8 54 183) (intervals 56 224 0) (buffers 960 13)) --047d7b5d98afc0fc0a050c7cfe75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

I have noticed that if a= broken window size change function is installed, `write-file' will sav= e the content of the wrong buffer. One such broken windows-size-change-func= tion is `follow-window-size-change' of Follow Mode (a package I wrote m= any years ago).

To verify this, place the followin= g piece of code in a buffer and evaluate it (lets call this the CODE buffer= ). Call M-x test-write-file RET. The code first creates a new file with the= content "Alpha", this works OK. It then tries to overwrite the f= ile with the content "Beta", answer "y" when asked to c= onfirm this. Now, the file contains the content of the CODE buffer, and the= CODE buffer is associated with the "test.txt" file name, which c= learly is incorrect.

What happens is that the `y-o= r-n-p' triggers a window size change callback. `follow-window-size-chan= ge' walks through all buffers to check if anything is needed to be done= . It then restores the original frame, the original buffer, and the origina= l window. Unfortunately, when restoring the original window, it also sets t= he buffer associated with the window as current, this causes `write-file= 9; to write the wrong buffer.

This will, most like= ly, affect other functions also using `y-or-n-p', or otherwise trigger = a window change callback.

Interestingly, the probl= em only is visible in Emacs 24.3 and 24.4, even though `follow-window-size-= change' has been broken much longer than that. This makes me wonder if = there has been a change done to the code that calls the functions in `windo= w-size-change-functions'.

Of course, this shou= ld be corrected in Follow Mode (maybe a simple reordering of the restore ex= pression would suffice). However, it might be a good idea for Emacs to ensu= re that the correct frame, window, and buffer is set, in case of other brok= en size change functions.

;;; write-file-bug.el

;; Works in 24.2, broken in 24.3.

(require 'follow)

;; This simu= lates that there is at least one buffer with Follow Mode
;; enabl= ed.
(add-hook 'window-size-change-functions 'follow-windo= w-size-change t)

(defvar test-write-file--filename= "test.txt")

(defun test-write-file--wri= te-to-file (s)
=C2=A0 (with-temp-buffer
=C2=A0 =C2=A0 (= insert s)
=C2=A0 =C2=A0 (write-file test-write-file--filename t))= )

(defun test-write-file ()
=C2=A0 (inte= ractive)
=C2=A0 (when (file-exists-p test-write-file--filename)
=C2=A0 =C2=A0 (delete-file test-write-file--filename))
= =C2=A0 (test-write-file--write-to-file "Alpha")
=C2=A0 = (test-write-file--write-to-file "Beta"))

;;; white-file-bug.el ends here.

Sincerely,=
=C2=A0 =C2=A0 Anders Lindgren


In GNU Emacs 24.4.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.= 21)
=C2=A0of 2014-10-21 on builder10-9.porkrind.org
Windowing system distributor `= Apple', version 10.3.1265
Configured using:
=C2=A0`= configure --with-ns'

Important settings:
=
=C2=A0 value of $LC_CTYPE: UTF-8
=C2=A0 locale-coding-system= : utf-8-unix

Major mode: Text

=
Minor modes in effect:
=C2=A0 tooltip-mode: t
=C2= =A0 electric-indent-mode: t
=C2=A0 mouse-wheel-mode: t
= =C2=A0 tool-bar-mode: t
=C2=A0 menu-bar-mode: t
=C2=A0 = file-name-shadow-mode: t
=C2=A0 global-font-lock-mode: t
=C2=A0 font-lock-mode: t
=C2=A0 blink-cursor-mode: t
= =C2=A0 auto-composition-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-compression-mode: t
=C2=A0 line-number-mode: = t
=C2=A0 transient-mark-mode: t

Recent i= nput:
<escape> x e v a l - b u f <tab> <return>= <escape>=C2=A0
x e <backspace> t e s t - e <backs= pace> w <tab> <return>=C2=A0
y <escape> x r = e p o <tab> o <backspace> r <tab> <
return&g= t;

Recent messages:
For information abou= t GNU Emacs and the GNU system, type C-h C-a.
Saving file /Users/= anders/emacs/src/bugs/test.txt...
Wrote /Users/anders/emacs/src/b= ugs/test.txt
File `test.txt' exists; overwrite? (y or n) y
Saving file /Users/anders/emacs/src/bugs/test.txt...
Wrot= e /Users/anders/emacs/src/bugs/test.txt
Making completion list...=

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacs= bug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm= -encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendma= il rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-ut= ils help-mode follow easymenu vc-dispatcher
vc-svn time-date tool= tip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel = ns-win tool-bar dnd fontset image regexp-opt
fringe tabulated-lis= t newcomment lisp-mode prog-mode register page
menu-bar rfn-eshad= ow timer select scroll-bar mouse jit-lock font-lock
syntax faceme= nu font-core frame cham georgian utf-8-lang misc-lang
vietnamese = tibetan thai tai-viet lao korean japanese hebrew greek
romanian s= lovak czech european ethiopic indian cyrillic chinese
case-table = epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
load= defs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtab= le-print-readable backquote make-network-process cocoa ns
multi-t= ty emacs)

Memory information:
((conses 1= 6 74101 5798)
=C2=A0(symbols 48 17581 0)
=C2=A0(miscs 4= 0 40 159)
=C2=A0(strings 32 10646 4637)
=C2=A0(string-b= ytes 1 280871)
=C2=A0(vectors 16 9360)
=C2=A0(vector-sl= ots 8 377207 14310)
=C2=A0(floats 8 54 183)
=C2=A0(inte= rvals 56 224 0)
=C2=A0(buffers 960 13))

--047d7b5d98afc0fc0a050c7cfe75-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 16 14:18:32 2015 Received: (at 19576) by debbugs.gnu.org; 16 Nov 2015 19:18:32 +0000 Received: from localhost ([127.0.0.1]:40466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyPIN-0008Dz-TI for submit@debbugs.gnu.org; Mon, 16 Nov 2015 14:18:32 -0500 Received: from mail-yk0-f178.google.com ([209.85.160.178]:34910) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyPIM-0008Dr-85 for 19576@debbugs.gnu.org; Mon, 16 Nov 2015 14:18:30 -0500 Received: by ykba77 with SMTP id a77so256322291ykb.2 for <19576@debbugs.gnu.org>; Mon, 16 Nov 2015 11:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yvSPed9rqwG/nAowU1dDLW2kUmF/dOGBB2Sa+arfA3c=; b=Yd3YaN6AdOPDCvuDV1PdteCt+AHQKFLnSIQJ4ANfk88S145z8aE5fqxFDtOzpmjxLB Vk7x4sttm/5eTpabPnW4MLifkv4LXEx5Ckj0bRwC1OenMl8SiQQBgocTaOIBYFXNW539 6f07q3mpCYPOaAfhGm0MLAYOW8dwwQJe0c80TsCi1U33ZeFIlSHQmiC0qhejxJ/YwMKm pVY/Bnh0xdOnN91rCNaNLMmfgfCLfyvLHsorYdBq+OQ7i4ES+YRDSsYkbetGJ9iQeZ8/ hyB6C+uIBR1D6fjDckgcBDa2ESRaG2jPY+Kyz3Wf9mKLQFwf0MGpLFQWMrce1Jhu4g4a IagA== MIME-Version: 1.0 X-Received: by 10.129.105.3 with SMTP id e3mr37229561ywc.244.1447701509528; Mon, 16 Nov 2015 11:18:29 -0800 (PST) Received: by 10.31.210.133 with HTTP; Mon, 16 Nov 2015 11:18:29 -0800 (PST) Date: Mon, 16 Nov 2015 20:18:29 +0100 Message-ID: Subject: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: martin rudalics , 19576@debbugs.gnu.org Content-Type: multipart/alternative; boundary=001a114902183767a10524ad4636 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a114902183767a10524ad4636 Content-Type: text/plain; charset=UTF-8 Hi, about a year ago I reported that `write-file' sometimes writes the wrong buffer to the destination file. Unfortunately, I had no feedback regarding this. When I checked today, the bug is still there. The problem occurs when a function on the hook `window-size-change-functions' change the current buffer. The functions in this hook are executed when `y-or-n-p' is called, which is used by `write-file' to verify that it is OK to overwrite an existing file. One such function is `follow-window-size-change' in follow.el. This problem is not limited to `write-file' -- all functions calling `y-or-n-p' are affected by this! Of course, it would be relatively straight forward to modify the offending function (and all other similar functions). However, a more robust solution would be for the code that calls the functions on the hook to ensure that it isn't derailed when the buffer is changed. Personally, I don't know that part of the code well enough to do this change. Martin, is this something that you could look into, or suggest someone who can? See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19576 for more details. -- Anders Lindgren --001a114902183767a10524ad4636 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

about a year ago I reported that `w= rite-file' sometimes writes the wrong buffer to the destination file. U= nfortunately, I had no feedback regarding this. When I checked today, the b= ug is still there.

The problem occurs when a = function on the hook `window-size-change-functions' change the current = buffer. The functions in this hook are executed when `y-or-n-p' is call= ed, which is used by `write-file' to verify that it is OK to overwrite = an existing file. One such function is `follow-window-size-change' in f= ollow.el.

This problem is not limited to= `write-file' -- all functions calling `y-or-n-p' are affected by t= his!

Of course, it would be relatively straight fo= rward to modify the offending function (and all other similar functions). H= owever, a more robust solution would be for the code that calls the functio= ns on the hook to ensure that it isn't derailed when the buffer is chan= ged.

Personally, I don't know that part of the= code well enough to do this change. Martin, is this something that you cou= ld look into, or suggest someone who can?

=

=C2=A0 =C2=A0 -- Anders Lindgren

--001a114902183767a10524ad4636-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 16 14:46:33 2015 Received: (at 19576) by debbugs.gnu.org; 16 Nov 2015 19:46:33 +0000 Received: from localhost ([127.0.0.1]:40475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyPjU-0000TF-Ns for submit@debbugs.gnu.org; Mon, 16 Nov 2015 14:46:32 -0500 Received: from mout.gmx.net ([212.227.17.20]:54571) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyPjS-0000T7-Om for 19576@debbugs.gnu.org; Mon, 16 Nov 2015 14:46:31 -0500 Received: from [192.168.1.100] ([213.162.68.70]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LwW8p-1aS0HC0i5P-018NE4; Mon, 16 Nov 2015 20:46:29 +0100 Message-ID: <564A3292.2050807@gmx.at> Date: Mon, 16 Nov 2015 20:46:26 +0100 From: martin rudalics MIME-Version: 1.0 To: Anders Lindgren , 19576@debbugs.gnu.org Subject: Re: bug#19576: write-file writes the wrong buffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:gLTFw6s0GXL+8Ja0TweCG41OQaKst6m3RgqQTCnBG0S3cTmeXgb EkbqVuFZtFLe7sA/RAPmoE3N1NKH+0vKJt96Hkl6EqRTpdwi245ABBzCobC3YEI8tthlIeb vrKNNXUaqpJ159KWmV0XKs4Uh+SJfXjlR9rXdovzi0culDQqcoZ/S+pGCT3K0QOL/lioiUk M9o87gEcbjLWNRFOhgNrA== X-UI-Out-Filterresults: notjunk:1;V01:K0:4qzHMxgd5ZU=:ECGgv6I714s+tQRK+Efame ZOjuiZYhpyDC71z567t0ChYrfT2ts/J/9DujaFO414tYnTglqSbgaZVOqmFiFTfI/jEIn/wSe aMugQll/fD7m93KT97tmcyJfJp9aR0PjvP0Mgqtbz5XbTf5XskLpBrKZZVHhmu3fKj7y9v29P nKSoZsls1mpnTlhaZJcUaP6a4u700eHV1gM5hHacCPrS5RBG2YY+j8mVVDrQuGpWxn/ZZTvYV Y7I+U+wEPQ6yp90GPl/UPatOr3tGJfL+6fMkPo9g7wZ7X5B8A+xA/29F+3z5afMlhEyqLTThx USIozorEXbTKF49VcaJEOMNAteF2EVuI0kbxLzsLikVPRNVnQQDaz2so0c72NXZBVW0MunjHc g36dcYnI4261Sc39G3CU/OxjFFQO5zgZuM5NPGu4Y1OPp3KsdfC7naDLzC7m8f1xb2o3wHTwl 9ewHgs7o2ePw7Je2TcjAwZGymmZ3gwUcvClr3Wc7XKE62iHJL21a4gBrL3wsKQAJ1pBIMyqR7 cGHmsW2F6EH15JWPANoJ7FI/juC7EAGJqL8Sf2DA8nFUc3A2VdY9mJefJNxYgUOopuICtebE3 +vRDTSrNBYqkjn80w+PI3PFuZz6rBaAiVLXl2sRC/mIaWuzA7Ft8C+i2CiriHEXi28ofA4+Yr Zdm8XnsiXAplH1wiAkuHPJwVxKEZ5Iwvaweo47Mrlf0lt4MrB4JcadMHJVETUHBKpEl6l566C 6EoWGv40qkVBhJMVoY09sOvcdHCeZaVFF5jQZT8bp74lfQQajeVXETySXHLfQwh9VMojrd3+Q Gycox7+a4jaOdUNBZ5CWxe0R0yMSQ== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > about a year ago I reported that `write-file' sometimes writes the wro= ng > buffer to the destination file. Unfortunately, I had no feedback regar= ding > this. When I checked today, the bug is still there. Sorry. I could have sworn we fixed that then. > The problem occurs when a function on the hook > `window-size-change-functions' change the current buffer. The function= s in > this hook are executed when `y-or-n-p' is called, which is used by > `write-file' to verify that it is OK to overwrite an existing file. On= e > such function is `follow-window-size-change' in follow.el. > > This problem is not limited to `write-file' -- all functions calling > `y-or-n-p' are affected by this! > > Of course, it would be relatively straight forward to modify the offen= ding > function (and all other similar functions). However, a more robust sol= ution > would be for the code that calls the functions on the hook to ensure t= hat > it isn't derailed when the buffer is changed. > > Personally, I don't know that part of the code well enough to do this > change. Martin, is this something that you could look into, or suggest= > someone who can? Conceptually it should be easy to do that. Save/restore current buffer, selected window and frame. But Alan (concerned about =E2=80=98follow-mod= e=E2=80=99), Pip (who unfortunately disappeared) and Eli are currently discussing how to fix =E2=80=98window-size-change-functions=E2=80=99 in various other wa= ys as well. I'll try to get the fix of this bug applied there too. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 16 15:06:10 2015 Received: (at 19576) by debbugs.gnu.org; 16 Nov 2015 20:06:10 +0000 Received: from localhost ([127.0.0.1]:40484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyQ2U-0000wu-Ce for submit@debbugs.gnu.org; Mon, 16 Nov 2015 15:06:10 -0500 Received: from mail-yk0-f169.google.com ([209.85.160.169]:33986) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyQ2A-0000wC-V9 for 19576@debbugs.gnu.org; Mon, 16 Nov 2015 15:06:09 -0500 Received: by ykfs79 with SMTP id s79so260546242ykf.1 for <19576@debbugs.gnu.org>; Mon, 16 Nov 2015 12:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jAfQivfwarcaAInYLLjXleJXK4FmXyigFoe9VorsNXc=; b=Xx6BPnPrBw1LX+eFnwtz560Tthe1h7WOd7YpJMGguW9q2B1jL6+U5NaZcF052UH3+e 0c9sk/2TKkohKuKM5fBy+bVtuuGKGTMfTtf+c4VTSaNPc5IXcZGy9hD0wm3cK5prlbBZ CjazZ9FSbY09hZmcxIdhnQL170WwIKCTMsTw9Y1Wtla+DHYH8H/me1IM5YsEbz3LWooo IM+zkHSfumZFpxS265ceVkLLCmU+J07ZFW1Nt0oMh7ELiJXqqQ665GfWoc/77TXEPaWW DRQSfKioDFMmLAsmFRzLfndaQxJR5nc9CYk9hGnOzaOfsky8fKuQMsDiMJIxSF5iWqRW aK2w== MIME-Version: 1.0 X-Received: by 10.129.147.135 with SMTP id k129mr37194030ywg.233.1447704350475; Mon, 16 Nov 2015 12:05:50 -0800 (PST) Received: by 10.31.210.133 with HTTP; Mon, 16 Nov 2015 12:05:50 -0800 (PST) In-Reply-To: <564A3292.2050807@gmx.at> References: <564A3292.2050807@gmx.at> Date: Mon, 16 Nov 2015 21:05:50 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: martin rudalics Content-Type: multipart/alternative; boundary=94eb2c0816088ccb470524adefde X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --94eb2c0816088ccb470524adefde Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Conceptually it should be easy to do that. Save/restore current buffer, > selected window and frame. But Alan (concerned about =E2=80=98follow-mod= e=E2=80=99), > Pip (who unfortunately disappeared) and Eli are currently discussing how > to fix =E2=80=98window-size-change-functions=E2=80=99 in various other wa= ys as well. > I'll try to get the fix of this bug applied there too. This sounds good! If Alan has any thoughts on follow mode, I'd be happy to discuss them. I might need a bit of a refresher, though -- after all, I wrote it more than twenty years ago. -- Anders --94eb2c0816088ccb470524adefde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Conceptually it should be easy to do that.=C2=A0= Save/restore current buffer,
selected window and frame.=C2=A0 But Alan (concerned about =E2=80=98follow-= mode=E2=80=99),
Pip (who unfortunately disappeared) and Eli are currently discussing how to fix =E2=80=98window-size-change-functions=E2=80=99 in various other ways= as well.
I'll try to get the fix of this bug applied there too.
This sounds good!

If Alan has any = thoughts on follow mode, I'd be happy to discuss them. I might need a b= it of a refresher, though -- after all, I wrote it more than twenty years a= go.

=C2=A0 =C2=A0 -- Anders

--94eb2c0816088ccb470524adefde-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 16 20:16:03 2015 Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 01:16:03 +0000 Received: from localhost ([127.0.0.1]:40657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyUsN-0002ZZ-3m for submit@debbugs.gnu.org; Mon, 16 Nov 2015 20:16:03 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:52483 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyUs2-0002Yj-Jd for 19576@debbugs.gnu.org; Mon, 16 Nov 2015 20:16:01 -0500 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id C927B2B206A; Mon, 16 Nov 2015 17:15:41 -0800 (PST) Received: from localhost.linkov.net (m91-131-172-22.cust.tele2.ee [91.131.172.22]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 66A332B2065; Mon, 16 Nov 2015 17:15:40 -0800 (PST) From: Juri Linkov To: Anders Lindgren Subject: Re: bug#19576: write-file writes the wrong buffer Organization: LINKOV.NET References: <564A3292.2050807@gmx.at> Date: Tue, 17 Nov 2015 02:55:39 +0200 In-Reply-To: (Anders Lindgren's message of "Mon, 16 Nov 2015 21:05:50 +0100") Message-ID: <87fv05phpw.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , 19576@debbugs.gnu.org, Alan Mackenzie X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> Conceptually it should be easy to do that. Save/restore current buffe= r, >> selected window and frame. But Alan (concerned about =E2=80=98follow-= mode=E2=80=99), >> Pip (who unfortunately disappeared) and Eli are currently discussing h= ow >> to fix =E2=80=98window-size-change-functions=E2=80=99 in various other= ways as well. >> I'll try to get the fix of this bug applied there too. > > This sounds good! > > If Alan has any thoughts on follow mode, I'd be happy to discuss them. = I > might need a bit of a refresher, though -- after all, I wrote it more t= han > twenty years ago. I hope Alan (Cc:ed) could explain in details all improvements he's doing in bug#17453. Meanwhile, I'm taking an opportunity to ask you about your intriguing com= ment in follow.el: ;; Almost like the real thing, except when the cursor ends up outside ;; the top or bottom... In our case however, we end up outside the ;; window and hence we are recentered. Should we let `recenter' handle ;; the point position we would never leave the selected window. To do ;; it ourselves we would need to do our own redisplay, which is easier ;; said than done. (Why didn't I do a real display abstraction from ;; the beginning?) What a real display abstraction would you create if you designed follow-mode today? From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 03:34:35 2015 Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 08:34:35 +0000 Received: from localhost ([127.0.0.1]:40883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zybik-00054V-PD for submit@debbugs.gnu.org; Tue, 17 Nov 2015 03:34:35 -0500 Received: from mout.gmx.net ([212.227.17.21]:53555) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zybii-00054M-69 for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 03:34:32 -0500 Received: from [192.168.1.100] ([213.162.68.66]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MEFqW-1a9b9K1ZmK-00FOuc; Tue, 17 Nov 2015 09:34:30 +0100 Message-ID: <564AE692.2040303@gmx.at> Date: Tue, 17 Nov 2015 09:34:26 +0100 From: martin rudalics MIME-Version: 1.0 To: Anders Lindgren Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040800000807010900000905" X-Provags-ID: V03:K0:ZBvrnHo5tHmeOQf0mTXbbfGpZgBYqAHxKs3eLKBdTmfC5asd+xW /ib0V/ac1/pQtnQ0n6PHr2iX3Xh8qrrg4FoaC8FBWmER1USsmxr0oHhJtuGYu26AUF271/w WklDXQcQ7jGiaqPGev5O+MhLdk47qZLPcv11KQFaf0WBhZdZec0L4CAttg45iLxLJvatbhi 1lKr8GDUwKsXCPy84UPkg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yqYYah9FwcU=:1sSDVgCURYIkgO/kjaakGz Ja0Lig46NVGDTEpXGcdG0Oe0mfAPsz33ZF9CKX8mKS/ieyd4LoGGWWDkYiHK/rW+XdYDNhOIl TEoEMDwbpl3GsLOQ+YMET80fvE3MPj1wyUrBPLPtBPQSlKmejpQNv10AKh1IBJ/MfOc3KyTaM 5vzKaedguWG5fQK8obe0MSIhtsJKUxNKQlF26J4FrcYkYLva5ahATFfBukZZxWRulNKc8q7us RlZ+ePGE/U47d6u2zDIMkwaOKL5uvg+T2Ah5xRfNgrrfdMF3qnfd69OzndDPKYPULzXLHv2bQ O3qmrxJmDTwfwZHEJ+YCf2a7Jl8LyaRaigr2jTQTTVYbalCogIEAoIytGh1dLlNYswllY1SyE 0zR//ydp6MvpE3wmqh2+n+Wla3I8MAXdWqjkZaPidWxfOHJ2sr2/rLByHh+6lgsNhcKwxOC22 CX0FT0VpKXBvO31qHqTR3UPUa5JHSqAnuIVys62/H/svTWhVykCKM9xmP7ADyscibAODUtxvp 8uy0fJ5g1MmzJuwmpo4x48W0mYZscsYPSQ33/SEQecAqRFaYI4tPZ6AzAg1KXswNpIOegGA+/ RcSdFAIvTDIzDXsG5jdmtyj3y2FF08GMl1mhWHCNom7m8TXhNPLTc4T+DlTRYuAAUX+fsqTaq EMHV3+yRv+W9zuThaE8XgBV1+rtdJXWHv4jh4v4V0SJA1CSN813tQAGo3PqTF0Oyui7r1TZVd MNFlHuyfDfBkwtOFAkP+nd54n9xbAv9j5RZnqORMC69s8F0nl25Tj6GGWUqgFSfgtnGY3fi9M +jH+LtB X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --------------040800000807010900000905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit >> I'll try to get the fix of this bug applied there too. I attach a fix for restoring current buffer and selected window (the latter hopefully taking care of selecting the right frame). Please tell me whether it's sufficient for your purposes. martin --------------040800000807010900000905 Content-Type: text/plain; charset=windows-1252; name="bug#19576.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bug#19576.diff" ZGlmZiAtLWdpdCBhL3NyYy93aW5kb3cuYyBiL3NyYy93aW5kb3cuYw0KaW5kZXggN2M5NWZm OS4uMDYwNjZmZCAxMDA2NDQNCi0tLSBhL3NyYy93aW5kb3cuYw0KKysrIGIvc3JjL3dpbmRv dy5jDQpAQCAtMzE0MiwxNCArMzE0MiwxNCBAQCBydW5fZnVucyAoTGlzcF9PYmplY3QgZnVu cykNCiAgICAgICBjYWxsMCAoWENBUiAoZnVucykpOw0KIH0NCg0KLXN0YXRpYyB2b2lkDQor dm9pZA0KIHNlbGVjdF93aW5kb3dfbm9yZWNvcmQgKExpc3BfT2JqZWN0IHdpbmRvdykNCiB7 DQogICBpZiAoV0lORE9XX0xJVkVfUCAod2luZG93KSkNCiAgICAgRnNlbGVjdF93aW5kb3cg KHdpbmRvdywgUXQpOw0KIH0NCg0KLXN0YXRpYyB2b2lkDQordm9pZA0KIHNlbGVjdF9mcmFt ZV9ub3JlY29yZCAoTGlzcF9PYmplY3QgZnJhbWUpDQogew0KICAgaWYgKEZSQU1FX0xJVkVf UCAoWEZSQU1FIChmcmFtZSkpKQ0KZGlmZiAtLWdpdCBhL3NyYy93aW5kb3cuaCBiL3NyYy93 aW5kb3cuaA0KaW5kZXggMTM1ZjVkZS4uOWVlM2Y4MSAxMDA2NDQNCi0tLSBhL3NyYy93aW5k b3cuaA0KKysrIGIvc3JjL3dpbmRvdy5oDQpAQCAtMTAxMyw2ICsxMDEzLDggQEAgZXh0ZXJu IHZvaWQgZ3Jvd19taW5pX3dpbmRvdyAoc3RydWN0IHdpbmRvdyAqLCBpbnQsIGJvb2wpOw0K IGV4dGVybiB2b2lkIHNocmlua19taW5pX3dpbmRvdyAoc3RydWN0IHdpbmRvdyAqLCBib29s KTsNCiBleHRlcm4gaW50IHdpbmRvd19yZWxhdGl2ZV94X2Nvb3JkIChzdHJ1Y3Qgd2luZG93 ICosIGVudW0gd2luZG93X3BhcnQsIGludCk7DQoNCit2b2lkIHNlbGVjdF93aW5kb3dfbm9y ZWNvcmQgKExpc3BfT2JqZWN0KTsNCit2b2lkIHNlbGVjdF9mcmFtZV9ub3JlY29yZCAoTGlz cF9PYmplY3QpOw0KIHZvaWQgcnVuX3dpbmRvd19jb25maWd1cmF0aW9uX2NoYW5nZV9ob29r IChzdHJ1Y3QgZnJhbWUgKmYpOw0KDQogLyogTWFrZSBXSU5ET1cgZGlzcGxheSBCVUZGRVIu ICBSVU5fSE9PS1NfUCBtZWFucyBpdCdzIGFsbG93ZWQNCmRpZmYgLS1naXQgYS9zcmMveGRp c3AuYyBiL3NyYy94ZGlzcC5jDQppbmRleCBkYmMyZDg0Li41ZTBkNGNhIDEwMDY0NA0KLS0t IGEvc3JjL3hkaXNwLmMNCisrKyBiL3NyYy94ZGlzcC5jDQpAQCAtMTE3MzksOCArMTE3Mzks MTYgQEAgcHJlcGFyZV9tZW51X2JhcnMgKHZvaWQpDQoNCiAJICAgICAgd2hpbGUgKENPTlNQ IChmdW5jdGlvbnMpKQ0KIAkJew0KKwkJICBwdHJkaWZmX3QgY291bnQgPSBTUEVDUERMX0lO REVYICgpOw0KKw0KKwkJICByZWNvcmRfdW53aW5kX2N1cnJlbnRfYnVmZmVyICgpOw0KKwkJ ICByZWNvcmRfdW53aW5kX3Byb3RlY3QgKHNlbGVjdF93aW5kb3dfbm9yZWNvcmQsIHNlbGVj dGVkX3dpbmRvdyk7DQorDQogCQkgIGlmICghRVEgKFhDQVIgKGZ1bmN0aW9ucyksIFF0KSkN CiAJCSAgICBjYWxsMSAoWENBUiAoZnVuY3Rpb25zKSwgZnJhbWUpOw0KKw0KKwkJICB1bmJp bmRfdG8gKGNvdW50LCBRbmlsKTsNCisNCiAJCSAgZnVuY3Rpb25zID0gWENEUiAoZnVuY3Rp b25zKTsNCiAJCX0NCiAJICAgIH0NCg0K --------------040800000807010900000905-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 14:08:08 2015 Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 19:08:08 +0000 Received: from localhost ([127.0.0.1]:42025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zylbs-0001QU-3N for submit@debbugs.gnu.org; Tue, 17 Nov 2015 14:08:08 -0500 Received: from mail-yk0-f173.google.com ([209.85.160.173]:33760) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zylbp-0001QI-GD for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 14:08:05 -0500 Received: by ykdv3 with SMTP id v3so23227134ykd.0 for <19576@debbugs.gnu.org>; Tue, 17 Nov 2015 11:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RGdThdhJQJq4u1lLUPI39p2yob5Gf7jus2X7HTn2ejY=; b=HXkFfbEM0tkqfavKYA+LlRenXOH3F6GbVMH5Zbn+q7bjbL8OVI4iTQgUYYwsgypG+y gRJ7G0m7Y6AGXBpTgdNeQ5jZPRd9gpnlosnLtRxQxLgrxKeJvrEVS2VQwzztOwqPGzz7 FlIlcrKhFa3xkozjCGs6+MOehov850ngKW8GYZ4y/lGQkb+oZIdw67PXrYyHbhIYlxRw O129tXwnonbQske6mTCpvF/U6Gv38fgQDKuUqRWHWPwwF/AuQkht5Ek0jbqGOuPH5iy9 0bTwLqp+ITfEMcePw1gXXFC/mqPRamLY212jT8ZfrHgfNP2eO4lnRpNNEal2AZL3rIMN HtVg== MIME-Version: 1.0 X-Received: by 10.129.153.201 with SMTP id q192mr45816568ywg.205.1447787284979; Tue, 17 Nov 2015 11:08:04 -0800 (PST) Received: by 10.31.210.133 with HTTP; Tue, 17 Nov 2015 11:08:04 -0800 (PST) In-Reply-To: <564AE692.2040303@gmx.at> References: <564A3292.2050807@gmx.at> <564AE692.2040303@gmx.at> Date: Tue, 17 Nov 2015 20:08:04 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: martin rudalics Content-Type: multipart/alternative; boundary=94eb2c0b7332d4eeff0524c13e4d X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --94eb2c0b7332d4eeff0524c13e4d Content-Type: text/plain; charset=UTF-8 Hi, I just tested the patch and I have verified that it works. Thanks! -- Anders On Tue, Nov 17, 2015 at 9:34 AM, martin rudalics wrote: > >> I'll try to get the fix of this bug applied there too. > > I attach a fix for restoring current buffer and selected window (the > latter hopefully taking care of selecting the right frame). Please tell > me whether it's sufficient for your purposes. > > martin > --94eb2c0b7332d4eeff0524c13e4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I just tested the patch and I have = verified that it works.

Thanks!

=C2=A0 =C2=A0 -- Anders

On Tue, Nov 17, 2015 at 9:34 AM, martin rudalics <= span dir=3D"ltr"><r= udalics@gmx.at> wrote:
>> I'll try to get the fix of this bug applied there= too.

I attach a fix for restoring current buffer and selected window (the
latter hopefully taking care of selecting the right frame).=C2=A0 Please te= ll
me whether it's sufficient for your purposes.

martin

--94eb2c0b7332d4eeff0524c13e4d-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 15:00:31 2015 Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 20:00:31 +0000 Received: from localhost ([127.0.0.1]:42036 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZymQX-0003pL-O3 for submit@debbugs.gnu.org; Tue, 17 Nov 2015 15:00:30 -0500 Received: from mail.muc.de ([193.149.48.3]:14880) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZymQC-0003nb-M6 for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 15:00:28 -0500 Received: (qmail 86722 invoked by uid 3782); 17 Nov 2015 20:00:06 -0000 Received: from acm.muc.de (p579E91A5.dip0.t-ipconnect.de [87.158.145.165]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 17 Nov 2015 21:00:05 +0100 Received: (qmail 5985 invoked by uid 1000); 17 Nov 2015 20:02:04 -0000 Date: Tue, 17 Nov 2015 20:02:04 +0000 To: Juri Linkov , Anders Lindgren Subject: Re: bug#19576: write-file writes the wrong buffer Message-ID: <20151117200204.GA5054@acm.fritz.box> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87fv05phpw.fsf@mail.linkov.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , 19576@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Anders and Juri. On Tue, Nov 17, 2015 at 02:55:39AM +0200, Juri Linkov wrote: > >> Conceptually it should be easy to do that. Save/restore current buffer, > >> selected window and frame. But Alan (concerned about ‘follow-mode’), > >> Pip (who unfortunately disappeared) and Eli are currently discussing how > >> to fix ‘window-size-change-functions’ in various other ways as well. I have a fix for the `window-size-change-functions' problem, which I posted just over an hour ago (see bug #21869 or #21333). The fix consists of only invoking w-s-c-f after any change to the echo area size has been done. This might have some relevance for the current bug. (I haven't followed the current bug, I'm afraid.) I really need the go-ahead from Eli before I can commit the fix to the emacs-25 or master branch. > >> I'll try to get the fix of this bug applied there too. > > This sounds good! > > If Alan has any thoughts on follow mode, I'd be happy to discuss them. I > > might need a bit of a refresher, though -- after all, I wrote it more than > > twenty years ago. In general, follow mode is wonderful (I use it all the time), but (i) is not sufficiently integrated with the rest of Emacs, and (ii) is too difficult to use in an emacs -Q. By (ii), I mean that manually creating the side by side windows and doing M-x follow-mode is too cumbersome. follow-delete-other-windows-and-split is not bound to any key sequence by default. I have my own private commands bound to C-c 2, C-c 3, C-c 4, which enable follow mode in 2, 3, and 4 windows. I also have C-c 0, which disables follow mode. I think Emacs should have something like these in its global key map, say on C-x w f. Maybe for Emacs 25.2, or 26.1. By (i), I mean that other lisp programs cannot use follow mode. For example, many programs use `window-start' to get the start of the area they want to work on, when really what they should get is the start of the "lowest" follow window. The most painful clash I know of is with Isearch. It has several places where it just doesn't work: for example, rather than point moving over the entire set of windows when you input C-s / C-r, is stays in the one window and scrolls that window. I have fixed these problems in isearch.el, and I gather Juri is reviewing these at the moment. These fixes depend on .... I have enhanced follow mode with the six functions follow-window-start, follow-window-end, follow-set-window-start, follow-pos-visible-in-window-p, follow-recenter, and follow-move-to-window-line, which do what their names suggest, but on an entire follow mode group of windows. The new follow-... functions need somehow to be connected with the rest of the lisp world. The idea is that another program can call just one interface which will invoke either window-start or follow-window-start, depending on whether follow mode is active. I have, as yet, two alternative implementations for this: (i) New functions with names like window*-start (notice the "*"), written in lisp in window.el; (ii) Adding an extra parameter to the primitives (mainly in window.c), so that instead of calling (window-start win), a function would call (window-start win t). Buffer local variables to perform the redirection are initialised at follow-mode start up, and removed at follow-mode termination. Of the above alternatives, Eli prefers (ii), but I think Juri prefers (i). > I hope Alan (Cc:ed) could explain in details all improvements he's doing > in bug#17453. > Meanwhile, I'm taking an opportunity to ask you about your intriguing comment > in follow.el: > ;; Almost like the real thing, except when the cursor ends up outside > ;; the top or bottom... In our case however, we end up outside the > ;; window and hence we are recentered. Should we let `recenter' handle > ;; the point position we would never leave the selected window. To do > ;; it ourselves we would need to do our own redisplay, which is easier > ;; said than done. (Why didn't I do a real display abstraction from > ;; the beginning?) I must say, I've been intrigued by this comment for some while, too. > What a real display abstraction would you create if you designed > follow-mode today? Indeed! -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 16:15:28 2015 Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 21:15:29 +0000 Received: from localhost ([127.0.0.1]:42049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zynb5-0007Im-NU for submit@debbugs.gnu.org; Tue, 17 Nov 2015 16:15:28 -0500 Received: from mail-yk0-f170.google.com ([209.85.160.170]:34553) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zynal-0007Hr-KA for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 16:15:26 -0500 Received: by ykfs79 with SMTP id s79so29828287ykf.1 for <19576@debbugs.gnu.org>; Tue, 17 Nov 2015 13:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ySETw/+Xh0b0DkEXbqQOTOwM5cK0zFu8Ahyiw2xAyK4=; b=E9uc+k1D1BVdqt5Qm2VYCDNjVRYeNZ70zXbiy53mLBcXUGDn9dbZWudxZJw+Ksp14r jTu88ttX001J8J5VprBe2SbpVj9oCE6SUfXWR3Uj+S9okup8ECMFI7ogMUJ+WbMYnOHQ Xa4juI7AWQ7H/JXz/6GYPAYduxzFrez+8C+zYdiYqKt5gDEc5nf7nGPnGVSwumX2N/6N wW19iQUVoJcNNZY97OC6ySidCXnTwXYFAQPDrlIkXvYNCfvmtgmpLLTACepY+V3V40Zw esD8N3EwC0bPOFXglJmI6RcFEv+dGjz5kGOuFtc2gpg0reHaV7KFV5M5gkWLZyH407h3 LaXw== MIME-Version: 1.0 X-Received: by 10.129.80.138 with SMTP id e132mr41847086ywb.90.1447794907116; Tue, 17 Nov 2015 13:15:07 -0800 (PST) Received: by 10.31.210.133 with HTTP; Tue, 17 Nov 2015 13:15:07 -0800 (PST) In-Reply-To: <87fv05phpw.fsf@mail.linkov.net> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> Date: Tue, 17 Nov 2015 22:15:07 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: Juri Linkov Content-Type: multipart/alternative; boundary=001a1147fa52257de10524c3054d X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , Eli Zaretskii , 19576@debbugs.gnu.org, Alan Mackenzie X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1147fa52257de10524c3054d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everybody! (I took the liberty to add Eli to this as well, as this involves the display engine.) Meanwhile, I'm taking an opportunity to ask you about your intriguing > comment > in follow.el: > > ;; Almost like the real thing, except when the cursor ends up outside > ;; the top or bottom... In our case however, we end up outside the > ;; window and hence we are recentered. Should we let `recenter' handle > ;; the point position we would never leave the selected window. To do > ;; it ourselves we would need to do our own redisplay, which is easier > ;; said than done. (Why didn't I do a real display abstraction from > ;; the beginning?) > > What a real display abstraction would you create if you designed > follow-mode today? > Unfortunately, I haven't got a clue what my twenty-years younger me was thinking when writing this... However, here are some thoughts on follow-mode I have accumulated over the years: * The core of follow-mode call `redisplay' and does all sorts of tricks to keep up the illusion that a number of windows form a very tall windows. I would like to do some investigations if this can be done more efficiently. Keith David Bershatsky (a.k.a. lawlist) has analyzed under which circumstances Emacs calls the different hooks and functions using a tool he named `test-mode'. Maybe this information can be used to write a better implementation of follow-mode. (Of course, one alternative would be to implement this in the Emacs display engine, but I don't see that happening anytime soon.) * The Emacs display engine tries to recenter windows when window-start =3D= =3D buffer-end, to ensure that no window would appear empty. When follow-mode is enabled, this is not what we want (except for the leftmost window). To counter the recentering efforts of Emacs, follow-mode sets window-start whenever it gets a chance. I would prefer if it was possible to tell the display engine to leave some windows alone, preferably with some kind of buffer-local `recenter-window-functions' variable. It could be made generic so that the return value would be an integer telling Emacs to show this many lines (if positive) or place the last line X lines from the bottom (when negative). If such hook existed, follow-mode could return 0 for all (except the leftmost) windows. Note that the user can change the content of any window at any time, so this property isn't static. * Make it easier for other packages to use it. By this I mean packages that display information, like "grep", should be able to use follow mode to display a buffer using side by side windows. Concretely, in font-lock-studio (a debugger for font-lock keywords I wrote a while ago) I do this, but I had to call `follow-post-command-hook' explicitly. Follow mode should need a better interface for this, alternatively this should be built into `display-buffer' so that it happens automatically. * When follow-mode is enabled, there is a noticeable lag when updating the region. You can see this by pressing C-c SPACE and holding the up or down key. When follow-mode is disabled, the region is updated as fast as the cursor moves, when enabled, it is updated in chunks. * When written in the Emacs old era, the region was always highlighted in all windows. Follow-mode went to great lengths to place the cursor in the non-selected windows so that the region would look good. Today, one could get the same effect by setting `highlight-nonselected-windows' (except that the region is visible on the last line of windows to the left of the selected window.) I would love to give the user the option to 1) automatically set this variable and move the cursor in the non-selected windows or 2) don't move the cursors at all. (Alternatively, invent a new way to highlight the region of the selected windows in the other windows, without the cursor in the non-selected windows affecting it.) * isearch: If I recall correctly, isearch used to worked across follow-mode windows. Of course, this was before isearch highlighted matches etc. It would be great if this could be restored once again! * Process output: In early versions of follow-mode, it could be used with any process. This was accomplished using `defadvice' on a handful of process-related functions. At some point in time, this system was replaced with a system specific to comint and compilation buffers -- as part of the great defadvice sweep. Personally, I would like to Emacs to provide `pre-process-output-functions' and `post-process-output-functions', allowing packages like follow-mode to perform whatever action they would like to the output of any process. * If a user have columns with different widths, follow-mode can't correctly display long lines stretching from one window to the next. The reason for this is that the start position can't be placed at an arbitrary location on a long line, only on positions that are a multiple of the column width. I don't see any way to solve this without modifying the display engine. * Automatic tests: These should verify the basic functionality, that the windows are aligned properly. That moving the point down in one window would move it to the next. All follow-mode-specific commands etc. Anyway, this is a dire wish-list and I feel that I, unfortunately, presently can't contribute to it. When it comes to Emacs responsibilities, I have taken over the NextStep port after Jan Dj=C3=A4rvs resignation, and = on a personal level I have a full time job and I have two small children and a third due in about a week (if all goes well). Anyway, I'm glad that Alan has taken this bull by the horn. However, feel free to ask questions or discuss implementation ideas regarding this. Sincerely, Anders Lindgren --001a1147fa52257de10524c3054d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Everybody!

(I took the liberty to add Eli to t= his as well, as this involves the display engine.)


Meanwhile, I'm taking an opportunity to ask= you about your intriguing comment
in follow.el:

;; Almost like the real thing, except when the cursor ends up outside
;; the top or bottom...=C2=A0 In our case however, we end up outside the ;; window and hence we are recentered.=C2=A0 Should we let `recenter' h= andle
;; the point position we would never leave the selected window.=C2=A0 To do=
;; it ourselves we would need to do our own redisplay, which is easier
;; said than done.=C2=A0 (Why didn't I do a real display abstraction fr= om
;; the beginning?)

What a real display abstraction would you create if you designed
follow-mode today?


Unfortunately, I haven't got a clue what my twenty-ye= ars younger me was thinking when writing this...


However, here are some thoughts on follow-mode I have accumulated over= the years:

* The core of follow-mode call `redisplay' and does all sorts of = tricks to keep up the illusion that a number of windows form a very tall wi= ndows. I would like to do some investigations if this can be done more effi= ciently. Keith David Bershatsky (a.k.a. lawlist) has analyzed under which c= ircumstances Emacs calls the different hooks and functions using a tool he = named `test-mode'. Maybe this information can be used to write a better= implementation of follow-mode. (Of course, one alternative would be to imp= lement this in the Emacs display engine, but I don't see that happening= anytime soon.)

* The Emacs display engine tries to recenter windows when win= dow-start =3D=3D buffer-end, to ensure that no window would appear empty. W= hen follow-mode is enabled, this is not what we want (except for the leftmo= st window). To counter the recentering efforts of Emacs, follow-mode sets w= indow-start whenever it gets a chance. I would prefer if it was possible to= tell the display engine to leave some windows alone, preferably with some = kind of buffer-local `recenter-window-functions' variable. It could be = made generic so that the return value would be an integer telling Emacs to = show this many lines (if positive) or place the last line X lines from the = bottom (when negative). If such hook existed, follow-mode could return 0 fo= r all (except the leftmost) windows. Note that the user can change the cont= ent of any window at any time, so this property isn't static.
=

* Make it e= asier for other packages to use it. By this I mean packages that display in= formation, like "grep", should be able to use follow mode to disp= lay a buffer using side by side windows. Concretely, in font-lock-studio (a= debugger for font-lock keywords I wrote a while ago) I do this, but I had = to call `follow-post-command-hook' explicitly. Follow mode should need = a better interface for this, alternatively this should be built into `displ= ay-buffer' so that it happens automatically.

* When follow-mode is enable= d, there is a noticeable lag when updating the region. You can see this by = pressing C-c SPACE and holding the up or down key. When follow-mode is disa= bled, the region is updated as fast as the cursor moves, when enabled, it i= s updated in chunks.

* When written in the Emacs old era, the region was always= highlighted in all windows. Follow-mode went to great lengths to place the= cursor in the non-selected windows so that the region would look good. Tod= ay, one could get the same effect by setting `highlight-nonselected-windows= ' (except that the region is visible on the last line of windows to the= left of the selected window.) =C2=A0I would love to give the user the opti= on to 1) automatically set this variable and move the cursor in the non-sel= ected windows or 2) don't move the cursors at all. (Alternatively, inve= nt a new way to highlight the region of the selected windows in the other w= indows, without the cursor in the non-selected windows affecting it.)
=

* isearch: = If I recall correctly, isearch used to worked across follow-mode windows. O= f course, this was before isearch highlighted matches etc. It would be grea= t if this could be restored once again!
* Process output: In early versions of fo= llow-mode, it could be used with any process. This was accomplished using `= defadvice' on a handful of process-related functions. At some point in = time, this system was replaced with a system specific to comint and compila= tion buffers -- as part of the great defadvice sweep. Personally, I would l= ike to Emacs to provide `pre-process-output-functions' and `post-proces= s-output-functions', allowing packages like follow-mode to perform what= ever action they would like to the output of any process.

* If a user have colu= mns with different widths, follow-mode can't correctly display long lin= es stretching from one window to the next. The reason for this is that the = start position can't be placed at an arbitrary location on a long line,= only on positions that are a multiple of the column width. I don't see= any way to solve this without modifying the display engine.

* Automatic tests: T= hese should verify the basic functionality, that the windows are aligned pr= operly. That moving the point down in one window would move it to the next.= All follow-mode-specific commands etc.


=
Anyway, this is a dire wish-list and I fee= l that I, unfortunately, presently can't contribute to it. When it come= s to Emacs responsibilities, I have taken over the NextStep port after Jan = Dj=C3=A4rvs resignation, and on a personal level I have a full time job and= I have two small children and a third due in about a week (if all goes wel= l). Anyway, I'm glad that Alan has taken this bull by the horn. However= , feel free to ask questions or discuss implementation ideas regarding this= .

Sinc= erely,
=C2=A0 =C2=A0 Anders Lindgren
<= div class=3D"gmail_extra">
--001a1147fa52257de10524c3054d-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 16:53:15 2015 Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 21:53:15 +0000 Received: from localhost ([127.0.0.1]:42070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyoBe-0000Xd-Ma for submit@debbugs.gnu.org; Tue, 17 Nov 2015 16:53:15 -0500 Received: from mail-yk0-f182.google.com ([209.85.160.182]:34881) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyoBJ-0000WW-QO for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 16:53:13 -0500 Received: by ykba77 with SMTP id a77so31327189ykb.2 for <19576@debbugs.gnu.org>; Tue, 17 Nov 2015 13:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MHifz/ctnsI+Bp5Il1ZldjaJo/AJIgUhvW/ZYf0NWOw=; b=suUVthCGOVcJIMls90an1WNAHI4ZZH15uUkA7RCxDeoSVor/PfkffuE/+I1hG1dJgs s+TDwv3arjArFYzv/ACS/XX3fK/G4HgdsUPFXQOlz110pkO7EnXxFyx8btcyKPpod43N SyMJAbExrp8ZWJrxT9TdNSxzXY6R03Klr1aAuZyJ9otMjcZcLMZRn259DyBE8RNjWV9G r09Ej9v16qrYz40KCKlxGUrwja7jCpBFYXIqB5Il8aJsNLdaYXNIO3NUXaMjuhTPh9MS C5sf+2jgXtCCwpbIVkWXn1f+XVwa3Y/CJmKg+jCnyWV24QdIsQtMYqfZ7WoRGVsOHx1J UQrw== MIME-Version: 1.0 X-Received: by 10.129.116.85 with SMTP id p82mr43011367ywc.158.1447797173298; Tue, 17 Nov 2015 13:52:53 -0800 (PST) Received: by 10.31.210.133 with HTTP; Tue, 17 Nov 2015 13:52:53 -0800 (PST) In-Reply-To: <20151117200204.GA5054@acm.fritz.box> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> Date: Tue, 17 Nov 2015 22:52:53 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: Alan Mackenzie Content-Type: multipart/alternative; boundary=001a11473d2c38ae340524c38c76 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , Eli Zaretskii , 19576@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11473d2c38ae340524c38c76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alan (and the rest of you)! First, I'm really glad that you have taken on the challange to modernize follow mode! On Tue, Nov 17, 2015 at 02:55:39AM +0200, Juri Linkov wrote: > > >> Conceptually it should be easy to do that. Save/restore current > buffer, > > >> selected window and frame. But Alan (concerned about =E2=80=98follo= w-mode=E2=80=99), > > >> Pip (who unfortunately disappeared) and Eli are currently discussing > how > > >> to fix =E2=80=98window-size-change-functions=E2=80=99 in various oth= er ways as well. > > I have a fix for the `window-size-change-functions' problem, which I > posted just over an hour ago (see bug #21869 or #21333). The fix > consists of only invoking w-s-c-f after any change to the echo area size > has been done. This might have some relevance for the current bug. (I > haven't followed the current bug, I'm afraid.) I really need the > go-ahead from Eli before I can commit the fix to the emacs-25 or master > branch. > Today Martin sent me a patch that solved the window-size-change-functions problem i reported in bug#19576. I think this is different from the varying echo area problems of the other bugs, though. In general, follow mode is wonderful (I use it all the time), I'm glad to hear it! I use it evert day too, and every time I do I'm glad that I invested the time to write it. but > (i) is not sufficiently integrated with the rest of Emacs, and > (ii) is too difficult to use in an emacs -Q. > > By (ii), I mean that manually creating the side by side windows and > doing M-x follow-mode is too cumbersome. > follow-delete-other-windows-and-split is not bound to any key sequence > by default. I have my own private commands bound to C-c 2, C-c 3, C-c > 4, which enable follow mode in 2, 3, and 4 windows. I also have C-c 0, > which disables follow mode. I think Emacs should have something like > these in its global key map, say on C-x w f. Maybe for Emacs 25.2, or > 26.1. > I agree, I use an Emacs frame with six columns spread out across two monitors, and it feels like many of the basic functions are missing. I while a go I put together a companion program for follow mode which I named "multicolumn". It provides functions to set up the frame to accommodate a number of side-by-side windows. It also resizes the frame (down to the pixel) for this. Also it defines a number of keys like "C-x <" and "C-x >" for going to the leftmost and rightmost window, respectively. You can find this at https://github.com/Lindydancer/multicolumn. By (i), I mean that other lisp programs cannot use follow mode. For > example, many programs use `window-start' to get the start of the area > they want to work on, when really what they should get is the start of > the "lowest" follow window. > Agreed. One thing that disturbs me (which I haven't fixed yet) is when a new buffer is displayed in the middle of a group of follow-mode windows. It would be a good idea to teach `display-buffer' to pick another window, like one the first or last instead. I have, as yet, two > alternative implementations for this: > (i) New functions with names like window*-start (notice the "*"), > written in lisp in window.el; > Maybe "window-group-start"? The "*" disappears easily and a window group could actually be something else than a follow-mode group. (ii) Adding an extra parameter to the primitives (mainly in window.c), > so that instead of calling (window-start win), a function would call > (window-start win t). > > Buffer local variables to perform the redirection are initialised at > follow-mode start up, and removed at follow-mode termination. > > Of the above alternatives, Eli prefers (ii), but I think Juri prefers > (i). I can't say that it matters, really, but I think that I would prefer (i) since 1) it's stands out more in the source and 2) it's an all-lisp implementation. Sincerely, Anders Lindgren --001a11473d2c38ae340524c38c76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alan (and the rest of you)!

First, I= 'm really glad that you have taken on the challange to modernize follow= mode!


<= div class=3D"gmail_quote">
On Tue, Nov 17,= 2015 at 02:55:39AM +0200, Juri Linkov wrote:
> >> Conceptually it should be easy to do that.=C2=A0 Save/restore= current buffer,
> >> selected window and frame.=C2=A0 But Alan (concerned about = =E2=80=98follow-mode=E2=80=99),
> >> Pip (who unfortunately disappeared) and Eli are currently dis= cussing how
> >> to fix =E2=80=98window-size-change-functions=E2=80=99 in vari= ous other ways as well.

I have a fix for the `window-size-change-functions' problem, whi= ch I
posted just over an hour ago (see bug #21869 or #21333).=C2=A0 The fix
consists of only invoking w-s-c-f after any change to the echo area size has been done.=C2=A0 This might have some relevance for the current bug.=C2= =A0 (I
haven't followed the current bug, I'm afraid.)=C2=A0 I really need = the
go-ahead from Eli before I can commit the fix to the emacs-25 or master
branch.

Today Martin sent me a patch th= at solved the window-size-change-functions problem i reported in bug#19576.= I think this is different from the varying echo area problems of the other= bugs, though.


In gener= al, follow mode is wonderful (I use it all the time),

=
I'm glad to hear it! I use it evert day too, and every time = I do I'm glad that I invested the time to write it.


but
(i) is not sufficiently integrated with the rest of Emacs, and
(ii) is too difficult to use in an emacs -Q.

By (ii), I mean that manually creating the side by side windows and
doing M-x follow-mode is too cumbersome.
follow-delete-other-windows-and-split is not bound to any key sequence
by default.=C2=A0 I have my own private commands bound to C-c 2, C-c 3, C-c=
4, which enable follow mode in 2, 3, and 4 windows.=C2=A0 I also have C-c 0= ,
which disables follow mode.=C2=A0 I think Emacs should have something like<= br> these in its global key map, say on C-x w f.=C2=A0 Maybe for Emacs 25.2, or=
26.1.

I agree, I use an Emacs frame wit= h six columns spread out across two monitors, and it feels like many of the= basic functions are missing.

I while a go I put t= ogether a companion program for follow mode which I named "multicolumn= ". It provides functions to set up the frame to accommodate a number o= f side-by-side windows. It also resizes the frame (down to the pixel) for t= his. Also it defines a number of keys like "C-x <" and "C= -x >" for going to the leftmost and rightmost window, respectively.=

You can find this at https://github.com/Lindydancer/multicolumn.<= /div>


By (i), I mean that ot= her lisp programs cannot use follow mode.=C2=A0 For
example, many programs use `window-start' to get the start of the area<= br> they want to work on, when really what they should get is the start of
the "lowest" follow window.

A= greed.

One thing that disturbs me (which I haven&#= 39;t fixed yet) is when a new buffer is displayed in the middle of a group = of follow-mode windows. It would be a good idea to teach `display-buffer= 9; to pick another window, like one the first or last instead.

=C2=A0 I have, as yet, two
alternative implementations for this:
(i) New functions with names like window*-start (notice the "*"),=
written in lisp in window.el;

Maybe &qu= ot;window-group-start"? The "*" disappears easily and a wind= ow group could actually be something else than a follow-mode group.


(ii) Adding an extra parameter to the primitives (mainly in window.c),
so that instead of calling (window-start win), a function would call
(window-start win t).

Buffer local variables to perform the redirection are initialised at
follow-mode start up, and removed at follow-mode termination.

Of the above alternatives, Eli prefers (ii), but I think Juri prefers
(i).

I can't say that it matters, reall= y, but I think that I would prefer (i) since 1) it's stands out more in= the source and 2) it's an all-lisp implementation.

Sincerely,
=C2=A0 =C2=A0 Anders Lindgren

--001a11473d2c38ae340524c38c76-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 17:10:21 2015 Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 22:10:21 +0000 Received: from localhost ([127.0.0.1]:42088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyoSC-0001JP-R1 for submit@debbugs.gnu.org; Tue, 17 Nov 2015 17:10:21 -0500 Received: from mail.muc.de ([193.149.48.3]:19164) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyoS9-0001J7-M7 for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 17:10:18 -0500 Received: (qmail 19101 invoked by uid 3782); 17 Nov 2015 22:10:16 -0000 Date: 17 Nov 2015 22:10:16 -0000 Message-ID: <20151117221016.19100.qmail@mail.muc.de> From: Alan Mackenzie To: 19576@debbugs.gnu.org Subject: Re: bug#19576: write-file writes the wrong buffer Organization: muc.de e.V. In-Reply-To: X-Newsgroups: gnu.emacs.bug User-Agent: tin/2.3.1-20141224 ("Tallant") (UNIX) (FreeBSD/10.1-RELEASE-p16 (amd64)) X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 19576 Cc: Anders Lindgren X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Anders. In article you wrote: > [-- text/plain, encoding 7bit, charset: UTF-8, 28 lines --] > Hi, > about a year ago I reported that `write-file' sometimes writes the wrong > buffer to the destination file. Unfortunately, I had no feedback regarding > this. When I checked today, the bug is still there. > The problem occurs when a function on the hook > `window-size-change-functions' change the current buffer. The functions in > this hook are executed when `y-or-n-p' is called, which is used by > `write-file' to verify that it is OK to overwrite an existing file. One > such function is `follow-window-size-change' in follow.el. I've run the test code you posted back in January, and I can reproduce the error. But I don't see why `window-size-change-functions' are being called when `y-or-n-p' is run. It seems to me, all windows stay the same size. Surely I'm missing something obvious, but what? > This problem is not limited to `write-file' -- all functions calling > `y-or-n-p' are affected by this! > Of course, it would be relatively straight forward to modify the offending > function (and all other similar functions). However, a more robust solution > would be for the code that calls the functions on the hook to ensure that > it isn't derailed when the buffer is changed. > Personally, I don't know that part of the code well enough to do this > change. Martin, is this something that you could look into, or suggest > someone who can? > See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19576 for more details. > -- Anders Lindgren -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 20:22:42 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 01:22:42 +0000 Received: from localhost ([127.0.0.1]:42156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyrSM-0007az-9y for submit@debbugs.gnu.org; Tue, 17 Nov 2015 20:22:42 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:58389 helo=homiemail-a101.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyrSK-0007ar-Em for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 20:22:40 -0500 Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id 49FA4117E06C; Tue, 17 Nov 2015 17:22:39 -0800 (PST) Received: from localhost.linkov.net (m91-131-172-22.cust.tele2.ee [91.131.172.22]) (Authenticated sender: jurta@jurta.org) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPA id BA027117E065; Tue, 17 Nov 2015 17:22:37 -0800 (PST) From: Juri Linkov To: Anders Lindgren Subject: Re: bug#19576: write-file writes the wrong buffer Organization: LINKOV.NET References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> Date: Wed, 18 Nov 2015 02:27:31 +0200 In-Reply-To: (Anders Lindgren's message of "Tue, 17 Nov 2015 22:52:53 +0100") Message-ID: <87h9kk6tjg.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: Alan Mackenzie , Eli Zaretskii , 19576@debbugs.gnu.org, martin rudalics X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > One thing that disturbs me (which I haven't fixed yet) is when a new buffer > is displayed in the middle of a group of follow-mode windows. It would be a > good idea to teach `display-buffer' to pick another window, like one the > first or last instead. We have now a powerful system of display-buffer actions such as display-buffer-reuse-window, display-buffer-below-selected, etc. So follow-mode could add a new specific display action to display-buffer-base-action that will exclude follow-mode windows from consideration when deciding where to display the buffer. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 17 20:38:00 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 01:38:00 +0000 Received: from localhost ([127.0.0.1]:42164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyrhA-00080C-3r for submit@debbugs.gnu.org; Tue, 17 Nov 2015 20:38:00 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:50736) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zyrgo-0007zf-Ov for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 20:37:57 -0500 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAI1baPh029567 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Nov 2015 01:37:37 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAI1bahp002148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Nov 2015 01:37:36 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAI1bZuW008625; Wed, 18 Nov 2015 01:37:35 GMT MIME-Version: 1.0 Message-ID: <10b92533-bce9-4839-9d13-2472fe816b14@default> Date: Tue, 17 Nov 2015 17:37:34 -0800 (PST) From: Drew Adams To: Juri Linkov , Anders Lindgren Subject: RE: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <87h9kk6tjg.fsf@mail.linkov.net> In-Reply-To: <87h9kk6tjg.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 19576 Cc: Alan Mackenzie , 19576@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) > We have now a powerful system of display-buffer actions such as > display-buffer-reuse-window, display-buffer-below-selected, etc. Don't forget `display-buffer-full-moon-but-not-blue-moon-unless-southern-he= misphere'. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 02:09:30 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 07:09:31 +0000 Received: from localhost ([127.0.0.1]:42300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zywrv-0003xO-Pk for submit@debbugs.gnu.org; Wed, 18 Nov 2015 02:09:29 -0500 Received: from mout.gmx.net ([212.227.15.18]:57148) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zywro-0003vx-Pr for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 02:09:23 -0500 Received: from [192.168.1.100] ([213.162.68.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MHX0m-1ZveXi3h1w-003JcD; Wed, 18 Nov 2015 08:09:19 +0100 Message-ID: <564C241A.4030505@gmx.at> Date: Wed, 18 Nov 2015 08:09:14 +0100 From: martin rudalics MIME-Version: 1.0 To: Alan Mackenzie , 19576@debbugs.gnu.org Subject: Re: bug#19576: write-file writes the wrong buffer References: <20151117221016.19100.qmail@mail.muc.de> In-Reply-To: <20151117221016.19100.qmail@mail.muc.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:ZjdS/u4iSf8tn0BF/zShcWOBIoA2qek5caGro7/O4D0JInQdWKq x2UcdmowDFUM6iUSRZHDEwotEWJjZfb0XDU8fM4fuawoUd1F7cp1ZsDtPOUZC+qpwJ4mtYG zpXqDuiQkBjYFwfAvZ+y9Hxi/n5cEiCSQCfBCc2dw8OD7ve16kBQYoAe78m+dhDjfO92eu7 uy2bu3TOHrKSXGnGavSaA== X-UI-Out-Filterresults: notjunk:1;V01:K0:FIEjdiLIw7s=:MCXjtNUP3L2+VSQd55Hzff JixeQDKw3FHzLricyC77nrm9CDU1kgufLf5r1Os0F8U/SjCbKbvZsdUB+iFtPgvK+5T8//+rr kn5J/NVafksBfmjXIok1wV6abnrfmMZf7dSWStMA1iTf13SwAxAVeIW5k+QqySBlCdK5rK+J8 8/dbv+0KSqdNksdGc3NbwzMomsLT80r48qAXDwN0tbJvA+kx4ifzm8AbO3nKU+ndFOLkF8lQR Y1sJVGPv03Su1hYXN/orwLnzN893zJxENR2vW171jF3ktDR/UX+tzE+mS9EU+avPlE3Va3E8M WN85ZKz/bTa27MhhYXPb9CGosT+eVAniTKfe43bZ+BtTEOr0HUEHpsuTcmJZOvJPRfKaMC3DD 5EQUayRJ1umocqba0X4R/QlPFf6NgCnvsY+C1EG0cpSDNjvFNaIqWND7VQImYCaDNzbvTCrKu DxvLgujf+V1mj3HiNs9Zh8zwQWEM2CwVYhatMKOmYIZ0M38q27AVFyZm1boNqo1cvtMFh7zsF q804fGmsF59VcRIQ4ZVL9AijwkU3uhXCiMf3Bhb/zd0FsDLaQ3Mqm5iZeRHGKNYkr6WAb+4+h GUtBEHDdVPTpFfg+JA6we4mMqahGPYlXZrfzBIrsl8hMfE9JyUlifX8o3oVgzXLPYamAGYs5k DCYUbcXHBoTHV0TFcSApbEBxuDkhTymOfpUC+folYnuAh64FWorHzFJL8pn+CkLrB43Fzp1ju C4gaea4w114AE/FwMBYTByJCSyc6MQeVgki0VWyJ5l8Iu84lpeQX1LR3Lpsv3D8keeWcY9uXL g2fMATjKyBRB8289rQ7sHOjZ+iXtw== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: Anders Lindgren X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > But I don't see why `window-size-change-functions' are being called wh= en > `y-or-n-p' is run. It seems to me, all windows stay the same size. > Surely I'm missing something obvious, but what? Probably =E2=80=98y-or-n-p=E2=80=99 somewhere in between saves and restor= es the window configuration where the latter counts as a size change even if there was none. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 02:54:47 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 07:54:47 +0000 Received: from localhost ([127.0.0.1]:42327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyxZn-0005Mw-AF for submit@debbugs.gnu.org; Wed, 18 Nov 2015 02:54:47 -0500 Received: from mail-yk0-f172.google.com ([209.85.160.172]:34654) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyxZm-0005Mo-16 for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 02:54:46 -0500 Received: by ykfs79 with SMTP id s79so50665152ykf.1 for <19576@debbugs.gnu.org>; Tue, 17 Nov 2015 23:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oRa72+WeYb4cefxnR1yuu94qR7Ppoh+4RjF83EG0srI=; b=Dcydad6EcZRQpD0d8WlQiQRwoDHEvECsTNoeVxKRLquk64EIcqeoh1RenegYR9XoY+ hmp3r+koOHUN5vdl2rgXvN4suJFguZl+UvNVOvT0FOxqCXT2aAP0UCHc7ByvCu7U6Koo VC03Aivh8bEnm+A2piFN2OppuNtSE8sE7+CzggN9Xf0lNNycDCnLB2pJ5XSRDXLuKx0D BDrwplMAoMpLPc8UVknTaOpCOuFTwsqL3muAvyKM2DjDWp5xVZ6LlmxMLKYCXwUStZ3+ 7Q7vfQnZLosL0jqklOyODTq5VOt7rYYHfSm3l1zgJCh/gMXYW5UQRW3ApqhLDZQm9whY M6cw== MIME-Version: 1.0 X-Received: by 10.129.147.135 with SMTP id k129mr93253ywg.233.1447833285353; Tue, 17 Nov 2015 23:54:45 -0800 (PST) Received: by 10.31.210.133 with HTTP; Tue, 17 Nov 2015 23:54:45 -0800 (PST) In-Reply-To: <87h9kk6tjg.fsf@mail.linkov.net> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <87h9kk6tjg.fsf@mail.linkov.net> Date: Wed, 18 Nov 2015 08:54:45 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: Juri Linkov Content-Type: multipart/alternative; boundary=94eb2c081608aae6620524cbf48c X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: Alan Mackenzie , Eli Zaretskii , 19576@debbugs.gnu.org, martin rudalics X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --94eb2c081608aae6620524cbf48c Content-Type: text/plain; charset=UTF-8 > > We have now a powerful system of display-buffer actions such as > display-buffer-reuse-window, display-buffer-below-selected, etc. > So follow-mode could add a new specific display action to > display-buffer-base-action that will exclude follow-mode windows > from consideration when deciding where to display the buffer. > It doesn't have to exclude all the windows. However, say that we have three side-by-side windows that contains the same buffer and follow-mode is active, then the middle window should not be picked. -- Anders --94eb2c081608aae6620524cbf48c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have now a powerful system of display-buffer = actions such as
display-buffer-reuse-window, display-buffer-below-selected, etc.
So follow-mode could add a new specific display action to
display-buffer-base-action that will exclude follow-mode windows
from consideration when deciding where to display the buffer.

It doesn't have to exclude all the windows. Howe= ver, say that we have three side-by-side windows that contains the same buf= fer and follow-mode is active, then the middle window should not be picked.=

=C2=A0 =C2=A0 -- Anders

--94eb2c081608aae6620524cbf48c-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 12:24:35 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 17:24:35 +0000 Received: from localhost ([127.0.0.1]:43582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6TD-00069s-DP for submit@debbugs.gnu.org; Wed, 18 Nov 2015 12:24:35 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:52510) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6St-00069J-3v for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 12:24:34 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NY000700TAMKC00@a-mtaout21.012.net.il> for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 19:24:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY00078CTO5JN30@a-mtaout21.012.net.il>; Wed, 18 Nov 2015 19:24:06 +0200 (IST) Date: Wed, 18 Nov 2015 19:24:02 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564AE692.2040303@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83vb8z9q6l.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <564AE692.2040303@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 17 Nov 2015 09:34:26 +0100 > From: martin rudalics > Cc: 19576@debbugs.gnu.org > > I attach a fix for restoring current buffer and selected window (the > latter hopefully taking care of selecting the right frame). Please tell > me whether it's sufficient for your purposes. Thanks for working on this, Martin. However, I don't think we should install this change. We call Lisp hooks from many places, including maybe a dozen in the display engine. It makes little sense to make only one of them resistant to this kind of problems. OTOH, if we do this everywhere, I feel that we will unduly punish 99.999% percent of legitimate users of these hooks just because one of them had a bug. I think this is a clear bug in follow.el, and should be fixed there, and nowhere else. Perhaps we should also have some prominent warnings in the documentation about this gotcha, so that the probability this will happen again becomes lower. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 12:46:08 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 17:46:08 +0000 Received: from localhost ([127.0.0.1]:43610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6o3-0006oI-ME for submit@debbugs.gnu.org; Wed, 18 Nov 2015 12:46:08 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:36793) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6o0-0006nz-Vs for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 12:46:06 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NY000200UI5FG00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 19:45:07 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY0002X3UN79350@a-mtaout20.012.net.il>; Wed, 18 Nov 2015 19:45:07 +0200 (IST) Date: Wed, 18 Nov 2015 19:45:03 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <20151117200204.GA5054@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie , martin rudalics Message-id: <83lh9v9p7k.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 17 Nov 2015 20:02:04 +0000 > From: Alan Mackenzie > Cc: 19576@debbugs.gnu.org > > On Tue, Nov 17, 2015 at 02:55:39AM +0200, Juri Linkov wrote: > > >> Conceptually it should be easy to do that. Save/restore current buffer, > > >> selected window and frame. But Alan (concerned about ‘follow-mode’), > > >> Pip (who unfortunately disappeared) and Eli are currently discussing how > > >> to fix ‘window-size-change-functions’ in various other ways as well. > > I have a fix for the `window-size-change-functions' problem, which I > posted just over an hour ago (see bug #21869 or #21333). The fix > consists of only invoking w-s-c-f after any change to the echo area size > has been done. This might have some relevance for the current bug. (I > haven't followed the current bug, I'm afraid.) I really need the > go-ahead from Eli before I can commit the fix to the emacs-25 or master > branch. Thanks for working on this, and sorry for the delay in reviewing your suggested changes. > I propose the following strategy to fix the bug: > > 1. Call resize_mini_window from redisplay_internal before the call to > prepare_menu_bars. > 2. Remove the call to resize_mini_window from display_echo_area_1, and > make that function of type void. > 3. Change the contract of echo_area_display, such that the echo area > must have been set to the correct height before calling it. > 4. Adapt message3_nolog (the only other function which calls > echo_area_display) to call resize_mini_window. > > As a result of these changes, any change in the size of the echo area > would be taken into account when invoking window-size-change-functions. I must say I prefer to avoid changes in the processing order of the display engine, unless they are absolutely necessary and we understand very well the effect of the order change. Which IMO is not the case here. Could you try a simpler patch below? It seems to fix both your test case and the one originally reported in bug#21333. Martin, is there any reason why window_resize_apply doesn't set the frame's window_sizes_changed flag, but instead relies on its callers to do that? --- src/window.c~0 2015-11-11 07:57:56.000000000 +0200 +++ src/window.c 2015-11-18 18:47:51.875303700 +0200 @@ -4555,6 +4555,7 @@ grow_mini_window (struct window *w, int /* Enforce full redisplay of the frame. */ /* FIXME: Shouldn't window--resize-root-window-vertically do it? */ fset_redisplay (f); + FRAME_WINDOW_SIZES_CHANGED (f) = true; adjust_frame_glyphs (f); unblock_input (); } @@ -4594,6 +4595,7 @@ shrink_mini_window (struct window *w, bo /* Enforce full redisplay of the frame. */ /* FIXME: Shouldn't window--resize-root-window-vertically do it? */ fset_redisplay (f); + FRAME_WINDOW_SIZES_CHANGED (f) = true; adjust_frame_glyphs (f); unblock_input (); } --- src/xdisp.c~0 2015-11-11 07:57:43.000000000 +0200 +++ src/xdisp.c 2015-11-18 18:53:32.333087700 +0200 @@ -13536,6 +13536,32 @@ redisplay_internal (void) { echo_area_display (false); + /* If echo_area_display resizes the mini-window, the redisplay and + window_sizes_changed flags of the selected frame are set, but + it's too late for the hooks in window-size-change-functions, + which have been examined already in prepare_menu_bars. So in + that case we call the hooks here only for the selected frame. */ + if (sf->redisplay && FRAME_WINDOW_SIZES_CHANGED (sf)) + { + Lisp_Object functions; + ptrdiff_t count1 = SPECPDL_INDEX (); + + record_unwind_save_match_data (); + + /* Clear flag first in case we get an error below. */ + FRAME_WINDOW_SIZES_CHANGED (sf) = false; + functions = Vwindow_size_change_functions; + + while (CONSP (functions)) + { + if (!EQ (XCAR (functions), Qt)) + call1 (XCAR (functions), selected_frame); + functions = XCDR (functions); + } + + unbind_to (count1, Qnil); + } + if (message_cleared_p) update_miniwindow_p = true; From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 12:52:44 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 17:52:44 +0000 Received: from localhost ([127.0.0.1]:43616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6uS-0006zV-1b for submit@debbugs.gnu.org; Wed, 18 Nov 2015 12:52:44 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:37845) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6uP-0006zM-WC for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 12:52:43 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NY000200UVCGH00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 19:52:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY0002OHUZR9370@a-mtaout20.012.net.il>; Wed, 18 Nov 2015 19:52:40 +0200 (IST) Date: Wed, 18 Nov 2015 19:52:35 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: X-012-Sender: halo1@inter.net.il To: Anders Lindgren Message-id: <83h9kj9ov0.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: rudalics@gmx.at, 19576@debbugs.gnu.org, acm@muc.de, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 17 Nov 2015 22:15:07 +0100 > From: Anders Lindgren > Cc: martin rudalics , Alan Mackenzie , 19576@debbugs.gnu.org, > Eli Zaretskii > > * The Emacs display engine tries to recenter windows when window-start == > buffer-end, to ensure that no window would appear empty. When follow-mode > is enabled, this is not what we want (except for the leftmost window). To > counter the recentering efforts of Emacs, follow-mode sets window-start > whenever it gets a chance. I would prefer if it was possible to tell the > display engine to leave some windows alone, preferably with some kind of > buffer-local `recenter-window-functions' variable. It could be made generic > so that the return value would be an integer telling Emacs to show this > many lines (if positive) or place the last line X lines from the bottom > (when negative). If such hook existed, follow-mode could return 0 for all > (except the leftmost) windows. Note that the user can change the content of > any window at any time, so this property isn't static. I don't understand why (set-window-start WINDOW POS t) is not sufficient. It does force the display engine to honor the window-start position requested by the call; no recentering will take place. You say you "would prefer if it was possible to tell the display engine to leave some windows alone", but that's exactly what the above call does, wrt the starting position of the window. So why isn't it sufficient? > * Make it easier for other packages to use it. By this I mean packages that > display information, like "grep", should be able to use follow mode to > display a buffer using side by side windows. But Follow is a minor-mode, right? So why cannot Grep etc. just turn it on? > * When follow-mode is enabled, there is a noticeable lag when updating the > region. You can see this by pressing C-c SPACE and holding the up or down > key. When follow-mode is disabled, the region is updated as fast as the > cursor moves, when enabled, it is updated in chunks. I guess follow-mode's post-command-hook interferes with pre-redisplay-functions used to display the region nowadays. Please look into this, it would be good to fix this before Emacs 25.1 is out. > * Process output: In early versions of follow-mode, it could be used with > any process. This was accomplished using `defadvice' on a handful of > process-related functions. At some point in time, this system was replaced > with a system specific to comint and compilation buffers -- as part of the > great defadvice sweep. Personally, I would like to Emacs to provide > `pre-process-output-functions' and `post-process-output-functions', > allowing packages like follow-mode to perform whatever action they would > like to the output of any process. Such hooks will be almost trivial to provide, I think. But I don't think I understand what problems would such hooks solve. Could you elaborate? > * If a user have columns with different widths, follow-mode can't correctly > display long lines stretching from one window to the next. The reason for > this is that the start position can't be placed at an arbitrary location on > a long line, only on positions that are a multiple of the column width. I > don't see any way to solve this without modifying the display engine. This is a tough nut, and the real problem is not necessarily obvious. The real problem is that the display engine _assumes_ the lines above and below the window edge are of the same pixel width. It uses this assumption in its layout code and decisions. But when follow-mode us used in windows of unequal width, that assumption breaks. This is a very serious problem, because the basic design of the Emacs display engine is that it does its job one window at a time, i.e. it assumes that displaying a window is possible by examining only the data of that single window, and its associated buffer. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 14:23:49 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 19:23:49 +0000 Received: from localhost ([127.0.0.1]:43710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz8KZ-0002rD-37 for submit@debbugs.gnu.org; Wed, 18 Nov 2015 14:23:48 -0500 Received: from mail-vk0-f42.google.com ([209.85.213.42]:34473) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz8KV-0002r1-KO for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 14:23:45 -0500 Received: by vkfr145 with SMTP id r145so1972537vkf.1 for <19576@debbugs.gnu.org>; Wed, 18 Nov 2015 11:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=guqVRJQ2SMkV2oIh++n+VQ1QnA969CQLMkymEVsqFPc=; b=uARnBFrb6HcqDB1bzu98K4ALLRbXuS8ubtjCekfWJEnBAn8RiwBilmHaBgbhjsYJuG lqXgEgBKg16nYlBIj8cLvZqi/mZ4WKDkViSFurpqMLtTfhKOF0xp6axvUWklhDwIQ6uC cuQKu9T9BdM1PyqmL55YTe9pYqnlue1iWHnii8j/0C3rlL01rg1eYCT6BPaRpNCTvwNF WaNw92zgB7qbaiviDXEXP6U2Da/7oELyjtANesHmOs056t/eiIGWf/rVZDdGNu1xvAHf 9vt+4UOzVyEGjhGQyW0ZAS38ifTJNKfLaBqjt1htbSY2dLI0YnkgJFEW4wV3ECUFJNEm 3ZNA== MIME-Version: 1.0 X-Received: by 10.31.169.142 with SMTP id s136mr447982vke.149.1447874623001; Wed, 18 Nov 2015 11:23:43 -0800 (PST) Received: by 10.31.210.133 with HTTP; Wed, 18 Nov 2015 11:23:42 -0800 (PST) In-Reply-To: <83h9kj9ov0.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> Date: Wed, 18 Nov 2015 20:23:42 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11415aca955b6e0524d594c6 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , 19576@debbugs.gnu.org, Alan Mackenzie , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11415aca955b6e0524d594c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! I don't understand why > > (set-window-start WINDOW POS t) > > is not sufficient. It does force the display engine to honor the > window-start position requested by the call; no recentering will take > place. You say you "would prefer if it was possible to tell the > display engine to leave some windows alone", but that's exactly what > the above call does, wrt the starting position of the window. So why > isn't it sufficient? > If "pos" is point-max, the window will be recentered after a while. You can try by entering the following in the *scratch* buffer: (set-window-start (selected-window) (point-max) t) Place the cursor at the end of the buffer and evaluate the expression using M-C-x. If you work with Emacs for a while, you will notice that the content of the *scratch* buffer will be visible after a while. This is what `follow-avoid-tail-recenter' is designed to avoid. (For follow-mode, this mean that the illusion of one tall window is broken, when the visible text doesn't reach the rightmost window.) As I have mentioned before, I would like to have a hook variable that the display engine can call when doing this. Packaged like follow-mode can use this to override the default behaviour. > > * Make it easier for other packages to use it. By this I mean packages > that > > display information, like "grep", should be able to use follow mode to > > display a buffer using side by side windows. > > But Follow is a minor-mode, right? So why cannot Grep etc. just turn > it on? > A package should never turn follow-mode on, but it should respect it when it is activated in buffer! Effectively, if a package wants to display a line in a buffer, and that line is visible in any of the windows in a follow-mode window group, that window should be used regardless if it was the window that was selected before. "Grep" does in fact do the right thing, the grep hit arrow move across the visible windows nicely. A package like "ispell" behaves behaves worse since it, somehow, prevent follow-mode from doing it's job. The effect is that the windows are no longer aligned (i.e. some lines are visible in more than one window, or some lines between two windows are no longer shown.) Another thing that makes things difficult is that the *selected* window group is aligned by follow-mode. If a package wants to show (but not select) another buffer, the windows of the other buffer will not be aligned automatically, and there is no good interface for this. (In my package `font-lock-studio', a control buffer is shown in the selected window, but I wanted the source buffer to be displayed aligned (if follow-mode was active). I ended up calling follow-post-command-hook directly, which really isn't a good practice.) > * When follow-mode is enabled, there is a noticeable lag when updating th= e > > region. You can see this by pressing C-c SPACE and holding the up or do= wn > > key. When follow-mode is disabled, the region is updated as fast as the > > cursor moves, when enabled, it is updated in chunks. > > I guess follow-mode's post-command-hook interferes with > pre-redisplay-functions used to display the region nowadays. Please > look into this, it would be good to fix this before Emacs 25.1 is out. > Unfortunately, I won't be able to work on this. We are expecting a baby any day now and when it comes to Emacs-related activitied I have picked up where Jan Dj=C3=A4rv left of regarding the NextStep port. Besides, this is more of a minor irritation point rather than showstopper, so it might just as well wait. > * Process output: In early versions of follow-mode, it could be used with > > any process. This was accomplished using `defadvice' on a handful of > > process-related functions. At some point in time, this system was > replaced > > with a system specific to comint and compilation buffers -- as part of > the > > great defadvice sweep. Personally, I would like to Emacs to provide > > `pre-process-output-functions' and `post-process-output-functions', > > allowing packages like follow-mode to perform whatever action they woul= d > > like to the output of any process. > > Such hooks will be almost trivial to provide, I think. But I don't > think I understand what problems would such hooks solve. Could you > elaborate? > Follow mode can be used both in plain source buffers and in process buffers. Concretely, you can have a *shell* buffer displayed in a number of side by side windows, where the prompt is at the bottom of the rightmost one, and the rest shows your recent activity. Normally, follow-mode use the post-command-hook to ensure that the windows are aligned. However, when you type something like "ls -lR" in your shell, output will be coming in through the process system, which is not seen by the post-command-hook. In my original follow-mode implementation, the process filter functions were advices so that all process output were passed through follow-modes own filter functions that aligned the windows and passed the output the real filter functions. The effect was that all process buffer, regardless of which system they used, worked with follow mode. At some point in time it was decided that `defavice' should not be used and this system was replaced with a simpler system only working with compilation and comint buffers. If generic process output hooks follow-mode could once again work for all processes, and in a much cleaner way. I can see other packages taking advantage of this, like packages that would color output or strip away parts of the output etc. > * If a user have columns with different widths, follow-mode can't > correctly > > display long lines stretching from one window to the next. The reason f= or > > this is that the start position can't be placed at an arbitrary locatio= n > on > > a long line, only on positions that are a multiple of the column width.= I > > don't see any way to solve this without modifying the display engine. > > This is a tough nut, and the real problem is not necessarily obvious. > The real problem is that the display engine _assumes_ the lines above > and below the window edge are of the same pixel width. It uses this > assumption in its layout code and decisions. But when follow-mode us > used in windows of unequal width, that assumption breaks. This is a > very serious problem, because the basic design of the Emacs display > engine is that it does its job one window at a time, i.e. it assumes > that displaying a window is possible by examining only the data of > that single window, and its associated buffer. > In most cases this is the sane thing to do, I guess. However, one way to handle this is to respect an explicit `set-window-start' position even if the column isn't a multiple of the screen width. > Thanks for working on this, Martin. However, I don't think we should > install this change. We call Lisp hooks from many places, including > maybe a dozen in the display engine. It makes little sense to make > only one of them resistant to this kind of problems. OTOH, if we do > this everywhere, I feel that we will unduly punish 99.999% percent of > legitimate users of these hooks just because one of them had a bug. > > I think this is a clear bug in follow.el, and should be fixed there, > and nowhere else. Perhaps we should also have some prominent warnings > in the documentation about this gotcha, so that the probability this > will happen again becomes lower. I don't agree with you on this but I respect your opinion. This is one of the most obscure bugs I have seen when working with Emacs -- trying to figure out why on earth `write-file' would save the wrong buffer was no easy task, even with many years of Emacs experience under my belt. There is a risk that other package writers will stumble upon similar problems and give up, or write it of as "unexplainable". Ensuring that the caller saves and restores the state is a very cheap life saver. -- Anders --001a11415aca955b6e0524d594c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

I don't understand why

=C2=A0 =C2=A0 (set-window-start WINDOW POS t)

is not sufficient.=C2=A0 It does force the display engine to honor the
window-start position requested by the call; no recentering will take
place.=C2=A0 You say you "would prefer if it was possible to tell the<= br> display engine to leave some windows alone", but that's exactly wh= at
the above call does, wrt the starting position of the window.=C2=A0 So why<= br> isn't it sufficient?

If "pos&q= uot; is point-max, the window will be recentered after a while. You can try= by entering the following in the *scratch* buffer:

=C2=A0(set-window-start (selected-window) (point-max) t)

Place the cursor at the end of the buffer and evaluate the express= ion using M-C-x.

If you work with Emacs for a whil= e, you will notice that the content of the *scratch* buffer will be visible= after a while. This is what `follow-avoid-tail-recenter' is designed t= o avoid. (For follow-mode, this mean that the illusion of one tall window i= s broken, when the visible text doesn't reach the rightmost window.)

As I have mentioned before, I would like to have a h= ook variable that the display engine can call when doing this. Packaged lik= e follow-mode can use this to override the default behaviour.

=C2=A0
&g= t; * Make it easier for other packages to use it. By this I mean packages t= hat
> display information, like "grep", should be able to use foll= ow mode to
> display a buffer using side by side windows.

But Follow is a minor-mode, right?=C2=A0 So why cannot Grep etc. jus= t turn
it on?

A package should never turn foll= ow-mode on, but it should respect it when it is activated in buffer!
<= div>
Effectively, if a package wants to display a line in a b= uffer, and that line is visible in any of the windows in a follow-mode wind= ow group, that window should be used regardless if it was the window that w= as selected before.

"Grep" does in fact = do the right thing, the grep hit arrow move across the visible windows nice= ly.

A package like "ispell" behaves beha= ves worse since it, somehow, prevent follow-mode from doing it's job. T= he effect is that the windows are no longer aligned (i.e. some lines are vi= sible in more than one window, or some lines between two windows are no lon= ger shown.)

Another thing that makes things diffic= ult is that the *selected* window group is aligned by follow-mode. If a pac= kage wants to show (but not select) another buffer, the windows of the othe= r buffer will not be aligned automatically, and there is no good interface = for this. (In my package `font-lock-studio', a control buffer is shown = in the selected window, but I wanted the source buffer to be displayed alig= ned (if follow-mode was active). I ended up calling follow-post-command-hoo= k directly, which really isn't a good practice.)


> * When follow-mode is e= nabled, there is a noticeable lag when updating the
> region. You can see this by pressing C-c SPACE and holding the up or d= own
> key. When follow-mode is disabled, the region is updated as fast as th= e
> cursor moves, when enabled, it is updated in chunks.

I guess follow-mode's post-command-hook interferes with
pre-redisplay-functions used to display the region nowadays.=C2=A0 Please look into this, it would be good to fix this before Emacs 25.1 is out.
<= /blockquote>

Unfortunately, I won't be able to work = on this. We are expecting a baby any day now and when it comes to Emacs-rel= ated activitied I have picked up where Jan Dj=C3=A4rv left of regarding the= NextStep port.

Besides, this is more of a minor i= rritation point rather than showstopper, so it might just as well wait.


> * Pr= ocess output: In early versions of follow-mode, it could be used with
> any process. This was accomplished using `defadvice' on a handful = of
> process-related functions. At some point in time, this system was repl= aced
> with a system specific to comint and compilation buffers -- as part of= the
> great defadvice sweep. Personally, I would like to Emacs to provide > `pre-process-output-functions' and `post-process-output-functions&= #39;,
> allowing packages like follow-mode to perform whatever action they wou= ld
> like to the output of any process.

Such hooks will be almost trivial to provide, I think.=C2=A0 But I d= on't
think I understand what problems would such hooks solve.=C2=A0 Could you elaborate?

Follow mode can be used both= in plain source buffers and in process buffers. Concretely, you can have a= *shell* buffer displayed in a number of side by side windows, where the pr= ompt is at the bottom of the rightmost one, and the rest shows your recent = activity.

Normally, follow-mode use the post-comma= nd-hook to ensure that the windows are aligned. However, when you type some= thing like "ls -lR" in your shell, output will be coming in throu= gh the process system, which is not seen by the post-command-hook.

In my original follow-mode implementation, the process fil= ter functions were advices so that all process output were passed through f= ollow-modes own filter functions that aligned the windows and passed the ou= tput the real filter functions. The effect was that all process buffer, reg= ardless of which system they used, worked with follow mode. At some point i= n time it was decided that `defavice' should not be used and this syste= m was replaced with a simpler system only working with compilation and comi= nt buffers.

If generic process output hooks follow= -mode could once again work for all processes, and in a much cleaner way. I= can see other packages taking advantage of this, like packages that would = color output or strip away parts of the output etc.


> * If a user have columns= with different widths, follow-mode can't correctly
> display long lines stretching from one window to the next. The reason = for
> this is that the start position can't be placed at an arbitrary lo= cation on
> a long line, only on positions that are a multiple of the column width= . I
> don't see any way to solve this without modifying the display engi= ne.

This is a tough nut, and the real problem is not necessarily obvious= .
The real problem is that the display engine _assumes_ the lines above
and below the window edge are of the same pixel width.=C2=A0 It uses this assumption in its layout code and decisions.=C2=A0 But when follow-mode us<= br> used in windows of unequal width, that assumption breaks.=C2=A0 This is a very serious problem, because the basic design of the Emacs display
engine is that it does its job one window at a time, i.e. it assumes
that displaying a window is possible by examining only the data of
that single window, and its associated buffer.

In most cases this = is the sane thing to do, I guess.

However, one way to handle this is to respect a= n explicit `set-window-start' position even if the column isn't a m= ultiple of the screen width.


> Thanks for working on this, Martin.=C2=A0 However, I= don't think we should
> install this change.=C2=A0 We call Lisp hooks fr= om many places, including
> maybe a dozen in the display engine.=C2=A0 It ma= kes little sense to make
> only one of them resistant to this kind of probl= ems.=C2=A0 OTOH, if we do
> this everywhere, I feel that we will unduly puni= sh 99.999% percent of
> legitimate users of these hooks just because one of t= hem had a bug.
>
> I think this is a clear b= ug in follow.el, and should be fixed there,
> and nowhere else.=C2=A0 Perhaps= we should also have some prominent warnings
> in the documentation about thi= s gotcha, so that the probability this
> will happen again becomes lower.
= I don't agree with you on this but I respect your opinion.
=

This is one o= f the most obscure bugs I have seen when working with Emacs -- trying to fi= gure out why on earth `write-file' would save the wrong buffer was no e= asy task, even with many years of Emacs experience under my belt.

<= /div>
There is a= risk that other package writers will stumble upon similar problems and giv= e up, or write it of as "unexplainable". Ensuring that the caller= saves and restores the state is a very cheap life saver.

=C2=A0 =C2=A0 --= Anders

--001a11415aca955b6e0524d594c6-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 15:52:57 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 20:52:57 +0000 Received: from localhost ([127.0.0.1]:43789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz9iq-0006vg-VW for submit@debbugs.gnu.org; Wed, 18 Nov 2015 15:52:57 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:57540) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz9iV-0006uy-NB for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 15:52:55 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NY100A002W5D300@mtaout28.012.net.il> for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 22:51:28 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY1006KB39SB140@mtaout28.012.net.il>; Wed, 18 Nov 2015 22:51:28 +0200 (IST) Date: Wed, 18 Nov 2015 22:52:26 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: X-012-Sender: halo1@inter.net.il To: Anders Lindgren Message-id: <8337w39gj9.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: rudalics@gmx.at, 19576@debbugs.gnu.org, acm@muc.de, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 18 Nov 2015 20:23:42 +0100 > From: Anders Lindgren > Cc: Juri Linkov , martin rudalics , Alan Mackenzie , > 19576@debbugs.gnu.org > > I don't understand why > > (set-window-start WINDOW POS t) > > is not sufficient. It does force the display engine to honor the > window-start position requested by the call; no recentering will take > place. You say you "would prefer if it was possible to tell the > display engine to leave some windows alone", but that's exactly what > the above call does, wrt the starting position of the window. So why > isn't it sufficient? > > > If "pos" is point-max, the window will be recentered after a while. You can try > by entering the following in the *scratch* buffer: > > (set-window-start (selected-window) (point-max) t) > > Place the cursor at the end of the buffer and evaluate the expression using > M-C-x. > > If you work with Emacs for a while, you will notice that the content of the > *scratch* buffer will be visible after a while. Is the M-C-x part important? (I used M-: instead.) If it isn't, then I don't see any spontaneous recentering after that, so a reproducible test case will be appreciated. Maybe something that makes the difference hides behind "work with Emacs for a while", I don't know. > As I have mentioned before, I would like to have a hook variable that the > display engine can call when doing this. When doing what? > Packaged like follow-mode can use this to override the default > behaviour. The default behavior in what aspect? > "Grep" does in fact do the right thing, the grep hit arrow move across the > visible windows nicely. > > A package like "ispell" behaves behaves worse since it, somehow, prevent > follow-mode from doing it's job. The effect is that the windows are no longer > aligned (i.e. some lines are visible in more than one window, or some lines > between two windows are no longer shown.) > > Another thing that makes things difficult is that the *selected* window group > is aligned by follow-mode. If a package wants to show (but not select) another > buffer, the windows of the other buffer will not be aligned automatically, and > there is no good interface for this. (In my package `font-lock-studio', a > control buffer is shown in the selected window, but I wanted the source buffer > to be displayed aligned (if follow-mode was active). I ended up calling > follow-post-command-hook directly, which really isn't a good practice.) These all sound like application-level problems to me, not issues with the display engine. At least not in the first approximation. > > * Process output: In early versions of follow-mode, it could be used with > > any process. This was accomplished using `defadvice' on a handful of > > process-related functions. At some point in time, this system was > replaced > > with a system specific to comint and compilation buffers -- as part of > the > > great defadvice sweep. Personally, I would like to Emacs to provide > > `pre-process-output-functions' and `post-process-output-functions', > > allowing packages like follow-mode to perform whatever action they would > > like to the output of any process. > > Such hooks will be almost trivial to provide, I think. But I don't > think I understand what problems would such hooks solve. Could you > elaborate? > > > Follow mode can be used both in plain source buffers and in process buffers. > Concretely, you can have a *shell* buffer displayed in a number of side by side > windows, where the prompt is at the bottom of the rightmost one, and the rest > shows your recent activity. > > Normally, follow-mode use the post-command-hook to ensure that the windows are > aligned. However, when you type something like "ls -lR" in your shell, output > will be coming in through the process system, which is not seen by the > post-command-hook. Doesn't this mean that you need a way to hook buffer text changes? Hooking processes is not necessarily what you want, since a process filter could eat up the output completely and not show it in any window, in which case follow-mode shouldn't be bothered. Right? > However, one way to handle this is to respect an explicit `set-window-start' > position even if the column isn't a multiple of the screen width. Ask Alain how easy that is. I'm telling you: this is the tip of a huge iceberg. The display engine was never designed to handle windows whose redisplay depends on other windows. > > Thanks for working on this, Martin. However, I don't think we should > > install this change. We call Lisp hooks from many places, including > > maybe a dozen in the display engine. It makes little sense to make > > only one of them resistant to this kind of problems. OTOH, if we do > > this everywhere, I feel that we will unduly punish 99.999% percent of > > legitimate users of these hooks just because one of them had a bug. > > > > I think this is a clear bug in follow.el, and should be fixed there, > > and nowhere else. Perhaps we should also have some prominent warnings > > in the documentation about this gotcha, so that the probability this > > will happen again becomes lower. > > I don't agree with you on this but I respect your opinion. > > This is one of the most obscure bugs I have seen when working with Emacs -- > trying to figure out why on earth `write-file' would save the wrong buffer was > no easy task, even with many years of Emacs experience under my belt. > > There is a risk that other package writers will stumble upon similar problems > and give up, or write it of as "unexplainable". Ensuring that the caller saves > and restores the state is a very cheap life saver. It's cheap for the "perpetrators", but it distributes the cost among the "innocent". Sorry, I simply cannot agree to such "re-balancing" of guilt. And yes, I know how much time debugging a tricky bug can consume. been there, done that. Still, once the reason is identified, we must find the best place to fix it. Choosing that place frequently involves compromises. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 18:21:11 2015 Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 23:21:11 +0000 Received: from localhost ([127.0.0.1]:43845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzC2I-0002MX-LP for submit@debbugs.gnu.org; Wed, 18 Nov 2015 18:21:11 -0500 Received: from mail.muc.de ([193.149.48.3]:39954) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzC2F-0002MN-9B for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 18:21:08 -0500 Received: (qmail 90774 invoked by uid 3782); 18 Nov 2015 23:21:05 -0000 Received: from acm.muc.de (p579E9E85.dip0.t-ipconnect.de [87.158.158.133]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 19 Nov 2015 00:21:04 +0100 Received: (qmail 19801 invoked by uid 1000); 18 Nov 2015 23:23:04 -0000 Date: Wed, 18 Nov 2015 23:23:04 +0000 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer Message-ID: <20151118232304.GB1690@acm.fritz.box> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83lh9v9p7k.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Eli. On Wed, Nov 18, 2015 at 07:45:03PM +0200, Eli Zaretskii wrote: > > Date: Tue, 17 Nov 2015 20:02:04 +0000 > > From: Alan Mackenzie > > Cc: 19576@debbugs.gnu.org [ .... ] > > I propose the following strategy to fix the bug: > > 1. Call resize_mini_window from redisplay_internal before the call to > > prepare_menu_bars. > > 2. Remove the call to resize_mini_window from display_echo_area_1, and > > make that function of type void. > > 3. Change the contract of echo_area_display, such that the echo area > > must have been set to the correct height before calling it. > > 4. Adapt message3_nolog (the only other function which calls > > echo_area_display) to call resize_mini_window. > > As a result of these changes, any change in the size of the echo area > > would be taken into account when invoking window-size-change-functions. > I must say I prefer to avoid changes in the processing order of the > display engine, unless they are absolutely necessary and we understand > very well the effect of the order change. Which IMO is not the case > here. Yes. This thought occurred to me too, this morning. I identified the function calls which were "missing" before doing the echo area size change that I inserted. These were (in order): 1. reconsider_clip_changes 2. bset_update_mode_line 3. clear_garbaged_frames 4. inhibit_garbage_collection 5. forget_escape_and_glyphless_faces . Why not duplicate some of these calls on the way to the new echo area size change code? 1. I don't know what "clip_changes" are. 2. is surely harmless if done twice. 3. doesn't seem connected with the purpose of the function, but surely is expensive enough only to be done once. 4. seems like a good idea anyway, and 5. is cheap, and may have some effect upon the calculation of the new size of the echo area. > Could you try a simpler patch below? It seems to fix both your test > case and the one originally reported in bug#21333. It does indeed fix my test case (I haven't tried it on #21333). However it violates the specification of window-size-change-functions, which says that the hook is called _before_ redisplay, not after it has started. I suppose one could argue over what "redisplay" means here, but intuitively I would say it is the putting of glyphs into matrices. Also, there may be a possibility of w-s-c-f being invoked twice in a single redisplay action. I don't know whether this is bad or not, but it doesn't seem good. One way to "solve" these problems, although it is not pretty, is to put an invocation of w-s-c-f into display_echo_area_1, just after the echo area has (possibly) been resized. This invocation would also test and reset FRAME_WINDOW_SIZES_CHANGED (f). There would have to be further invocation(?s) of w-s-c-f in the other arms of the pertinent conditional in redisplay_internal. For that pain, we could take the w-s-c-f out of prepare_menu_bars. > Martin, is there any reason why window_resize_apply doesn't set the > frame's window_sizes_changed flag, but instead relies on its callers > to do that? [ patch tested and snipped ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 18 21:07:20 2015 Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 02:07:20 +0000 Received: from localhost ([127.0.0.1]:43920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzEd6-0000Ab-CN for submit@debbugs.gnu.org; Wed, 18 Nov 2015 21:07:20 -0500 Received: from mail-pa0-f49.google.com ([209.85.220.49]:36553) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzEcV-00008m-ED for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 21:07:00 -0500 Received: by pacdm15 with SMTP id dm15so63648217pac.3 for <19576@debbugs.gnu.org>; Wed, 18 Nov 2015 18:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version:content-type; bh=hPEWXC+h6Ip6eY3ljBT0sswO6Xn6I+su+7bWoVVGYa8=; b=M5Cyy9R2urgYdz5tOu+l8m/8KHZU0bcIYsEi7aL4yacqbmQq1Qjnr+lXUN2UPHRFU+ eLJ8NW/1XLcwZk4m8IeddsXgS+8ZbOxuUO7iumwShwOA860h8kCqZZ6EUgzz08quToVX ha7/qWtqg/fKnoYSf3g2N+C/86aG4W2ISLGfzCTnAwmQE/SZ27mnlyM9hU3Vrjnh5+Gu yPxNONuf9OQkG7kdDoD6aGHWFrQ7PfYGd05+VtmBWGvUrVls19KtS3k6PC2M4Px8NokX 154Q2o3H8U4OQQDxX/rNZP4i0qXJvoFoC30+vvwCj8xCcbAc0Jop7t1lOz3Yr3w9Wn92 AUmw== X-Received: by 10.68.68.233 with SMTP id z9mr6886000pbt.76.1447898803014; Wed, 18 Nov 2015 18:06:43 -0800 (PST) Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id ea1sm6637082pbb.76.2015.11.18.18.06.40 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 18 Nov 2015 18:06:41 -0800 (PST) From: John Wiegley X-Google-Original-From: "John Wiegley" Received: by Vulcan.local (Postfix, from userid 501) id 8670B109F5D0F; Wed, 18 Nov 2015 18:06:39 -0800 (PST) To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-Reply-To: <8337w39gj9.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 18 Nov 2015 22:52:26 +0200") Date: Wed, 18 Nov 2015 18:06:37 -0800 Message-ID: References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> <8337w39gj9.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, Anders Lindgren , juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>>>> Eli Zaretskii writes: > It's cheap for the "perpetrators", but it distributes the cost among the > "innocent". Sorry, I simply cannot agree to such "re-balancing" of guilt. > And yes, I know how much time debugging a tricky bug can consume. been > there, done that. Still, once the reason is identified, we must find the > best place to fix it. Choosing that place frequently involves compromises. I have to agree with Eli on this one. John From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 19 01:54:36 2015 Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 06:54:36 +0000 Received: from localhost ([127.0.0.1]:44122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzJ75-00030u-6Z for submit@debbugs.gnu.org; Thu, 19 Nov 2015 01:54:35 -0500 Received: from mail-vk0-f51.google.com ([209.85.213.51]:35502) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzJ72-00030m-TR for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 01:54:33 -0500 Received: by vkha189 with SMTP id a189so11011213vkh.2 for <19576@debbugs.gnu.org>; Wed, 18 Nov 2015 22:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BnDnO+iBWsZWEX1OhqnmpRjFvMzgmzbaJEKDW9SxjLE=; b=VDDNIcQSwFqQX/d+zFebE1sZZDwFJs9JJu40K9COXvZgFr60LZVIYjaXDrhkPJgYmg NOFbOvnwDqa5bCOMcLgdLwHilfWcPq5kd8YMnh6CDYdHdFtvi3hQJKXvPuSYtbOBxcb1 bS2U5tqbTpGCKklQDEMs034vjRkdPkNS4+P0Xsw3NrpJukixmzCThvNz7u9OZbEqAXRo Gmq46GP32lbiALgN3b+Pyz1K6j+gzKkfnbxdSrzAEMiXY7auGOUUWImKhc1jYqNFX7Gj 6h0R5mY0xwodmr7gOC16SLn60Lj21JzbNmh0acu58mmd6MdKdr08IfnyMeF6jjwavnnb NCuA== MIME-Version: 1.0 X-Received: by 10.31.150.150 with SMTP id y144mr3089737vkd.70.1447916072175; Wed, 18 Nov 2015 22:54:32 -0800 (PST) Received: by 10.31.210.133 with HTTP; Wed, 18 Nov 2015 22:54:32 -0800 (PST) In-Reply-To: <8337w39gj9.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> <8337w39gj9.fsf@gnu.org> Date: Thu, 19 Nov 2015 07:54:32 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a1141b5f22591f40524df3b87 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , 19576@debbugs.gnu.org, Alan Mackenzie , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1141b5f22591f40524df3b87 Content-Type: text/plain; charset=UTF-8 Hi, > I don't see any spontaneous recentering after that, so a reproducible > test case will be appreciated. Maybe something that makes the > difference hides behind "work with Emacs for a while", I don't know. > It's hard to give an exact recipe, because the recentering occurs stochastically. Sometimes, it occurs within a few seconds, sometimes within a minute and sometimes the window stays like it is for a long period of time. The fact remains that a window where window-start equals point-max (i.e. a window displaying nothing) do recenter itself from time to time. Today, follow-mode actively prevents this by updating window-start of "tail windows" whenever it gets a change (in the post-command-hook and in all display-related hooks). Clearly, this is not an elegant solution, but in practice it works. My proposal is to modify the display engine so that instead of simply recentering a window, it should call a hook to determine if the recentering should take place. This can be made more of less fancy -- a simple solution would be to return a boolean. A more advances solution could let a lisp function in packages to decide how many lines should be visible. Clearly, this is not something that would affect efficiency negatively as this would be called relative seldom, maybe once a minute, and only if the hook variable is non-nil. In fact, it will have a positive effect on efficiency as the current solution isn't very efficient. Anyway, this is not something that we have to change. The current solution, albeit clumsy, have been working for 20 years. > These all sound like application-level problems to me, not issues with > the display engine. At least not in the first approximation. Yes, I agree on this. The list I originally mailed contained all follow-mode related thoughts, not just the display-engine related. Doesn't this mean that you need a way to hook buffer text changes? > Hooking processes is not necessarily what you want, since a process > filter could eat up the output completely and not show it in any > window, in which case follow-mode shouldn't be bothered. Right? > Right. However, the difference is rather academic since it would probably few cases where a prior filter would eat all output. > However, one way to handle this is to respect an explicit > `set-window-start' > > position even if the column isn't a multiple of the screen width. > > Ask Alain how easy that is. > > I'm telling you: this is the tip of a huge iceberg. The display > engine was never designed to handle windows whose redisplay depends on > other windows. OK, lets leave it as it is for now. When it comes to bug#19576 (write-file saves the wrong buffer). As both John and Eli think this shouldn't be fixed in the Emacs core, I will correct the code in follow-mode and (if needed) update the documentation to warn others of the dragons in these waters. Anyway, I will pull out the this follow-mode discussion, partly because I feel it has taken the focus away from the work Alan is doing, and partly for personal reasons. The little time I have for Emacs-related work, I will focus on NextStep issues. Sincerely, Anders Lindgren --001a1141b5f22591f40524df3b87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0
I don't see any spontaneous recentering after that, so a reproducible test case will be appreciated.=C2=A0 Maybe something that makes the
difference hides behind "work with Emacs for a while", I don'= t know.

It's hard to give an exact = recipe, because the recentering occurs stochastically. Sometimes, it occurs= within a few seconds, sometimes within a minute and sometimes the window s= tays like it is for a long period of time.

The fac= t remains that a window where window-start equals point-max (i.e. a window = displaying nothing) do recenter itself from time to time.

Today, follow-mode actively prevents this by updating window-start = of "tail windows" whenever it gets a change (in the post-command-= hook and in all display-related hooks). Clearly, this is not an elegant sol= ution, but in practice it works.

My proposal is to= modify the display engine so that instead of simply recentering a window, = it should call a hook to determine if the recentering should take place. Th= is can be made more of less fancy -- a simple solution would be to return a= boolean. A more advances solution could let a lisp function in packages to= decide how many lines should be visible.

Clearly,= this is not something that would affect efficiency negatively as this woul= d be called relative seldom, maybe once a minute, and only if the hook vari= able is non-nil. In fact, it will have a positive effect on efficiency as t= he current solution isn't very efficient.

Anyw= ay, this is not something that we have to change. The current solution, alb= eit clumsy, have been working for 20 years.


> These all sound like application-level problems to me, not is= sues with
> the display engine.=C2=A0 At least not in the firs= t approximation.

Yes, I agree on this. The list I = originally mailed contained all follow-mode related thoughts, not just the = display-engine related.


Doesn't this mean that you need a way to hook buffer text changes?
Hooking processes is not necessarily what you want, since a process
filter could eat up the output completely and not show it in any
window, in which case follow-mode shouldn't be bothered.=C2=A0 Right?

Right. However, the difference is rather= academic since it would probably few cases where a prior filter would eat = all output.


> = However, one way to handle this is to respect an explicit `set-window-start= '
> position even if the column isn't a multiple of the screen width.<= br>
Ask Alain how easy that is.

I'm telling you: this is the tip of a huge iceberg.=C2=A0 The display engine was never designed to handle windows whose redisplay depends on
other windows.

OK, lets leave it as it is f= or now.


When it comes to bug#19576 = (write-file saves the wrong buffer). As both John and Eli think this should= n't be fixed in the Emacs core, I will correct the code in follow-mode = and (if needed) update the documentation to warn others of the dragons in t= hese waters.

Anyway, I will pull out the this foll= ow-mode discussion, partly because I feel it has taken the focus away from = the work Alan is doing, and partly for personal reasons. The little time I = have for Emacs-related work, I will focus on NextStep issues.

Sincerely,
=C2=A0 =C2=A0 Anders Lindgren
<= /div>

--001a1141b5f22591f40524df3b87-- From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 19 03:13:01 2015 Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 08:13:01 +0000 Received: from localhost ([127.0.0.1]:44174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzKKy-0004uX-Kf for submit@debbugs.gnu.org; Thu, 19 Nov 2015 03:13:01 -0500 Received: from mout.gmx.net ([212.227.15.15]:56393) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzKKw-0004uM-B9 for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 03:12:58 -0500 Received: from [192.168.1.100] ([213.162.68.32]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MOwbP-1a2uyd2bN1-006LJo; Thu, 19 Nov 2015 09:12:56 +0100 Message-ID: <564D8482.20804@gmx.at> Date: Thu, 19 Nov 2015 09:12:50 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <564AE692.2040303@gmx.at> <83vb8z9q6l.fsf@gnu.org> In-Reply-To: <83vb8z9q6l.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:BBde84AAjt7GkRmiYqnXGoKkBYF0KxlsQiTVb6mUSMLJNxgvz0k R2kOnWSr23PDaPC3lgyzzDkw+sfR3s/DkELittPEbVLujLrPUjappGLPFqK5eI8rra++l5S KvYh9ZbSouUJNO0XY3zgv7LbMoKfekFzgT96rszNajrS8jgc54B/HUT9y2/Wt3s6tN4q6zJ F/0aelgVE0JCs92/HPykw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ozi8RhAXYIQ=:80ReKC2uaHviR/Aozwn0Vo H+cd1ag1hAe7zBIR9qGfMGgLyEcF8bwr0niF54/zKIJhIwVdp1ndnupxplZgElPoPabHS+tmr qnXOgz3AVngi8JMEVZC9mNITfHxnc1pYt6RJ+Qzpy2FfBgTYcdcirHE2BXC3zQeYA63nGuapm tSnKcxGHb+oYYHuVMSrgvfM155bnSeioq1zk3Q4jjJoggCzfKhuTaK2SaMF/qLDL9aXODxb5j 03J0HYV1OS/kYOCSKG+r4f03hmwpRYO44p5bcBB99PH1EZfSp5KrLn29wATqjcn9NG5QFR0ec jrOP+4OCKJLkioiXzodZLMK3w4mdRuD7P39RRh0Cf290Ioo209+IcflkLLu9ijaXmsL7rneKT p5oXbOzKVJ3lZ2oAk+fY1Y+x1gIsPIwaws4R880c3STDvZmLgzVgWMMKtiHQwECxzgcP2V0gV XS5sa/T8MSEj+LpRdWfgh8NUa5TCAwsp3uUxMISFf2Nzkz0+8/WRjcbb65SKTEBMCjYC5tU9t KgFH/mDwwIRaZJXmRCV/m0KB/9eG6pAB3jgclHRHtM1TJIzP7FxBYLSwDuHwFE+ruenpMdKZ+ uJ9bSZUpCt4jBGcoJXsX5yV0MkGrc6uzNDJKLNmeiI5VQnj9sLWh/B3jFg6sSUyTvRy6FnvOZ Kb8EG6RtP7fd6pvmwT+z7uXrCqbZrHXcrISoLE/AHz+PMg1xeWmsJUk7YvY0rO46xklttjbHK H06n0o8UsQhuTCZeDFyXz+LoVMAALYaezzmBulD4D2CGCZX8LId9J9KTXf2/bJLTwd+xraRmv C6NgrtQC4N1hjZknjUwahlvSKCU8w== X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Thanks for working on this, Martin. However, I don't think we should > install this change. We call Lisp hooks from many places, including > maybe a dozen in the display engine. It makes little sense to make > only one of them resistant to this kind of problems. OTOH, if we do > this everywhere, I feel that we will unduly punish 99.999% percent of > legitimate users of these hooks just because one of them had a bug. [...] Content analysis details: (3.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [213.162.68.32 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.32 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Thanks for working on this, Martin. However, I don't think we should > install this change. We call Lisp hooks from many places, including > maybe a dozen in the display engine. It makes little sense to make > only one of them resistant to this kind of problems. OTOH, if we do > this everywhere, I feel that we will unduly punish 99.999% percent of > legitimate users of these hooks just because one of them had a bug. [...] Content analysis details: (3.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.32 listed in zen.spamhaus.org] 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [213.162.68.32 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > Thanks for working on this, Martin. However, I don't think we should > install this change. We call Lisp hooks from many places, including > maybe a dozen in the display engine. It makes little sense to make > only one of them resistant to this kind of problems. OTOH, if we do > this everywhere, I feel that we will unduly punish 99.999% percent of > legitimate users of these hooks just because one of them had a bug. 100% agreed. But run_window_configuration_change_hook goes a long way saving and restoring current buffer and selected window around each call to a function on =E2=80=98window-configuration-change-hook=E2=80=99. People who put their functions on =E2=80=98window-size-change-functions=E2= =80=99 and =E2=80=98window-configuration-change-hook=E2=80=99 usually don't care abo= ut the precise reason why these function get called. They simply want to cover all cases where a new window appears or a specific window changes size. Do we really expect them to add a =E2=80=98save-window-excursion=E2=80=99 in= one case and avoid it in the other because it would mean unnecessary extra work? > I think this is a clear bug in follow.el, and should be fixed there, > and nowhere else. Perhaps we should also have some prominent warnings= > in the documentation about this gotcha, so that the probability this > will happen again becomes lower. We've broken the taboo in =E2=80=98window-configuration-change-hook=E2=80= =99. Anything we add now will only increase confusion. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 19 03:13:24 2015 Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 08:13:24 +0000 Received: from localhost ([127.0.0.1]:44178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzKLM-0004vX-9z for submit@debbugs.gnu.org; Thu, 19 Nov 2015 03:13:24 -0500 Received: from mout.gmx.net ([212.227.15.15]:61552) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzKLK-0004vP-Mi for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 03:13:23 -0500 Received: from [192.168.1.100] ([213.162.68.32]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MUZKF-1ZquRZ1RKd-00RKFR; Thu, 19 Nov 2015 09:13:18 +0100 Message-ID: <564D8497.4090703@gmx.at> Date: Thu, 19 Nov 2015 09:13:11 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Alan Mackenzie Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> In-Reply-To: <83lh9v9p7k.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:EBnzvm2xakx9+G9EbuxU0jj1PDNMFrAshk6ifyEZ5wxdgoIUMWQ HEf5qmZlC/8dmyuaZYva5wqLnsCpxYG+1tDdc4yrZMTSB9I5mmMzwhL7wxPVMC6C8Fimrl1 N0r1jDSoDj5mvH2kwzbrZ65o89rnphejDJAqS8zKc21hr98/EbZXcLUpH1Fjja6jFf1dYxy 6i5o2D4VTE7ibgcXeiT6Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:bD0D2NKmPMw=:ZJx+Jd7Z5hn9S/vhmcVb/I EFJOOwWkEn53gjPXWq1504viX/kc0CKd9zKSuonYL68sUMRqtn1DMCel19ff1XtuhURpYlZk8 MO+0uXtL2o+wcccipXq0E9u4DZW9eE/iE0wmwaBq8rd8jPMiFQ5O1I0B/ClhzTUtC3Kxz6RSI EI6Boa6Hw52Er9BD6twZax8T/I3G5YFonFr0/m7U2cr+1VkzF9QJXVqqN12nZr7yIO6y/NzT8 t/uW7SJRLqjODIzOfhUnBjY8C4N5LWh+7dyi8OsE+Q09KREyV5NhbvzbD7fBrhVK/mY7nlj7m I37B3rPzvbdGT3XBSJMxrM7yndpprgKXe2mCbprSl0ZmDVMK32ApSZzDoPR+ZrhPzXPNt0ppL fe0DGYpgv3Gh7B3iw/WaNl3Fbs6qXGIMPO3CXefz3gw1YO/1LG2hlZmMrOLfbG+l4giZOelRT gMzohrcPgodq+hXqkU4G39tM7a0QjBUZWpUL6bHGTJpnFp7NQ21N21lZ/vW3ajRi9lpV1Lh02 W10LelokRdoRgt1U2koMShtVn2TDIdxFCCmz6YdpQSqq5vyHipps48V8LYLD/3AldEznCFG4S iib7SxN0aJ/7nroA75zjt1ki5lOpdPOYKdTgP2bRD1ewnqRcEvuX8B5vIq+WRyR0KDQW45XuP Mxpwy7829h9/xRwYtgxFqaxfh6GWpNM6XWjHIFNM1xDWJBANYZ4UjxHWBIS+N3O4qbYA7P4FF ZAsip/V6Q3cFWruaLnVG9+sftM7+aYKn2GlWPxDrAcDOwamRbqmBWWwrfyQ5M0Ed1NxdxYiq8 hteGFcvd77aDg+CPUOMLJZMt6WWFg== X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Martin, is there any reason why window_resize_apply doesn't set the > frame's window_sizes_changed flag, but instead relies on its callers > to do that? No particular reason. But note that ‘delete-other-windows-internal’ may bypass window_resize_apply, so in that particular case we have to manually make sure that the window_sizes_changed flag gets set. I hope this is the only case where it matters. [...] Content analysis details: (3.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.32 listed in zen.spamhaus.org] 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [213.162.68.32 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Martin, is there any reason why window_resize_apply doesn't set the > frame's window_sizes_changed flag, but instead relies on its callers > to do that? No particular reason. But note that ‘delete-other-windows-internal’ may bypass window_resize_apply, so in that particular case we have to manually make sure that the window_sizes_changed flag gets set. I hope this is the only case where it matters. [...] Content analysis details: (3.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.32 listed in zen.spamhaus.org] 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [213.162.68.32 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > Martin, is there any reason why window_resize_apply doesn't set the > frame's window_sizes_changed flag, but instead relies on its callers > to do that? No particular reason. But note that =E2=80=98delete-other-windows-intern= al=E2=80=99 may bypass window_resize_apply, so in that particular case we have to manually make sure that the window_sizes_changed flag gets set. I hope this is the only case where it matters. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 19 10:32:19 2015 Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 15:32:19 +0000 Received: from localhost ([127.0.0.1]:45085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzRC6-0000ee-Hv for submit@debbugs.gnu.org; Thu, 19 Nov 2015 10:32:19 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:63463) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzRC3-0000eU-P2 for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 10:32:17 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NY200B00IUH6S00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 17:32:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY200A2DJ5PQFB0@a-mtaout20.012.net.il>; Thu, 19 Nov 2015 17:32:14 +0200 (IST) Date: Thu, 19 Nov 2015 17:31:58 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: X-012-Sender: halo1@inter.net.il To: Anders Lindgren Message-id: <83vb8y80pd.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> <8337w39gj9.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: rudalics@gmx.at, 19576@debbugs.gnu.org, acm@muc.de, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 19 Nov 2015 07:54:32 +0100 > From: Anders Lindgren > Cc: Juri Linkov , martin rudalics , Alan Mackenzie , > 19576@debbugs.gnu.org > > I don't see any spontaneous recentering after that, so a reproducible > test case will be appreciated. Maybe something that makes the > difference hides behind "work with Emacs for a while", I don't know. > > It's hard to give an exact recipe, because the recentering occurs stochastically. Sometimes, it occurs within a few seconds, sometimes within a minute and sometimes the window stays like it is for a long period of time. > The fact remains that a window where window-start equals point-max (i.e. a window displaying nothing) do recenter itself from time to time. I could only understand that if whatever you do following a call to set-window-start includes resizing of windows or creation/deletion of windows. Or maybe you meant editing in that window? Even then at least the simple commands I tried don't do that. The display engine generally doesn't do anything unless the screen should change. So if you work outside of the window whose starting point you forced, Emacs should never do anything with that window. > My proposal is to modify the display engine so that instead of simply recentering a window, it should call a hook to determine if the recentering should take place. The display engine doesn't recenter because it needs recentering. Recentering is a means to achieve a specific goal, it isn't the goal itself. The goal is to determine the window's starting point when the previous starting point cannot be used for some reason. This is a crucial part of the display of each window -- without determining window-start, the display engine cannot proceed with displaying the window. So you cannot tell the display engine not to recenter, because it won't know how to proceed. I could understand if you'd ask for a way to tell the display engine not to try redisplaying a certain window. But disabling just the recentering is not in general possible, AFAIU. (Actually, Emacs doesn't necessarily recenter: user options like scroll-conservatively dictate how it finds a good candidate for window-start, and recentering is just the simplest and the fastest method. But this doesn't seem to matter for the purposes of this discussion, since you'd like to suppress _any_ kind of scrolling, I believe.) > This can be made more of less fancy -- a simple solution would be to return a boolean. A more advances solution could let a lisp function in packages to decide how many lines should be visible. I'm not sure I understand: how many lines are visible is determined by the window height and the height of the font(s) used by the text displayed there. Once these parameters are fixed, you cannot control the number of lines visible in a window, except by changing the window height. What am I missing? > Doesn't this mean that you need a way to hook buffer text changes? > Hooking processes is not necessarily what you want, since a process > filter could eat up the output completely and not show it in any > window, in which case follow-mode shouldn't be bothered. Right? > > Right. However, the difference is rather academic since it would probably few cases where a prior filter would eat all output. ispell and gdb-mi come to mind, and there are probably more examples. > When it comes to bug#19576 (write-file saves the wrong buffer). As both John and Eli think this shouldn't be fixed in the Emacs core, I will correct the code in follow-mode and (if needed) update the documentation to warn others of the dragons in these waters. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 19 10:45:14 2015 Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 15:45:14 +0000 Received: from localhost ([127.0.0.1]:45091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzROc-00010m-6B for submit@debbugs.gnu.org; Thu, 19 Nov 2015 10:45:14 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:55207) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzROZ-00010W-IP for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 10:45:12 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NY200900JAROT00@a-mtaout23.012.net.il> for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 17:45:09 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY2009UZJR9OK10@a-mtaout23.012.net.il>; Thu, 19 Nov 2015 17:45:09 +0200 (IST) Date: Thu, 19 Nov 2015 17:44:54 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564D8482.20804@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83twoi803t.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <564AE692.2040303@gmx.at> <83vb8z9q6l.fsf@gnu.org> <564D8482.20804@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 19 Nov 2015 09:12:50 +0100 > From: martin rudalics > CC: andlind@gmail.com, 19576@debbugs.gnu.org > > > Thanks for working on this, Martin. However, I don't think we should > > install this change. We call Lisp hooks from many places, including > > maybe a dozen in the display engine. It makes little sense to make > > only one of them resistant to this kind of problems. OTOH, if we do > > this everywhere, I feel that we will unduly punish 99.999% percent of > > legitimate users of these hooks just because one of them had a bug. > > 100% agreed. But run_window_configuration_change_hook goes a long way > saving and restoring current buffer and selected window around each call > to a function on ‘window-configuration-change-hook’. That function isn't called by the display engine, but only by a handful of functions that react to changes in windows. So I really don't consider that to be an analogous case, sorry. > People who put their functions on ‘window-size-change-functions’ and > ‘window-configuration-change-hook’ usually don't care about the precise > reason why these function get called. They simply want to cover all > cases where a new window appears or a specific window changes size. Do > we really expect them to add a ‘save-window-excursion’ in one case and > avoid it in the other because it would mean unnecessary extra work? Yes, we do. Hooks called by the display engine should be coded very carefully, because they are a large part of that proverbial rope that Emacs gives us to hang ourselves. If they don't write those hooks with great care, they get what they deserve. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 19 10:46:15 2015 Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 15:46:15 +0000 Received: from localhost ([127.0.0.1]:45095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzRPa-00012d-MS for submit@debbugs.gnu.org; Thu, 19 Nov 2015 10:46:14 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:41994) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzRPY-00012U-JT for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 10:46:13 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NY200700JN3IL00@mtaout28.012.net.il> for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 17:45:05 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY2002TYJR5DI40@mtaout28.012.net.il>; Thu, 19 Nov 2015 17:45:05 +0200 (IST) Date: Thu, 19 Nov 2015 17:45:56 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564D8497.4090703@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83si428023.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > X-Spam-Status: No, score=3.4 required=5.0 tests=BAYES_20,FREEMAIL_FROM, > RCVD_IN_DNSWL_LOW,RCVD_IN_SBL_CSS,RCVD_IN_SORBS_WEB autolearn=disabled > version=3.3.2 > Date: Thu, 19 Nov 2015 09:13:11 +0100 > From: martin rudalics > CC: juri@linkov.net, andlind@gmail.com, 19576@debbugs.gnu.org > > > Martin, is there any reason why window_resize_apply doesn't set the > > frame's window_sizes_changed flag, but instead relies on its callers > > to do that? > > No particular reason. But note that ‘delete-other-windows-internal’ may > bypass window_resize_apply, so in that particular case we have to > manually make sure that the window_sizes_changed flag gets set. I hope > this is the only case where it matters. Would you mind doing this on the master branch, please? From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 19 11:06:30 2015 Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 16:06:30 +0000 Received: from localhost ([127.0.0.1]:45106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzRjC-0001fL-41 for submit@debbugs.gnu.org; Thu, 19 Nov 2015 11:06:30 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:46820) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzRj9-0001f8-J4 for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 11:06:28 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NY200B00KD26W00@a-mtaout21.012.net.il> for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 18:03:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY200BPGKMI5K30@a-mtaout21.012.net.il>; Thu, 19 Nov 2015 18:03:56 +0200 (IST) Date: Thu, 19 Nov 2015 18:03:39 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <20151118232304.GB1690@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie Message-id: <83mvua7z8k.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: rudalics@gmx.at, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 18 Nov 2015 23:23:04 +0000 > Cc: martin rudalics , juri@linkov.net, andlind@gmail.com, > 19576@debbugs.gnu.org > From: Alan Mackenzie > > > Could you try a simpler patch below? It seems to fix both your test > > case and the one originally reported in bug#21333. > > It does indeed fix my test case (I haven't tried it on #21333). However > it violates the specification of window-size-change-functions, which > says that the hook is called _before_ redisplay, not after it has > started. I suppose one could argue over what "redisplay" means here, > but intuitively I would say it is the putting of glyphs into matrices. "Redisplay" is indeed not defined well enough, but the only reasonable interpretation of "before redisplay" is that it happens before the call to redisplay_internal. And this is false for your suggested solution as well. It is false even by your definition, because prepare_menu_bars already manipulates the glyph matrices, the ones it creates for the tool bar (and also menu bar on some display types). And display_echo_area also manipulates glyph matrices (it calls try_window). Which is only logical for an event that by itself is triggered as part of redisplay! It's redisplay that decides to resize the mini-window, so calling the hook after that decision _cannot_ possibly count as being "before redisplay". IOW, once we, by popular demand, decided to call window-size-change-functions when the mini-window is resized, we invalidated that specification. All the other callers of this hook are not part of a redisplay cycle, but this one is, and cannot be anywhere else. So no matter what change we eventually install, the documentation of the hook needs to be amended to say that it's called "before redisplay or at the beginning of a redisplay cycle", and maybe also mention that the second case is when the mini-window is resized. (Btw, the ELisp manual wisely doesn't say "before redisplay", only the doc string does.) > Also, there may be a possibility of w-s-c-f being invoked twice in a > single redisplay action. How do you see that as a possibility? For that to happen, the flag indicating that the mini-window was resized should be already set for that window when we enter redisplay, but I don't see how that could happen, and still lead to an additional resize as part of redisplay. I also don't think it's a catastrophe if this hook is called more than once in some rare situations. > One way to "solve" these problems, although it is not pretty, is to put > an invocation of w-s-c-f into display_echo_area_1, just after the echo area > has (possibly) been resized. This invocation would also test and reset > FRAME_WINDOW_SIZES_CHANGED (f). There would have to be further > invocation(?s) of w-s-c-f in the other arms of the pertinent conditional in > redisplay_internal. For that pain, we could take the w-s-c-f out of > prepare_menu_bars. I don't see the need for such complications, certainly not on the release branch. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 03:22:43 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 08:22:43 +0000 Received: from localhost ([127.0.0.1]:45455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzgxv-0005Oc-4P for submit@debbugs.gnu.org; Fri, 20 Nov 2015 03:22:43 -0500 Received: from mout.gmx.net ([212.227.17.21]:56882) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzgxa-0005O6-BR for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 03:22:41 -0500 Received: from [192.168.1.100] ([213.162.68.41]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MdWO8-1Zj6RM37UK-00PNcz; Fri, 20 Nov 2015 09:22:20 +0100 Message-ID: <564ED837.6090007@gmx.at> Date: Fri, 20 Nov 2015 09:22:15 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <564AE692.2040303@gmx.at> <83vb8z9q6l.fsf@gnu.org> <564D8482.20804@gmx.at> <83twoi803t.fsf@gnu.org> In-Reply-To: <83twoi803t.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:cIF03JMe8q0Xmxasdn/Akx0IBHyv0SQYoOrRvAaJOmLAKgtywmF L1i9Trylydz2abhsMqf6nVm8JW7KWAUtk+K3xfUOzzT08WHCSf8Waf542SxzH/dyWNX8jHk l+b7iRaExwaSwzLqDAE9Ts44Wc0VjDGNyEJ0O3v2eW/xxLqJtajBzevIT7FzJyRzUlWvHWu WqRbOObEsIHrITsFGG21Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:p4iK6Loqn3A=:tdpvshGXiTLf+0I53MIgLj JFmVMNHfen38ffXAO2ejZFfVCRtQ22Tgh8H1foASif6EGg+eHYWRbnKylzHC2MF4iEMN7GLqe D4rgzk9U//yIswnguo/hbqlNmyEAGRLJMwZjtkbdQVd8509FZpH8kHIbgvIrJCbgBItlD8uWU 3+CcDpCcUg/U3ZRGZqAD0wYmnYGOluqIl7o3xGYM2kJ35kA4osRDvwmsdwS8Jum14rCSx27DW UQstqlWAqFBmVJCb3+eQAQDbgncthnwe0DZrn18VEaP4UbTcpn8OK9Zm+9GfuvgLJAWKmeKfu 4kOux1OThzKinM4WuypRMTk/Kwi2MxFMHWyHEk0PdinXYfR2nuyHRvhU8HvSpwuRn1N3XhLM3 Ng95m9ErILLwHmFZ3fXevhlc5hhbo8JM1G7YN70rQzORUeaonFXvFji6HpTPoCnCnM4v325t7 LuRWNiZ7hruqTH7Vw0hP1TLlAaDjzrfCJjINROPb12+o5t04/cuunNE5PMu5+9oiH5fwn5Y7Z WdmxXuc7ekmeq2ejhWJAbJDwm2/eapdgzrnjI8PLlGK40QlqTePjuRsaUR4Srp69kd6dvMppt V4v9yoKuDXYErYHYYDDiEubbSZSnHKbN1DN4GLXHW+9UHP/zac13/Nd9OwKWIuJUI616slRVZ C/g8Hp4VnrtRHA9TrqAxyJtBzAg3X16YmV1XwnOLctwbMB4QfQ4ngsGyUEIwskMCWdRcZZ9yv gRZ9TPsRXKSglsZKVjdoCCffk5+GYU5nys3DcuBCfn04EfMzze5p5p+5g3lpZN9I56I7GJ+O4 YFOtpOhIECxHVGP5vvulkIbL5mK6A== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) >> 100% agreed. But run_window_configuration_change_hook goes a long wa= y >> saving and restoring current buffer and selected window around each c= all >> to a function on =E2=80=98window-configuration-change-hook=E2=80=99. > > That function isn't called by the display engine, but only by a > handful of functions that react to changes in windows. So I really > don't consider that to be an analogous case, sorry. Reconsider. =E2=80=98window-size-change-functions=E2=80=99 are processed= by the display engine because it's the one we expect to know that window resizing activity has ceased. And if you look at how packages use these two hooks (and also =E2=80=98post-command-hook=E2=80=99) you will see that pe= ople should get more help. Just to quote from =E2=80=98linum-mode=E2=80=99 ;; Using both window-size-change-functions and ;; window-configuration-change-hook seems redundant. --Stef and (add-hook 'window-configuration-change-hook ;; FIXME: If the buffer is shown in N windows, this ;; will be called N times rather than once. We should= use ;; something like linum-update-window instead. 'linum-update-current nil t) >> People who put their functions on =E2=80=98window-size-change-functio= ns=E2=80=99 and >> =E2=80=98window-configuration-change-hook=E2=80=99 usually don't care= about the precise >> reason why these function get called. They simply want to cover all >> cases where a new window appears or a specific window changes size. = Do >> we really expect them to add a =E2=80=98save-window-excursion=E2=80=99= in one case and >> avoid it in the other because it would mean unnecessary extra work? > > Yes, we do. Hooks called by the display engine should be coded very > carefully, because they are a large part of that proverbial rope that > Emacs gives us to hang ourselves. If they don't write those hooks > with great care, they get what they deserve. People do care. But how would they know that in one case we save all sorts of things while we don't in the other. At least the OP got what he deserved: Waiting one year for being told that the bug he reported is his own fault. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 03:22:55 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 08:22:55 +0000 Received: from localhost ([127.0.0.1]:45458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzgy7-0005P7-JB for submit@debbugs.gnu.org; Fri, 20 Nov 2015 03:22:55 -0500 Received: from mout.gmx.net ([212.227.17.22]:55880) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzgy6-0005Ox-07 for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 03:22:54 -0500 Received: from [192.168.1.100] ([213.162.68.41]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MexlN-1ZkTSb2PSz-00OZn6; Fri, 20 Nov 2015 09:22:48 +0100 Message-ID: <564ED851.1080805@gmx.at> Date: Fri, 20 Nov 2015 09:22:41 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Alan Mackenzie Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> In-Reply-To: <83mvua7z8k.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:DCTUjUrfxIsYTeEPCNoT6eOAG5LiXrMC4/pLJCV39C83c5dvVKO X95ZKBWQs4OuxGtjCsPilo0fRgZV0WJLeNsayL8zngzQ6jnPV8biwA64oJCbJYrovwMLXq7 UmX79iycZBqtVpJzAXsRyO7ak1IPlyTkDOZI0xzqgJrY/wSA/rbJC+MV9YfPScpNz49j07m pDgQRwHtntEdpON1lTNDg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Uosa9LyuZqk=:lrtveksUs+PsZUtHkegwfz 6LtPd/zmSxQbFWhvSVnAAmXV6AuApPaTS+BFOeNBXdm3NyYU49zO/1i+KJfcldyIj/gbwVosu XpKFednQn54VnzfbnqJNvTvk+JN3A4lVVYqV8RMljtMfPuaFcE7eeXDUEFJ+SH6gPD0vrhAVf tlx6gySpQqhi1J3cnOCfK4FC2YRNmOYtvVxVZvZzzYXoMNPCPvjednFgw7MXVOA4TPxU2ZP9q qHI1iZT+MAKNV9rFIX/owLMCn5Hqd/o+mEnPTFA8239VlJVNIDZtmgR/I1iqlLNbI844S0sNP tUFhnw1kmR7Pu3WGNU20okcyspzbqXwZazBkPwCh+a9CqrNk8ktkLmYZvCnQjviHN6n8g1tOL 9itc00x7atWoE/NFqd/ibijd7cj89JZz/fz2UywqPsQ0oJp5jjoBTc2QMNSD+XPY2TZwolPvz y2EN0RJZa0PenzQ2q89Mf5Ky+Sk0xHOjzgvdYPD2pMQN/82yD5s9MkOlHYXSrJ+NkBDxd5XX3 3k3gwyKoy3AbzYWoMMtXWPNsfy48bztPd2AhvesfirERz2qqbL/YWs5ymSclfNFaCzJrybnvH +N39uSquFylzSHTmRLicW+TzLpK+/EAZ0gzi9N8gAca/dn8xlR3ORIT1kr/7OUQmJpogbG3tB Y+bDmE4HPiJMbFRkPtHU7BtOdt1MqLnaLe+He8PnacfTsPSBTarKYxOGik93XcOPjUXsfmUGV 7iPxoQM9hvQ7z99DHRwhRujLPNGGhTpf9MjDmSOgX2Q6QhCXcto5cUurPw0e2R83VxdU4xIk/ eGHGAfOdcszFqB1eN01kFazAw05eA== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > IOW, once we, by popular demand, decided to call > window-size-change-functions when the mini-window is resized, we > invalidated that specification. All the other callers of this hook > are not part of a redisplay cycle, but this one is, and cannot be > anywhere else. I still wonder what will happen when the function called by =E2=80=98window-size-change-functions=E2=80=99 triggers a message that re= sizes the mini-window. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 03:23:00 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 08:23:00 +0000 Received: from localhost ([127.0.0.1]:45460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzgyB-0005PN-SP for submit@debbugs.gnu.org; Fri, 20 Nov 2015 03:23:00 -0500 Received: from mout.gmx.net ([212.227.17.21]:60817) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzgxs-0005OT-1T for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 03:22:58 -0500 Received: from [192.168.1.100] ([213.162.68.41]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LzoSt-1aU1to0VQh-0153sz; Fri, 20 Nov 2015 09:22:35 +0100 Message-ID: <564ED844.8090908@gmx.at> Date: Fri, 20 Nov 2015 09:22:28 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> In-Reply-To: <83si428023.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:+B8ys5pyYe19YCrSe5FqJ+Cd5l/6GBhJDyV8zP+waedae4Iv1Bj eH+odfugCIobA13vHH6g78o4Tv03rJ2aqvtW9JOWY9X/3WiJw955z08nJaIp+u6yNSxD4sf naKEh853nsZepcj+d+sDp3XiMtFyjcA5RsxhLXq20rwM2ubkoFKj09aVNk0hDU22q0ZRQHy pxpHtBedquaIjnOLV76bg== X-UI-Out-Filterresults: notjunk:1;V01:K0:79jmvXpeKok=:xZ3PgSg0+jQFmsJGOxa4J8 4Uz9lqssShxQci5+3gUhl7+wOxlEpCpEtF1HEgc7xUyGEXFAJCz5pz7OFNKyKBGSGSlA4kWmX /RBeuuf2Ri+JKTCoieh8efcciLeCgkQdnx+S1DqmwOe9qW7oH6knQPtkUk85gXkVDQYdHglZL lNbwZdjXx6s75736ErH4KKjbSbeqypRR4dHIgW2NSuvQzNvaDXLmUXNuMIYhPDrPrnLi8XPOK Lgk4JClCdBgKeIYukfe4IEEt/FC9ijaNGO5RV+2xtHhm5Dd060ZKeXbB0XfOiP0zPb5dowWC/ Cne1bZrKwBcpWylR6rYsr1oj2EzgHC2PJqNVMlo6XdKPP7OuS8gQ2A6OIZbo3JfMoxyCpWcR8 Bozk9llVA14l50ukdA37sa7n+gR1xmqQG8gSEQLZ0Fga0SkFmY/BCknCufdNRQAPN292HnN0C Mi9a5vyokGIuAoldzaWwz7EVl+485ShzcD2xtkWjDgAhOhGRVPE3lcHwq7xIRsaERM3okT8qx okQHhzdbER4yZeVBvPNbtNqYJlI+HSyte21N4I+LrQ8vGCIg8t4qUaE6I1ntGKlOSA2mxQGg3 XIYCO6QDJVe1QJ8t02c1lXRJ8u5Z+eO6vUZ+rybbuRrevRg8+nEzMG4xNQpjqwZ5wJ2S8IWey K5cSrwQRhl3RTe508d661CrGzsJLTd3LE3xT5i+YBj/inMdYZP4Px/VuvrCeoY11CvbQVp+LA TjFQdsEdouXzlIYXubHaS2eonCTCsm20Kgbrbm2kgriMYMKhets336y5Ie1RQOUuvGQx2zHPj wGkhX4wuGc/0qMxVrN6pcKSjdemkA== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) >> No particular reason. But note that =E2=80=98delete-other-windows-in= ternal=E2=80=99 may >> bypass window_resize_apply, so in that particular case we have to >> manually make sure that the window_sizes_changed flag gets set. I ho= pe >> this is the only case where it matters. > > Would you mind doing this on the master branch, please? It might have interesting consequences. Presumably, you expect that this way we'll be finally able to run =E2=80=98window-size-change-functio= ns=E2=80=99 if and only if the size of windows really changed. Correct? martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 03:33:05 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 08:33:05 +0000 Received: from localhost ([127.0.0.1]:45472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzh7w-0005mG-Bm for submit@debbugs.gnu.org; Fri, 20 Nov 2015 03:33:04 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:48120) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzh7a-0005lK-RH for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 03:33:02 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NY300D00TXIE000@a-mtaout21.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 10:32:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY300DFJUEHAW60@a-mtaout21.012.net.il>; Fri, 20 Nov 2015 10:32:41 +0200 (IST) Date: Fri, 20 Nov 2015 10:32:28 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564ED837.6090007@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83h9kh6pgj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <564AE692.2040303@gmx.at> <83vb8z9q6l.fsf@gnu.org> <564D8482.20804@gmx.at> <83twoi803t.fsf@gnu.org> <564ED837.6090007@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 09:22:15 +0100 > From: martin rudalics > CC: andlind@gmail.com, 19576@debbugs.gnu.org > > >> People who put their functions on ‘window-size-change-functions’ and > >> ‘window-configuration-change-hook’ usually don't care about the precise > >> reason why these function get called. They simply want to cover all > >> cases where a new window appears or a specific window changes size. Do > >> we really expect them to add a ‘save-window-excursion’ in one case and > >> avoid it in the other because it would mean unnecessary extra work? > > > > Yes, we do. Hooks called by the display engine should be coded very > > carefully, because they are a large part of that proverbial rope that > > Emacs gives us to hang ourselves. If they don't write those hooks > > with great care, they get what they deserve. > > People do care. But how would they know that in one case we save all > sorts of things while we don't in the other. They don't need to. We won't tell them that we do that even in a single case. > At least the OP got what he deserved: Waiting one year for being told > that the bug he reported is his own fault. Yes, our bug-handling routine can and should be improved. I'm sorry he had to wait for so long. To be fair, the original report already put the blame squarely on installing a "broken window size change function", so I don't think what I wrote here 10 months later is a revelation of any kind. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 03:35:09 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 08:35:10 +0000 Received: from localhost ([127.0.0.1]:45476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzh9x-0005py-79 for submit@debbugs.gnu.org; Fri, 20 Nov 2015 03:35:09 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:63981) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzh9u-0005pp-MA for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 03:35:07 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NY300700UA5HJ00@a-mtaout22.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 10:35:05 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY3007FDUIG6Z60@a-mtaout22.012.net.il>; Fri, 20 Nov 2015 10:35:05 +0200 (IST) Date: Fri, 20 Nov 2015 10:34:51 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564ED844.8090908@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83fv016pck.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> <564ED844.8090908@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 09:22:28 +0100 > From: martin rudalics > CC: acm@muc.de, juri@linkov.net, andlind@gmail.com, > 19576@debbugs.gnu.org > > >> No particular reason. But note that ‘delete-other-windows-internal’ may > >> bypass window_resize_apply, so in that particular case we have to > >> manually make sure that the window_sizes_changed flag gets set. I hope > >> this is the only case where it matters. > > > > Would you mind doing this on the master branch, please? > > It might have interesting consequences. Presumably, you expect that > this way we'll be finally able to run ‘window-size-change-functions’ if > and only if the size of windows really changed. Correct? No, not really. It's just a cleanup, IMO: instead of asking each caller of window_resize_apply to set that flag, set it in that function itself. I didn't envision any changes in functionality due to this change. What did I miss? From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 05:17:51 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 10:17:51 +0000 Received: from localhost ([127.0.0.1]:45536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzilK-0000eI-SK for submit@debbugs.gnu.org; Fri, 20 Nov 2015 05:17:51 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:53181) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzilI-0000e5-MQ for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 05:17:49 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NY300D00YWYN200@a-mtaout21.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 12:17:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY300DMXZ9MME20@a-mtaout21.012.net.il>; Fri, 20 Nov 2015 12:17:47 +0200 (IST) Date: Fri, 20 Nov 2015 12:17:33 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564ED851.1080805@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <831tbl6kle.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <564ED851.1080805@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 09:22:41 +0100 > From: martin rudalics > CC: juri@linkov.net, andlind@gmail.com, 19576@debbugs.gnu.org > > I still wonder what will happen when the function called by > ‘window-size-change-functions’ triggers a message that resizes the > mini-window. That was the test case in bug#21333. I tried it after applying the patch, and saw the expected resize messages. Does that answer your concerns? From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 05:26:02 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 10:26:02 +0000 Received: from localhost ([127.0.0.1]:45542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzitF-0000tt-SB for submit@debbugs.gnu.org; Fri, 20 Nov 2015 05:26:02 -0500 Received: from mout.gmx.net ([212.227.15.19]:58637) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzitD-0000td-UN for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 05:26:00 -0500 Received: from [192.168.1.100] ([213.162.68.45]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MGj8j-1aD90d08w5-00DUxG; Fri, 20 Nov 2015 11:25:54 +0100 Message-ID: <564EF52B.5060601@gmx.at> Date: Fri, 20 Nov 2015 11:25:47 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> <564ED844.8090908@gmx.at> <83fv016pck.fsf@gnu.org> In-Reply-To: <83fv016pck.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:xqAeTQ9qxZqpsPtEcKx9vpdBr1guENyq7bqSfdGj34zjIqpo8zH KkflLlCepe2ib6IgvUeTGBnHxn1jRqPlaNaasIkexdNt88v0hvBUV/zGaNegOJMd0v+jtdm h49FsCcWCEnihp7qI0gmIYsxp32Yz30tFep/eIRXgV/iQEmVaELOPB0T/g2o60FT6TxEy9Y WFoKKcaxHSxhXNTqhJJNA== X-UI-Out-Filterresults: notjunk:1;V01:K0:bmeyH6Xsdko=:rwy8ATnUsdaz+e7NsjuRpO Q9j+Qvos24W2/Akx+10eHgscX0k9k/uZP1O+Zl7qg8qy0y4+pgIPha59sJoPuTH7KgEqRXItd kS+/qYVca49DefjRCip/MzuWFFBC0yyjEbyd70GD/POQNAH3+BgFkyHlukHMVfhE/NNiaXAnd NxRVwZKQ7BwIMgYSpkDJtHF8Olx3z5rvObolWQcSifgN0jzv/XREX6GSTheDCuiW8i74d75El 9WqruAnjuwlAhkfsGwGIwW3w+cuMB6r2Yi/r1sdrCzf+QQkptxyVkN6SN/OOPd+XNZVWPQ5i7 73hYiOClA2Lm8Z0FXVW7b+LUyc8Vz8GL8Yv2ddEifczCj9Ejgfnenl6WHiZyn+7WUnFz5U6Nn zdFmRS4zxQ0M5kr/f18PIwD8ubTIRLvXoIx22d2PkEAMbnSLN0iNpGwsODPZVZ0nvkQYU54kk ysiuI+ctKJM1amnizqTbmIiwlhAxWE8/WFbTPktMZE3fTHqnLFZJBjFv+2HYRQaMU/GzyceGn DeYOcgtIIaidv1q47WUvhy93WudhvCTyjJ4N/o87I1N2dmOCqUV/UXf1vuMoKSg0T4sHrNApx WL4qmq0vayUj8glNnyi/iHzQb/9Oq8TU3RAYMRw2jlsihfFD7Httm28a95BN6RMRJOKVYdm1/ SDzAlEd/8dyed+9pyQMQY2y9JwkdH4958OkHL/iwrph7O8bSItd4e2fXdoxVPb55UTk9sfjRY vPp2pMrzXv8rO5XPZsHDNVbSWBlbUHTSajqRDhYzdFxqktLD3yZlXYX9C3udjQShPlJ0zQHce EUBkj1GQZKatv3KsktdAsw7ImwvoA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> It might have interesting consequences. Presumably, you expect that >> this way we'll be finally able to run =E2=80=98window-size-change-fun= ctions=E2=80=99 if >> and only if the size of windows really changed. Correct? > > No, not really. It's just a cleanup, IMO: instead of asking each > caller of window_resize_apply to set that flag, set it in that > function itself. In addition it would do that then for grow_mini_window and shrink_mini_window too but I suppose that's what you want. > I didn't envision any changes in functionality due > to this change. What did I miss? "All" window size changes must pass through window_resize_apply. So we could easily check there if any size really changes and set that flag only in that case. This way you would get your check whether =E2=80=98set-window-configuration=E2=80=99 did change the size of any win= dow for free. It's not a minor change since I probably would remove the check done by =E2=80=98window--resize-apply-p=E2=80=99, have window_resize_apply return= a boolean indicating that some size really changed and have =E2=80=98window-resize-= apply=E2=80=99 pass that value back to its caller so we can avoid calling =E2=80=98window--pixel-to-total=E2=80=99 and =E2=80=98window-configuratio= n-change-hook=E2=80=99 if nothing changed. And, as I mentioned earlier, the one case in =E2=80=98delete-other-windows=E2=80=99 would have to be treated specially= =2E But I think it's worth if we care about =E2=80=98set-window-configuration=E2=80=99. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 05:48:10 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 10:48:10 +0000 Received: from localhost ([127.0.0.1]:45550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjEf-0001ac-OM for submit@debbugs.gnu.org; Fri, 20 Nov 2015 05:48:09 -0500 Received: from mout.gmx.net ([212.227.15.15]:63401) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjEe-0001aU-Bu for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 05:48:08 -0500 Received: from [192.168.1.100] ([213.162.68.45]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M7YF5-1aK8Go3IRT-00xLZE; Fri, 20 Nov 2015 11:48:05 +0100 Message-ID: <564EFA60.5030909@gmx.at> Date: Fri, 20 Nov 2015 11:48:00 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <564ED851.1080805@gmx.at> <831tbl6kle.fsf@gnu.org> In-Reply-To: <831tbl6kle.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:UAM+0GxLNezugjURj8mg6697R1ldvmTiLKA+iqmVC9iQETfzkju 1bh2d3eVbBCgolRftoXpziaA4K2bayO5ehtNL2zFsqdCXyeV9JgCSIg/02G36gZwDaYbmK8 EbL80phv0gthiLrgE6BldpQBtNF0uU46mvb6/QYdFOAtOjR452Hjmvqt++r5MPZziKimniD iyHNGhCq2H1fu7OVI1Neg== X-UI-Out-Filterresults: notjunk:1;V01:K0:/J3UKzu1Uj0=:STL8kvMcqUQDNm82eSjCNd SI7r/EJBI8YDa848EkDMLvgfzbGkkrjgNmQvqhN61W1IvsCaNxJjLGVYPogDDVzFBLE1yW5tz KeFRy26NaKei0UMhc7qS4kSUeCWpebkM0sp+YiwW6IW1ok4S8zAfe0ukpcqlk/YoQ17Vp0Bao pgJVlGRRXLw+Lnul7JPHfy7PrFMYdQygkyUNGxXX3egb636APyfOMsJXyDROvjv4xjXjtS2XS j6U3zHYOxC8+jffUVF6MUByAtm3Le3OmPoiBxdefmV4DnVUOel0bfdV3J/rlvIAVzu6luKdE6 mKzJ7Z2uorqlKW7oRtOxnBJ4qAR4IfssPL31JNFgJdnD4k7ZBNRBOoWueABqBxyQUv9cgPOF/ JmJL5PGHj6dQSq7BlW3LSIypJfv61O7n7ffjWCCUC8340i5FEs3Pf/owFv+cKYDFqsSJkHmqf CvYkwW+6Lb1cPTJfle5XuMEFE+Fvfx12fiLDSk6wa5oDh6wvREKoVjZ+VvE1G7qkdFp9ClYBM 20nR4gDIUbHutc6RLh5M6HIKW4H2MYgEgRfmU8z7/VkYTsN8SC0/z/NHM9ImSl67wSdczsun8 165URcu5SzeyYziGEAJ26g9ZpZB+SCDk2mAGniQc2yu0Wb/T+gKd23d0FUGLt5ypXP4w1FToc vQmD0pZVyaNZI83bUQ1p9JFQsVmPNCW7S3EQzTsmYgYIc9BaCQba64FoxuK28z/B6TF0jK+Ro iWWsbWhkJIUTb5hEUX9xErGvTBQXYXlsKCZztDcl513EARNfbaKEeDf5AfD0cXAp18BuIQGhW R720C7m6PS2L2w8qppN6mcWa5/0Dg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > That was the test case in bug#21333. I tried it after applying the > patch, and saw the expected resize messages. Does that answer your > concerns? Does it run =E2=80=98window-size-change-functions=E2=80=99 again? martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 06:17:09 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 11:17:09 +0000 Received: from localhost ([127.0.0.1]:45566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzjgj-0002Y1-5q for submit@debbugs.gnu.org; Fri, 20 Nov 2015 06:17:09 -0500 Received: from mtaout29.012.net.il ([80.179.55.185]:54953) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjgP-0002Ws-3A for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 06:17:08 -0500 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NY400N001WEUV00@mtaout29.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 13:16:07 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY400MC51YVO410@mtaout29.012.net.il>; Fri, 20 Nov 2015 13:16:07 +0200 (IST) Date: Fri, 20 Nov 2015 13:16:34 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564EFA60.5030909@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83y4ds6hv1.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <564ED851.1080805@gmx.at> <831tbl6kle.fsf@gnu.org> <564EFA60.5030909@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 11:48:00 +0100 > From: martin rudalics > CC: acm@muc.de, juri@linkov.net, andlind@gmail.com, > 19576@debbugs.gnu.org > > > That was the test case in bug#21333. I tried it after applying the > > patch, and saw the expected resize messages. Does that answer your > > concerns? > > Does it run ‘window-size-change-functions’ again? Yes, because I counted the number of those messages, and saw the expected number of them. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 06:17:12 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 11:17:12 +0000 Received: from localhost ([127.0.0.1]:45568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzjgl-0002YG-GE for submit@debbugs.gnu.org; Fri, 20 Nov 2015 06:17:11 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:57728) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjgQ-0002X0-9d for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 06:17:09 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NY400M001S3OX00@mtaout26.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 13:18:53 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY400NE223HHC00@mtaout26.012.net.il>; Fri, 20 Nov 2015 13:18:53 +0200 (IST) Date: Fri, 20 Nov 2015 13:15:39 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564EF52B.5060601@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83ziy86hwk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> <564ED844.8090908@gmx.at> <83fv016pck.fsf@gnu.org> <564EF52B.5060601@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 11:25:47 +0100 > From: martin rudalics > CC: acm@muc.de, juri@linkov.net, andlind@gmail.com, > 19576@debbugs.gnu.org > > >> It might have interesting consequences. Presumably, you expect that > >> this way we'll be finally able to run ‘window-size-change-functions’ if > >> and only if the size of windows really changed. Correct? > > > > No, not really. It's just a cleanup, IMO: instead of asking each > > caller of window_resize_apply to set that flag, set it in that > > function itself. > > In addition it would do that then for grow_mini_window and > shrink_mini_window too but I suppose that's what you want. Indeed, that was what triggered my question. > > I didn't envision any changes in functionality due > > to this change. What did I miss? > > "All" window size changes must pass through window_resize_apply. So we > could easily check there if any size really changes and set that flag > only in that case. This way you would get your check whether > ‘set-window-configuration’ did change the size of any window for free. Yes, that'd be an additional benefit. > It's not a minor change since I probably would remove the check done by > ‘window--resize-apply-p’, have window_resize_apply return a boolean > indicating that some size really changed and have ‘window-resize-apply’ > pass that value back to its caller so we can avoid calling > ‘window--pixel-to-total’ and ‘window-configuration-change-hook’ if > nothing changed. And, as I mentioned earlier, the one case in > ‘delete-other-windows’ would have to be treated specially. But I think > it's worth if we care about ‘set-window-configuration’. Yes, and we are allowed non-minor changes on master. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 06:25:58 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 11:25:58 +0000 Received: from localhost ([127.0.0.1]:45578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjpF-0002sq-Eh for submit@debbugs.gnu.org; Fri, 20 Nov 2015 06:25:57 -0500 Received: from mout.gmx.net ([212.227.15.18]:60759) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjpC-0002se-OM for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 06:25:55 -0500 Received: from [192.168.1.100] ([213.162.68.45]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LbuCq-1agoOo14ZY-00jEo7; Fri, 20 Nov 2015 12:25:50 +0100 Message-ID: <564F0338.6080901@gmx.at> Date: Fri, 20 Nov 2015 12:25:44 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> <564ED844.8090908@gmx.at> <83fv016pck.fsf@gnu.org> <564EF52B.5060601@gmx.at> <83ziy86hwk.fsf@gnu.org> In-Reply-To: <83ziy86hwk.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HWyJkguYbeVq/TZUV+goYHPySotRIRDcnYRMroboMWTIPg7bfHm db0r+Xz2RwPKQ6pR2bzF5x5ggAn6LvGjoFmEi19zjSjIYKhwGeGphInKyFbh26wQIMRgonm y52YlvcxgVzkBxyfzJ8zPTjXSrlYKoAhaSYwwboji3J4ShfRWKq9MZrybVoMlHkNhd0sPXw XYOmeuc3SFadZNvroaVTA== X-UI-Out-Filterresults: notjunk:1;V01:K0:XiZj+WYYjb8=:iQfHJzC1dR+hcpCWDb2drQ xfmz8BRMWZw/WR0JwNPx30WfqgiQnRrEgBSF5vpJ8OCsZdA9zFsuSXDAZiicjpsQIBwQFCUSx MiHfowDiLaprqta1QpZH71vYVmLKz9G4HKNCZ+QEFlpFuKRGcyJfq99kYul0Eop1jd2I+72Aq Hd49MSGKG29iaaqCy8Z8vjJJItlKGNfJTMc6RYDwE0Pg2YXT9elbDrRUDQ+KnMqUdVNVjzKRY 0EjT+fzCfDV441VhiDTzdQ2eVp2ebHvm1z54Q8x2DRwrrUQUrkrOzTtUvFs8IDxnJ8/uTcrl1 6JiWHBxXsH8ZARdaTLogangPhsJL5YO/AyiLBH+p0Br0EkzF35aC1kSiyhc26fkZADe13M1yQ O1zOndYJEzg3RMU/r0uhF85lKkvktUkOhhrxTI6qerA/FuL/AGMwCB6jz/YH/MyYPzEYZa4jl 5TVzV8ug5i9H11MZdWPSkgo9LnDwtwMNzKZK3h5AysZozvj+luD52E+PieVnO4L3RlDaAn80R YIYoqWiyB88WiChuUD+R0xEymWg8YZm1oXofwDRUTOV0GHTMWytbkE8p6QwhnhvJl5Jzyharw 6F8xOR9Gc5VSJhOED8o16QsbfKbIocJxZZiA6440jctoRDbBEVPwE6cAHDSWOVWGGXObcCb7A lSE89HUlxjTvNkkRlMi7kA3MDImhMuqvAyoQ1dcUOcC7OKJBEU/QD1nsrViNGPpNPEKstZYBb Jr3dvGkM9kBGyH8YekOnULvmZSsNCdo0NscJyi8LAmsS+exnAQheHbqga8SB2/NY5M+mDdKwe 86Ll8z6fBAHb/XQszyUD2sTL7l57g== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > Yes, and we are allowed non-minor changes on master. I can't test emacs-25 anyway. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 06:26:03 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 11:26:03 +0000 Received: from localhost ([127.0.0.1]:45582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjpL-0002tW-4N for submit@debbugs.gnu.org; Fri, 20 Nov 2015 06:26:03 -0500 Received: from mout.gmx.net ([212.227.15.18]:54253) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjpI-0002sz-8d for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 06:26:00 -0500 Received: from [192.168.1.100] ([213.162.68.45]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MZkv0-1ZeMvK1fVm-00LYnz; Fri, 20 Nov 2015 12:25:56 +0100 Message-ID: <564F033F.9070509@gmx.at> Date: Fri, 20 Nov 2015 12:25:51 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <564ED851.1080805@gmx.at> <831tbl6kle.fsf@gnu.org> <564EFA60.5030909@gmx.at> <83y4ds6hv1.fsf@gnu.org> In-Reply-To: <83y4ds6hv1.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:POdmoCeBHIG4Uf+t8yxrXyf/I68XYeqAKwSl21aTfrKy1rvb7s9 fjTpk9ZGnCIkKSbIrtEEFOIqqkFfhuTjZDIT2zBscnGoHHse6TzxZ0vypUs6qORXPQ3+qE0 PFvpSvgREK+Ek9TPuDvtRLxUyMDSWqCnT4rDahs0p3QfzeRW2pScJhPeho/Fm9WPACdpMnD cPonn4R7wybGL3C7tKnkQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:O6ohSlfqprs=:pWUqXc2S3OptoEI97TzGNk c7zOw5jW1+Y14eXEebzL6Rywb8phE37YpRN4OJYTxsrmXr/bY2926r2XKsP4MPw1ghBBEzplN 9ZZeYEMWDzZnnqfwyY6tIvya6ddSHMHLfKmKpNOaFVWbosW22yLDvvEOq4rceFy5Zto6LVX/w mi3U2crRr0SYsmG9ZXyolGkYjtCZv9X7xvafaWGbXfHD4zXAwyRC2bAl6ELNwYl0wLcqYu6eQ mfPZ/KSDzu0kvoYLeFHA95ixIP8x85hufcPhjZICGIoZSYs/rul0SiaAlhY0RDp8wQgCiaxH3 x8tFejWPG8jRSxffwDloZV6M6JdIDZ+H3NRlKVcQFnn1UYWMjN6WTVgkMVbsiy3IXtyZ2r6yB ZiBRaoWUx5yTSLyhN+6upG6grXJDY4U5BwV0yjsDUvYoT+lEoC2cA3LtNGSMsHB7iM0IDxhLM Ss/tysa9LkzZBQAcOvX6Z8Ycbxj8lipQpCLD4qB4hcbhhULf7BCTNVGAXDFUUDxM9+jJ1ZYRr PACBV/CxXM+OUrb2nG3CAAtIWuFw+EQfFb2wIHVNJZKmVBYNUV9OPvFI1UxO8DmlCze8IU3ts TTfv0n5fT7BoyCpKzhxIohQf1UTg6BSxU3Ia4vEnVEZ/6/ANdYA5P1sEZPAhkZWn3yTr5CCu8 OpvQcZ2uKU2uecoXvK+wbwqIdLPj1ll1K94wLfkKHXNnXXFtNn+WdKk4WBAwe0FJXQ/osDkTG n0ULl+TpPstrGpAbJmi6UHfhD42d3AT5HUw1mObN3Dl8+1W287k3LI5wcC7yi11kBt+sc4o/I h8MnX7rFlAgim3xxJ6uAIyCWwjYpw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> Does it run =E2=80=98window-size-change-functions=E2=80=99 again? > > Yes, because I counted the number of those messages, and saw the > expected number of them. Then it conceptually can run into a loop where it continuously grows and shrinks the mini window? martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 06:30:40 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 11:30:40 +0000 Received: from localhost ([127.0.0.1]:45586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzjtn-00034I-CF for submit@debbugs.gnu.org; Fri, 20 Nov 2015 06:30:39 -0500 Received: from mail.muc.de ([193.149.48.3]:47505) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzjtR-00033P-3S for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 06:30:36 -0500 Received: (qmail 89812 invoked by uid 3782); 20 Nov 2015 11:30:16 -0000 Received: from acm.muc.de (p548A4FBE.dip0.t-ipconnect.de [84.138.79.190]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 20 Nov 2015 12:30:14 +0100 Received: (qmail 11127 invoked by uid 1000); 20 Nov 2015 11:32:14 -0000 Date: Fri, 20 Nov 2015 11:32:14 +0000 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer Message-ID: <20151120113214.GB10389@acm.fritz.box> References: <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> <564ED844.8090908@gmx.at> <83fv016pck.fsf@gnu.org> <564EF52B.5060601@gmx.at> <83ziy86hwk.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83ziy86hwk.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Eli. On Fri, Nov 20, 2015 at 01:15:39PM +0200, Eli Zaretskii wrote: > > Date: Fri, 20 Nov 2015 11:25:47 +0100 > > From: martin rudalics > > CC: acm@muc.de, juri@linkov.net, andlind@gmail.com, > > 19576@debbugs.gnu.org [ .... ] > > It's not a minor change since I probably would remove the check done by > > ‘window--resize-apply-p’, have window_resize_apply return a boolean > > indicating that some size really changed and have ‘window-resize-apply’ > > pass that value back to its caller so we can avoid calling > > ‘window--pixel-to-total’ and ‘window-configuration-change-hook’ if > > nothing changed. And, as I mentioned earlier, the one case in > > ‘delete-other-windows’ would have to be treated specially. But I think > > it's worth if we care about ‘set-window-configuration’. > Yes, and we are allowed non-minor changes on master. Please don't decide that this bug won't be fixed for Emacs 25.1. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 06:39:26 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 11:39:26 +0000 Received: from localhost ([127.0.0.1]:45595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzk2I-0003MI-BQ for submit@debbugs.gnu.org; Fri, 20 Nov 2015 06:39:26 -0500 Received: from mtaout25.012.net.il ([80.179.55.181]:44630) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzk2F-0003M4-Jp for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 06:39:24 -0500 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NY4008002M6PF00@mtaout25.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 13:36:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY4004A12X9XQ40@mtaout25.012.net.il>; Fri, 20 Nov 2015 13:36:46 +0200 (IST) Date: Fri, 20 Nov 2015 13:39:09 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564F0338.6080901@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83vb8w6gte.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> <564ED844.8090908@gmx.at> <83fv016pck.fsf@gnu.org> <564EF52B.5060601@gmx.at> <83ziy86hwk.fsf@gnu.org> <564F0338.6080901@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 12:25:44 +0100 > From: martin rudalics > CC: acm@muc.de, juri@linkov.net, andlind@gmail.com, > 19576@debbugs.gnu.org > > > Yes, and we are allowed non-minor changes on master. > > I can't test emacs-25 anyway. Because of loaddefs? You should be able to produce them with a different Emacs binary. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 06:41:37 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 11:41:37 +0000 Received: from localhost ([127.0.0.1]:45599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzk4P-0003Qz-9o for submit@debbugs.gnu.org; Fri, 20 Nov 2015 06:41:37 -0500 Received: from mtaout25.012.net.il ([80.179.55.181]:48682) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzk45-0003QJ-9V for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 06:41:35 -0500 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NY4008002M6PF00@mtaout25.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 13:38:39 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY4004KV30FXQ40@mtaout25.012.net.il>; Fri, 20 Nov 2015 13:38:39 +0200 (IST) Date: Fri, 20 Nov 2015 13:41:02 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <20151120113214.GB10389@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie Message-id: <83si406gq9.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> <564ED844.8090908@gmx.at> <83fv016pck.fsf@gnu.org> <564EF52B.5060601@gmx.at> <83ziy86hwk.fsf@gnu.org> <20151120113214.GB10389@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: rudalics@gmx.at, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 11:32:14 +0000 > Cc: martin rudalics , juri@linkov.net, andlind@gmail.com, > 19576@debbugs.gnu.org > From: Alan Mackenzie > > Hello, Eli. > > On Fri, Nov 20, 2015 at 01:15:39PM +0200, Eli Zaretskii wrote: > > > Date: Fri, 20 Nov 2015 11:25:47 +0100 > > > From: martin rudalics > > > CC: acm@muc.de, juri@linkov.net, andlind@gmail.com, > > > 19576@debbugs.gnu.org > > [ .... ] > > > > It's not a minor change since I probably would remove the check done by > > > ‘window--resize-apply-p’, have window_resize_apply return a boolean > > > indicating that some size really changed and have ‘window-resize-apply’ > > > pass that value back to its caller so we can avoid calling > > > ‘window--pixel-to-total’ and ‘window-configuration-change-hook’ if > > > nothing changed. And, as I mentioned earlier, the one case in > > > ‘delete-other-windows’ would have to be treated specially. But I think > > > it's worth if we care about ‘set-window-configuration’. > > > Yes, and we are allowed non-minor changes on master. > > Please don't decide that this bug won't be fixed for Emacs 25.1. This issue doesn't affect this bug. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 06:42:50 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 11:42:50 +0000 Received: from localhost ([127.0.0.1]:45603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzk5Z-0003Tj-PC for submit@debbugs.gnu.org; Fri, 20 Nov 2015 06:42:50 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:54192) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzk5X-0003TZ-T7 for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 06:42:48 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NY400I002WQAB00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 13:40:45 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY400H4S33XZQB0@a-mtaout20.012.net.il>; Fri, 20 Nov 2015 13:40:45 +0200 (IST) Date: Fri, 20 Nov 2015 13:40:32 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564F033F.9070509@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83twog6gr3.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <564ED851.1080805@gmx.at> <831tbl6kle.fsf@gnu.org> <564EFA60.5030909@gmx.at> <83y4ds6hv1.fsf@gnu.org> <564F033F.9070509@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 12:25:51 +0100 > From: martin rudalics > CC: acm@muc.de, juri@linkov.net, andlind@gmail.com, > 19576@debbugs.gnu.org > > >> Does it run ‘window-size-change-functions’ again? > > > > Yes, because I counted the number of those messages, and saw the > > expected number of them. > > Then it conceptually can run into a loop where it continuously grows and > shrinks the mini window? What loop? Redisplay doesn't call 'message'; calling 'message' enters another redisplay. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 09:21:45 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 14:21:45 +0000 Received: from localhost ([127.0.0.1]:45709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzmZM-0001co-Ty for submit@debbugs.gnu.org; Fri, 20 Nov 2015 09:21:45 -0500 Received: from mout.gmx.net ([212.227.15.15]:60602) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzmZ2-0001cC-Ly for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 09:21:43 -0500 Received: from [192.168.1.100] ([213.162.68.45]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMBun-1a0c2D2qp3-007zOB; Fri, 20 Nov 2015 15:21:16 +0100 Message-ID: <564F2C53.9020608@gmx.at> Date: Fri, 20 Nov 2015 15:21:07 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <564ED851.1080805@gmx.at> <831tbl6kle.fsf@gnu.org> <564EFA60.5030909@gmx.at> <83y4ds6hv1.fsf@gnu.org> <564F033F.9070509@gmx.at> <83twog6gr3.fsf@gnu.org> In-Reply-To: <83twog6gr3.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:WX2cBgIQjMda7c2U6e+0sBcIOF4Pd2bSs6stMTZliu7tptTkYu8 bRtJvLyrN+SfW09ZXssfEH8CG6BPXLEVIIf68F8JzidIxpHNQrrQ2022ij4UfmELCUOmw67 m9pJsR1CGaUXRZbstYWNNLR8vID/R8KNePwkVzhPCtnaPmHXPn2XPF+PxrR4VJnCEzqw4l1 dqlyzo3+LL6FwNr4Fb3YQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:zDgn8IuHokM=:DgEYruDmWdBluZ6utvfxah 0mUaNYhsq2muXmF4QGHY+gFgI0j5ZAb33y/EMh7thZjzsnYOkwXBS4WIo1fJJqubMwxRiC6oZ r2MhEmCNbwKwVrbu6vBrd4AR/53E7tV7gYfpuiQya3Qg0evRTJCfsS0HkKCTqlla8ei4bBCKQ rcaNQ2PdQo4j51rX2fO52k5vxy1MOw2TLzfyBclslt6duImTGf70O9j1+vL6bvgYaZEbzxTs8 /iWHI3d/yOwzCGB6hdJvrv6kS+rpctPysaNkdHfIR1OmkfQEliRA6swjb1VITJGH2qGjl8ipa q2tum+ohskRD4OThxKRtnNgfmWVQeJUJwcSBBuhYWQ8E/exBU6nRJMPXaDL2WLc0v6qXbeANX BN6+n9RwzH6UnpcdiJvWJVbmD69y0xcHQ1rGpYv09JSf+ivqHRjmn24yhQDRT4ESSnVYoZNFU pNK9JFXErnUcdo+4l7O6sYUbQ8VqyULjZyOWNfUV3w0GjPgB9rT/UxMwWYDXdI3jtV2dUdluy hT/F1we1VyfnyZt/XZyqyg2TmTsXLGTx8Vnpl/pjtj9fszcFyk+LQRnWAFg0CnHk5r7NxeKql heRtJxpzFhrxn4tUf493u0UDxhL6pk4adpFQbBDQtEktprY3Nm4U0PbBib3Y+Jc9keFBTuZQg yL0teO0ltFKMd9QeHnEThzbRlDyXic9n5OUvGJenoCGiT1QntLGrDKkfgzxnLHOehO3PDiCRL xuzc48O6kJ09mH9U3k1q176nW1pzLoTgyxXHJ8HFtVA5KtbOjzeskfN8HNDUaUGBOhAHcPrVT MxCRm8SBo3EK+Oe7Ace8qiFZAx29w== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> Then it conceptually can run into a loop where it continuously grows = and >> shrinks the mini window? > > What loop? Redisplay doesn't call 'message'; I meant the code run by =E2=80=98window-size-change-functions=E2=80=99 mi= ght call =E2=80=98message=E2=80=99. > calling 'message' enters > another redisplay. Then there should be no problems. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 09:21:49 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 14:21:49 +0000 Received: from localhost ([127.0.0.1]:45711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzmZR-0001cy-8U for submit@debbugs.gnu.org; Fri, 20 Nov 2015 09:21:49 -0500 Received: from mout.gmx.net ([212.227.15.15]:62300) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzmZ3-0001cE-Rk for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 09:21:44 -0500 Received: from [192.168.1.100] ([213.162.68.45]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MXIcX-1Zu3Vs03Yj-00WIPh; Fri, 20 Nov 2015 15:21:21 +0100 Message-ID: <564F2C59.1090300@gmx.at> Date: Fri, 20 Nov 2015 15:21:13 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <564D8497.4090703@gmx.at> <83si428023.fsf@gnu.org> <564ED844.8090908@gmx.at> <83fv016pck.fsf@gnu.org> <564EF52B.5060601@gmx.at> <83ziy86hwk.fsf@gnu.org> <564F0338.6080901@gmx.at> <83vb8w6gte.fsf@gnu.org> In-Reply-To: <83vb8w6gte.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NTTT2EA/ofZ+bmXKR1UdQZKyK6M1brvViHyvxRedwMBSxRtnHLi Kh4Ojnoto+3R+/ZPk8XRq4n2lbK3ciqE6e+W67mRChZ3MoS9D4Q2K1/Emb93XYB+GhWHIZq wWL4g8ipPT1avpWNLrnIgfXsfcNbP6UAyn1uiNgqMo7TLXhwnYcfyphq+OU9x2PkxjQIDa4 X3UFFRXM3B4n9flJRMvsg== X-UI-Out-Filterresults: notjunk:1;V01:K0:/zQhadyKfL0=:OZpgOR8Gxahidwu716JkmO yVVXliowYmw+1wRlOyy7cpCt1bKeF0tzHu4XqUGPDBZF0FSKGuAVFAVu2gLZ3N8/lmrO4k0jE 9k84hDdj27PLCPch2hOTlUE/UZQEN4KBZN5WyPTUImfpN+spenv4CtPQpnLtuHLGDwMhnokww 5FKE7Zo6NNFDHV51uuQZnp/3RyQeJOnzhY/EXZwsg0tpGPFJvHXmHhCLPP6V6ESPtNtEbp2WD de7jF7/z/HyIxlPxaA1DrZ3VGtkiCIpuZOUprwo6dwqYmSWe3yZwamXkaDoYcT8bidA0qhKFC mQM4H6xtmMMduSpsyLY9a3fmLznKGsA8kEm2A5y+YaUiksbReHaWmsFYeMD/sis1+OdMhBlb7 auWU1S1wdWJEfHMl4rJiVPdkSXEjDdhQl8eigWimirsJrX3dNSxXJydp7sO56vvOUuwCtgeQm EaR9KIpLnPAp/xySbgg11dh3IpxU9Qm5AJND7lBsLFnlEJOvshTe5hiy7BFfEjpToF7B9EOaM wisdCFvxt5JNZVKCDZeR8rxF5gzNaWgsfJPJQ27WVdLm+TgLZNuA4ZEJprpC8q71OpW2g7F3e rO7tzTEDfgFNld1aojWs4FedLHyOIesdqmAmjZsNa/TZULwXsCkbWVG49c4REW2kHi2QJ3fuw 8TRcHjfXym1anZlwMmgb2fH2AxVHavyLA9eisIqTDYiwsgr0VPHv0GZumMI+EDTYvOmPjKObG 98DUwRI+jgDB1fXgjSCpWC9pwDtldrvLSZWjnhwJlo4JLxVxplzGIGluaGf+UtLJcfRRC7SCy ZpMsaQ85vaLM84/NG9H5INUoQyt6A== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > Because of loaddefs? You should be able to produce them with a > different Emacs binary. I'll rather wait a few days. I'm in no hurry. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 09:54:43 2015 Received: (at 19576) by debbugs.gnu.org; 20 Nov 2015 14:54:43 +0000 Received: from localhost ([127.0.0.1]:45735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzn5D-0002an-1U for submit@debbugs.gnu.org; Fri, 20 Nov 2015 09:54:43 -0500 Received: from mtaout28.012.net.il ([80.179.55.184]:48621) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzn58-0002ab-2u for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 09:54:38 -0500 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NY400D00BI8Z100@mtaout28.012.net.il> for 19576@debbugs.gnu.org; Fri, 20 Nov 2015 16:53:26 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY400361C0TLLB0@mtaout28.012.net.il>; Fri, 20 Nov 2015 16:53:26 +0200 (IST) Date: Fri, 20 Nov 2015 16:54:06 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <564F2C53.9020608@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83mvu867sh.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <564ED851.1080805@gmx.at> <831tbl6kle.fsf@gnu.org> <564EFA60.5030909@gmx.at> <83y4ds6hv1.fsf@gnu.org> <564F033F.9070509@gmx.at> <83twog6gr3.fsf@gnu.org> <564F2C53.9020608@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 20 Nov 2015 15:21:07 +0100 > From: martin rudalics > CC: acm@muc.de, juri@linkov.net, andlind@gmail.com, > 19576@debbugs.gnu.org > > >> Then it conceptually can run into a loop where it continuously grows and > >> shrinks the mini window? > > > > What loop? Redisplay doesn't call 'message'; > > I meant the code run by ‘window-size-change-functions’ might call > ‘message’. In that case, redisplay won't be called by that invocation of 'message'. Moreover, redisplay_internal doesn't allow to invoke itself recursively (although I never saw it happening), it returns immediately if that happens. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 20 15:18:12 2015 Received: (at 19576-done) by debbugs.gnu.org; 20 Nov 2015 20:18:12 +0000 Received: from localhost ([127.0.0.1]:46437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzs8J-0003LD-Uk for submit@debbugs.gnu.org; Fri, 20 Nov 2015 15:18:12 -0500 Received: from mail-vk0-f49.google.com ([209.85.213.49]:34352) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zzs80-0003KV-PF for 19576-done@debbugs.gnu.org; Fri, 20 Nov 2015 15:18:11 -0500 Received: by vkbs1 with SMTP id s1so5071328vkb.1 for <19576-done@debbugs.gnu.org>; Fri, 20 Nov 2015 12:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0wR1ugHBumRLyDN86F3fKduPK0TWe45PLf2yKHwt6Ec=; b=C6yfvzXJSPhBSe/iw2E4bA6CKXntzquh5Fk+TAuqtW4UrHjJ7LyhBvoZVWFvIn66lz WcU/oXhPqFCD+9QVge96l7zi89B5tQJfL5/FssE1ZZh5FWd9drcviO+mp54qAE+MoZc9 Uo2gpVnaluxhkWBgU1mtQvhIYhCZHI0nnE7+nEMkK2T9AfWIXCPRhCc4RW/Byi90BA5c t0zgmqYyPTHphGFiuK/T70VW4stwCQbCAtxMAujSJTwxBsvXhoS8TCBb36GdV/jFMY6f JBXkfdvGFoyxNUD39AeUKriknwBtYefhiiPIWwMpiTO8+5K0PJAZ18G2tHZ6K7dw8aAX 7C7g== MIME-Version: 1.0 X-Received: by 10.31.146.66 with SMTP id u63mr1269726vkd.31.1448050672226; Fri, 20 Nov 2015 12:17:52 -0800 (PST) Received: by 10.31.210.133 with HTTP; Fri, 20 Nov 2015 12:17:52 -0800 (PST) Date: Fri, 20 Nov 2015 21:17:52 +0100 Message-ID: Subject: Fixed: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: 19576-done@debbugs.gnu.org Content-Type: multipart/alternative; boundary=001a1143a94cef55a50524fe91ed X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1143a94cef55a50524fe91ed Content-Type: text/plain; charset=UTF-8 After discussing this with Eli and John, it was decided that the responsibility to restore the current buffer lies on the lisp function and not the Emacs code that calls `window-size-change-functions'. I committed a patch to follow.el that ensures that the buffer is restored, see http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=75a1d009f747a220c7b9b1cfdbe7077082fe02d6 for details. -- Anders Lindgren --001a1143a94cef55a50524fe91ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After discussing this with Eli and John, it was decided th= at the responsibility to restore the current buffer lies on the lisp functi= on and not the Emacs code that calls `window-size-change-functions'.
I committed a patch to follow.el that ensures that the buf= fer is restored, see=C2=A0http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=3Demacs-25&id=3D= 75a1d009f747a220c7b9b1cfdbe7077082fe02d6 for details.

=C2=A0 =C2=A0 -- Anders Lindgren

--001a1143a94cef55a50524fe91ed-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 06:35:18 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 11:35:18 +0000 Received: from localhost ([127.0.0.1]:46655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a06Rp-0001nc-RP for submit@debbugs.gnu.org; Sat, 21 Nov 2015 06:35:18 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:42604) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a06Rm-0001nS-WB for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 06:35:16 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NY500G00XNIN000@mtaout26.012.net.il> for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 13:38:12 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY5008YTXNNW460@mtaout26.012.net.il>; Sat, 21 Nov 2015 13:38:12 +0200 (IST) Date: Sat, 21 Nov 2015 13:35:02 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <83mvua7z8k.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: acm@muc.de Message-id: <83k2pb4mc9.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 19 Nov 2015 18:03:39 +0200 > From: Eli Zaretskii > Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net > > > Date: Wed, 18 Nov 2015 23:23:04 +0000 > > Cc: martin rudalics , juri@linkov.net, andlind@gmail.com, > > 19576@debbugs.gnu.org > > From: Alan Mackenzie > > > > > Could you try a simpler patch below? It seems to fix both your test > > > case and the one originally reported in bug#21333. > > > > It does indeed fix my test case (I haven't tried it on #21333). However > > it violates the specification of window-size-change-functions, which > > says that the hook is called _before_ redisplay, not after it has > > started. I suppose one could argue over what "redisplay" means here, > > but intuitively I would say it is the putting of glyphs into matrices. > > "Redisplay" is indeed not defined well enough, but the only reasonable > interpretation of "before redisplay" is that it happens before the > call to redisplay_internal. And this is false for your suggested > solution as well. It is false even by your definition, because > prepare_menu_bars already manipulates the glyph matrices, the ones it > creates for the tool bar (and also menu bar on some display types). > And display_echo_area also manipulates glyph matrices (it calls > try_window). > > Which is only logical for an event that by itself is triggered as part > of redisplay! It's redisplay that decides to resize the mini-window, > so calling the hook after that decision _cannot_ possibly count as > being "before redisplay". > > IOW, once we, by popular demand, decided to call > window-size-change-functions when the mini-window is resized, we > invalidated that specification. All the other callers of this hook > are not part of a redisplay cycle, but this one is, and cannot be > anywhere else. > > So no matter what change we eventually install, the documentation of > the hook needs to be amended to say that it's called "before redisplay > or at the beginning of a redisplay cycle", and maybe also mention that > the second case is when the mini-window is resized. No further comments, so I've committed the changes I posted here earlier. I also modified the documentation to be consistent with what the code does. Please tell me if this bug and bug#21333 could now be closed, or if there are any leftovers. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 10:55:03 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 15:55:03 +0000 Received: from localhost ([127.0.0.1]:47205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0AVC-00019H-PV for submit@debbugs.gnu.org; Sat, 21 Nov 2015 10:55:03 -0500 Received: from mail.muc.de ([193.149.48.3]:61174) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0AVA-00018r-10 for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 10:55:00 -0500 Received: (qmail 44165 invoked by uid 3782); 21 Nov 2015 15:54:57 -0000 Received: from acm.muc.de (p5B1473B2.dip0.t-ipconnect.de [91.20.115.178]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 21 Nov 2015 16:54:56 +0100 Received: (qmail 3849 invoked by uid 1000); 21 Nov 2015 15:56:58 -0000 Date: Sat, 21 Nov 2015 15:56:58 +0000 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer Message-ID: <20151121155658.GA3636@acm.fritz.box> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83k2pb4mc9.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Eli. On Sat, Nov 21, 2015 at 01:35:02PM +0200, Eli Zaretskii wrote: > > Date: Thu, 19 Nov 2015 18:03:39 +0200 > > From: Eli Zaretskii > > Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net > > > Date: Wed, 18 Nov 2015 23:23:04 +0000 > > > Cc: martin rudalics , juri@linkov.net, andlind@gmail.com, > > > 19576@debbugs.gnu.org > > > From: Alan Mackenzie > > > > Could you try a simpler patch below? It seems to fix both your test > > > > case and the one originally reported in bug#21333. > > > It does indeed fix my test case (I haven't tried it on #21333). However > > > it violates the specification of window-size-change-functions, which > > > says that the hook is called _before_ redisplay, not after it has > > > started. I suppose one could argue over what "redisplay" means here, > > > but intuitively I would say it is the putting of glyphs into matrices. > > "Redisplay" is indeed not defined well enough, but the only reasonable > > interpretation of "before redisplay" is that it happens before the > > call to redisplay_internal. And this is false for your suggested > > solution as well. It is false even by your definition, because > > prepare_menu_bars already manipulates the glyph matrices, the ones it > > creates for the tool bar (and also menu bar on some display types). > > And display_echo_area also manipulates glyph matrices (it calls > > try_window). > > Which is only logical for an event that by itself is triggered as part > > of redisplay! It's redisplay that decides to resize the mini-window, > > so calling the hook after that decision _cannot_ possibly count as > > being "before redisplay". > > IOW, once we, by popular demand, decided to call > > window-size-change-functions when the mini-window is resized, we > > invalidated that specification. All the other callers of this hook > > are not part of a redisplay cycle, but this one is, and cannot be > > anywhere else. > > So no matter what change we eventually install, the documentation of > > the hook needs to be amended to say that it's called "before redisplay > > or at the beginning of a redisplay cycle", and maybe also mention that > > the second case is when the mini-window is resized. > No further comments, so I've committed the changes I posted here > earlier. I also modified the documentation to be consistent with what > the code does. Thanks. > Please tell me if this bug and bug#21333 could now be closed, or if > there are any leftovers. I don't think this fix concerns #19576. The discussion of #21869 seems, somehow, to have moved to here. But I think that #21333 can be closed, and #21869 certainly can be; both of these were about window-size-change-functions not getting called for echo area size changes. > Thanks. Ditto! -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 11:01:50 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 16:01:50 +0000 Received: from localhost ([127.0.0.1]:47213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Abl-0001KD-LS for submit@debbugs.gnu.org; Sat, 21 Nov 2015 11:01:49 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:49668) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Abi-0001K2-7G for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 11:01:47 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NY6005009L5MI00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 18:01:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY6005B29UWCG70@a-mtaout20.012.net.il>; Sat, 21 Nov 2015 18:01:44 +0200 (IST) Date: Sat, 21 Nov 2015 18:01:34 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <20151121155658.GA3636@acm.fritz.box> X-012-Sender: halo1@inter.net.il To: Alan Mackenzie Message-id: <83bnan4a01.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 21 Nov 2015 15:56:58 +0000 > Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net > From: Alan Mackenzie > > > Please tell me if this bug and bug#21333 could now be closed, or if > > there are any leftovers. > > I don't think this fix concerns #19576. The discussion of #21869 seems, > somehow, to have moved to here. Right. But then 19576 should be closed "for other reasons", right? > But I think that #21333 can be closed, and #21869 certainly can be; both > of these were about window-size-change-functions not getting called for > echo area size changes. Will do. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 11:49:48 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 16:49:48 +0000 Received: from localhost ([127.0.0.1]:47247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0BMC-0002UM-18 for submit@debbugs.gnu.org; Sat, 21 Nov 2015 11:49:48 -0500 Received: from mail-vk0-f47.google.com ([209.85.213.47]:32978) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0BMA-0002UE-Bi for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 11:49:46 -0500 Received: by vkfr145 with SMTP id r145so15405556vkf.0 for <19576@debbugs.gnu.org>; Sat, 21 Nov 2015 08:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yGOT5HAf4jr+5SSF3YUcOcrFka/HESvXN0a5NxRFNYo=; b=RLPSg3XZilB/qtb+QwTyXfeDNPegjuGebG/Dj1Mb4KezJ6rJTbcI4Idv0XwOacOAuU UXKsF35JzXQIUsLb3pE/BC2pP1ZatC0ZmYry3UGWbnwVwth9u1JDZEQq/e6ZbPheo9eT MeN1dG3SqP63XJFysXpV59qLoVeush2RsYm4SGsya65WfD0LD2HheRXVJm9IkgLzyDX7 PhrKCFB3lXOC2eTXqqSSrdvpgSJBf0C08SynRRfI/tGarYQcmH5UUhQe+wfGo+RWX6P4 cBv/LyqQIbSz1lJVo82af5xLkqgGwUqXBkGAdQeUVoHQTiq0cf9QgDHu/KA9HpV8NDqx Q+fw== MIME-Version: 1.0 X-Received: by 10.31.107.21 with SMTP id g21mr6950410vkc.26.1448124585585; Sat, 21 Nov 2015 08:49:45 -0800 (PST) Received: by 10.31.210.133 with HTTP; Sat, 21 Nov 2015 08:49:45 -0800 (PST) In-Reply-To: <83bnan4a01.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> Date: Sat, 21 Nov 2015 17:49:45 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a1147830283b1cf05250fc7ba X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: Alan Mackenzie , 19576@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1147830283b1cf05250fc7ba Content-Type: text/plain; charset=UTF-8 > > Right. But then 19576 should be closed "for other reasons", right? > Correct, I fixed and closed 19576 a couple of days ago. I did the change in follow-mode as Eli suggested. However, while we are discussing window-size-change-functions -- I noticed that on OS X and Windows, it is not called when the user manually resized a frame, whereas on X11 it is. It seems logical that is should be called -- should I file this as a bug (or one for each interface)? -- Anders --001a1147830283b1cf05250fc7ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right.=C2=A0 But then 19576 should be closed &qu= ot;for other reasons", right?

Corr= ect, I fixed and closed 19576 a couple of days ago. I did the change in fol= low-mode as Eli suggested.


However,= while we are discussing window-size-change-functions -- I noticed that on = OS X and Windows, it is not called when the user manually resized a frame, = whereas on X11 it is. It seems logical that is should be called -- should I= file this as a bug (or one for each interface)?

= =C2=A0 =C2=A0 -- Anders
--001a1147830283b1cf05250fc7ba-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 12:10:41 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 17:10:41 +0000 Received: from localhost ([127.0.0.1]:47255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0BgN-0002yn-9P for submit@debbugs.gnu.org; Sat, 21 Nov 2015 12:10:39 -0500 Received: from mtaout24.012.net.il ([80.179.55.180]:59656) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Bg1-0002yJ-Q2 for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 12:10:37 -0500 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NY600300C9OKQ00@mtaout24.012.net.il> for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 19:03:09 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY6003GKCP8G610@mtaout24.012.net.il>; Sat, 21 Nov 2015 19:03:09 +0200 (IST) Date: Sat, 21 Nov 2015 19:10:06 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: X-012-Sender: halo1@inter.net.il To: Anders Lindgren Message-id: <838u5r46tt.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 21 Nov 2015 17:49:45 +0100 > From: Anders Lindgren > Cc: Alan Mackenzie , 19576@debbugs.gnu.org, Juri Linkov > > Correct, I fixed and closed 19576 a couple of days ago. I did the change in > follow-mode as Eli suggested. Thanks. > However, while we are discussing window-size-change-functions -- I noticed that > on OS X and Windows, it is not called when the user manually resized a frame, > whereas on X11 it is. It seems logical that is should be called -- should I > file this as a bug (or one for each interface)? Please file a single bug report for both platforms. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 13:27:57 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 18:27:58 +0000 Received: from localhost ([127.0.0.1]:47278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0CtB-0004sS-A2 for submit@debbugs.gnu.org; Sat, 21 Nov 2015 13:27:57 -0500 Received: from mout.gmx.net ([212.227.17.22]:59263) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Ct9-0004sK-6e for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 13:27:55 -0500 Received: from [192.168.1.100] ([213.162.68.49]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MWkZL-1Zq3UU2mWB-00XtSZ; Sat, 21 Nov 2015 19:27:49 +0100 Message-ID: <5650B79A.1090504@gmx.at> Date: Sat, 21 Nov 2015 19:27:38 +0100 From: martin rudalics MIME-Version: 1.0 To: Anders Lindgren , Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:5LhgxH/1ik902bnUFKnk1IYHJNT1HDgYYXX42wuSIDNxzwvcWwW C7cF1Lc67MT2kA6x7KuK6pNcB5Ly3IKKqPf95DaXxokpZmkRiymyuHOLx/MTR5PYuU9ueAo oz3ZDifMZi5HyVxrQ1qD3ayAjWG8GovVZZ3jafvES8lPSX+qIvSAs9J7z3x3VqzxSgT3mmf Rd2/wfIyu7G8RrHvvY2Yw== X-UI-Out-Filterresults: notjunk:1;V01:K0:DN9D8WdMHHo=:rX3fCpTNtY6eBLbQvAaWIW HaGYwJ/Lgu/6zTXykqQ79ezgTQoOECiHISUXqudTVmrlMh6SqA02Z9pqV0qjCNCkYVpROTO3B a9PkVGb0yLcBwyIKU6rNG7Op7aHmOj/l+heI9qO49BoS08MZ4dvga9S2gGnmbBcjbK9xNRntG Dv/0/51pNNEeMw2DiBMO3Dkpia2Ioo/epDoS1CoKwOyG7zt6MHgyK0Gi1fPFez3qCQ7woZc8+ 78aB2JgyPWb7IutL/ABNspeoUDZVL3d5kQ0+WQ68f2PBAUTqQr7t0Oc6zfrEu35MVZ1oXabez 5lzE2+8vBYNu3vx7xFH2VObJsT9mm50IAXU5iYl1eHEN7s/fz8QGluTcPPQBUOLxyKzBqWiD5 0A4KvOggnZ9PQ02ADGd6u1XdYFQPKUWYZc3OmP7On3dkMZVbUNRsoydOvhV11E3hXFMbiAVT4 594MXRhh10KfgxX4yWSJFT5FyoWku/gPIrmaWMJr9AuVOayLHaVx29dSbiyHaFcAWGsxk7EDv AXddaAwZBIiCU07P6x2ZJRS2VNTV8X8f4XRlqHJirZ6233f0RdHu17tTsA1GTe0soMyiVxY6X 4lDnL9+aszRZPGJKXEhe/3L8HTsi8zROjmukNqQtnXEhUge2j5C630AI2OXJlHOQhkmeFXiEP cnQh8kKFmoOFUxiDH0jeuEGhxFb2fjCJwUtKEiGUDOMdQ6ztT9iChjgKTgAZjHz1ca+cj/dn+ xSnJsMPiNiQzc7TCxXynChQeiXQB+Uqvh5nx2dvA3GoVm57b6wFcAFi2tJpYKxhBF160ypjkq dunxMjRpKr+H0qVn25Huuvhxc1iJA== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: Alan Mackenzie , 19576@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > However, while we are discussing window-size-change-functions -- I not= iced > that on OS X and Windows, it is not called when the user manually resi= zed a > frame, whereas on X11 it is. It seems logical that is should be called= -- > should I file this as a bug (or one for each interface)? I can't imagine how this got called for X11 - something else must have been intervening here. Resizing a frame calls =E2=80=98window-configuration-change-hook=E2=80=99= instead. In Emacs 22 change_frame_size_1 still had /* This isn't quite a no-op: it runs window-configuration-change-hook.= */ Fset_window_buffer (FRAME_SELECTED_WINDOW (f), XWINDOW (FRAME_SELECTED_WINDOW (f))->buffer, Qt); while in Emacs 23 change_frame_size_1 already uses run_window_configuration_change_hook (f); Obviously =E2=80=98window-size-change-functions=E2=80=99 seems more logic= al here but might break packages that expect the old behavior. Running both hooks for frame resizes doesn't seem overly clever but we do so already when deleting and splitting windows. Anyway, this is a can of worms. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 13:33:58 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 18:33:58 +0000 Received: from localhost ([127.0.0.1]:47282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Cyz-000530-LM for submit@debbugs.gnu.org; Sat, 21 Nov 2015 13:33:57 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:40828) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Cyf-00052S-23 for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 13:33:56 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NY600600GETEW00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 20:33:35 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY6006S1GVYH200@a-mtaout20.012.net.il>; Sat, 21 Nov 2015 20:33:35 +0200 (IST) Date: Sat, 21 Nov 2015 20:33:25 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <5650B79A.1090504@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83610v42yy.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> <5650B79A.1090504@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 21 Nov 2015 19:27:38 +0100 > From: martin rudalics > CC: Alan Mackenzie , 19576@debbugs.gnu.org, > Juri Linkov > > Resizing a frame calls ‘window-configuration-change-hook’ instead. In > Emacs 22 change_frame_size_1 still had > > /* This isn't quite a no-op: it runs window-configuration-change-hook. */ > Fset_window_buffer (FRAME_SELECTED_WINDOW (f), > XWINDOW (FRAME_SELECTED_WINDOW (f))->buffer, Qt); > > while in Emacs 23 change_frame_size_1 already uses > > run_window_configuration_change_hook (f); > > Obviously ‘window-size-change-functions’ seems more logical here but > might break packages that expect the old behavior. Running both hooks > for frame resizes doesn't seem overly clever but we do so already when > deleting and splitting windows. Anyway, this is a can of worms. We could run both types of hooks, couldn't we? The documentation seems to suggest that both of them should be run in this situation. As for "can of worms", we could make that change on master and see what breaks. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 13:44:44 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 18:44:44 +0000 Received: from localhost ([127.0.0.1]:47290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0D9Q-0005JQ-Bl for submit@debbugs.gnu.org; Sat, 21 Nov 2015 13:44:44 -0500 Received: from mout.gmx.net ([212.227.17.21]:61496) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0D96-0005Ix-54 for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 13:44:43 -0500 Received: from [192.168.1.100] ([213.162.68.49]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0La2Xx-1albax3xr3-00llzE; Sat, 21 Nov 2015 19:44:19 +0100 Message-ID: <5650BB77.40106@gmx.at> Date: Sat, 21 Nov 2015 19:44:07 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> <5650B79A.1090504@gmx.at> <83610v42yy.fsf@gnu.org> In-Reply-To: <83610v42yy.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:mqAEaJEPUnYW709gblQbIR1xtv5zFve6VCWHfSZKUu78Z3PA0Hl BoNeKVDDSM3J6wfAhg842/m/mu4G/J+38jMciEBz1WGbQCg35Fh3jD4DrgDmTgwkkZpm60h sNgUG1A5/sAmCp6aQIWh99AcBMnnB0DQQOSTR85ed5+N/pwGZHipTKHLQtJPqyalB47Pd2+ d81MkSiN2Wpha6Ipzhf+w== X-UI-Out-Filterresults: notjunk:1;V01:K0:jZgpFxa3Zh0=:vylH63qLygeMLRsR+l6E1K EdD77oAqFjqHVQZWA7eft55pcs5I7unKYN9cHy5evwJdPRx7gBoaDg31IDp2vUcq1Tp5Ka6HU u22rbtmNIlUa4UZ54sHyusP67iew4gkARIUj5GSRMTHSTqA1fNu/LhsJWLxctTXmyeYENUW5t wXs8MLMtsGXt4Fhjp2d1ZQeJ3vIFE66QqfBCS+OeL0FXgxM9ST5rSekuUMFJ9kKxFQAQmDqbO KNz+dsvmo7kFvO3skyWGEyJReKzEjrL/XQ6+e1srhZhtFfyRnbKue5vmQG2hoJrw6MHKYYJg6 tQq81BzjTK0PGAY0/GqfE3YeU5zbm4x03bFhgiiBmfYGF+d7uyHRL43aeblJ//q/x8NmJ5Fmv FBy2l+el8jlovBUj2twxsP0ZSgD1ADQUP8F9n4t1p2vXG2gmmoK1RdlUwYBlVl8XsjwwU0+ef 1ElfsqRM+dfAVqnrT0YHEJJhQDem1LTzIDXW5Y9o97x/RFR6ZmCpsYbEaDd6AyhcP84g/X1se zNCdu0wV5RitB/fH+CUcv8gQ8nXvlOzcAju6sbuQIuLFRDyP/19o6IfAXnlsMCOlw5OdVAOiH SBok2uYfqusF5mdiM1bQtWmIVVWAfeacsL30LyWntKXj5ToMqNIaiIkTC4PIxYGOZMydkMXkj /nRDb30pDmjTbZIuWH60Q8Uqi+xfIcZCvPvuiAtKRUs+Mz14TmViM6+58BiUixQJ2wrsUs93i Lk+Xafh8UgBtMStRxblTNrYMVm/ql/+12dPKigwxpJjiZFS2Njg7ADB2CpTxtUlCGF4F32rBf KxM83x1/nx5z20Cw/6c2JJjBDRy7A== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > We could run both types of hooks, couldn't we? As I said we do that already for splitting and deleting windows. So we obviously could. But this means that packages run the same function twice because they are used to run the same function in both hooks. > The documentation > seems to suggest that both of them should be run in this situation. =E2=80=98window-configuration-change-hook=E2=80=99 shouldn't run since th= e window configuration does not change. > As for "can of worms", we could make that change on master and see > what breaks. WDYT? It won't break anything. But why should we OT1H make =E2=80=98window-size-change-functions=E2=80=99 more efficient when OTOH w= e call it after we already called =E2=80=98window-configuration-change-hook=E2=80=99? martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 14:09:04 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 19:09:04 +0000 Received: from localhost ([127.0.0.1]:47294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0DWx-0005vL-Ep for submit@debbugs.gnu.org; Sat, 21 Nov 2015 14:09:03 -0500 Received: from mtaout27.012.net.il ([80.179.55.183]:51207) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0DWb-0005ua-QE for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 14:09:00 -0500 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NY600K00I75MS00@mtaout27.012.net.il> for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 21:03:35 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY600IAII9ZEA20@mtaout27.012.net.il>; Sat, 21 Nov 2015 21:03:35 +0200 (IST) Date: Sat, 21 Nov 2015 21:08:29 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <5650BB77.40106@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <834mgf41ci.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> <5650B79A.1090504@gmx.at> <83610v42yy.fsf@gnu.org> <5650BB77.40106@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 21 Nov 2015 19:44:07 +0100 > From: martin rudalics > CC: andlind@gmail.com, acm@muc.de, 19576@debbugs.gnu.org, > juri@linkov.net > > > We could run both types of hooks, couldn't we? > > As I said we do that already for splitting and deleting windows. So we > obviously could. But this means that packages run the same function > twice because they are used to run the same function in both hooks. That'[s why I think we should do this on master, to see if this causes any problems. > > The documentation > > seems to suggest that both of them should be run in this situation. > > ‘window-configuration-change-hook’ shouldn't run since the window > configuration does not change. But the ELisp manual says it should: -- Variable: window-configuration-change-hook A normal hook that is run every time you change the window configuration of an existing frame. This includes splitting or deleting windows, changing the sizes of windows, or displaying a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ different buffer in a window. > But why should we OT1H make ‘window-size-change-functions’ more > efficient when OTOH we call it after we already called > ‘window-configuration-change-hook’? Sorry, I don't see the relevance of efficiency to this issue. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 21 15:33:55 2015 Received: (at 19576) by debbugs.gnu.org; 21 Nov 2015 20:33:55 +0000 Received: from localhost ([127.0.0.1]:47336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Er4-0008UW-Ez for submit@debbugs.gnu.org; Sat, 21 Nov 2015 15:33:55 -0500 Received: from mail-vk0-f44.google.com ([209.85.213.44]:34424) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Er2-0008UP-VW for 19576@debbugs.gnu.org; Sat, 21 Nov 2015 15:33:53 -0500 Received: by vkbs1 with SMTP id s1so17040048vkb.1 for <19576@debbugs.gnu.org>; Sat, 21 Nov 2015 12:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NxOFSa1US8rw5WQTBEvHIIVTfLhI+2kryLod1RuMdIA=; b=rOTqE4efqKLCnW0quh++lJpkUYPBSBXVnbFQdgQq4fLr2G8+Ufyuw3lKQ2KS4Dul0O /G3Sqz6XDK6+f68fOFiFkSnowSizTfGrZftcFeoijlqcpW6QZVC0KmkufYELaFlqmtND Cp4l9Akzj9/2828epnaHSK4ieqK36bxF1nDF+DlOi5pHUO1mElzu7WtiXL+JfiW8JCWm mq1xQKGBcn1dD56zruQAxHafyCFs3CyVpOHM4z2aM0CL0DXLq2YwelFnWLyulMItxh99 PvfD+QRCR+HWMk6KjJjz76qByOs6lpO5uPYjm2Al13kFHa1doWjuGOdylOIcemj3N2qk lhcg== MIME-Version: 1.0 X-Received: by 10.31.146.66 with SMTP id u63mr7657197vkd.31.1448138032508; Sat, 21 Nov 2015 12:33:52 -0800 (PST) Received: by 10.31.210.133 with HTTP; Sat, 21 Nov 2015 12:33:52 -0800 (PST) In-Reply-To: <834mgf41ci.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> <5650B79A.1090504@gmx.at> <83610v42yy.fsf@gnu.org> <5650BB77.40106@gmx.at> <834mgf41ci.fsf@gnu.org> Date: Sat, 21 Nov 2015 21:33:52 +0100 Message-ID: Subject: Re: bug#19576: write-file writes the wrong buffer From: Anders Lindgren To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a1143a94c03ab23052512e95f X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , Juri Linkov , 19576@debbugs.gnu.org, Alan Mackenzie X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1143a94c03ab23052512e95f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Auhm -- when starting to write the bug report I decided to make sure I got all the facts right. Unfortunately, it turned out that I had run an old Emacs 23 on X11 -- which do run the window-size-change-functions. When testing on an Emacs 25 on X11, it turns out that it doesn't. Back on the mac, I see the same pattern. In other words: On Emacs 23, window-size-change-functions is called when the user manually resized the frame. On Emacs 24 and Emacs 25 it isn't. Sorry for the mixup. Anyway, I just reported this regression as bug#21975. I noticed this since Follow-mode no longer aligns its windows automatically when the user resized the frame. In practice, this is not a big problem since they will become aligned at the first user interaction instead. -- Anders On Sat, Nov 21, 2015 at 8:08 PM, Eli Zaretskii wrote: > > Date: Sat, 21 Nov 2015 19:44:07 +0100 > > From: martin rudalics > > CC: andlind@gmail.com, acm@muc.de, 19576@debbugs.gnu.org, > > juri@linkov.net > > > > > We could run both types of hooks, couldn't we? > > > > As I said we do that already for splitting and deleting windows. So we > > obviously could. But this means that packages run the same function > > twice because they are used to run the same function in both hooks. > > That'[s why I think we should do this on master, to see if this causes > any problems. > > > > The documentation > > > seems to suggest that both of them should be run in this situation. > > > > =E2=80=98window-configuration-change-hook=E2=80=99 shouldn't run since = the window > > configuration does not change. > > But the ELisp manual says it should: > > -- Variable: window-configuration-change-hook > A normal hook that is run every time you change the window > configuration of an existing frame. This includes splitting or > deleting windows, changing the sizes of windows, or displaying a > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > different buffer in a window. > > > But why should we OT1H make =E2=80=98window-size-change-functions=E2=80= =99 more > > efficient when OTOH we call it after we already called > > =E2=80=98window-configuration-change-hook=E2=80=99? > > Sorry, I don't see the relevance of efficiency to this issue. > --001a1143a94c03ab23052512e95f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Auhm -- when starting to write the bug report I decided to= make sure I got all the facts right.

Unfortunately, it = turned out that I had run an old Emacs 23 on X11 -- which do run the window= -size-change-functions. When testing on an Emacs 25 on X11, it turns out th= at it doesn't. Back on the mac, I see the same pattern.

<= /div>
In other words: On Emacs 23, window-size-change-functions is call= ed when the user manually resized the frame. On Emacs 24 and Emacs 25 it is= n't.

Sorry for the mixup.

=
Anyway, I just reported this regression as bug#21975.

I noticed this since Follow-mode no longer aligns its windows auto= matically when the user resized the frame. In practice, this is not a big p= roblem since they will become aligned at the first user interaction instead= .

=C2=A0 =C2=A0 -- Anders


On Sat, Nov 21,= 2015 at 8:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Sat, 21 Nov 2015 19:44:07 +0100
> From: martin rudalics <rudalics@= gmx.at>
> CC: andlind@gmail.com, acm@muc.de, 19576@debbugs.gnu.org,
>=C2=A0 juri@linkov.net
>
>=C2=A0 > We could run both types of hooks, couldn't we?
>
> As I said we do that already for splitting and deleting windows.=C2=A0= So we
> obviously could.=C2=A0 But this means that packages run the same funct= ion
> twice because they are used to run the same function in both hooks.
That'[s why I think we should do this on master, to see if this = causes
any problems.

>=C2=A0 > The documentation
>=C2=A0 > seems to suggest that both of them should be run in this si= tuation.
>
> =E2=80=98window-configuration-change-hook=E2=80=99 shouldn't run s= ince the window
> configuration does not change.

But the ELisp manual says it should:

=C2=A0 =C2=A0-- Variable: window-configuration-change-hook
=C2=A0 =C2=A0 =C2=A0 =C2=A0A normal hook that is run every time you change = the window
=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration of an existing frame.=C2=A0 This i= ncludes splitting or
=C2=A0 =C2=A0 =C2=A0 =C2=A0deleting windows, changing the sizes of windows,= or displaying a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0different buffer in a window.

> But why should we OT1H make =E2=80=98window-size-change-functions=E2= =80=99 more
> efficient when OTOH we call it after we already called
> =E2=80=98window-configuration-change-hook=E2=80=99?

Sorry, I don't see the relevance of efficiency to this issue.

--001a1143a94c03ab23052512e95f-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 22 05:45:15 2015 Received: (at 19576) by debbugs.gnu.org; 22 Nov 2015 10:45:15 +0000 Received: from localhost ([127.0.0.1]:47643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0S8x-0001Yd-9W for submit@debbugs.gnu.org; Sun, 22 Nov 2015 05:45:15 -0500 Received: from mout.gmx.net ([212.227.15.15]:57976) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0S8v-0001YT-5i for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 05:45:13 -0500 Received: from [192.168.1.100] ([213.162.68.105]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0McDl1-1ZkIT63M8N-00Jds2; Sun, 22 Nov 2015 11:45:07 +0100 Message-ID: <56519CA8.3090406@gmx.at> Date: Sun, 22 Nov 2015 11:44:56 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> <5650B79A.1090504@gmx.at> <83610v42yy.fsf@gnu.org> <5650BB77.40106@gmx.at> <834mgf41ci.fsf@gnu.org> In-Reply-To: <834mgf41ci.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:sVK9buuyMjRKjKcNPpBxMSC9bJGhHSrCdSU2GQuI//ghAo6bsQ5 kLhhCWK1iEwHeiLuFEjmy7oUkVVLQU0mnY7tKl7vRNhB3oh3r5OhLlzF3WV3o2jkN3kNWYa 61ZtJAIpur6i4oShMFXOF5dRbzqhpLkQtLewssCqCP+cKrkQdJ9lIfKicUsLmQgS1ky7mz7 x8qQKZ5AQ34EHBjBHh+Bw== X-UI-Out-Filterresults: notjunk:1;V01:K0:j/T69OjkzLw=:jqpcDF2TmERjY6J90cT5as BHMgI0rEyn3IKrtgA3Xu/hofoCzt1XS+6B/wXRFwWTwMzM/9f27Lb5aMsrHFsFyzfQk9k+UIZ wKSwzVtHLsR0sL+ZCvG/QDTD/XO7htmgLmEaH6xvOwbvzm/uksgysuktXtv7jR7CcV980TuBP n9yihnKK/DJXlrx01ovz3/45fBnONqsU8/B1sxRHEkU3mWb0zSj63eRSeP89fD8g1OlowLcae 3GGXxrRxgp8Zrxr3IQ8JZ33Lhe1mKi5qN4jo353yhmKoTO6TlLQFgEfLukh9QKxhIIpy/5Uab +D95zFD4fs82OhYaKK/SmKar+8vBRAhO3WxWk26+UanMrhPPOPQ2qzXXy2pySgp9yBQfFKVD5 cZEwNHZeBtTz/NpkZQlS15/DgYTy5g2FLnlOBgM0BdYHS+j5yZv+XnkZeN1YfKBx4ZpEUmcVf uBYzAQkDvwnzSfEw6SNfNdd6/o8wqjY1Tw1eWUx3I4zU3q5A8tMf1VzptGzpf2ssIG52af/uA +H9qmvwlkOotmadiwDhJSsXaBXNBof0pjpkMQjBhFFN6jOTC1ZQj/9DnloDwmIp2ZEfFvS+/y xjnTu5gtI8dwgIQFrSDO21SjrunGOLuxAvLIr8crnrjJQFhNbQBVyICuxXwnqxuW1wIS5YAjD 6N1Qlc4BoRoBww+LJpNd1wilgOrGrYWo8+/Ua67Q4k+cwHtjIX2QujVD7xZCm0PwqLai959aV t2DXgKUugxhaTBNwLrZT3ArQvv8yjL17icF+XUTUdIiT+YsUlk6MMgENA8AqE3BEIBl/NGINB JldEm4tQdMVSzX6TPungAmEtBT3mw== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > That'[s why I think we should do this on master, to see if this causes= > any problems. It shouldn't because, as Anders remarked, it already worked this way in Emacs 23. So I tend to install this on Emacs-25. >> > The documentation >> > seems to suggest that both of them should be run in this situatio= n. >> >> =E2=80=98window-configuration-change-hook=E2=80=99 shouldn't run sinc= e the window >> configuration does not change. > > But the ELisp manual says it should: > > -- Variable: window-configuration-change-hook > A normal hook that is run every time you change the window > configuration of an existing frame. This includes splitting o= r > deleting windows, changing the sizes of windows, or displaying= a > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > different buffer in a window. Taken literally we'd then have to run =E2=80=98window-configuration-chang= e-hook=E2=80=99 also when we resize windows without resizing the frame. In particular, we'd then have to run it in prepare_menu_bars and in redisplay_internal. Do we really want to do that? If so, we could easily obsolete =E2=80=98window-size-change-functions=E2=80=99 because then every case wo= uld have been already covered by =E2=80=98window-configuration-change-hook=E2=80=99 bef= ore. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 22 06:09:19 2015 Received: (at 19576) by debbugs.gnu.org; 22 Nov 2015 11:09:19 +0000 Received: from localhost ([127.0.0.1]:47665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0SWF-0002BJ-GG for submit@debbugs.gnu.org; Sun, 22 Nov 2015 06:09:19 -0500 Received: from mout.gmx.net ([212.227.17.21]:64285) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0SVv-0002AW-PL for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 06:09:18 -0500 Received: from [192.168.1.100] ([213.162.68.105]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MIPhr-1a42sj1v4x-0049mu; Sun, 22 Nov 2015 12:08:54 +0100 Message-ID: <5651A23A.3030907@gmx.at> Date: Sun, 22 Nov 2015 12:08:42 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , acm@muc.de Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> In-Reply-To: <83k2pb4mc9.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jB6a/btc4rIN+s6Cdymm8z08yMK6EUV/NXqtWUSqOLsC8JCwUOA kSlLZLit5jngv7k794ySeZ6EQnr8NOrG52K4K8qJqW/Cag5xa0IWS1VrT5egrSY3U1G6pTW /Nerx+Xhdb6/s/8sfxY3HfBuqNYolK0ws9IUDQ+2sFWcKKQQc9iFvuhWV7Vc2bFHefNpl44 aJtJdo3xA8nQLeLQpKrUQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:pjOuxRBUI6A=:3DkHluxhOjG6MuHSicvrDD mvlsnkMJW9qmiV4xZKLHSquF+YL9vKYmbAIVknswzebD2zcoVGbZ/8U0Bvkgt51zi+mZvNKBN Th4hshMrHTAXfosJ/dCSCQaDpzBSXAF8B3/uUowkRQQM6PwL9Pus6QVHtoRkZax9nEj1SqFaH CFxt3WD6TUoXHSLof6hLZKamfzNQbPF/HgzhgR763IpozM2DzqM63cykGRXhqFEm3+54BOps3 GH82IvkyPjJjWGPoK2BeNrJ2QPnyQFgjhFOK+fDUErAyfKJNKScoLNtfxUirLuXNmANDDmuSK ZR4zAYYh9bXaKNDhGrmcclfGFa2oOouBa10l/IL0ZunZaVAHJgO8Bt5dhDp8zGqYQGWXnHSnk mlnH6hsD04xFY+m5cACdG1ZM+Be/n16Bbp7VSIfST5rgZmRh+1vL+9CzYWpfX/cg1fiNLt1qT UO7deoswC+AtSbKUzu0oY3auNT12wOdenRWB68ij68TMko95/BArCZZfDFzB0iX9gYI1COZ7q 6ABqO6dbUqJkZ3lIN7twV8BNbzRw6PazpQ8TjazoP1Q5q6CNNQbK4qDAWx8KFSsdYNEVt8n/q A9E6wuUWCxURZIro91a9egiQuj6RWGYSRE9fn9Dh1QikO7KGS5YglPYN9/IUmF/RvAzUVJh5h PNF+jiJXID3zArhEf2aYLJ/sOWgvoP6w6CsH54DqltCQCPGb5cG+5vt4glTjiuwoE11Bsyz/o HE02PMHX7tXDLkuMOGyTb6fKdj7W4PcQCGfpSM6f8RN6Thxz27+2uQjzWfGu8m22vjG43b7SO Lg/Bszw12dCpqewwzF+IF2mRmS6aA== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > I also modified the documentation to be consistent with what > the code does. The Elisp manual now says The functions are called at the beginning of a redisplay cycle, and just once for each frame on ^^^^^^^^^ which size changes have occurred. IIUC the functions may now be called twice for the selected frame: A first time when a "normal" size changed occurred and a second time when the mini-window got resized. Or am I missing something? martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 22 10:38:02 2015 Received: (at 19576) by debbugs.gnu.org; 22 Nov 2015 15:38:02 +0000 Received: from localhost ([127.0.0.1]:48331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0WiI-0002Ku-0A for submit@debbugs.gnu.org; Sun, 22 Nov 2015 10:38:02 -0500 Received: from mtaout27.012.net.il ([80.179.55.183]:52374) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Whw-0002KJ-0z for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 10:37:59 -0500 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NY800E0032EZ800@mtaout27.012.net.il> for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 17:31:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY800EWL34U4Z00@mtaout27.012.net.il>; Sun, 22 Nov 2015 17:31:42 +0200 (IST) Date: Sun, 22 Nov 2015 17:36:39 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <56519CA8.3090406@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <831tbi3v20.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <20151121155658.GA3636@acm.fritz.box> <83bnan4a01.fsf@gnu.org> <5650B79A.1090504@gmx.at> <83610v42yy.fsf@gnu.org> <5650BB77.40106@gmx.at> <834mgf41ci.fsf@gnu.org> <56519CA8.3090406@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 22 Nov 2015 11:44:56 +0100 > From: martin rudalics > CC: andlind@gmail.com, acm@muc.de, 19576@debbugs.gnu.org, > juri@linkov.net > > > That'[s why I think we should do this on master, to see if this causes > > any problems. > > It shouldn't because, as Anders remarked, it already worked this way in > Emacs 23. So I tend to install this on Emacs-25. Fine with me. > > -- Variable: window-configuration-change-hook > > A normal hook that is run every time you change the window > > configuration of an existing frame. This includes splitting or > > deleting windows, changing the sizes of windows, or displaying a > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > different buffer in a window. > > Taken literally we'd then have to run ‘window-configuration-change-hook’ > also when we resize windows without resizing the frame. In particular, > we'd then have to run it in prepare_menu_bars and in redisplay_internal. > Do we really want to do that? If so, we could easily obsolete > ‘window-size-change-functions’ because then every case would have been > already covered by ‘window-configuration-change-hook’ before. Fine with me, too, although this change is incompatible, and so should be made on master, IMO. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 22 10:39:38 2015 Received: (at 19576) by debbugs.gnu.org; 22 Nov 2015 15:39:38 +0000 Received: from localhost ([127.0.0.1]:48346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Wjq-0002O1-9u for submit@debbugs.gnu.org; Sun, 22 Nov 2015 10:39:38 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:57090) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Wjo-0002Ns-45 for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 10:39:36 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NY800L003E8SD00@a-mtaout21.012.net.il> for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 17:39:34 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY800LHZ3HYOI80@a-mtaout21.012.net.il>; Sun, 22 Nov 2015 17:39:34 +0200 (IST) Date: Sun, 22 Nov 2015 17:39:27 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <5651A23A.3030907@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83ziy62gcw.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5651A23A.3030907@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 22 Nov 2015 12:08:42 +0100 > From: martin rudalics > CC: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net > > > I also modified the documentation to be consistent with what > > the code does. > > The Elisp manual now says > > The functions are called at the > beginning of a redisplay cycle, and just once for each frame on > ^^^^^^^^^ > which size changes have occurred. > > IIUC the functions may now be called twice for the selected frame: A > first time when a "normal" size changed occurred and a second time when > the mini-window got resized. Or am I missing something? I couldn't think of any situation that would cause that. It would require a resize of windows outside redisplay that would also cause redisplay to decide that the mini-window needs to be resized. If you can come up with a recipe for this, we should indeed remove the "just once" promise. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 22 12:46:37 2015 Received: (at 19576) by debbugs.gnu.org; 22 Nov 2015 17:46:37 +0000 Received: from localhost ([127.0.0.1]:48461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Yii-000616-UT for submit@debbugs.gnu.org; Sun, 22 Nov 2015 12:46:37 -0500 Received: from mout.gmx.net ([212.227.17.22]:51034) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Yig-00060v-FA for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 12:46:34 -0500 Received: from [192.168.1.100] ([213.162.68.105]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MT74k-1ZtIcy1KL8-00SAsv; Sun, 22 Nov 2015 18:46:30 +0100 Message-ID: <5651FF6B.90609@gmx.at> Date: Sun, 22 Nov 2015 18:46:19 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5651A23A.3030907@gmx.at> <83ziy62gcw.fsf@gnu.org> In-Reply-To: <83ziy62gcw.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:DMTbdEMW1Rs9OC77f9f1qkrN8rOKX0GULp8Y+G6+mTWFryERO4Q X7Jv9LBZ8oR/Afy0Y4iKaPP/RU9HmkyGczuK4O8fd3/s9B4EdrZ+/8/M2ZWKMoe9Ma3z3aM HrDlRIiP80mUdH1yHN9tm8D0/azLX87ORzqrfjzxt7thUBM7SIQYLaEYAwQ1gUkkFFFrbyP PtTov3iWHRnGIdpmeZ4LA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZDhig/doZrk=:PHcI9DiPiyCVdAbD/TKJNz +0CCxX36th3sBbGEruLWeOTTQJhjuXEG4A5zolgEeEW3yCR7tNWW12uQD9eF7hep4c/G+vyA/ zoExjuRK3tnf0KU+T7FX+eiCo6SWxrhljYW+guBw7izohwSOBcrpFcFfNUyn5ljnr6attDcC1 67DOpEBkE7zE4WXOBKEDeaSE56RmASFoycVidx0v2otGTl7Sj1UapWNSV5sOwKiWA5xiM3DT1 lE4lYE4lSb1x6oaZHIoMeDqOp7z7391RLqiWqzI1d3yLS60LaSXoJHpMwvP85aZYnXMbsPlh4 ++X/kDq8324x7J2etVDSKIHt5JB5QmnVt/L1aAhI/pKvFC+m+w/jfLW4KR5hWpIsZTbGIqque Y2VSYAUnVNn2lafwf78DC7Nx4ShTaZSG+0SCD+r8B+0X2LEh1AVvEB/uu52RjwZVKwOX2QsZw POiXm1Zx8MxkIgGnt1Aek6tBL+clQoo8HfG4X2DmysCzAShUYyaqMucL0v3huIljNu4UIdovg 2LLnSHXi14WuKQTVurHfdJ8vQMXXjpneFNNgi25lz8sUG1gI2raij7cs46MGs/NHBREYYrnwT chZCKXK9Fj8+kAQE//311gWxPdaclh71Jsf6A7iPEWl7souRYw7nTkzZlVY7dLJTpaAPIq4Ud IkCVnv1DlEAHOPQ5MKk9P1dSI9Fd7M9CxpW4RJJBAj5at6vBYSiulAkGkXVmb+s0jd7at5Vnb HZSp58S61wFK6Lal49PzGK/iODsMfML69ISxULcv91jK1AgWYGN5BIw7qcEgmxN2LRRavy5mT koFN9QpqXZfGSTzHK0HAZOnkB3k1w== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > I couldn't think of any situation that would cause that. It would > require a resize of windows outside redisplay that would also cause > redisplay to decide that the mini-window needs to be resized. If you > can come up with a recipe for this, we should indeed remove the "just > once" promise. A silly example with emacs -Q is (defvar fun 0) (defun fun (frame) "..." (message "\n%s\n" (setq fun (1+ fun))) (ding)) (add-hook 'window-size-change-functions 'fun) This gets me complete erratic behavior when moving point. Another example is (defvar fun 0) (defun fun (frame) "..." (message "%s" (setq fun (1+ fun))) (ding)) (add-hook 'window-size-change-functions 'fun) (progn (tool-bar-mode -1) (sit-for 1) (tool-bar-mode 1)) With my patch for bug#21975 this runs =E2=80=98fun=E2=80=99 twice when th= e tool-bar is reenabled. Likely due to my calculations of the real tool bar height. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 22 13:44:11 2015 Received: (at 19576) by debbugs.gnu.org; 22 Nov 2015 18:44:11 +0000 Received: from localhost ([127.0.0.1]:48515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0ZcQ-0007pR-RL for submit@debbugs.gnu.org; Sun, 22 Nov 2015 13:44:11 -0500 Received: from smtprelay-h22.telenor.se ([195.54.99.197]:44716) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0ZcO-0007pJ-OC for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 13:44:09 -0500 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 8DCB1E1B8 for <19576@debbugs.gnu.org>; Sun, 22 Nov 2015 19:44:05 +0100 (CET) X-SMTPAUTH-B2: [bocjoh] X-SENDER-IP: [85.228.202.64] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ADBwDZC1JWOUDK5FVeGQEBAQELAQIBAQECgwuBADMPhl24NQENgWWGDwKBITkUAQEBAQEBAQYBAQEBFyo/hDUBAQMBViMQCyElDwEEGAEMChoTiCYMAb4BAQEBAQEFAQEBAR+LUoQohREFllCpfB8BAYRHPTSDYYFKAQEB X-IPAS-Result: A2ADBwDZC1JWOUDK5FVeGQEBAQELAQIBAQECgwuBADMPhl24NQENgWWGDwKBITkUAQEBAQEBAQYBAQEBFyo/hDUBAQMBViMQCyElDwEEGAEMChoTiCYMAb4BAQEBAQEFAQEBAR+LUoQohREFllCpfB8BAYRHPTSDYYFKAQEB X-IronPort-AV: E=Sophos;i="5.20,333,1444687200"; d="scan'208";a="1022054170" Received: from c-40cae455.04-211-6c6b701.cust.bredbandsbolaget.se (HELO muon.localdomain) ([85.228.202.64]) by ipb3.telenor.se with ESMTP; 22 Nov 2015 19:44:05 +0100 Received: by muon.localdomain (Postfix, from userid 1000) id 5A8224841BF; Sun, 22 Nov 2015 19:44:04 +0100 (CET) From: =?utf-8?Q?Johan_Bockg=C3=A5rd?= To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> <8337w39gj9.fsf@gnu.org> <83vb8y80pd.fsf@gnu.org> Date: Sun, 22 Nov 2015 19:44:04 +0100 In-Reply-To: <83vb8y80pd.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 19 Nov 2015 17:31:58 +0200") Message-ID: <877fl97u2z.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, Anders Lindgren X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Eli Zaretskii writes: >> The fact remains that a window where window-start equals point-max >> (i.e. a window displaying nothing) do recenter itself from time to >> time. > > I could only understand that if whatever you do following a call to > set-window-start includes resizing of windows or creation/deletion of > windows. Or maybe you meant editing in that window? Even then at > least the simple commands I tried don't do that. > > The display engine generally doesn't do anything unless the screen > should change. So if you work outside of the window whose starting > point you forced, Emacs should never do anything with that window. E.g. the following cause a recenter of *scratch*: emacs -Q M-: (set-window-start (selected-window) (point-max) t) RET C-x 2 Click mouse in other window or emacs -Q M-: (set-window-start (selected-window) (point-max) t) RET C-x 2 C-x o C-h i or emacs -Q M-: (set-window-start (selected-window) (point-max) t) RET Resize frame or... From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 22 13:55:47 2015 Received: (at 19576) by debbugs.gnu.org; 22 Nov 2015 18:55:47 +0000 Received: from localhost ([127.0.0.1]:48528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Zne-00088k-Fn for submit@debbugs.gnu.org; Sun, 22 Nov 2015 13:55:47 -0500 Received: from smtprelay-h22.telenor.se ([195.54.99.197]:45588) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Znb-00088a-Cd for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 13:55:44 -0500 Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id C551EEA15 for <19576@debbugs.gnu.org>; Sun, 22 Nov 2015 19:55:42 +0100 (CET) X-SMTPAUTH-B2: [bocjoh] X-SENDER-IP: [85.228.202.64] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2B0AwBpDlJW/0DK5FVeGQEBAQEPAQEBAYMLgTMPvxIBDYFlhg8CgSE5FAEBAQEBAQGBCkESAYNhAQEDASMzIwULCxoCBSECAg8BBBgBDCQTiCYMAa48j0YBAQEBBgEBAQEfgQGKUYd1gUQFllCpfB8BAUKEBT00g1iBUwEBAQ X-IPAS-Result: A2B0AwBpDlJW/0DK5FVeGQEBAQEPAQEBAYMLgTMPvxIBDYFlhg8CgSE5FAEBAQEBAQGBCkESAYNhAQEDASMzIwULCxoCBSECAg8BBBgBDCQTiCYMAa48j0YBAQEBBgEBAQEfgQGKUYd1gUQFllCpfB8BAUKEBT00g1iBUwEBAQ X-IronPort-AV: E=Sophos;i="5.20,333,1444687200"; d="scan'208";a="449479861" Received: from c-40cae455.04-211-6c6b701.cust.bredbandsbolaget.se (HELO muon.localdomain) ([85.228.202.64]) by ipb1.telenor.se with ESMTP; 22 Nov 2015 19:55:42 +0100 Received: by muon.localdomain (Postfix, from userid 1000) id 227CA4841BF; Sun, 22 Nov 2015 19:55:30 +0100 (CET) From: =?utf-8?Q?Johan_Bockg=C3=A5rd?= To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> <8337w39gj9.fsf@gnu.org> <83vb8y80pd.fsf@gnu.org> <877fl97u2z.fsf@gnu.org> Date: Sun, 22 Nov 2015 19:55:30 +0100 In-Reply-To: <877fl97u2z.fsf@gnu.org> ("Johan =?utf-8?Q?Bockg=C3=A5rd=22's?= message of "Sun, 22 Nov 2015 19:44:04 +0100") Message-ID: <87ziy56ezh.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, Anders Lindgren X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Johan Bockg=C3=A5rd writes: > or... emacs -Q M-: (set-window-start (selected-window) (point-max) t) RET C-x 2 C-x o C-s From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 22 14:02:11 2015 Received: (at 19576) by debbugs.gnu.org; 22 Nov 2015 19:02:11 +0000 Received: from localhost ([127.0.0.1]:48536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Ztq-0008Kq-Ga for submit@debbugs.gnu.org; Sun, 22 Nov 2015 14:02:10 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:39068) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0Zto-0008Ki-UK for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 14:02:09 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NY800500C70V600@mtaout26.012.net.il> for 19576@debbugs.gnu.org; Sun, 22 Nov 2015 21:05:04 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY8005QED0G6220@mtaout26.012.net.il>; Sun, 22 Nov 2015 21:05:04 +0200 (IST) Date: Sun, 22 Nov 2015 21:02:00 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <877fl97u2z.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Johan =?iso-8859-1?Q?Bockg=E5rd?= Message-id: <834mgd3ljr.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> <8337w39gj9.fsf@gnu.org> <83vb8y80pd.fsf@gnu.org> <877fl97u2z.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Johan Bockgård > Cc: Anders Lindgren , 19576@debbugs.gnu.org > Date: Sun, 22 Nov 2015 19:44:04 +0100 > > Eli Zaretskii writes: > > > I could only understand that if whatever you do following a call to > > set-window-start includes resizing of windows or creation/deletion of > > windows. Or maybe you meant editing in that window? Even then at > > least the simple commands I tried don't do that. > > > > The display engine generally doesn't do anything unless the screen > > should change. So if you work outside of the window whose starting > > point you forced, Emacs should never do anything with that window. > > E.g. the following cause a recenter of *scratch*: > > emacs -Q > M-: (set-window-start (selected-window) (point-max) t) RET > C-x 2 > Click mouse in other window > > or > > emacs -Q > M-: (set-window-start (selected-window) (point-max) t) RET > C-x 2 > C-x o > C-h i > > or > > emacs -Q > M-: (set-window-start (selected-window) (point-max) t) RET > Resize frame That's what I said (see above): resizing of windows or creation/deletion of windows can indeed cause recentering. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 23 13:21:24 2015 Received: (at 19576) by debbugs.gnu.org; 23 Nov 2015 18:21:24 +0000 Received: from localhost ([127.0.0.1]:49808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0vjv-0007rc-Nu for submit@debbugs.gnu.org; Mon, 23 Nov 2015 13:21:24 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:52781) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0vjs-0007rO-11 for 19576@debbugs.gnu.org; Mon, 23 Nov 2015 13:21:21 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NYA00J005HAUL00@a-mtaout22.012.net.il> for 19576@debbugs.gnu.org; Mon, 23 Nov 2015 20:21:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYA00JR15NIMF80@a-mtaout22.012.net.il>; Mon, 23 Nov 2015 20:21:18 +0200 (IST) Date: Mon, 23 Nov 2015 20:21:14 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <5651FF6B.90609@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83vb8szied.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5651A23A.3030907@gmx.at> <83ziy62gcw.fsf@gnu.org> <5651FF6B.90609@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 22 Nov 2015 18:46:19 +0100 > From: martin rudalics > CC: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, > juri@linkov.net > > > I couldn't think of any situation that would cause that. It would > > require a resize of windows outside redisplay that would also cause > > redisplay to decide that the mini-window needs to be resized. If you > > can come up with a recipe for this, we should indeed remove the "just > > once" promise. > > A silly example with emacs -Q is > > (defvar fun 0) > > (defun fun (frame) > "..." > (message "\n%s\n" (setq fun (1+ fun))) (ding)) > > (add-hook 'window-size-change-functions 'fun) > > This gets me complete erratic behavior when moving point. Maybe I'm blind, but I don't see anything erratic. > Another example is > > (defvar fun 0) > > (defun fun (frame) > "..." > (message "%s" (setq fun (1+ fun))) (ding)) > > (add-hook 'window-size-change-functions 'fun) > > (progn > (tool-bar-mode -1) > (sit-for 1) > (tool-bar-mode 1)) > > With my patch for bug#21975 this runs ‘fun’ twice when the tool-bar is > reenabled. Likely due to my calculations of the real tool bar height. I see that, but does that mean we should remove the "once only" promise? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 23 13:26:49 2015 Received: (at 19576) by debbugs.gnu.org; 23 Nov 2015 18:26:49 +0000 Received: from localhost ([127.0.0.1]:49818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0vpB-000838-0Z for submit@debbugs.gnu.org; Mon, 23 Nov 2015 13:26:49 -0500 Received: from mail.muc.de ([193.149.48.3]:39423) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0vp8-00082m-Th for 19576@debbugs.gnu.org; Mon, 23 Nov 2015 13:26:47 -0500 Received: (qmail 42153 invoked by uid 3782); 23 Nov 2015 18:26:45 -0000 Received: from acm.muc.de (p579E89A6.dip0.t-ipconnect.de [87.158.137.166]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 23 Nov 2015 19:26:44 +0100 Received: (qmail 9734 invoked by uid 1000); 23 Nov 2015 18:28:48 -0000 Date: Mon, 23 Nov 2015 18:28:48 +0000 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer Message-ID: <20151123182848.GF2004@acm.fritz.box> References: <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5651A23A.3030907@gmx.at> <83ziy62gcw.fsf@gnu.org> <5651FF6B.90609@gmx.at> <83vb8szied.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83vb8szied.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 19576 Cc: martin rudalics , 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hello, Eli and Martin. On Mon, Nov 23, 2015 at 08:21:14PM +0200, Eli Zaretskii wrote: > > Date: Sun, 22 Nov 2015 18:46:19 +0100 > > From: martin rudalics > > CC: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, > > juri@linkov.net > > > > > I couldn't think of any situation that would cause that. It would > > > require a resize of windows outside redisplay that would also cause > > > redisplay to decide that the mini-window needs to be resized. If you > > > can come up with a recipe for this, we should indeed remove the "just > > > once" promise. > > > > A silly example with emacs -Q is > > > > (defvar fun 0) > > > > (defun fun (frame) > > "..." > > (message "\n%s\n" (setq fun (1+ fun))) (ding)) > > > > (add-hook 'window-size-change-functions 'fun) > > > > This gets me complete erratic behavior when moving point. > Maybe I'm blind, but I don't see anything erratic. > > Another example is > > > > (defvar fun 0) > > > > (defun fun (frame) > > "..." > > (message "%s" (setq fun (1+ fun))) (ding)) > > > > (add-hook 'window-size-change-functions 'fun) > > > > (progn > > (tool-bar-mode -1) > > (sit-for 1) > > (tool-bar-mode 1)) > > > > With my patch for bug#21975 this runs ‘fun’ twice when the tool-bar is > > reenabled. Likely due to my calculations of the real tool bar height. > I see that, but does that mean we should remove the "once only" > promise? Or, alternatively, perhaps reconsider my proposed patch from a few days ago which has w-s-c-functions run at most once for any redisplay operation. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 24 03:28:03 2015 Received: (at 19576) by debbugs.gnu.org; 24 Nov 2015 08:28:03 +0000 Received: from localhost ([127.0.0.1]:50250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a18xH-00053Y-IZ for submit@debbugs.gnu.org; Tue, 24 Nov 2015 03:28:03 -0500 Received: from mout.gmx.net ([212.227.15.18]:59814) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a18xF-000531-IA for 19576@debbugs.gnu.org; Tue, 24 Nov 2015 03:28:02 -0500 Received: from [192.168.1.100] ([213.162.68.65]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M92ZJ-1aBL2901Xh-00CPuN; Tue, 24 Nov 2015 09:27:56 +0100 Message-ID: <56541F88.1060006@gmx.at> Date: Tue, 24 Nov 2015 09:27:52 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5651A23A.3030907@gmx.at> <83ziy62gcw.fsf@gnu.org> <5651FF6B.90609@gmx.at> <83vb8szied.fsf@gnu.org> In-Reply-To: <83vb8szied.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:6/hFXzGKmFZbhhWhc5nnxopg8mYo8HsFlbm6Wm8wec4QCwpGORR JtUUeWsRBI5U9NAh+ukMM6a7B2/eY94k2VLvU/UEwQG3K717usOTLkMs94IUDSCSr/HqtDb 0JS6zxjx1xB9192MgTsGxKmru0ZRg7lML33HFpPCEvDYmMDMe+hcyjZTiwHcWbZXhOvW2mf swo+av5wZGkFLzFLrphkA== X-UI-Out-Filterresults: notjunk:1;V01:K0:x57j0OSQXbg=:1CXC1ktZkggNIqOW4Y/af5 7cx3m6UzBRf5utEd7UBzwHUPRzUDI0rg3SmI4Qs0LhAXAd02lS8tJ5YPoNqmJmH4WrOYQJYgx atdgWQ+Bn76kBwIFClYufA3nNveD0QbLxmzFsQ26/Ksf/T1/iPMyO68b0rahBU3X6VuVQLlqd l6sVpkd1qwZxYLLEK5c6VG8H/Rc+gfKeMz1sXUY/1hyuOweX5hpQL9tbfowH3QHE3fCEX5UJ3 ka/rtp8YInSuWkHjFRqd0twsO5j0PVX7vyIuiBk+5gB6RXKvbOJoFXssrg1MsHxLxvvTOY5bu rV0z7Zk2geee86ErriHh5JTg1jdUROg5X6Z/9IZp7V8YH4ffwicrTNyyttYiTpd74z+BB3+Uh q7JDuBnwgWDRLY2dGZwBrZXoVZzZCfLWs5ilFBE5yguwp33RCN9trUbA2Ly2mxEjZjpUrZY9v gSYdoilrY51A8IVKRRtfTiGoidRCuMdZJKq54KDgxgGSc4RVeKrAOaIxyumIUbfok5FM/lGnd aP+AAvuXnHOzWDKw3aGCihjfwa2xMj9N8Yd8q7PMUJfmk+LefCSQmsHS4APpHNHzMRPqlgFEC oZhL3rHsdXHwYBSYFwIklK2bZiuXaUXegV+K5L/6kvyxVYhf5p+ZnwjPv1BujnaJIrKx3RvC0 HhTIoLufvGK1alyTw4nBHnmX2mH9t7XwqKzvuppsn2V2saIWI5nRgvjjlF9PtNoMoaIVTgrJ3 HnI1uCaUTnjpXokRbouwMXfTvsb3939KDkLtw/R+1p00YZ7mvCwg+iKSvLict0taRcZK3AWAv rVLUZFqE+aVNTf9CwNys4N9uKD/Ow== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) >> A silly example with emacs -Q is >> >> (defvar fun 0) >> >> (defun fun (frame) >> "..." >> (message "\n%s\n" (setq fun (1+ fun))) (ding)) >> >> (add-hook 'window-size-change-functions 'fun) >> >> This gets me complete erratic behavior when moving point. > > Maybe I'm blind, but I don't see anything erratic. OK. Here the erratic behavior is caused by =E2=80=98eldoc-mode=E2=80=99.= In any case =E2=80=98window-size-change-functions=E2=80=99 is executed twice per redi= splay IIUC. > I see that, but does that mean we should remove the "once only" > promise? I'd just remove the qualifier "just". martin From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 24 11:19:15 2015 Received: (at 19576) by debbugs.gnu.org; 24 Nov 2015 16:19:15 +0000 Received: from localhost ([127.0.0.1]:51555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1GJG-0001Gs-RL for submit@debbugs.gnu.org; Tue, 24 Nov 2015 11:19:15 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:46021) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1GJE-0001Gi-T2 for 19576@debbugs.gnu.org; Tue, 24 Nov 2015 11:19:13 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NYB00800UGP8R00@mtaout26.012.net.il> for 19576@debbugs.gnu.org; Tue, 24 Nov 2015 18:22:06 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYB003M3UST2550@mtaout26.012.net.il>; Tue, 24 Nov 2015 18:22:06 +0200 (IST) Date: Tue, 24 Nov 2015 18:19:10 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <56541F88.1060006@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <837fl7z7y9.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5651A23A.3030907@gmx.at> <83ziy62gcw.fsf@gnu.org> <5651FF6B.90609@gmx.at> <83vb8szied.fsf@gnu.org> <56541F88.1060006@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 24 Nov 2015 09:27:52 +0100 > From: martin rudalics > CC: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, > juri@linkov.net > > > I see that, but does that mean we should remove the "once only" > > promise? > > I'd just remove the qualifier "just". Feel free. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 28 05:26:36 2015 Received: (at 19576) by debbugs.gnu.org; 28 Nov 2015 10:26:36 +0000 Received: from localhost ([127.0.0.1]:57604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2ciB-0000Di-TB for submit@debbugs.gnu.org; Sat, 28 Nov 2015 05:26:36 -0500 Received: from mout.gmx.net ([212.227.17.20]:56321) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2ciA-0000DZ-EF for 19576@debbugs.gnu.org; Sat, 28 Nov 2015 05:26:34 -0500 Received: from [192.168.1.100] ([213.162.68.93]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LuwiT-1aSiBQ26zJ-0106bT; Sat, 28 Nov 2015 11:26:29 +0100 Message-ID: <5659814A.2040007@gmx.at> Date: Sat, 28 Nov 2015 11:26:18 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , acm@muc.de Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> In-Reply-To: <83k2pb4mc9.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:tQgmoHiM0Wv7aokmMo6hwB7LNa7paUxrxWG891nrCs6NQhDuXBs auPCA/GOQq2i9Ky+D2nmz8puAPob21tQFZbNQifHr0U8li3lEPE7JFOJwMVpr9/76QjHH7h MH+BVb/B/QhUBEmrAjenQM6NCV+dh3K83UrWgrBd3RdntfuvaZ/jsgEsGwPJXCcavbSZ0zS HEb+2mo3Vu60YZjnyNjEg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rhx98K5aaLs=:oa4RjzkbuOyE2ohVJAA677 8NxWxeSVKNJugJB1yUk2kNRXGw3xL+pp1f34uKEyvZqcGedxc42VNwF+dyrtW+I6k2Ly1r5d0 RDrF6opHJEx7dcW4HNak8N3PNjjRKl1NnU6aGcV8PhcYCiI+M9LojVZVf9YEuw1s+qRgtGTWv LpyQ54TbMaB9zV0C7aKYz6W5/AI1C64mIz/kAw8tf6ls1PAZANLX4mm4rNK2LaDGXFtRYR7Hl hY/t1oSRqM62t8d2gOLhDIyuaJq4w7IPrYQYo9juNJbz8W5yMoLg8zEnZWnOGX3UtRBttfo6e A5f0xOjUTLSYKfujmshW5g1v13awudC/LUsmQ1134iZFcJa3MMCoO2zuXpKcjFg0qRBhAkEwl 8zq1hkX61QVk5AcHeRAtaHAfjq5sa8S6fYRJha+E54XzJAj0epwtwVRaVw3S4snWZ+IHplWyD JzJEcr+ckBfmdC179glNnw4vToPo5Lo8nk669LD0NzXv3pIvvGe8lb6OBEiCjLv0ks7YkFLZy 5PWLmJTbVM5+vR/64U7f3VPdKCxacoWbFq+uID4G/4VIpa5aYt2XfJX/8j+xsE2BgZXXdhupM FL9m1WKgntNv0x34I49XJgglFFByCNk770mc8sM2G/DY7mVl0ccTRWZX+7TrQqOjnNCPtoJtf C+3y7hwcBKtSxjvxlkmxEGjGqypsPR1BStOuO7Z7ZQLLZAbPUUQXN5cs3e1iwBydyi12c2raw /q+JCl0H5nb31vBMYUAANCFJNBOhuCGRXfxAokX1oPLzbGxXznWsCzvdF62fEWOK/90Zz1906 JMgPGmuGaz5m+o8bRAgHZtJ9qmIUA== X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Please tell me if this bug and bug#21333 could now be closed, or if > there are any leftovers. Here with emacs -Q evaluating (message "...\n") [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.93 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 19576 Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Please tell me if this bug and bug#21333 could now be closed, or if > there are any leftovers. Here with emacs -Q evaluating (message "...\n") [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [213.162.68.93 listed in zen.spamhaus.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > Please tell me if this bug and bug#21333 could now be closed, or if > there are any leftovers. Here with emacs -Q evaluating (message "...\n") runs =E2=80=98window-size-change-functions=E2=80=99. Evaluating (read-file-name "...\n") doesn't. If this is intentional it should be documented. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 28 06:27:44 2015 Received: (at 19576) by debbugs.gnu.org; 28 Nov 2015 11:27:45 +0000 Received: from localhost ([127.0.0.1]:57614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2dfM-0001dd-HY for submit@debbugs.gnu.org; Sat, 28 Nov 2015 06:27:44 -0500 Received: from mtaout26.012.net.il ([80.179.55.182]:50119) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a2df1-0001dC-G2 for 19576@debbugs.gnu.org; Sat, 28 Nov 2015 06:27:42 -0500 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NYI00I00VQ8NP00@mtaout26.012.net.il> for 19576@debbugs.gnu.org; Sat, 28 Nov 2015 13:30:10 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYI008BPVYASP90@mtaout26.012.net.il>; Sat, 28 Nov 2015 13:30:10 +0200 (IST) Date: Sat, 28 Nov 2015 13:27:11 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <5659814A.2040007@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83si3qpdo0.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5659814A.2040007@gmx.at> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Sat, 28 Nov 2015 11:26:18 +0100 > From: martin rudalics > CC: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net > > > Please tell me if this bug and bug#21333 could now be closed, or if > > there are any leftovers. > > Here with emacs -Q evaluating > > (message "...\n") > > runs ‘window-size-change-functions’. Evaluating > > (read-file-name "...\n") > > doesn't. If this is intentional it should be documented. I don't know if it's intentional. Could you please look into this and publish what you find? I really could use some help here. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 30 08:40:57 2015 Received: (at 19576) by debbugs.gnu.org; 30 Nov 2015 13:40:57 +0000 Received: from localhost ([127.0.0.1]:60231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3OhN-0007M9-9n for submit@debbugs.gnu.org; Mon, 30 Nov 2015 08:40:57 -0500 Received: from mout.gmx.net ([212.227.15.18]:58341) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3OhL-0007Lz-Nt for 19576@debbugs.gnu.org; Mon, 30 Nov 2015 08:40:56 -0500 Received: from [192.168.1.100] ([213.162.68.23]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M6BKc-1aF0ZP2bYQ-00yCp5; Mon, 30 Nov 2015 14:40:49 +0100 Message-ID: <565C4F77.3040306@gmx.at> Date: Mon, 30 Nov 2015 14:30:31 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5659814A.2040007@gmx.at> <83si3qpdo0.fsf@gnu.org> In-Reply-To: <83si3qpdo0.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------070402080503050902060308" X-Provags-ID: V03:K0:ppw53bjxx28vi1nkyy76GcKLrQFFVVEmCzUL9fcqveAzn2aEzt0 DI37CRKgPm+R6U/AJrPQlOBl0MTLLifWKFkpNgJKt+2s5q0QYeVxhflh17GHHgMJrWCBQFE NrPGV/Uxdptn2lSHTI8OJx1uWVBzIi/LphFBShFTGaawkqPiezSsWaNbO5cDBAs6IT3TyZN L4gpGDsStmLYYeaEOGGMg== X-UI-Out-Filterresults: notjunk:1;V01:K0:U3Cmd9bEuFs=:weiToo9CIEVWtM7Aevg6kN C85fc1WRAn5cqe3XkRbM9x5yVed/Xszf2Jny7LdnFRGPEUxrg8ziJXbvYmg4mLPGxWiwOct6r jurj0xLBXpXIr5G2Uh8y5U5NmTwEQkS1IHNa7bFHGwyWEEi+/sRRyx65+3fmffVLbM3Ea9R3S qR8U9u/+vbmZEmFu/h5sfTJQqUjjFEniR9Z5sTx/cOslVUfacuaEf9i7eVc6baVKXUWQzmTkz P0N1vd3+Z0DkDyzsB7ExtL9/C0yN/3DbKDwtAAUxuq1Gt0SXltJa5AIbaRRI08aAJqVXpXOr9 5qJa31fdPVZ+VF8K65xvGAf6x4KPvGu2a0CLZVXQdIoY3X10OJ3YOikDQDLDg+2E5d8215sV6 LsEra79wSm3+M3jhNAdA1vElchwSa1QH6HaMe9d+b4J+zCEEDhVv3HLoYz7noN+/gAcP3llKc UjKg+wYzOtFmTL+eBqS4bCXQG+rXZadsHK9+gc7hvjhqyRaiEjNIMuHJXdiL5OE+Et8IJztGQ 2r0513qFYA/jhEmnBWVispHxAH7IRJ+s8NCMM7HE4jl2uCUctqXbmXFymb6pSeRQu9JA/TDLo mYVls1TrY3JKFjzNbetGZbbgSyfgSyL7gI2NwKZSxyTAOLwK3tJi20nMkAXWu6DwZyVq8Pq4H xkMyUqcvdb1Hv9aj+GlXbxpPe61n2qHGZ2nW1UTyva7sStvuDLd5fnwGJsDZi/YOlqNvAaMSz 3YSB3cMLsHg0Ob8Y5sOWCa1NtzecMTYob+tHfhCOHVvjVN1eRrj9o7wcfk75gYGCbQw74KRbv MRALQzd X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) This is a multi-part message in MIME format. --------------070402080503050902060308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable >> Here with emacs -Q evaluating >> >> (message "...\n") >> >> runs =E2=80=98window-size-change-functions=E2=80=99. Evaluating >> >> (read-file-name "...\n") >> >> doesn't. If this is intentional it should be documented. > > I don't know if it's intentional. Could you please look into this and= > publish what you find? I really could use some help here. The attached patch runs =E2=80=98window-size-change-functions=E2=80=99 fo= r any call of =E2=80=98read-from-minibuffer=E2=80=99 that changes the size of the minib= uffer window either via the prompt or user input. I have no idea whether it handles all possible cases nor whether it might baldy interact with the part that traces messages resizing the echo area. Also, saving match data around the =E2=80=98window-size-change-functions=E2= =80=99 calls and not saving current buffer and selected window constitutes a gross inconsistency IMHO. So I'd rather prefer to close my eyes to this part of the code, if possible. martin --------------070402080503050902060308 Content-Type: text/plain; charset=windows-1252; name="xdisp.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xdisp.diff" LS0tIGEvc3JjL3hkaXNwLmMKKysrIGIvc3JjL3hkaXNwLmMKQEAgLTEzNTgxLDYgKzEzNTgx LDI3IEBAIHJlZGlzcGxheV9pbnRlcm5hbCAodm9pZCkKIAkgICAmJiAoY3VycmVudF9idWZm ZXItPmNsaXBfY2hhbmdlZCB8fCB3aW5kb3dfb3V0ZGF0ZWQgKHcpKQogCSAgICYmIHJlc2l6 ZV9taW5pX3dpbmRvdyAodywgZmFsc2UpKQogICAgIHsKKyAgICAgIGlmIChzZi0+cmVkaXNw bGF5KQorCXsKKwkgIExpc3BfT2JqZWN0IGZ1bmN0aW9uczsKKwkgIHB0cmRpZmZfdCBjb3Vu dDEgPSBTUEVDUERMX0lOREVYICgpOworCisJICByZWNvcmRfdW53aW5kX3NhdmVfbWF0Y2hf ZGF0YSAoKTsKKworCSAgLyogQ2xlYXIgZmxhZyBmaXJzdCBpbiBjYXNlIHdlIGdldCBhbiBl cnJvciBiZWxvdy4gICovCisJICBGUkFNRV9XSU5ET1dfU0laRVNfQ0hBTkdFRCAoc2YpID0g ZmFsc2U7CisJICBmdW5jdGlvbnMgPSBWd2luZG93X3NpemVfY2hhbmdlX2Z1bmN0aW9uczsK KworCSAgd2hpbGUgKENPTlNQIChmdW5jdGlvbnMpKQorCSAgICB7CisJICAgICAgaWYgKCFF USAoWENBUiAoZnVuY3Rpb25zKSwgUXQpKQorCQljYWxsMSAoWENBUiAoZnVuY3Rpb25zKSwg c2VsZWN0ZWRfZnJhbWUpOworCSAgICAgIGZ1bmN0aW9ucyA9IFhDRFIgKGZ1bmN0aW9ucyk7 CisJICAgIH0KKworCSAgdW5iaW5kX3RvIChjb3VudDEsIFFuaWwpOworCX0KKwogICAgICAg LyogUmVzaXplZCBhY3RpdmUgbWluaS13aW5kb3cgdG8gZml0IHRoZSBzaXplIG9mIHdoYXQg aXQgaXMKICAgICAgICAgIHNob3dpbmcgaWYgaXRzIGNvbnRlbnRzIG1pZ2h0IGhhdmUgY2hh bmdlZC4gICovCiAgICAgICBtdXN0X2ZpbmlzaCA9IHRydWU7Cgo= --------------070402080503050902060308-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 30 11:29:19 2015 Received: (at 19576) by debbugs.gnu.org; 30 Nov 2015 16:29:20 +0000 Received: from localhost ([127.0.0.1]:33056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3RKJ-0003Hx-Ju for submit@debbugs.gnu.org; Mon, 30 Nov 2015 11:29:19 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:62517) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3RJz-0003HB-JX for 19576@debbugs.gnu.org; Mon, 30 Nov 2015 11:29:18 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NYM00M00Z3JJY00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Mon, 30 Nov 2015 18:28:58 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYM00M79Z499W60@a-mtaout20.012.net.il>; Mon, 30 Nov 2015 18:28:58 +0200 (IST) Date: Mon, 30 Nov 2015 18:28:52 +0200 From: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer In-reply-to: <565C4F77.3040306@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83fuznmoxn.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5659814A.2040007@gmx.at> <83si3qpdo0.fsf@gnu.org> <565C4F77.3040306@gmx.at> X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) > Date: Mon, 30 Nov 2015 14:30:31 +0100 > From: martin rudalics > CC: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, > juri@linkov.net > > >> Here with emacs -Q evaluating > >> > >> (message "...\n") > >> > >> runs ‘window-size-change-functions’. Evaluating > >> > >> (read-file-name "...\n") > >> > >> doesn't. If this is intentional it should be documented. > > > > I don't know if it's intentional. Could you please look into this and > > publish what you find? I really could use some help here. > > The attached patch runs ‘window-size-change-functions’ for any call of > ‘read-from-minibuffer’ that changes the size of the minibuffer window > either via the prompt or user input. I have no idea whether it handles > all possible cases nor whether it might baldy interact with the part > that traces messages resizing the echo area. Thanks, please push to the emacs-25 branch. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 30 12:27:47 2015 Received: (at 19576) by debbugs.gnu.org; 30 Nov 2015 17:27:47 +0000 Received: from localhost ([127.0.0.1]:33096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3SEt-0006Qr-3K for submit@debbugs.gnu.org; Mon, 30 Nov 2015 12:27:47 -0500 Received: from mout.gmx.net ([212.227.15.15]:62115) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a3SEZ-0006QC-Lk for 19576@debbugs.gnu.org; Mon, 30 Nov 2015 12:27:46 -0500 Received: from [192.168.1.100] ([213.162.68.23]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MAQXq-1aAe1e3hZS-00BYrf; Mon, 30 Nov 2015 18:27:25 +0100 Message-ID: <565C86F9.6060900@gmx.at> Date: Mon, 30 Nov 2015 18:27:21 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#19576: write-file writes the wrong buffer References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> <83lh9v9p7k.fsf@gnu.org> <20151118232304.GB1690@acm.fritz.box> <83mvua7z8k.fsf@gnu.org> <83k2pb4mc9.fsf@gnu.org> <5659814A.2040007@gmx.at> <83si3qpdo0.fsf@gnu.org> <565C4F77.3040306@gmx.at> <83fuznmoxn.fsf@gnu.org> In-Reply-To: <83fuznmoxn.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5Y2lIS/+LKP+5lljcEGU4pQtKBs4ROIgkN3IGGCdKcYjt47/gEo eHwlvBjkPK1DLve3oRP2Oyj8PszfXjyHVO5fb4g/RkW/tW/mXQ6A4639Iafgcl4dVlpIejV 4bnD+7hnARQ3UF1KSV27MglidQqZd9Sy+xQza3eaaRcggYsLIj3owsgjQjuJC3oLIjdxezY UJfCAACqyuw0JyZWfTyCg== X-UI-Out-Filterresults: notjunk:1;V01:K0:bJIlpyJ21aM=:wltULmR96o29QozS5G02Mj 3vbIaNBp5cesWfPzkT9zByob24NpOuGUnAMu9crGkML2KDdyFgSqh7U+SaVF0vKoAx+M2Ryxq B0I2bbtXHPQz/ZBTISChBjZYCPpc7PP5kUc3qNVJWgANqk0E4ldbB4euivhhSlwQW1ZHBaWMD 7uZw23qesGR+u+ipm7zUlleou+RMCoXaPUCgHkcEvjQJME9DpexcQo5ygaigQSWiAHHkLAFiT IMDqxbysIraIl2bBIrYOPpG8eOHC9qnTJ68jjcRNpsE9SdfhNUW5CFj6I2nzJxK6T7ExBcsa5 DmuBMfdj4tNippIQB0OqKea5j08ThcZyrZ7S1Y80Al4WMO+s1rKIZf1tJon8qD37vZDoyhiip tBMgwU7lrV4BsjUwd85Lkx+N5+AK6EEj8PypCK/3TMHOJU/5dv20aR0yqjhKx35zLEbB+4ktP RsOr1mZWxgslj7OMl9/AGUxYBE3nn9OplYFK5LWzJCItc99Q0jjfvWMOoEdnpT34npeAlctwZ gMI1X07oIktRJSfwbotDO9Hekd5Joh4+Ul1GT6oamwIvlYIh9PYTEcOMRKkHoLueaNj/RqKRj uOYFw7cvjscSacRiiAxwceWPoZwBSVcKjQXAGlWofPrKR6MY0gnkkNxA1BHAx2xuNOqCM1JeV vwzBxZS+cjp13bwbag0kuJeOUsmg74e35poxYVrJaVpvlAmi0X8NBRiZ5cZUizJp0eKQFomY6 oY0Vtwp7Lmp1bphdpNo0h2q1XDWmMuA+SqvAW2VuAR+rvJFY2to6MmlXymGM84D191LM5CtC5 BlYU3tiN3AZe7ip+mC3pY/uGv2lCw== X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 19576 Cc: acm@muc.de, 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) > Thanks, please push to the emacs-25 branch. Done. martin From unknown Mon Jun 23 20:16:32 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 29 Dec 2015 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator