Re: [RFC] Getting rid of selected_window

[Stefan Monnier]

> What for?  I don't think you can get rid of the need to synchronize
> those, because of features like focus redirection and minibuffer-only
> frames.

AFAIK these don't interact at all.  IOW they're unrelated.

> I don't understand what is the difference between Fselected_window and
> SELECTED_WINDOW.  Why do we use both in C?  It's confusing.

Indeed, it is confusing.  Part of the confusion comes from the current
code, tho.  This is an opportunity to clarify the code.

> SELECTED_WINDOW can return NULL, and then this dereference will
> segfault.

This is the crucial part of the difficulty: figure out which part of the
code needs to pay attention to the case where there's no selected-window yet.

I think SELECTED_WINDOW should never return NULL.  Instead, we should
have a new function to test if there is a selected-window, and call it
explicitly before SELECTED_WINDOW, at those rare places where such is needed.

> This changes the semantics of selected_window, because it requires
> that its frame be live.

Indeed the Fframe_live_p check shouldn't be in there.  If there are
places where such a check is needed, then let's add the check at those
specific places.

> So now we have SELECTED_BUFFER and current_buffer, which are
> different in unspecified ways.

Yes, we now have it, and this patch won't change that, other than giving
a name to the concept of "selected buffer".

> What do you think is the probability that someone will use the wrong
> one of that pair?  I think it's 100%.

That's already a risk and such errors already happen.  This said,
I think that instead of selected_buffer, we should use the name
selected_window_buffer, to make things more clear.


        Stefan