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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#13594: 24.2.92;	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Sun, 17 Nov 2013 10:48:16 +0100

>> That's one possibility, yes.  Tho adding an argument doesn't sound
>> much fun.  So I'd prefer if it could be passed via ACTION.
>
> I have read this bug thread again. I am confused by this decision. Why
> do we want to tell display-buffer to do nothing (via ACTION or extra
> arg) when we can choose not to call it? Isn't not calling it better?

Stefan proposes to handle the case where the application wants to
display the buffer but `display-buffer' is not able to do so.  Ever
since, all callers of `display-buffer' I know of silently assumed that
the latter would display the buffer and return its window despite the
fact that it was possible that the buffer would not get displayed.

Stefan's proposal would correct that misunderstanding although now these
might result from the fact that if no argument is "passed via ACTION",
`display-buffer' could use the selected window, harming an application's
assumptions provided via setting inhibit-same-window to non-nil.  We at
least would have to document such fact but it's an "incompatible change"
nevertheless.  I think this is a minor evil and should be fairly rare as
well.

Now if an application and/or user do not want to display the buffer in
the first case, `display-buffer' should not be called.  If, however, the
call cannot be avoided, we should add a second (user) action which
avoids entering the loop in `display-buffer' and returns nil immediately
provided the first action was set (that is, the calling application at
least pretends to know how to handle a nil return value).

martin

Previous Next

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