From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet 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 18:13:29 +0000 Message-ID: References: <83k2skhhz1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=089e01182a341b415e051e129359 X-Trace: ger.gmane.org 1440440066 3898 80.91.229.3 (24 Aug 2015 18:14:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Aug 2015 18:14:26 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 24 20:14:13 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 1ZTwG3-0002T0-PP for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Aug 2015 20:14:12 +0200 Original-Received: from localhost ([::1]:55955 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTwG2-0005DC-Si for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Aug 2015 14:14:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTwFx-0005Cm-MO for bug-gnu-emacs@gnu.org; Mon, 24 Aug 2015 14:14:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTwFu-0000e6-9f for bug-gnu-emacs@gnu.org; Mon, 24 Aug 2015 14:14:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTwFu-0000dy-6u for bug-gnu-emacs@gnu.org; Mon, 24 Aug 2015 14:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZTwFt-0006Kg-O4 for bug-gnu-emacs@gnu.org; Mon, 24 Aug 2015 14:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Aug 2015 18:14: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.144044001524289 (code B ref 21333); Mon, 24 Aug 2015 18:14:01 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 24 Aug 2015 18:13:35 +0000 Original-Received: from localhost ([127.0.0.1]:37203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTwFR-0006Jg-Vk for submit@debbugs.gnu.org; Mon, 24 Aug 2015 14:13:35 -0400 Original-Received: from mail-ig0-f171.google.com ([209.85.213.171]:36767) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTwFO-0006JV-9l for 21333@debbugs.gnu.org; Mon, 24 Aug 2015 14:13:31 -0400 Original-Received: by igcse8 with SMTP id se8so54078822igc.1 for <21333@debbugs.gnu.org>; Mon, 24 Aug 2015 11:13:29 -0700 (PDT) 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=g2Jc43GBJvXckRC9mcnRJoOaWvIRDIau0fAKEnTL8pw=; b=B9OiE9fDcpkkOzOCyXvUwZzp+9L11C+IHVgFXApCuHwN2Bap9N8XAPYX9vzxzcVBJp 8fY7v+w17DoI6JIS+L2OXHjV4WsN3ccmYHzFLQgRuWU7wIkIEWVSz9voVN0jJm6nElKX EKpzuaYpi5TZRHnXt3BONwzAY96Cu/ocb7v1fg3cPV7ZBnVCj0KsVJw5yzCf74RtK1aj w5pggvkmIZc7fspXJfrUzfexfKZCGjqKqNkv7hSYLSH1ONjSTJGlUI44Xx0llOCVWmLi JJn2+8SSeU0DBZqvbMujHzAdHmb1kg1F1jPPtMhnW7A25EVMIv0lhAtUjMBZw7iHFOjv 8nRw== X-Received: by 10.50.17.9 with SMTP id k9mr16612964igd.93.1440440009817; Mon, 24 Aug 2015 11:13:29 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Mon, 24 Aug 2015 11:13:29 -0700 (PDT) In-Reply-To: <83k2skhhz1.fsf@gnu.org> 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:105785 Archived-At: --089e01182a341b415e051e129359 Content-Type: text/plain; charset=UTF-8 Thank you for your response! Sorry this is a long email, but I really, really want the full-featured window-size-change-functions. I understand if you don't have time to read it all, so let me summarize: - Redisplay is so slow that it really doesn't matter that we call an extra bit of Lisp code before running it. - 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. - 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. On Mon, Aug 24, 2015 at 2:35 PM, Eli Zaretskii wrote: >> Recipe: eval >> (progn (push (lambda (&rest args) (message "window size changed")) >> window-size-change-functions) >> (message (make-string 3000 ?*))) >> >> Expected result: a "window size changed" message. >> >> Actual result: no such message. >> >> The symptom is that the window size change function is not run after a >> mini-window size change. > > Note that resizing the mini-window involves resizing of at least one > other window on the same frame. So this is not exactly about the > mini-window. Noted. >> So far, I can produce this behavior only when the minibuffer or echo >> area grows to several lines; when it shrinks afterwards, my window size >> change function is called. > > I don't see the message even when the mini-window shrinks back. Are > you sure the message you see is not triggered by some other event? No, I'm not sure, and that turns out to be correct. Thanks for helping to clarify that point. > It's way too easy to trigger it, see below. I'm going to go into this in more detail, but I think that point can be restated as "since it's called frequently, in most cases, the hook function should return immediately after checking that the event isn't interesting", and I agree with that. >> 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. >> Is this a bug? The documentation says: >> >> [...] to be called if the size of any window changes for any reason. >> >> Please correct me if I'm wrong, but when the minibuffer/echo area gets >> resized (and the windows on top of it, too), that counts as a change of >> size, I would say. > > I believe the original reason for this is largely historical: > window-size-change-functions exists since Emacs 19.29, whereas > automatic resizing of mini-window was introduced in Emacs 21. Since > Emacs before 21 didn't have the mini-window resizing functionality, > Emacs 21 was careful not to gratuitously trigger these functions by > something that is purely a new redisplay feature. > > 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? There's pre-redisplay function, but I believe that is called far, far more often. The real-life use case I'm thinking of (which I'm not advocating as a good idea, but am advocating strongly as something that it should be possible to do) is EXWM, an X window manager written in Elisp that creates dummy buffers and dynamically maps X windows to cover their Emacs windows. But it seems to me every attempt to make an Emacs window's graphical representation fit in with its environment requires a way of knowing when that window is resized; and, if it wants to warp the mouse cursor (again, almost certainly not a good idea, but something that should be possible) it needs to know when its position within the frame changed, as well, since mouse coordinates are frame-relative. 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). I suspect you will object that in that case, there's no harm in the minibuffer temporarily hiding some of the document, but imagine reading the last line on a PDF page and, for some reason, deciding to type in some of that text into the minibuffer: the minibuffer would resize, obstructing the last line, and you could no longer see the text you're trying to type in. (Yes, it's somewhat far-fetched, but you're the one suggesting to change the documented behaviour of a feature to remove it once and for all, and I'm the conservative one arguing we should keep it.) 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 (either because you want the screen reader to read the mini-window contents, or because a window above the minibuffer is close to its minimum height and needs to move vertically to accomodate the growing mini-window). And if your accessibility utility is stupid (I understand most are) and only allows you to enter text by warping the mouse pointer and generating key press events, well, that's easy if you know how to update its idea of where to type. I can think of many X hacks that would probably be possible with or without window-size-change-functions, but much easier to implement with that hook: for example, while I doubt this could be made really secure (you'd have to synchronize with x11vnc), you could clip x11vnc to a given Emacs window without revealing the contents of the minibuffer to the remote viewer. 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. 2. automatic-resize applications. These, strictly speaking, need to know only the window size, not its frame-relative position. 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. > I believe window-size-change-functions is meant for taking notice of > resizes done by the user or some Lisp code, not for automated resizes > whose sole purpose is to allow some message be read in its entirety. I disagree with the notion that the possible applications of a software feature are limited to what I can think of beforehand :-) 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. That's what Emacs has historically implemented, it's still clearly reflected in the code, and as you yourself point out, auto-resizing affects all windows, not just mini-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. That's potentially disastrous, either because information is revealed that shouldn't be (my minibuffer extended into the VNC-shared window) or not accessible when it should be (while I specifically want the last line of my PDF to be visible at all times, the "temporary" minibuffer has covered it). In the case of EXWM, the mini-window will resize so the top of it is hidden underneath another X window, rendering echo area messages unreadable. 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. That's negligible. Those users that do have hooks, and specifically only want to do work if the normal size of the window changed, need one "equal" call to detect that window-normal-size hasn't changed and no work needs to be done. That's not quite as negligible, but on today's machines I think it's acceptable overhead to add to what's most likely a user-triggered action. That leaves a third group, that of users who have hooks and want them to do work only after explicit resizes, but wrote buggy code and accidentally called window-size instead of window-normal-size. While I sympathize with everyone who writes buggy code, I do not think that third group should be accommodated. > If you agree, then the current behavior will make sense to you. I hope I've made it clear so far that I 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. From my point of view, it makes sense to call our hook, since one window (the echo area) has been replaced by another (the minibuffer). 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. >> If this is merely a documentation issue, the exception should be noted >> in the manual. > > That's easy. Deciding what's TRT in this case is harder. Let's go for doing what the documentation says. I'm thinking of your implied proposal as two changes: 1. rip out the current feature 2. implement a new, crippled feature that satisfies some users of the old feature but not all of them. That's not "extensible". It's not conservative either, IMHO. Maybe it would be useful to add to the documentation of the hook an example of how to test whether a frame's current mini-window is at what the manual calls its "normal size", and to suggest that expensive hook functions not be run if it isn't. The exact code that does that is left as an exercise to the reader (i.e. I haven't figured it out yet). >> If this behavior is deliberate, I believe it is inconsistent to set >> FRAME_WINDOW_SIZES_CHANGED (f) in `resize-mini-window-internal'. > > It's consistent if we adopt the POV that this feature only catches > resizes from Lisp code. And those from explicit user interaction, yes. That's a valid POV but not, I think, the one we should adopt. Let me repeat that what I understand your POV to be is already fully accommodated by minibuffer-only frames: they're temporary and obstruct what's underneath them, but leave the window sizes in the real frame alone. The converse does not hold: if we remove the feature/fail to fix it, there's no good way to implement my bad ideas. Let's go for "extensible" and "customizable" over "negligibly faster". Sorry, again, that this email has gotten so long. (This is a separate issue, but on first reading it, the pre-redisplay-function(s) code seems like it would be a much better candidate for optimization and elimination, though that might require rewriting some of the simple.el code in C). Thank you again for responding, Pip --089e01182a341b415e051e129359 Content-Type: text/x-emacs-lisp; charset=US-ASCII; name="emacs-benchmark-013.el" Content-Disposition: attachment; filename="emacs-benchmark-013.el" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idq8s1sr0 KGRlZnZhciBteS1mcmFtZSAoc2VsZWN0ZWQtZnJhbWUpKQooZGVmdmFyIG15LXdpbmRvdyAoc2Vs ZWN0ZWQtd2luZG93KSkKKGRlZnZhciBteS1zaXplIG5pbCkKCihkZWZ1biB3LXMtYy1mIChmcmFt ZSkKICAoYW5kIChlcSBmcmFtZSBteS1mcmFtZSkKICAgICAgIChub3QgKGVxdWFsIChjb25zICh3 aW5kb3ctc2l6ZSBteS13aW5kb3cpICh3aW5kb3ctc2l6ZSBteS13aW5kb3cgdCkpCgkJICAgbXkt c2l6ZSkpCiAgICAgICAoc2V0cSBteS1zaXplIChjb25zICh3aW5kb3ctc2l6ZSBteS13aW5kb3cp ICh3aW5kb3ctc2l6ZSBteS13aW5kb3cgdCkpKSkpCgooc2V0cSB3aW5kb3ctc2l6ZS1jaGFuZ2Ut ZnVuY3Rpb25zIG5pbCkKKHB1c2ggIyd3LXMtYy1mIHdpbmRvdy1zaXplLWNoYW5nZS1mdW5jdGlv bnMpCihiZW5jaG1hcmstcnVuIDEwMDAwMDAgKGRvbGlzdCAoZiB3aW5kb3ctc2l6ZS1jaGFuZ2Ut ZnVuY3Rpb25zKSAoZnVuY2FsbCBmIChzZWxlY3RlZC1mcmFtZSkpKSkK --089e01182a341b415e051e129359--