[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: Wed, 02 Jun 2010 14:59:42 +0200
User-agent: Thunderbird (Windows/20090302)

>> Maybe we also agree that we should show such a buffer when the window
>> was "stolen" by a construct like `with-temp-buffer'.
> with-temp-buffer is probably a poor example since it doesn't affect
> windows, but if you mean something like with-output-to-temp-buffer,

That's what I meant.

> then
> yes, we probably all agree.

Tracing `with-output-to-temp-buffer' is a pain.  I suppose
temp_output_buffer_show needs some reserved value for the second
argument of `display-buffer' so the latter can set up the window-local
buffer list appropriately.

> We can solve each case as it shows up.  E.g. for the split-window case
> (i.e. buffer shown in 2 windows only because that's what split-window
> does, but the user then immediately switches to some other buffer), we
> should try and find a way to capture the user's intention.

That's precisely the case I had in mind.  I have no idea how and why
people use `split-window'.  Hardly always to show the same buffer twice.
But I don't even know how I use it myself.

> E.g. "immediately" after split-window, any set-window-buffer will not
> push the current buffer on the buffer-list of that window.

Aren't there too many ways to make this `set-window-buffer' happen?  One
of the simplest is `next-buffer' which does `bury-buffer' for the old
buffer so it won't create any problems.  But what if the user decides to
consult some buffer switching application that pops up a window with

> I thought you suggested to have a config var to decide whether to use
> the current heuristic, or to use another heuristic which prefers buffers
> from the window's buffer-list regardless of whether they are
> shown elsewhere.  Isn't that what you meant in:
>    >> we should think about how we can tell which is
>    >> the better choice in a given situation.
>    > We could make this customizable.

Not really.  I want to avoid that changing the established behavior
causes people who do not care anyway ask for getting the old behavior
back.  If we make this customizable we can concentrate on the criticism
of people who really do care.


reply via email to

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