bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode

[Leo]

On 2009-05-30 10:51 +0100, martin rudalics wrote:
>>> But I'm not sure whether this is a bug in calc or temp-buffer-resize-mode.
>>
>> Or neither, and simply unexpected behavior.
>> I've never used temp-buffer-resize-mode before, but if it's supposed to
>> make a window a better size for displaying a temporary buffer, I'm
>> surprised it doesn't change anything back when the buffer is killed or
>> hidden.
>
> Changing window sizes when `temp-buffer-resize-mode' exits is tricky.
> That is, we could restore the window configuration that existed when
> `temp-buffer-resize-mode' was started but that has the often unwanted
> side-effect that other windows created (deleted) in the meantime get
> deleted (resurrected).
>
>> In this case, I'm not sure it's Calc's job to keep track of why
>> it changed its window size.  Perhaps an option "Always start Calc with
>> the initial window height" might be helpful.
>
> Calc could make its windows fixed-size but that's hardly reasonable with
> the current handling of fixed-size windows.  Any option affecting only
> the initial size of Calc windows won't help in the present case either.
> We could give Calc window parameters, say ideal-height and ideal-width,
> and try to use these when exiting `temp-buffer-resize-mode' but writing
> the corresponding code won't be trivial.
>
> martin

I wonder if it may be possible to distinguish program or human changing
the size. In most cases, when a program (in this case:
temp-buffer-resize-mode) changes the size, it is hardly ideal to keep
that change. But I agree that for example, if a user drags the calc
window to be bigger, it is desirable to keep that change permanent.

At the moment I have to have (setq calc-window-height 7) at my finger
tip to get rid of the size change sometimes accidentally happens.

Leo