Subject: bug#13594: Planning Emacs-24.4

From: martin rudalics <[email-masked]>
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