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: Wed, 26 Aug 2015 16:00:16 +0000 Message-ID: References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <55DDB8A2.8020606@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0158b2ce5f5dd0051e38f243 X-Trace: ger.gmane.org 1440604936 22506 80.91.229.3 (26 Aug 2015 16:02:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2015 16:02:16 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 26 18:02:01 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 1ZUd9C-0004dr-BN for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Aug 2015 18:01:58 +0200 Original-Received: from localhost ([::1]:39170 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUd9A-00035R-Pv for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Aug 2015 12:01:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUd8M-0001wV-GI for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 12:01:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUd8I-0004Ln-8L for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 12:01:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUd8I-0004Ld-3w for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 12:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUd8H-0007xe-MV for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 12:01: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: Wed, 26 Aug 2015 16:01: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.144060482230549 (code B ref 21333); Wed, 26 Aug 2015 16:01:01 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 16:00:22 +0000 Original-Received: from localhost ([127.0.0.1]:38968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUd7c-0007wd-SR for submit@debbugs.gnu.org; Wed, 26 Aug 2015 12:00:22 -0400 Original-Received: from mail-ig0-f172.google.com ([209.85.213.172]:36952) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUd7Z-0007wT-Ny for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 12:00:19 -0400 Original-Received: by igui7 with SMTP id i7so15304834igu.0 for <21333@debbugs.gnu.org>; Wed, 26 Aug 2015 09:00:17 -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=EIyuvhF0Yn/Hg+tKw7U7i8IkKHL16A2aqWKYWt92JhU=; b=rNuMEp5c+F6lIo6P3aaG1L+Szs3MvkhHCvYNBajpmJzTv8KaRG25jGQXx2KrY/rNGT r0i9uZBBstkVgczxWNeEzVybQ4u8M3Ml8hkIqqNgYuS5q1e4mNCxLjrdwskgVhtpneNL ltiTTQHVW0tFSTvUWYOyyK54xm56ZAjcDyXzIX5fv5tFpuQf5DLfi0lDcehV7Ywaa0/W cQM/JStuZnJb2vbBJdSPf4/9GNvhttLjKecFrC9hRxiG52XywvMTnnldBSFMEcV/8dnp NG1voWxO/eEmFuM3aSRZ6rjEKxCHaCpqSvhuIfgzIAdK9aP0xlxl3YXwjl6LlXB0bGU4 W94Q== X-Received: by 10.50.28.70 with SMTP id z6mr11330132igg.61.1440604816889; Wed, 26 Aug 2015 09:00:16 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Wed, 26 Aug 2015 09:00:16 -0700 (PDT) In-Reply-To: <55DDB8A2.8020606@gmx.at> 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:105840 Archived-At: --089e0158b2ce5f5dd0051e38f243 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2015 at 1:01 PM, martin rudalics wrote: >>>> So an alternative that doesn't need any hook is >>>> simply to recompute the coordinates every time they are needed. It's >>>> not like this calculation is expensive, is it? >>> >>> Correct. >> >> I disagree, if I understand correctly. > > My "correct" referred to Eli's "It's not like this calculation is > expensive, is it?". I suppose we all agree on that. We do. >> The coordinates might be passed >> to another program, for example, and then we simply don't know when >> that program decides to use them, so we still need a way to update our >> (and its) idea of what the window size and position is, in my opinion. > > I don't understand you here. IIUC Eli means that any application can > store the old coordinates somewhere and easily compare them to the > current ones in order to detect whether window sizes have changed. I understood Eli differently. If I'm not misquoting him, his suggestion was to "simply recompute the coordinates every time they are needed". My objection to that is that in many applications, you don't know when the coordinates will be needed without changing other programs. > Even simpler: We could store the sizes in the window structure. This > way prepare_menu_bars would simply walk the window tree of each frame to > detect whether the size of any window has changed, call the functions on > =E2=80=98window-size-change-functions=E2=80=99 and afterwards (better whe= n redisplay > completed) store the current size values into the old ones. Would (window-size) return the old or the new size values? > The > functions on the hook, OTOH, could check for each window individually > whether and how its size changed. The advantage of this approach is > that we never accumulate any fake size changes. Agreed. >>> So =E2=80=98window-size-change-functions=E2=80=99 is dispensable. >> >> Iff we keep/fix pre-redisplay-function, I agree. I had, wrongly, >> assumed that pre-redisplay-function is run many times per redisplay >> call, but that appears to be incorrect. The huge majority of >> redisplays call it just once, and that makes the overhead negligible. > > We can declare =E2=80=98window-size-change-functions=E2=80=99 obsolete an= d suggest to > use =E2=80=98pre-redisplay-function=E2=80=99 instead. Still we'd have to= support it for > quite some time. Is there consensus for keeping pre-redisplay-function? >> So what's the way forward, assuming my paperwork ever gets here? >> - document window-size-change-functions aren't called for mini-window >> resizes > > ... and maybe neither when the menu or tool bar wrap. > > Yes (if we decide to not change anything else). > >> - document window-configuration-change-hook isn't called for >> mini-window resizes > > No (because we nowhere say that `window-configuration-change-hook' is > called for resize operations). windows.texi: @defvar window-configuration-change-hook A normal hook that is run every time you change the window configuration of an existing frame. This includes splitting or deleting windows, *changing the sizes of windows*, or displaying a different buffer in a window. I think it's at least possible to read that as applying to window resize operations. >> - document set-window-configuration doesn't call >> window-size-change-functions if nothing changed > > No (because IIRC we never document fixed bugs). Are you sure? It occurs to me I should have said "remove the bit in the documentation that says window-size-change-functions is always called by set-window-configuration". It's not about documenting the bugfix, but undocumenting the old bug. >> - fix set_window_configuration not to set the window size change flag >> unless there was an actual size change > > Unless we decide to move that check to prepare_menu_bars as I sketched > above. And get rid of the window size change flag entirely. That's a good idea. >> - wishlist item: call pre-redisplay-function between >> grow/shrink_mini_window and the actual X repaint, rather than before. > > Are you sure? If prepare_menu_bars is called before auto-resizing the > minibuffer window, then =E2=80=98window-size-change-functions=E2=80=99 wo= uldn't catch > those auto-resizes either. That's why I consider it "wishlist". My Christmas wish is to be told whenever the X rectangle corresponding to my Emacs window has changed, just before the X server is told about the change. Should that be impossible? As far as I can tell, the documentation reads like it should be possible. At least some people make use of it, if in ways you probably think useless. I consider the documentation to be more authoritative than current behavior: if a feature should work according to the documentation, but doesn't, I think the right thing to do is almost always to fix the feature and then, afterwards, discuss whether it should be removed. >> - mark window-size-change-functions as obsolete and see whether >> anyone complains? > > This will happen if we don't provide a good subsitute. Wait, don't you mean that will happen if we do provide a good substitute? >> + if (w->pixel_left !=3D XFASTINT (p->pixel_left) || >> + w->pixel_top !=3D XFASTINT (p->pixel_top) || >> + w->pixel_width !=3D XFASTINT (p->pixel_width) || >> + w->pixel_height !=3D XFASTINT (p->pixel_height)) > > You still didn't explain why you find it necessary to compare the > pixel_left and pixel_top values. (Sorry, I missed that email initially! And thanks for pointing out my coding style typo, I'll try to be more careful in future.) I no longer do so. I think pre-redisplay-function, but not window-size-change-functions, should be told about a change in those values, so let's remove those checks. Reasons for calling pre-redisplay-function in these cases: Mouseover, if you need more than text properties give you. Cursor warping. X hacks. It's what the previous code did, so I didn't dare change it. One thing it occurs to me might be useful is an option to warp the mouse cursor when the echo area is resized, so you don't end up clicking the wrong link when the resize happens precisely at the wrong moment. An option I could live with, though it's not my preference, is to add a hook especially for mini-window resizes. Thank you again for spending so much time on this, Pip --089e0158b2ce5f5dd0051e38f243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 26, 2015 at 1:01 PM, martin rudalics <= rudalics@gmx.at>= ; wrote:
>>>> So an alternative that doesn't need any ho= ok is
>>>> simply to recompute the coordinates every time th= ey are needed.=C2=A0 It's
>>>> not like this calculation= is expensive, is it?
>>>
>>> Correct.
>><= br>>> I disagree, if I understand correctly.
>
> My "= ;correct" referred to Eli's "It's not like this calculati= on is
> expensive, is it?".=C2=A0 I suppose we all agree on that= .

We do.

>> The coordinates might be passed
>>= to another program, for example, and then we simply don't know when>> that program decides to use them, so we still need a way to updat= e our
>> (and its) idea of what the window size and position is, i= n my opinion.
>
> I don't understand you here.=C2=A0 IIUC E= li means that any application can
> store the old coordinates somewhe= re and easily compare them to the
> current ones in order to detect w= hether window sizes have changed.

I understood Eli differently. If I= 'm not misquoting him, his suggestion was to "simply recompute the= coordinates every time they are needed". My objection to that is that= in many applications, you don't know when the coordinates will be need= ed without changing other programs.

> Even simpler: We could stor= e the sizes in the window structure.=C2=A0 This
> way prepare_menu_ba= rs would simply walk the window tree of each frame to
> detect whethe= r the size of any window has changed, call the functions on
> =E2=80= =98window-size-change-functions=E2=80=99 and afterwards (better when redisp= lay
> completed) store the current size values into the old ones.
=
Would (window-size) return the old or the new size values?

> = =C2=A0The
> functions on the hook, OTOH, could check for each window = individually
> whether and how its size changed.=C2=A0 The advantage = of this approach is
> that we never accumulate any fake size changes.=

Agreed.

>>> So =E2=80=98window-size-change-function= s=E2=80=99 is dispensable.
>>
>> Iff we keep/fix pre-redi= splay-function, I agree. I had, wrongly,
>> assumed that pre-redis= play-function is run many times per redisplay
>> call, but that ap= pears to be incorrect. The huge majority of
>> redisplays call it = just once, and that makes the overhead negligible.
>
> We can d= eclare =E2=80=98window-size-change-functions=E2=80=99 obsolete and suggest = to
> use =E2=80=98pre-redisplay-function=E2=80=99 instead.=C2=A0 Stil= l we'd have to support it for
> quite some time.

Is there consensus for keeping pre-redisplay-function?

= >> So what's the way forward, assuming my paperwork ever gets her= e?
>> =C2=A0 - document window-size-change-functions aren't ca= lled for mini-window
>> resizes
>
> ... and maybe neit= her when the menu or tool bar wrap.
>
> Yes (if we decide to no= t change anything else).
>
>> =C2=A0 - document window-confi= guration-change-hook isn't called for
>> mini-window resizes>
> No (because we nowhere say that `window-configuration-change= -hook' is
> called for resize operations).

windows.texi:@defvar window-configuration-change-hook
A normal hook that is r= un every time you change the window configuration
of an existing frame.= =C2=A0 This includes splitting or deleting windows,
*changing the sizes = of windows*, or displaying a different buffer in a
window.

I think it's at least possible to read = that as applying to window resize operations.

>> =C2=A0 -= document set-window-configuration doesn't call
>> window-size= -change-functions if nothing changed
>
> No (because IIRC we ne= ver document fixed bugs).

Are you sure? It occurs to me I= should have said "remove the bit in the documentation that says windo= w-size-change-functions is always called by set-window-configuration".= It's not about documenting the bugfix, but undocumenting the old bug.<= br>

>> =C2=A0 - fix set_window_configuration not to set= the window size change flag
>> unless there was an actual size ch= ange
>
> Unless we decide to move that check to prepare_menu_ba= rs as I sketched
> above.

And get rid of the window= size change flag entirely. That's a good idea.

>&= gt; =C2=A0 - wishlist item: call pre-redisplay-function between
>>= grow/shrink_mini_window and the actual X repaint, rather than before.
&= gt;
> Are you sure?=C2=A0 If prepare_menu_bars is called before auto-= resizing the
> minibuffer window, then =E2=80=98window-size-change-fu= nctions=E2=80=99 wouldn't catch
> those auto-resizes either.
<= br>
That's why I consider it "wishlist". My Christmas wi= sh is to be told whenever the X rectangle corresponding to my Emacs window = has changed, just before the X server is told about the change.
Should that be impossible? As far as I can tell, the documentat= ion reads like it should be possible. At least some people make use of it, = if in ways you probably think useless.

I consider the doc= umentation to be more authoritative than current behavior: if a feature sho= uld work according to the documentation, but doesn't, I think the right= thing to do is almost always to fix the feature and then, afterwards, disc= uss whether it should be removed.

>> =C2=A0 - mark = window-size-change-functions as obsolete and see whether
>> anyone= complains?
>
> This will happen if we don't provide a good= subsitute.

Wait, don't you mean that will happen if = we do provide a good substitute?

>> + =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0if (w->pixel_left !=3D XFASTINT (p->pixel= _left) ||
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0w->pixel_top !=3D XFASTINT (p->pixel_top) ||
>> + =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0w->pixel_width !=3D = XFASTINT (p->pixel_width) ||
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0w->pixel_height !=3D XFASTINT (p->pixel_he= ight))
>
> You still didn't explain why you find it necessa= ry to compare the
> pixel_left and pixel_top values.
(Sorry, I missed that email initially! And thanks for pointing= out my coding style typo, I'll try to be more careful in future.)
<= /div>

I no longer do so. I think pre-redisplay-function,= but not window-size-change-functions, should be told about a change in tho= se values, so let's remove those checks.

Reasons for = calling pre-redisplay-function in these cases: Mouseover, if you need more = than text properties give you. Cursor warping. X hacks. It's what the p= revious code did, so I didn't dare change it.

One thi= ng it occurs to me might be useful is an option to warp the mouse cursor wh= en the echo area is resized, so you don't end up clicking the wrong lin= k when the resize happens precisely at the wrong moment.

= An option I could live with, though it's not my preference, is to add a= hook especially for mini-window resizes.

Than= k you again for spending so much time on this,
Pip
<= /div> --089e0158b2ce5f5dd0051e38f243--