GNU bug report logs -
#13594
24.2.92; [PATCH] compilation-start doesn't consider nil OUTWIN
Previous Next
Reported by: Leo Liu <sdl.web <at> gmail.com>
Date: Thu, 31 Jan 2013 10:45:02 UTC
Severity: normal
Tags: patch
Found in version 24.2.92
Done: Leo Liu <sdl.web <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>> 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
This bug report was last modified 11 years and 234 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.