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: Thu, 19 Nov 2015 18:03:39 +0200 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447949244 12974 80.91.229.3 (19 Nov 2015 16:07:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 16:07:24 +0000 (UTC) Cc: 19576@debbugs.gnu.org, andlind@gmail.com, juri@linkov.net To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 19 17:07:11 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 1ZzRjq-0007Sj-Sy for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 17:07:11 +0100 Original-Received: from localhost ([::1]:42672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRjq-0000pC-6B for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 11:07:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRjm-0000ob-4R for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 11:07:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzRji-0005UE-Nv for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 11:07:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRji-0005U8-KP for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 11:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZzRji-0001gt-1G for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 11:07: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: Thu, 19 Nov 2015 16:07:01 +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.14479491906413 (code B ref 19576); Thu, 19 Nov 2015 16:07:01 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 16:06:30 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <20151118232304.GB1690@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:108913 Archived-At: > 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.