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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Tue, 19 Nov 2013 08:42:10 +0100

>>> t was just a value to stop display-buffer searching down the action
>>> list. this seems enough to manage display-buffer via
>>> display-buffer-alist or the like.
>> It is not.
>
> In which sense is it not?

To handle the case where the application is not able to correctly deal
with a nil return value.

>> Returning t when calling `display-buffer' without may-fail
>> set doesn't improve anything.
>
> Indeed, an FUNCTION that returns t when may-fail is not set is in error.
> But this has never happened so far, so I'm not sure it's terribly
> important to check it.

So far t was not a valid return value for `display-buffer' which was
supposed to "Return the window chosen for displaying BUFFER-OR-NAME, or
nil if no such window is found.".

>> And if my-fail is set, we can return nil
>> because the caller is prepared for it.
>
> t is the return value of the FUNCTION.  It can't be nil, since nil already
> means "try the next FUNCTION".  `display-buffer' can then take this
> t return value and turn it into a nil.

That's what Leo implemented now.  In fact, this handles the erroneous
case where a user action could return a non-nil, non-window value and
cause `display-buffer' to return it.

>> And you still don't handle the case where a user doesn't want to see
>> the buffer in the first place.
>
> I think his code does handle it (by having the FUNCTION return t without
> displaying the buffer).

I meant that he didn't explicitly write a function like
`display-buffer-no-window' as sketched by Juri.

>> (1) Provide two actions designators may-fail and do-fail, say.
>
> What would `do-fail' mean?  Is that a FUNCTION or an element of the ALIST?

ALIST elements.  `may-fail' stands for "the application is capable of
handling a non-window return value".  `do-fail' means `display-buffer'
should return nil when and if this ALIST element gets handled (thus was
not overridden by another action).  For example, an application could
propose to not display a buffer by default but let the user override it.

>> (2) When may-fail is set and no window is found, return nil.
>
> We already do that (regardless of `may-fail', actually).  But "no window
> is found" can pretty much never happen.

I agreed earlier that we need not handle this case.

>>     When may-fail is not set, return the most suitable window.
>
> If no window is found, there is no "most suitable window".

Emacs 23 had

		  (or (get-lru-window frame-to-use)
		      (let ((window (get-buffer-window buffer 'visible)))
			(unless (and not-this-window
				     (eq window (selected-window)))
			  window))
		      (get-largest-window 'visible)
		      (let ((window (get-buffer-window buffer 0)))
			(unless (and not-this-window
				     (eq window (selected-window)))
			  window))
		      (get-largest-window 0)
		      (frame-selected-window (funcall pop-up-frame-function))))

which made it really hard for a user to prevent finding a "most suitable
window" ;-)

>
>> (3) When may-fail and do-fail are both set, break the
>> 	(while (and functions (not window))
>> 	  (setq window (funcall (car functions) buffer alist)
>> 	  	functions (cdr functions)))
>>     loop in `display-buffer' (for example, by having the function called
>>     return 'fail) and return nil.
>
> That sounds cumbersome, compared to the simple solution he uses now of
> stopping when FUNCTION returns t (which the code already does, by virtue
> of stopping as soon as FUNCTION returns non-nil).

It would have just meant that a function like `display-buffer-no-window'
would have to return 'fail in order to confirm that it is aware of the
semantics of a thing like no-display-ok.

martin

Previous Next

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