bug#6385: A slightly less aggressive fit-window-to-buffer

[Lennart Borgman]

On Sat, Jun 12, 2010 at 10:00 AM, martin rudalics <rudalics@gmx.at> wrote:
>> What I saw was the even  2 lines high buffer made fit-window-to-buffer
>> delete sibling windows. All the time - but... I thought I knew how to
>> reproduce it. So I did not write any test procedures, I was just a bit
>> irritated. A mistake.
> [...]
>> This function killed all other siblings even if it just actually needs
>> two lines if certain conditions are met. (Those I tried to describe.)
>>
>> So this was just a desperate attempt to stop that. I do not know what
>> to do at the moment. I will try to reproduce this and look a bit
>> closer at it later.
>
> Deleting other windows when resizing was a misguided feature.  I don't
> do that any more for quite some time and didn't miss it yet ;-)

Did you rewrite fit-window-to-buffer or do you have another function for this?

> In any case, the issue whether a position is visible in a window is a
> priori not related to the issue whether resizing is allowed to delete
> any windows.  You patch might handle a few cases, accidentally ...

Yes, but what it handled was that it prevented a window to grow over
the buffers size.

But I do not know why the window grow bigger than the buffer. It is
just that after it happened to me ten times or so I throw in this
quick fix - and hoped that you had something more to say about it. If
I just had calmed down a bit and investigated it instead... ;-)