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

Previous Next

Full log

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

Previous Next

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