On Wed, Aug 26, 2015 at 1:01 PM, martin rudalics <
rudalics@gmx.at> 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
> ‘window-size-change-functions’ and afterwards (better when 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 ‘window-size-change-functions’ 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 ‘window-size-change-functions’ obsolete and suggest to
> use ‘pre-redisplay-function’ 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 ‘window-size-change-functions’ wouldn'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 != XFASTINT (p->pixel_left) ||
>> + w->pixel_top != XFASTINT (p->pixel_top) ||
>> + w->pixel_width != XFASTINT (p->pixel_width) ||
>> + w->pixel_height != 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