GNU bug report logs - #6385
A slightly less aggressive fit-window-to-buffer

Previous Next

Full log

View this message in rfc822 format

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 6385 <at> debbugs.gnu.org
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 <rudalics <at> 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... ;-)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.