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: Mon, 24 Aug 2015 22:03:13 +0300 Message-ID: <83twrofr0u.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1440443063 20865 80.91.229.3 (24 Aug 2015 19:04:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Aug 2015 19:04:23 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 24 21:04: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 1ZTx2R-0004p5-Rx for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Aug 2015 21:04:12 +0200 Original-Received: from localhost ([::1]:56164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTx2R-0003zr-BE for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Aug 2015 15:04:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTx2N-0003zl-Hx for bug-gnu-emacs@gnu.org; Mon, 24 Aug 2015 15:04:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTx2I-0004yd-Fj for bug-gnu-emacs@gnu.org; Mon, 24 Aug 2015 15:04:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTx2I-0004yZ-Bl for bug-gnu-emacs@gnu.org; Mon, 24 Aug 2015 15:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZTx2I-0007V6-0S for bug-gnu-emacs@gnu.org; Mon, 24 Aug 2015 15:04: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: Mon, 24 Aug 2015 19:04:01 +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.144044301128792 (code B ref 21333); Mon, 24 Aug 2015 19:04:01 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 19:03:31 +0000 Original-Received: from localhost ([127.0.0.1]:37237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTx1m-0007UK-65 for submit@debbugs.gnu.org; Mon, 24 Aug 2015 15:03:30 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:40377) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTx1j-0007U9-17 for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 15:03:28 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTL00700OPCX400@mtaout28.012.net.il> for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 22:03:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTL004H5OXJ4J40@mtaout28.012.net.il>; Mon, 24 Aug 2015 22:03:19 +0300 (IDT) In-reply-to: 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:105788 Archived-At: > Date: Mon, 24 Aug 2015 18:13:29 +0000 > From: Pip Cet > Cc: 21333@debbugs.gnu.org > > Sorry this is a long email There's long, and there's long. I mean, geeez.... > - Redisplay is so slow that it really doesn't matter that we call an > extra bit of Lisp code before running it. I'm not worried by performance aspects of this. And this hook doesn't slow down redisplay anyway, because redisplay just sets a flag. > - Doing it "my way" is cheap in terms of performance (I benchmarked), > easy to implement, enables cool but not necessarily useful hacks, but > requires very slow hook functions to rate-limit themselves in order to > keep the minibuffer usable. This is not about performance. It's about utility and complexity. Having to program for a system where your hook is called in umpteen unrelated situations makes your program much more complex and fragile than it could be if the hook was more accurate. > - Doing it your way is even cheaper in terms of performance, not very > hard to implement, requires those hacks to hook into > pre-redisplay-functions instead, and has the questionable benefit of > allowing badly-written non-rate-limiting hook functions to keep the > minibuffer usable, but still break drag-resizing. Once again, this is not about performance. > >> I cannot reproduce the behavior with other windows. > > > > See above: at least one other window is resized in this recipe, so the > > exemption is not about the mini-window itself, it's about any window > > involved in resizing in this particular scenario. > > I understand what's happening, but wanted to make clear that the > mini-window involvement is the decisive factor. No, it's not. The decisive factor is that the way this is implemented simply doesn't set the flag in this situation. IOW, the code to set it wasn't written. > > That said, I wonder whether changing the code now to call these > > functions due to automatic resizing would make sense. What would be > > the real-life use cases for using that? > > I am beginning to suspect I'm missing something here. Is there another > way for windows to find out they're resized? They are not resized, from my POV. > For example, I don't see another way to implement dynamic > fit-image-to-window applications. > > What I would consider a valid use case is to call > doc-view-fit-page-to-window if the window has been resized (of course, > a practical implementation would ensure that such automatic resize > operations would not cause a full re-rendering to happen upon every > size change, but that's an implementation detail). How is this different from something else, like a tooltip or a drop-down menu, temporarily obscuring a portion of the display? If you want to make the hook scroll the display when the minibuffer is resized, you will cause annoying jumpy display when some Lisp program repeatedly displays echo-area messages and clears the echo area -- for example, consider a Lisp compilation of a large buffer that produces many warnings. Moreover, you are worried by the last line of a PDF text, but what about the first one? When the window becomes smaller, some part will have to disappear from display, there's no way around that. Why should we care about the last portion more than about the first? > For something that's less far-fetched, I'm thinking of accessibility > and automation applications: if you want to point a screen reader to > the right text to read, you're going to need its X coordinates, which > might change due to a mini-window resize But the coordinates of the text that stays on screen don't change in such a resize. Some text is obscured, but what's left doesn't move. So I see no problem here. > Use cases: > 1. X hacks. I want to do something with the Emacs X windows and need > to know their coordinates to do so. EXWM, accessibility, compositing > WM hacks (transparency, duplicating windows, rendering them > upside-down, whatever), VNC clipping. Most of those are possible > without a reliable w-s-c-f hook, but are much easier to implement with > one. I'm not sure I understand the use case, but if I do, it's impossible: you need to have redisplay finish before you can ask Emacs about coordinates of some point. So this cannot be done while the minibuffer is being resized. > 2. automatic-resize applications. These, strictly speaking, need to > know only the window size, not its frame-relative position. Already covered above. I see no problems here that are specific to this particular resize. > 3. things I'm too stupid to think of. I think this is the big one: > let's leave the feature in and see what smart people come up with. That's not a use case. > You appear to be arguing for considering the mini-window a temporary > overlay that obstructs "real" windows while it exists and goes away > when it's no longer needed. That's fine, you can have that: create a > minibuffer-only frame and raise or lower it to your heart's content. > > I'm arguing that the mini-window should be treated like any other > window. I'm not special-casing the mini-window here. I'm special-casing this particular case of resizing the windows. > Let's also consider the potential harm done by both options: not > calling the hook when I think it should be will result in something > being done to the wrong buffer. I don't see why it should, not without a more detailed description. > Calling the hook "too often" will result, well, for most users, in > twenty lost CPU cycles as a variable is tested and found to be nil. Once again, this isn't about performance. > > If you agree, then the current behavior will make sense to you. > > I hope I've made it clear so far that I disagree. Then I guess we will have to agree to disagree. > > If anything, IMO we should _reduce_ the number of unrelated events > > that trigger a call to these functions. For example, currently any > > command that reads from the minibuffer will trigger it, because when > > read-from-minibuffer exits, it restores the window configuration by > > calling set-window-configuration, which is documented to trigger these > > functions. That just doesn't make any sense to me, since most reads > > from the minibuffer don't resize any windows! > > I believe that's a separate issue. No, it's not. It's the same issue: this hook is already called in situations where it shouldn't have been, and thus imposes on the programmers who use it complex ways of deciding whether there was or wasn't a change they should care about. You suggest to add one more situation in that class, something that most application that define this hook shouldn't and don't care. It's the complexity that worries me. > I do not understand why you seem so loath to calling a rarely-used > hook somewhat more often; I conjecture you might be overestimating the > cost of checking whether a window's size has actually changed and > returning if it hasn't. I've attached a test file that uses > benchmark-run to time a million invocations of the test-and-return > code, and it takes less than two seconds on this very old machine; > IOW, to take up 1% of one CPU core, you'd need 5000 resize events per > second. I can run `redisplay' 20,000 times per second, and that's only > because those calls return without doing anything. It's cheap. Once again, this is not about performance. Never was. It's about complexity, IMO gratuitous in this case. Emacs is already too complex for this kinds of job due to several hooks that are called indiscriminately, and leave it to the programmer to figure out whether some change really happened. Anyway, it's clear we disagree. I just wanted to voice my protest against such creeping featurism.