[Top][All Lists]

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

Re: Window configurations

From: martin rudalics
Subject: Re: Window configurations
Date: Mon, 31 May 2010 19:28:21 +0200
User-agent: Thunderbird (Windows/20090302)

> In the functions `buffer-list' and `other-buffer' the buffers in the
> selected frame's `buffer-list' come first, followed by the rest of the
> buffers from the global value of `buffer-list', and buffers from the
> selected frame's parameters `buried-buffer-list' come last.
> Doing the same for the window-local parameter `buffer-list',
> i.e. when `buffer-list' will return a list composed of
>  window-local buffer-list
>  frame-local buffer-list
>  global buffer-list
>  frame-local buried-buffer-list
>  window-local buried-buffer-list
> then `quit-window' and all occurrences of `other-buffer'
> in window handling code should do the right thing like
> `view-return-to-alist' does (i.e. to get the right buffer).

I've been looking into this now.  `buffer-list' and `other-buffer' are
currently in pretty bad shape so it's occasionally difficult to tell
what they are supposed to do.  Anyway, the three major obstacles to your
approach seem:

(1) All calls to `other-buffer' for determining which buffer to show in
a window have the second argument nil.  So if a buffer is already shown
in another window it's against some unwritten rule to show it in the
window in question again.  If I follow that rule, then working with two
windows showing the same buffer remains just as tedious as it is now.

(2) The length of frame-local buffer-lists is unbound.  For a one-frame
user this already doubles the consing and maintenance overhead of buffer
lists without any gain.  If we add window-local buffer-lists, we'd
double the current overhead once more for one window/one frame users.

(3) For each buffer on the window-local buffer-list I'd have to maintain
its old point and its old window start position as markers.  Otherwise
restoring the buffer would either get me a silly position if the buffer
was modified in the meantime (a rare case probably, but unacceptable
nevertheless) or a useless position like `point' (which would usually
coincide with `window-point' of some other window showing that buffer).
This means that for each buffer we get as many additional markers as
there are live windows in which the buffer was shown (times two).


reply via email to

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