Wrong window end reported after splitting window

Wrong window end reported after splitting window

[Juanma Barranquero]

Using linum.el showcases a bug in Emacs computation of a window's end.
Here's a simple test case from Markus Triska. Just save the code below
to problem.el and run

  emacs -q -l problem.el

The reported window end does not match the real one (as can be easily
determined with what-cursor-position or goto-char).

;;; problem.el starts here ;;;
(defun problem-show-end ()
  (message "Window end of buffer %s: %s"
           (buffer-name) (window-end (selected-window) t)))

(view-emacs-news)
(add-hook 'window-configuration-change-hook 'problem-show-end nil t)
(split-window)
(switch-to-buffer (get-buffer-create "test"))
(enlarge-window (- 8 (window-height)))
;;; problem.el ends here ;;;

             Juanma

Re: Wrong window end reported after splitting window

[martin rudalics]

 > ;;; problem.el starts here ;;;
 > (defun problem-show-end ()
 >   (message "Window end of buffer %s: %s"
 >            (buffer-name) (window-end (selected-window) t)))
 >
 > (view-emacs-news)
 > (add-hook 'window-configuration-change-hook 'problem-show-end nil t)
                                                                     ^
FWIW, here you add `problem-show-end' buffer-locally for NEWS.

 > (split-window)

Here NEWS is the current buffer and the actual value gets reported.

 > (switch-to-buffer (get-buffer-create "test"))

Here NEWS is no more current, no value gets reported.

 > (enlarge-window (- 8 (window-height)))
 > ;;; problem.el ends here ;;;

What you see is the value reported after splitting the window not after
enlarging it.

Re: Wrong window end reported after splitting window

[Juanma Barranquero]

On Sat, Feb 23, 2008 at 7:52 PM, martin rudalics <rudalics@gmx.at> wrote:

>  Here NEWS is no more current, no value gets reported.

Why should only the current buffer receive window change
notifications? The fact that the hook is added locally should not
affect that.

>  What you see is the value reported after splitting the window not after
>  enlarging it.

Which is an error, isn't it? Enlarging the window is a window
configuration change.

             Juanma

Re: Wrong window end reported after splitting window

[martin rudalics]

 > Why should only the current buffer receive window change
 > notifications? The fact that the hook is added locally should not
 > affect that.

What would be the purpose of making a hook buffer-local if not running
it for the current buffer only?

 >> What you see is the value reported after splitting the window not after
 >> enlarging it.
 >
 > Which is an error, isn't it? Enlarging the window is a window
 > configuration change.

Yes.  But since you deliberately made the hook buffer-local it won't get
run :-(

I suppose what you want is to investigate all affected windows when the
corresponding configuration changes.  This means we'd have to change
`delete-window', `enlarge-window', `shrink-window',
`adjust-window-trailing-edge' and `set-window-configuration' as to walk
all windows on the frame, check whether one of the associated buffers
has a non-nil local value for `window-configuration-change-hook', and
run that hook (in addition to a global hook).  The question here is what
to do when the same buffer is shown in two or more windows on the
affected frame - should we call the hook twice in that case?

BTW, did you try how `window-size-change-functions' behaves in this
regard?

Re: Wrong window end reported after splitting window

[Juanma Barranquero]

On Sat, Feb 23, 2008 at 11:36 PM, martin rudalics <rudalics@gmx.at> wrote:

>  What would be the purpose of making a hook buffer-local if not running
>  it for the current buffer only?

Being local is about which hook functions are set for a certain buffer
and which ones are not; not about when the hook is run (which depends
on the hook).

>  I suppose what you want is to investigate all affected windows when the
>  corresponding configuration changes.  This means we'd have to change
>  `delete-window', `enlarge-window', `shrink-window',
>  `adjust-window-trailing-edge' and `set-window-configuration' as to walk
>  all windows on the frame, check whether one of the associated buffers
>  has a non-nil local value for `window-configuration-change-hook', and
>  run that hook (in addition to a global hook).

That's the behavior I expected, yes.

>  BTW, did you try how `window-size-change-functions' behaves in this
>  regard?

No. The test case was from Markus, but I've just checked in a fix by
him to the problem with linum.el.

             Juanma

Re: Wrong window end reported after splitting window

[Stefan Monnier]

> I suppose what you want is to investigate all affected windows when the
> corresponding configuration changes.  This means we'd have to change
> `delete-window', `enlarge-window', `shrink-window',
> `adjust-window-trailing-edge' and `set-window-configuration' as to walk
> all windows on the frame, check whether one of the associated buffers
> has a non-nil local value for `window-configuration-change-hook', and
> run that hook (in addition to a global hook).

Indeed, it may be "too much work" but might be worth the trouble.
Otherwise buffer-local settings for window-configuration-change-hook
simply don't make any sense.

> The question here is what
> to do when the same buffer is shown in two or more windows on the
> affected frame - should we call the hook twice in that case?

The behavior of window-configuration-change-hook is clearly documented
as being run "once per frame", so the hook function are currently
responsible for cycling through  the windows  of the frame
if/when needded.
[ This doesn't rule out running the hook twice or more, tho, since we
  don't specifically say how careful Emacs should be in avoiding to run
  it redundantly. ]

Looking at it again, maybe the right thing to do is to make the
window-configuration-change-hook be treated differently for buffer-local
vs global settings: the global settings are run like now, but we also
cycle through the windows looking for buffer-local settings and we run
each one of them "once per window".

At least for image-mode and doc-view-mode's use of
window-configuration-change-hook, this would do the right thing.


        Stefan

Re: Wrong window end reported after splitting window

[martin rudalics]

 >>I suppose what you want is to investigate all affected windows when the
 >>corresponding configuration changes.  This means we'd have to change
 >>`delete-window', `enlarge-window', `shrink-window',
 >>`adjust-window-trailing-edge' and `set-window-configuration' as to walk
 >>all windows on the frame, check whether one of the associated buffers
 >>has a non-nil local value for `window-configuration-change-hook', and
 >>run that hook (in addition to a global hook).

 > Indeed, it may be "too much work" but might be worth the trouble.
 > Otherwise buffer-local settings for window-configuration-change-hook
 > simply don't make any sense.

I'm not sure whether buffer-local settings make sense at all.  You have
to walk windows anyway to find out which window is affected.  IMHO a
buffer-local hook makes sense here iff the affected window is passed as
argument.

 >>The question here is what
 >>to do when the same buffer is shown in two or more windows on the
 >>affected frame - should we call the hook twice in that case?
 >
 > The behavior of window-configuration-change-hook is clearly documented
 > as being run "once per frame", so the hook function are currently
 > responsible for cycling through  the windows  of the frame
 > if/when needded.

You mean they "should" be responsible?

 > [ This doesn't rule out running the hook twice or more, tho, since we
 >   don't specifically say how careful Emacs should be in avoiding to run
 >   it redundantly. ]

When I show the same buffer twice in the frame and run the hook twice
for the buffer how do I convey the feedback for _which_ window the hook
is run?  BTW, shall I run it for the buffers of deleted windows too?

 > Looking at it again, maybe the right thing to do is to make the
 > window-configuration-change-hook be treated differently for buffer-local
 > vs global settings: the global settings are run like now, but we also
 > cycle through the windows looking for buffer-local settings and we run
 > each one of them "once per window".

That's what I meant.
 >
 > At least for image-mode and doc-view-mode's use of
 > window-configuration-change-hook, this would do the right thing.

Please elaborate.

Re: Wrong window end reported after splitting window

[Stefan Monnier]

>>> I suppose what you want is to investigate all affected windows when the
>>> corresponding configuration changes.  This means we'd have to change
>>> `delete-window', `enlarge-window', `shrink-window',
>>> `adjust-window-trailing-edge' and `set-window-configuration' as to walk
>>> all windows on the frame, check whether one of the associated buffers
>>> has a non-nil local value for `window-configuration-change-hook', and
>>> run that hook (in addition to a global hook).

>> Indeed, it may be "too much work" but might be worth the trouble.
>> Otherwise buffer-local settings for window-configuration-change-hook
>> simply don't make any sense.

> I'm not sure whether buffer-local settings make sense at all.  You have
> to walk windows anyway to find out which window is affected.  IMHO a
> buffer-local hook makes sense here iff the affected window is passed as
> argument.

I was thining of passing it implicitly as the selected-window, just as
the selected-frame is passed implicitly for global
window-configuration-change-hooks.

>>> The question here is what
>>> to do when the same buffer is shown in two or more windows on the
>>> affected frame - should we call the hook twice in that case?
>> 
>> The behavior of window-configuration-change-hook is clearly documented
>> as being run "once per frame", so the hook function are currently
>> responsible for cycling through  the windows  of the frame
>> if/when needded.

> You mean they "should" be responsible?

No, they *are* responsible, i.e. they *should* do it.

>> [ This doesn't rule out running the hook twice or more, tho, since we
>> don't specifically say how careful Emacs should be in avoiding to run
>> it redundantly. ]

> When I show the same buffer twice in the frame and run the hook twice
> for the buffer how do I convey the feedback for _which_ window the hook
> is run?

See above.

> BTW, shall I run it for the buffers of deleted windows too?

I don't think it can be done (i.e. it would be a different hook).

>> At least for image-mode and doc-view-mode's use of
>> window-configuration-change-hook, this would do the right thing.

> Please elaborate.

They currently (incorrectly) use a buffer-local setting which needs to
be run whenever set-window-buffer is set to display those buffers (so
as to reset the [vh]scroll settings among other things).
Making the hook global would make the code work right, but with the
disadvantage that ...well... it would be global even though it's only
needed when/where those buffers are displayed.


        Stefan

Re: Wrong window end reported after splitting window

[martin rudalics]

 >>I'm not sure whether buffer-local settings make sense at all.  You have
 >>to walk windows anyway to find out which window is affected.  IMHO a
 >>buffer-local hook makes sense here iff the affected window is passed as
 >>argument.
 >
 > I was thining of passing it implicitly as the selected-window, just as
 > the selected-frame is passed implicitly for global
 > window-configuration-change-hooks.

This would make it impossible for the function to guess which window is
selected after the configuration change and/or set the selected window.
BTW `window-size-change-functions' also passes only the frame as
argument.  `window-scroll-functions' appears more intelligent.

 >>BTW, shall I run it for the buffers of deleted windows too?
 >
 > I don't think it can be done (i.e. it would be a different hook).

Not doing it would obscure the semantics considerably - the global hook
gets run when a window is deleted, the local one not.  To do it one
would obviously have to compare the configurations before and after the
operation.

 > They currently (incorrectly) use a buffer-local setting which needs to
 > be run whenever set-window-buffer is set to display those buffers (so
 > as to reset the [vh]scroll settings among other things).
 > Making the hook global would make the code work right, but with the
 > disadvantage that ...well... it would be global even though it's only
 > needed when/where those buffers are displayed.

We should carefully reevaluate these hooks and how they are used.  Maybe
it's better to provide a new hook then.

Re: Wrong window end reported after splitting window

[Stefan Monnier]

>> I was thining of passing it implicitly as the selected-window, just as
>> the selected-frame is passed implicitly for global
>> window-configuration-change-hooks.

> This would make it impossible for the function to guess which window is
> selected after the configuration change and/or set the selected window.

Right.  But note that even the global hook is not currently really able
to do that.  At least it can't guess and/or set the selected frame.
It hasn't been a problem AFAICT.  I don't think it's
a significant restriction.

> BTW `window-size-change-functions' also passes only the frame as
> argument.

Yup.  And it probably also fails to handle correctly buffer-local settings.

> `window-scroll-functions' appears more intelligent.

Because it does not apply to window-disposition so it only applies to
a single window at a time, so figuring out which buffer to consider is
immediately obvious.

>>> BTW, shall I run it for the buffers of deleted windows too?
>> I don't think it can be done (i.e. it would be a different hook).

> Not doing it would obscure the semantics considerably - the global hook
> gets run when a window is deleted, the local one not.

I'm not convinced it's a problem.  Again, it's a restriction but it's
not clear that it will pose problems for actual users.  After all, the
current competition is easy to beat: buffer-local settings just plain
fail to work reliably at all and they very much don't work for
window-deletion already.

>> They currently (incorrectly) use a buffer-local setting which needs to
>> be run whenever set-window-buffer is set to display those buffers (so
>> as to reset the [vh]scroll settings among other things).
>> Making the hook global would make the code work right, but with the
>> disadvantage that ...well... it would be global even though it's only
>> needed when/where those buffers are displayed.

> We should carefully reevaluate these hooks and how they are used.  Maybe
> it's better to provide a new hook then.

Maybe.


        Stefan