bug#13594: Planning Emacs-24.4

[martin rudalics]

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