GNU bug report logs - #13594
24.2.92; [PATCH] compilation-start doesn't consider nil OUTWIN

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 08:55:44 -0500

>> Implemented as requested. I have also briefly tested with ggtags and it
>> worked.  Comments welcome.  Thanks.

Thank you.  Two comments:
1- You can/should use nil instead of `ignore'.
2- I'm not sure `may-fail' is the right name.  After all, it's not
   really a failure, but rather a conscious (and successful) decision to
   not display the buffer.  I don't have a good counter-proposition, tho
   ("no-display-ok" is what comes to my mind, but I don't like it too
   much either).

> Why didn't you implement the may-fail part?  IIUC `display-buffer'
> should *not* return nil unless may-fail has been set.  So if may-fail is
> not set, `display-buffer' should either create a new window, a new
> frame, or reuse some window at any cost.

AFAICT, display-buffer does already try pretty hard.  I think that if
display-buffer returns nil in a context where may-fail is nil, it's not
a bug in display-buffer but in some of the ACTIONS, and I see no reason
why `display-buffer' should try and cover up the problem.

> And there's no use for `display-buffer' returning t.

You mean, it should return nil (and never t) if the return value is not
a window?
I guess it would indeed be cleaner, yes,


        Stefan

Previous Next

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