GNU bug report logs - #3419
23.0.94; calc, calendar and temp-buffer-resize-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3419 in the body.
You can then email your comments to 3419 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 29 May 2009 20:03:11 +0100

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

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jay Belanger <jay.p.belanger <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Cc: jay.p.belanger <at> gmail.com
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 29 May 2009 18:46:44 -0500

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

Message #15 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Sat, 30 May 2009 02:43:35 +0100

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

Message #25 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jay Belanger <jay.p.belanger <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org, bug-gnu-emacs <at> gnu.org
Cc: jay.p.belanger <at> gmail.com
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 29 May 2009 21:15:34 -0500

Leo <sdl.web <at> 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.

Message #35 received at 3419 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: jay.p.belanger <at> gmail.com, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Sat, 30 May 2009 11:51:45 +0200

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

Message #40 received at 3419 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 3419 <at> debbugs.gnu.org, jay.p.belanger <at> gmail.com
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Sat, 30 May 2009 11:58:19 +0100

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

Message #45 received at 3419 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Leo <sdl.web <at> gmail.com>
Cc: 3419 <at> debbugs.gnu.org, jay.p.belanger <at> gmail.com
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Sat, 30 May 2009 14:19:32 +0200

> 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

Message #48 received at 3419 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Sat, 30 May 2009 14:21:59 -0400

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

Message #53 received at 3419 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Sat, 30 May 2009 23:37:33 +0100

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

Message #58 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: jay.p.belanger <at> gmail.com
Cc: 3419 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 02 Jun 2009 16:57:12 +0100

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

Message #73 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jay Belanger <jay.p.belanger <at> gmail.com>
To: Leo <sdl.web <at> gmail.com>
Cc: emacs-pretest-bug <at> gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 02 Jun 2009 14:20:45 -0500

Leo <sdl.web <at> 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....))

Message #83 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 02 Jun 2009 22:28:42 +0100

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

Message #93 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jay.p.belanger <at> gmail.com, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Mon, 24 Oct 2011 19:07:39 +0800

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

Message #96 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Leo <sdl.web <at> gmail.com>
Cc: jay.p.belanger <at> gmail.com, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Mon, 24 Oct 2011 18:15:57 +0200

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

Message #99 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 25 Oct 2011 10:17:04 +0800

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

Message #102 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Jay Belanger <jay.p.belanger <at> gmail.com>
To: Leo <sdl.web <at> gmail.com>
Cc: jay.p.belanger <at> gmail.com, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Mon, 24 Oct 2011 21:47:03 -0500

Leo <sdl.web <at> 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

Message #105 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: jay.p.belanger <at> gmail.com
Cc: 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 25 Oct 2011 23:20:40 +0800

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

Message #110 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 3419 <at> debbugs.gnu.org
Subject: Re: close 3419
Date: Sat, 29 Oct 2011 19:25:21 +0800

On 2011-10-29 12:55 +0800, Chong Yidong wrote:
> close 3419
> thanks

The original bug is still there. My last message was addressing another
problem popped up in the discussion.

Leo

Message #115 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Mon, 31 Oct 2011 12:34:05 +0200

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

Message #118 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Jay Belanger <jay.p.belanger <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: jay.p.belanger <at> gmail.com, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Mon, 31 Oct 2011 13:56:17 -0500

Juri Linkov <juri <at> 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

Message #121 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: jay.p.belanger <at> gmail.com
Cc: 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 01 Nov 2011 11:27:20 +0200

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

Message #124 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 01 Nov 2011 15:38:17 +0100

> 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

Message #127 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juri Linkov <juri <at> jurta.org>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 01 Nov 2011 16:00:46 -0400

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

That's my impression as well.


        Stefan

Message #130 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 01 Nov 2011 23:54:43 +0200

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

Message #133 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juri Linkov <juri <at> jurta.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Tue, 01 Nov 2011 21:21:53 -0400

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

Message #136 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: martin rudalics <rudalics <at> gmx.at>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Wed, 02 Nov 2011 11:35:39 +0200

>> (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")))

Message #139 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Wed, 02 Nov 2011 11:04:18 +0100

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

Message #142 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juri Linkov <juri <at> jurta.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Wed, 02 Nov 2011 08:37:01 -0400

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

Message #145 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 03 Nov 2011 11:05:45 +0200

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

Message #148 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 03 Nov 2011 11:07:13 +0100

> 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

Message #151 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 03 Nov 2011 12:17:34 +0200

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

Message #154 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juri Linkov <juri <at> jurta.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 03 Nov 2011 08:26:30 -0400

> 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

Message #157 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 03 Nov 2011 14:59:45 +0100

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

Message #160 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: martin rudalics <rudalics <at> gmx.at>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 03 Nov 2011 21:44:05 +0200

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

Message #163 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 03 Nov 2011 21:45:06 +0200

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

Message #166 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 03 Nov 2011 17:07:52 -0400

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

Message #169 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 04 Nov 2011 10:39:05 +0100

> 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

Message #172 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 04 Nov 2011 10:39:30 +0100

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

Message #175 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 04 Nov 2011 11:38:50 +0200

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

Message #178 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 04 Nov 2011 12:12:51 +0200

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

Message #181 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juri Linkov <juri <at> jurta.org>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 04 Nov 2011 09:12:59 -0400

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

Message #184 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Fri, 04 Nov 2011 14:55:49 +0100

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

Message #187 received at 3419 <at> debbugs.gnu.org (full text, mbox):

From: Jay Belanger <jay.p.belanger <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juri Linkov <juri <at> jurta.org>, jay.p.belanger <at> gmail.com,
	3419 <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Sun, 06 Nov 2011 15:09:03 -0600

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

Message #192 received at 3419-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 3419-done <at> debbugs.gnu.org
Subject: Re: bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode
Date: Thu, 04 Oct 2012 15:18:29 +0200

> 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

Previous Next

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