[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wrong window end reported after splitting window

From: Stefan Monnier
Subject: Re: Wrong window end reported after splitting window
Date: Mon, 25 Feb 2008 11:09:31 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]