From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19576: write-file writes the wrong buffer Date: Wed, 18 Nov 2015 19:45:03 +0200 Message-ID: <83lh9v9p7k.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1447868843 31341 80.91.229.3 (18 Nov 2015 17:47:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Nov 2015 17:47:23 +0000 (UTC) Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net To: Alan Mackenzie , martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 18 18:47:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zz6p5-00067D-Ki for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 18:47:11 +0100 Original-Received: from localhost ([::1]:37299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz6p4-0003ho-V5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 12:47:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz6oz-0003hV-Sz for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 12:47:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz6ow-0000KP-MO for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 12:47:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz6ow-0000KJ-Ig for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 12:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zz6ow-0006pw-Cg for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 12:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Nov 2015 17:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19576 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19576-submit@debbugs.gnu.org id=B19576.144786876826187 (code B ref 19576); Wed, 18 Nov 2015 17:47:02 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 17:46:08 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <20151117200204.GA5054@acm.fritz.box> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108866 Archived-At: > 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;