GNU bug report logs - #8862
compilation-window-height no good anymore

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Nix <nix <at> esperi.org.uk>, 8862 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#8862: compilation-window-height no good anymore
Date: Wed, 15 Jun 2011 11:38:32 -0400

>> AFAIK, `enlarge-window' did not signal an error when the size was too
>> large, so I think it's best to keep being silent, for backward
>> compatibility's sake.
> OK.  I'll use the maximum possible height for enlarging and
> window-min-height/-width for shrinking.  The only cases where I signal
> an error are when the window is either fixed-size or the root window.

In Emacs-23, enlarge-window called on the root window doesn't seem to
signal an error either.  Maybe you'll be lucky and won't bump into bugs
resulting from such a change, but I think you'd be safer keeping the old
non-signaling behavior.
After all, you don't like enlarge-window anyway and can't really change
it into something you like, so you may as well keep it unchanged and
deprecate it in favor of something you like better.

> Agreed.  I tend to discourage using `enlarge-window' in ELisp because it
> only works on the selected window leading to things like compile.el's

> 	 ;; Stef said that doing the saves in this order is safer:
> 	 (save-excursion
> 	   (save-selected-window
> 	     (select-window window)
> 	     (enlarge-window (- height (window-height))))))))

Hmm... not sure why it doesn't use with-selected-window, but yes,
providing a `window' argument is even better.


        Stefan

Previous Next

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