bug#13594: Planning Emacs-24.4

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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?

> 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.

> 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.

> 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).

> (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?

> (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.

>     When may-fail is not set, return the most suitable window.

If no window is found, there is no "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).


        Stefan