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#21333: 25.0.50; window-size-change-functions not called after mini-window resize Date: Tue, 25 Aug 2015 18:11:46 +0300 Message-ID: <83pp2bfln1.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> 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 1440515928 5397 80.91.229.3 (25 Aug 2015 15:18:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Aug 2015 15:18:48 +0000 (UTC) Cc: pipcet@gmail.com, 21333@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 25 17:18:37 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 1ZUFzg-0006vE-Ie for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Aug 2015 17:18:36 +0200 Original-Received: from localhost ([::1]:60869 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUFzg-0004tP-3Q for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Aug 2015 11:18:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUFtO-0004cl-MH for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 11:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUFtK-0000wk-Ke for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 11:12:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUFtK-0000wf-IS for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 11:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUFtK-0005IQ-37 for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 11:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Aug 2015 15:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21333 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21333-submit@debbugs.gnu.org id=B21333.144051552120351 (code B ref 21333); Tue, 25 Aug 2015 15:12:02 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 25 Aug 2015 15:12:01 +0000 Original-Received: from localhost ([127.0.0.1]:38165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUFtI-0005IB-Jy for submit@debbugs.gnu.org; Tue, 25 Aug 2015 11:12:01 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:48004) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUFtG-0005I1-6S for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 11:11:59 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NTN008008CPEW00@a-mtaout20.012.net.il> for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 18:11:56 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTN008WS8VWF410@a-mtaout20.012.net.il>; Tue, 25 Aug 2015 18:11:56 +0300 (IDT) In-reply-to: <55DC1856.7000501@gmx.at> 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:105801 Archived-At: > Date: Tue, 25 Aug 2015 09:25:10 +0200 > From: martin rudalics > CC: pipcet@gmail.com, 21333@debbugs.gnu.org Before I respond to your comments, let me just clarify that what I say about this should not be interpreted as a veto of some kind. You are our window-management czar: if you think my objections should be overruled, by all means go ahead and make the changes. > >> Naively spoken it's obvious that when you shrink the minibuffer you show > >> more lines in the window above and ‘linum-mode’ has to add numbers for > >> those lines. And when you enlarge the minibuffer, ‘follow-mode’ will > >> lose some lines at the bottom of the left window and has to show them at > >> the top of the right window. > > > > In well-behaved modes this happens automatically, as part of > > redisplay. > > Via ‘pre-redisplay-function’? No, by arranging the buffer contents and letting redisplay do its job. Problems of this kind happen only when a mode changes buffer contents and related data structures (such as properties and overlays) in response to redisplay, something that is bad idea to begin with, because at the very least it immediately triggers another redisplay cycle, and kills many redisplay optimizations. > >> Maybe they use the ‘post-command-hook’ function instead. > > > > Of course, they do! The flag of bad design. > > IIUC they didn't have another choice before ‘pre-redisplay-function’ was > added. IMO, lack of infrastructure is not an excuse for bad design. Either the missing infrastructure should be added, or the design changed (if possible) to some better-behaving alternative. In extreme cases, the whole idea should be dropped as unworkable. > >> This is, in fact, an abuse of ‘set-window-configuration’. But how fix > >> it? We'd need a hook, say ‘window-size-change-functions’, that tracks, > >> among other things, whether a window was resized due to a change of the > >> minibuffer height and, if that happens, set a flag to indicate that the > >> window configuration must be restored. > > > > I'd say, don't set the "size changed" flag unless the size really > > changed. > > Sure. Nevertheless we would have to also track changes due to automatic > minibuffer resizing. As an option, perhaps. And it should be opt-in IMO, because most use cases shouldn't care about automatic resizing such as this one. > Alternatively, Fset_window_configuration could run a modified version of > ‘compare-window-configurations’ to compare the current configuration > with the one to be restored and restore the old configuration iff these > differ. I'm not sure whether this would be any cheaper, especially when > the configuration does change frequently. As I said too many times in this thread, performance is the last thing I care about in this respect.