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

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

[Leo]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Packages such as calc or calendar that use a small window does not play
well with temp-buffer-resize-mode. i.e. their windows get enlarged by
temp-buffer-resize-mode. In the case of calc, the size change is
permanent.

1. Emacs -Q
2. (temp-buffer-resize-mode t)
3. M-x calc
4. h h

You will notice that calc-window-height is changed to a much larger
value. Calendar also has this similar problem but it can restore to its
default height after restarting itself.

GNU Emacs 23.0.94.1 (i386-apple-darwin9.7.0, NS apple-appkit-949.46) of
 2009-05-23 on 200.sub-75-216-116.myvzw.com

Best wishes,

Leo

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

[Jay Belanger]

> Packages such as calc or calendar that use a small window does not play
> well with temp-buffer-resize-mode. i.e. their windows get enlarged by
> temp-buffer-resize-mode. In the case of calc, the size change is
> permanent.

Calc keeps track of changes to its size, and restarts it in the last
size that it had.  Why is that a problem?

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

[Leo]

On 2009-05-30 00:46 +0100, Jay Belanger wrote:
>> Packages such as calc or calendar that use a small window does not play
>> well with temp-buffer-resize-mode. i.e. their windows get enlarged by
>> temp-buffer-resize-mode. In the case of calc, the size change is
>> permanent.
>
> Calc keeps track of changes to its size, and restarts it in the last
> size that it had.  Why is that a problem?

When temp-buffer-resize-mode is enabled, `C-h v' on a variable that has
2 or 3 lines of documentation will make the calc window takes up 70-80%
of the frame. See this screen shot http://imagebin.org/50896

It might be good to track the size, but when the size change is caused
by a program instead of the user, it can be annoying.

For example, when I'm editing some file and need some calculations, I'd
like calc to take up as little screen estate as possible so that the
file is visible to help me with the calculations.

But I'm not sure whether this is a bug in calc or temp-buffer-resize-mode.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

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

[Jay Belanger]

Leo <sdl.web@gmail.com> writes:
...
> 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.  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.

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

[martin rudalics]

 >> 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

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

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

[martin rudalics]

 > 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.

It can be done but it's not trivial.

 > 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.

In your use case it might make sense to set `split-height-threshold' to
a smaller value so the "other" window gets split instead of reused.
Alternatively we could allow `temp-buffer-resize-mode' to resize a
window iff it was obtained by splitting a window before.

martin

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

[Glenn Morris]

I winder if temp-buffer-resize-mode should only do its thing if the
window displaying the temp-buffer was created specifically to show
said buffer. If it was a pre-existing window, it should leave it
alone. ?

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

[Leo]

On 2009-05-30 19:21 +0100, Glenn Morris wrote:
> I winder if temp-buffer-resize-mode should only do its thing if the
> window displaying the temp-buffer was created specifically to show
> said buffer. If it was a pre-existing window, it should leave it
> alone. ?

This seems to imply that if before displaying the temp-buffer there's
only one window do the resize otherwise do nothing. This is better than
the default behaviour because temp-buffer-resize-mode is only useful in
very limited cases.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

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

[Leo]

On 2009-05-30 03:15 +0100, Jay Belanger wrote:
> 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.  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.

I have started looking for a workaround to save me doing (setq
calc-window-height 7) all the time. I am thinking of using
calc-end-hook, however it is located right in the middle of calc-quit.
So I cannot use the following:

    (add-hook 'calc-end-hook
              (lambda ()
                (setq calc-window-height 7)))

But it seems to me that moving the hook to the very end of calc-quit is
better than putting it in the middle. Do you recall any reason why this
is not the case? Thank you.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

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

[Jay Belanger]

Leo <sdl.web@gmail.com> writes:

> I have started looking for a workaround to save me doing (setq
> calc-window-height 7) all the time. I am thinking of using
> calc-end-hook, however it is located right in the middle of calc-quit.
> So I cannot use the following:
>
>     (add-hook 'calc-end-hook
>               (lambda ()
>                 (setq calc-window-height 7)))
>
> But it seems to me that moving the hook to the very end of calc-quit is
> better than putting it in the middle. Do you recall any reason why this
> is not the case? Thank you.

It is mentioned in the documentation that the hook is called early, so I
guess it was done on purpose.  I don't know why, though.

A workaround for now might be to define `my-calc' or `my-calc-dispatch'
with
(defun my-calc ()
   (interactive)
   (setq calc-window-heigth)
   (calc....))

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

[Leo]

On 2009-06-02 20:20 +0100, Jay Belanger wrote:
> It is mentioned in the documentation that the hook is called early, so I
> guess it was done on purpose.  I don't know why, though.
>
> A workaround for now might be to define `my-calc' or `my-calc-dispatch'
> with
> (defun my-calc ()
>    (interactive)
>    (setq calc-window-heigth)
>    (calc....))

I have disabled temp-buffer-resize-mode until it is properly
implemented. Thanks.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

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

[Leo]

On 2009-05-30 17:51 +0800, martin rudalics wrote:
[snipped 18 lines]
> 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

Is there a satisfactory solution in light of the new windowing features?

Leo

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

[martin rudalics]

 >> 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
 >
 > Is there a satisfactory solution in light of the new windowing features?

It depends on what you want.  You can resove the example in your
original posting

 > 1. Emacs -Q
 > 2. (temp-buffer-resize-mode t)
 > 3. M-x calc
 > 4. h h

by doing

(setq temp-buffer-max-height
       (lambda (buffer)
	(max
	 (window-total-size)
	 (/ (- (frame-height) 2) 2))))

in your .emacs (personally I think that this should be the default
value).  If you refer to Jay's remark

 > 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.

that is you want to get the *scratch* window back in its original size,
then typing "q" in the help window should do what you want.

martin

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

[Leo]

On 2011-10-25 00:15 +0800, martin rudalics wrote:
>> 1. Emacs -Q
>> 2. (temp-buffer-resize-mode t)
>> 3. M-x calc
>> 4. h h
>
> by doing
>
> (setq temp-buffer-max-height
>       (lambda (buffer)
> 	(max
> 	 (window-total-size)
> 	 (/ (- (frame-height) 2) 2))))
>
> in your .emacs (personally I think that this should be the default
> value).  If you refer to Jay's remark

Thanks, this seems to work well. But I am using a build from 2011-09-04.
Also I have noticed that `q' in calc no longer deletes all its windows.
So after hitting `q', I am left with three windows on the frame as shown
here: http://i.imgur.com/jFKG5.jpg.

Leo

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

[Jay Belanger]

Leo <sdl.web@gmail.com> writes:
...
> Thanks, this seems to work well. But I am using a build from 2011-09-04.
> Also I have noticed that `q' in calc no longer deletes all its windows.
> So after hitting `q', I am left with three windows on the frame as shown
> here: http://i.imgur.com/jFKG5.jpg.

I haven't been able to recreate this with a current build.
I tried it from a gnus buffer, as you did, and from the scratch
buffer.  I tried it with and without the temp-buffer adjustments that
martin mentioned.  Nothing in calc.el has changed since 2011-09-04,
either.
Is there anything special you did before you started and quit Calc?

Jay

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

[Leo]

On 2011-10-25 10:47 +0800, Jay Belanger wrote:
> I haven't been able to recreate this with a current build. I tried it
> from a gnus buffer, as you did, and from the scratch buffer. I tried
> it with and without the temp-buffer adjustments that martin mentioned.
> Nothing in calc.el has changed since 2011-09-04, either. Is there
> anything special you did before you started and quit Calc?

I have just tried it with the latest build and the problem is gone.

Leo

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

[Juri Linkov]

>> Is there a satisfactory solution in light of the new windowing features?
>
> It depends on what you want.  You can resove the example in your
> original posting
>
>> 1. Emacs -Q
>> 2. (temp-buffer-resize-mode t)
>> 3. M-x calc
>> 4. h h

When I type `M-x calc RET h h', it displays the *Help* window in the
Calc window that is too small to read comfortably the Help buffer.

That's because I have in .emacs:
(add-to-list 'same-window-buffer-names "*Help*")

Is it possible to display the Help buffer in another window in this case
when `h h' is typed in the Calc window?

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

[Jay Belanger]

Juri Linkov <juri@jurta.org> writes:
...
> When I type `M-x calc RET h h', it displays the *Help* window in the
> Calc window that is too small to read comfortably the Help buffer.
>
> That's because I have in .emacs:
> (add-to-list 'same-window-buffer-names "*Help*")
>
> Is it possible to display the Help buffer in another window in this case
> when `h h' is typed in the Calc window?

I'm not sure what you want, since you are explicitly telling Emacs to
display Help in the same window.  Is that line from your .emacs for some
other *Help* buffer, and you never want the Calc help to appear in the
same window?  Perhaps if the Calc help were named "*Calc Help*" (or
better, perhaps, using a variable to determine the name,
`calc-help-buffer-name' or somesuch).  That wouldn't be hard, but
perhaps should wait until after 24.1.

Jay

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

[Juri Linkov]

>> When I type `M-x calc RET h h', it displays the *Help* window in the
>> Calc window that is too small to read comfortably the Help buffer.
>>
>> That's because I have in .emacs:
>> (add-to-list 'same-window-buffer-names "*Help*")
>>
>> Is it possible to display the Help buffer in another window in this case
>> when `h h' is typed in the Calc window?
>
> I'm not sure what you want, since you are explicitly telling Emacs to
> display Help in the same window.  Is that line from your .emacs for some
> other *Help* buffer, and you never want the Calc help to appear in the
> same window?  Perhaps if the Calc help were named "*Calc Help*" (or
> better, perhaps, using a variable to determine the name,
> `calc-help-buffer-name' or somesuch).  That wouldn't be hard, but
> perhaps should wait until after 24.1.

Some modes bind `same-window-buffer-names' to nil when it makes no sense
to display the *Help* or *Info* buffer in the same window when it is
too small, thus overridding the user's settings.

IIUC, with the new window rules, the right way to do this is to bind
`display-buffer-overriding-action' to `display-buffer-pop-up-window'.
But this doesn't work as expected:

(let ((display-buffer-overriding-action '(display-buffer-pop-up-window)))
  (with-output-to-temp-buffer "*Help*"
    (princ "GNU Emacs Calculator.\n")))

It still displays the *Help* buffer in the same window when
(add-to-list 'same-window-buffer-names "*Help*") is presented in .emacs.

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

[martin rudalics]

 > Some modes bind `same-window-buffer-names' to nil when it makes no sense
 > to display the *Help* or *Info* buffer in the same window when it is
 > too small, thus overridding the user's settings.
 >
 > IIUC, with the new window rules, the right way to do this is to bind
 > `display-buffer-overriding-action' to `display-buffer-pop-up-window'.
 > But this doesn't work as expected:
 >
 > (let ((display-buffer-overriding-action '(display-buffer-pop-up-window)))
 >   (with-output-to-temp-buffer "*Help*"
 >     (princ "GNU Emacs Calculator.\n")))
 >
 > It still displays the *Help* buffer in the same window when
 > (add-to-list 'same-window-buffer-names "*Help*") is presented in .emacs.

I suppose because `display-buffer-pop-up-window' cannot split the window
due to `split-height-threshold' being too large.  You really just wanted
to add (inhibit-same-window . t) somewhere.

A related problem: With emacs -Q insert and evaluate in *scratch* the
form

(customize-set-variable
  'display-buffer-alist
  '(("\\*.*\\*" . (display-buffer-pop-up-frame . nil))))

move point to "alist" and type M-$.  Gets me

ispell-highlight-spelling-error-overlay: Marker points into wrong buffer

martin

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

[Stefan Monnier]

> You really just wanted to add (inhibit-same-window . t) somewhere.

That's my impression as well.


        Stefan

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

[Juri Linkov]

> I suppose because `display-buffer-pop-up-window' cannot split the window
> due to `split-height-threshold' being too large.  You really just wanted
> to add (inhibit-same-window . t) somewhere.

Thanks, this works as expected:

(let ((display-buffer-overriding-action '(display-buffer-reuse-window
                                          (inhibit-same-window . t))))
  (with-output-to-temp-buffer "*Help*"
    (princ "GNU Emacs Calculator.\n")))

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

[Stefan Monnier]

> (let ((display-buffer-overriding-action '(display-buffer-reuse-window
>                                           (inhibit-same-window . t))))

Better would be

> (let ((display-buffer-overriding-action '(nil (inhibit-same-window . t))))


-- Stefan

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

[Juri Linkov]

>> (let ((display-buffer-overriding-action '(display-buffer-reuse-window
>>                                           (inhibit-same-window . t))))
>
> Better would be
>
>> (let ((display-buffer-overriding-action '(nil (inhibit-same-window . t))))

Yes, this works too.

Looking at the available display actions in window.el, I found that
there are `display-buffer--other-frame-action' and the command
`display-buffer-other-frame' that uses it, but their counterpart
window functions are missing.

Copying these frame-related functions and replacing "frame" with "window"
in their names, produces two new functions:

(defvar display-buffer--other-window-action
  '((display-buffer-reuse-window
     display-buffer--special
     display-buffer-pop-up-window)
    (inhibit-same-window . t)))

(defun display-buffer-other-window (buffer)
  (interactive "BDisplay buffer in other window: ")
  (display-buffer buffer display-buffer--other-window-action))

I don't know why these window functions are omitted from window.el,
but the `display-buffer--other-window-action' would be useful for this case:

(let ((display-buffer-overriding-action display-buffer--other-window-action))
  (with-output-to-temp-buffer "*Help*"
    (princ "GNU Emacs Calculator.\n")))

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

[martin rudalics]

 > (defvar display-buffer--other-window-action
 >   '((display-buffer-reuse-window
 >      display-buffer--special
 >      display-buffer-pop-up-window)
 >     (inhibit-same-window . t)))

Isn't this the default behavior?  Try reusing a window showing the
buffer, try the special stuff, try popping up a new window, try reusing
another window?

martin

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

[Stefan Monnier]

>>> (let ((display-buffer-overriding-action '(display-buffer-reuse-window
>>> (inhibit-same-window . t))))
>> Better would be
>>> (let ((display-buffer-overriding-action '(nil (inhibit-same-window . t))))

> Looking at the available display actions in window.el, I found that
> there are `display-buffer--other-frame-action' and the command
> `display-buffer-other-frame' that uses it, but their counterpart
> window functions are missing.

We don't need them: inhibit-same-window works as well.


        Stefan

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

[Juri Linkov]

>> (defvar display-buffer--other-window-action
>>   '((display-buffer-reuse-window
>>      display-buffer--special
>>      display-buffer-pop-up-window)
>>     (inhibit-same-window . t)))
>
> Isn't this the default behavior?  Try reusing a window showing the
> buffer, try the special stuff, try popping up a new window, try reusing
> another window?

As I understand from window.el, the default behavior in
`display-buffer-fallback-action' is to try first
`display-buffer--maybe-same-window', that uses
`display-buffer-same-window' where a non-nil `inhibit-same-window'
prohibits it from using the same window.

BTW, do you think it's possible for `calc' to use a single
`display-buffer' call with a display action so that users could easily
override its default *Calc* window displaying behavior?

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

[martin rudalics]

 > BTW, do you think it's possible for `calc' to use a single
 > `display-buffer' call with a display action so that users could easily
 > override its default *Calc* window displaying behavior?

Do you mean that `calc' should call `display-buffer' with an appropriate
ACTION argument?  Here `calc' pops up two windows.  So even if this were
possible, it would constitute an abuse of `display-buffer'.

Or do you mean the display of calc's *Help* buffer?

martin

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

[Juri Linkov]

>> BTW, do you think it's possible for `calc' to use a single
>> `display-buffer' call with a display action so that users could easily
>> override its default *Calc* window displaying behavior?
>
> Do you mean that `calc' should call `display-buffer' with an appropriate
> ACTION argument?  Here `calc' pops up two windows.  So even if this were
> possible, it would constitute an abuse of `display-buffer'.
>
> Or do you mean the display of calc's *Help* buffer?

With the calc's *Help* buffer it's clear now that
(inhibit-same-window . t) is available for users
that have (add-to-list 'same-window-buffer-names "*Help*")
in .emacs.

But I meant that *Calculator* and *Calc Trail* windows could be
displayed with `display-buffer' and an appropriate ACTION argument.
Then users will be able to customize its default behavior.

Isn't it the goal of window related improvements to allow
customizing easily of how windows are displayed?

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

[Stefan Monnier]

> But I meant that *Calculator* and *Calc Trail* windows could be
> displayed with `display-buffer' and an appropriate ACTION argument.
> Then users will be able to customize its default behavior.

Can't they already do that with display-buffer-alist?

> Isn't it the goal of window related improvements to allow
> customizing easily of how windows are displayed?

Yes, but not only that: it should be possible without having to do
special gymnastics in the Elisp code.


        Stefan

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

[martin rudalics]

 >>> BTW, do you think it's possible for `calc' to use a single
 >>> `display-buffer' call with a display action so that users could easily
 >>> override its default *Calc* window displaying behavior?
[...]
 > But I meant that *Calculator* and *Calc Trail* windows could be
 > displayed with `display-buffer' and an appropriate ACTION argument.
 > Then users will be able to customize its default behavior.

We'd have to change the calling convention if we were to allow a "single
`display-buffer' call" to display both *Calculator* and *Calc Trail*.

 > Isn't it the goal of window related improvements to allow
 > customizing easily of how windows are displayed?

Yes.  But it's already quite tedious to achieve this goal for the one
buffer case (as in ispell, ibuffer, buff-menu or calendar).

martin

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

[Juri Linkov]

>> But I meant that *Calculator* and *Calc Trail* windows could be
>> displayed with `display-buffer' and an appropriate ACTION argument.
>> Then users will be able to customize its default behavior.
>
> Can't they already do that with display-buffer-alist?

`display-buffer-alist' can't undo splitting done outside of the
`display-buffer' call.  When splitting is done in a display action,
user can easily override it.  For instance, a new action
`display-buffer-pop-up-window-below' I posted in bug#9873
does splitting that users can override.  This action
can be used in `calendar-generate-window', and when I tested it,
I observe finally the ideal behavior of `M-x calendar RET'
in many different window configurations with this very small patch:

=== modified file 'lisp/calendar/calendar.el'
--- lisp/calendar/calendar.el	2011-10-30 08:29:56 +0000
+++ lisp/calendar/calendar.el	2011-11-03 19:36:29 +0000
@@ -1331,7 +1331,7 @@ (defun calendar-basic-setup (&optional a
         ;;
         ;; Is this a wide frame?  If so, split it horizontally.
         (if (window-splittable-p t) (split-window-right))
-        (pop-to-buffer calendar-buffer)
+        (pop-to-buffer calendar-buffer '(display-buffer-pop-up-window-below))
         ;; Has the window already been split vertically?
         (when (and (not (window-dedicated-p))
                    (window-full-height-p))

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

[Juri Linkov]

>> Isn't it the goal of window related improvements to allow
>> customizing easily of how windows are displayed?
>
> Yes.  But it's already quite tedious to achieve this goal for the one
> buffer case (as in ispell, ibuffer, buff-menu or calendar).

The goal can be achieved for calendar with the patch I sent in another
message.  For ibuffer and buff-menu I see no problem.  For ispell
I guess you mean your test case with `display-buffer-pop-up-frame'?
IIUC, ispell already supports displaying the choices in another frame
when `ispell-use-framepop-p' is non-nil, but it does this with
an unknown function `framepop-display-buffer'.

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

[Stefan Monnier]

>>> But I meant that *Calculator* and *Calc Trail* windows could be
>>> displayed with `display-buffer' and an appropriate ACTION argument.
>>> Then users will be able to customize its default behavior.
>> Can't they already do that with display-buffer-alist?
> `display-buffer-alist' can't undo splitting done outside of the
> `display-buffer' call.

I think I'm completely lost here.  What splitting are you talking about?


        Stefan

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

[Juri Linkov]

>>>> But I meant that *Calculator* and *Calc Trail* windows could be
>>>> displayed with `display-buffer' and an appropriate ACTION argument.
>>>> Then users will be able to customize its default behavior.
>>> Can't they already do that with display-buffer-alist?
>> `display-buffer-alist' can't undo splitting done outside of the
>> `display-buffer' call.
>
> I think I'm completely lost here.  What splitting are you talking about?

There is an explicit call to `split-window' in `calc'.
So users can't override it with `display-buffer-alist'.

With `split-window' implemented in a special action, users will be able
to override it with another action, e.g. an action that displays the
*Calc* buffer above the minibuffer, or below the selected window, etc.
(Currently *Calc* is displayed only in the largest window,
and this is not customizable yet).

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

[martin rudalics]

 > The goal can be achieved for calendar with the patch I sent in another
 > message.  For ibuffer and buff-menu I see no problem.

You mean doing the same as in calendar?  Things like

		  (lambda (buf)
		    (split-window nil height (eq type 'horizontally))
		    (other-window 1)
		    (switch-to-buffer buf)))

look suspicious because `switch-to-buffer' without FORCE-SAME-WINDOW set
can now make the behavior differently wrt Emacs 23.

 > For ispell
 > I guess you mean your test case with `display-buffer-pop-up-frame'?

No.  I mean the same as above.  More precisely

     (let ((choices-window (get-buffer-window ispell-choices-buffer)))
       ...
	;; Overlay *Choices* window when it isn't showing
	(ispell-overlay-window (max line ispell-choices-win-default-height)))
       (switch-to-buffer ispell-choices-buffer)
       (goto-char (point-min)))))

does strange things when `switch-to-buffer' does _not_ use the window
selected by `ispell-overlay-window'.  You can, for example, get an extra
window showing the initial buffer.

 > IIUC, ispell already supports displaying the choices in another frame
 > when `ispell-use-framepop-p' is non-nil, but it does this with
 > an unknown function `framepop-display-buffer'.

We have to rewrite ispell's window handling from scratch.

martin

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

[martin rudalics]

 > `display-buffer-alist' can't undo splitting done outside of the
 > `display-buffer' call.

We have to identify all cases where this happens and replace them
appropriately.

 > When splitting is done in a display action,
 > user can easily override it.  For instance, a new action
 > `display-buffer-pop-up-window-below' I posted in bug#9873
 > does splitting that users can override.

We have to make sure that it doesn't create too small windows.  Binding
`split-height-threshold' to zero might be too strong in some cases and
ignores user preferences.

martin

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

[Juri Linkov]

>> `display-buffer-alist' can't undo splitting done outside of the
>> `display-buffer' call.
>
> We have to identify all cases where this happens and replace them
> appropriately.

I agree.

>> When splitting is done in a display action,
>> user can easily override it.  For instance, a new action
>> `display-buffer-pop-up-window-below' I posted in bug#9873
>> does splitting that users can override.
>
> We have to make sure that it doesn't create too small windows.  Binding
> `split-height-threshold' to zero might be too strong in some cases and
> ignores user preferences.

In this case users can express preferences by customizing
`display-buffer-alist' to a different action.

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

[Stefan Monnier]

> 		  (lambda (buf)
> 		    (split-window nil height (eq type 'horizontally))
> 		    (other-window 1)
> 		    (switch-to-buffer buf)))

When performing such low-level setup of a window-configuration,
I recommend set-window-buffer.


        Stefan

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

[martin rudalics]

 >> We have to make sure that it doesn't create too small windows.  Binding
 >> `split-height-threshold' to zero might be too strong in some cases and
 >> ignores user preferences.
 >
 > In this case users can express preferences by customizing
 > `display-buffer-alist' to a different action.

Sure.  But we should also make sure that the standard behavior remains
unchanged.  Going through those "used to work for years" complaints is
no fun.

martin

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

[Jay Belanger]

>>>> BTW, do you think it's possible for `calc' to use a single
>>>> `display-buffer' call with a display action so that users could easily
>>>> override its default *Calc* window displaying behavior?
> [...]
>> But I meant that *Calculator* and *Calc Trail* windows could be
>> displayed with `display-buffer' and an appropriate ACTION argument.
>> Then users will be able to customize its default behavior.
>
> We'd have to change the calling convention if we were to allow a "single
> `display-buffer' call" to display both *Calculator* and *Calc Trail*.

Is that what Juri meant, or did he mean a single `display-buffer' for
each display action?  Currently, Calc uses `split-window' to set up 
*Calculator* and then a separate `split-window' to split the
*Calculator* window and use the new window for *Calc Trail* (or the
keypad).   Is the suggestion to replace both of these with a single
`display-buffer' or each `split-window' with a `display-buffer'?

Jay

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

[martin rudalics]

 > 1. Emacs -Q
 > 2. (temp-buffer-resize-mode t)
 > 3. M-x calc
 > 4. h h
 >
 > You will notice that calc-window-height is changed to a much larger
 > value. Calendar also has this similar problem but it can restore to its
 > default height after restarting itself.
 >
 > GNU Emacs 23.0.94.1 (i386-apple-darwin9.7.0, NS apple-appkit-949.46) of
 >  2009-05-23 on 200.sub-75-216-116.myvzw.com

With Emacs 24.3 `temp-buffer-resize-mode' should no longer resizes a window
that formerly showed another buffer.  Bug closed.

For any related problems that have been discussed in the thread of this
bug please make a new report.

Thanks, martin