[Top][All Lists]

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

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

From: Lennart Borgman
Subject: bug#6385: A slightly less aggressive fit-window-to-buffer
Date: Sat, 12 Jun 2010 15:03:22 +0200

On Sat, Jun 12, 2010 at 10:00 AM, martin rudalics <address@hidden> 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... ;-)

reply via email to

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