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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13594 in the body.
You can then email your comments to 13594 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2.92; [PATCH] compilation-start doesn't consider nil OUTWIN
Date: Thu, 31 Jan 2013 18:43:31 +0800

In building ggtags on top of compile.el, I have found one annoyance that
is I need to popup and immediately delete the compile window if there is
one or zero match, which is visually disturbing.

While finding my way to fix this annoyance, I discovered
compilation-start does not consider the case when OUTWIN is nil (which
is legitimate per the doc-string of `display-buffer').

        (setq outwin (display-buffer outbuf))

When OUTWIN is nil, all the subsequent window operations will be acting
on the wrong window.

(proposed patch attached)

Leo

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index f383e02b..13ef425f 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1616,7 +1616,7 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
       (set-buffer-modified-p nil))
     ;; Pop up the compilation buffer.
     ;; http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01638.html
-    (setq outwin (display-buffer outbuf))
+    (setq outwin (display-buffer outbuf)) ; Note: OUTWIN may be nil
     (with-current-buffer outbuf
       (let ((process-environment
 	     (append
@@ -1638,7 +1638,7 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
 	     (list command mode name-function highlight-regexp))
 	(set (make-local-variable 'revert-buffer-function)
 	     'compilation-revert-buffer)
-	(set-window-start outwin (point-min))
+	(and outwin (set-window-start outwin (point-min)))
 
 	;; Position point as the user will see it.
 	(let ((desired-visible-point
@@ -1647,15 +1647,16 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
 		   (point-max)
 		 ;; Normally put it at the top.
 		 (point-min))))
-	  (if (eq outwin (selected-window))
-	      (goto-char desired-visible-point)
-	    (set-window-point outwin desired-visible-point)))
+	  (when outwin
+	    (if (eq outwin (selected-window))
+		(goto-char desired-visible-point)
+	      (set-window-point outwin desired-visible-point))))
 
 	;; The setup function is called before compilation-set-window-height
 	;; so it can set the compilation-window-height buffer locally.
 	(if compilation-process-setup-function
 	    (funcall compilation-process-setup-function))
-	(compilation-set-window-height outwin)
+	(and outwin (compilation-set-window-height outwin))
 	;; Start the compilation.
 	(if (fboundp 'start-process)
 	    (let ((proc

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

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Thu, 31 Jan 2013 20:35:23 +0800

On 2013-01-31 18:43 +0800, Leo Liu wrote:
> (proposed patch attached)

All three instances of display-buffer in compile fails to account for
nil value. The following patch fix them all.


 lisp/progmodes/compile.el | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

	Modified lisp/progmodes/compile.el
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index f383e02b..09a2d9a2 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1616,7 +1616,7 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
       (set-buffer-modified-p nil))
     ;; Pop up the compilation buffer.
     ;; http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01638.html
-    (setq outwin (display-buffer outbuf))
+    (setq outwin (display-buffer outbuf)) ; Note: OUTWIN may be nil
     (with-current-buffer outbuf
       (let ((process-environment
 	     (append
@@ -1638,7 +1638,7 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
 	     (list command mode name-function highlight-regexp))
 	(set (make-local-variable 'revert-buffer-function)
 	     'compilation-revert-buffer)
-	(set-window-start outwin (point-min))
+	(and outwin (set-window-start outwin (point-min)))
 
 	;; Position point as the user will see it.
 	(let ((desired-visible-point
@@ -1647,15 +1647,16 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
 		   (point-max)
 		 ;; Normally put it at the top.
 		 (point-min))))
-	  (if (eq outwin (selected-window))
-	      (goto-char desired-visible-point)
-	    (set-window-point outwin desired-visible-point)))
+	  (when outwin
+	    (if (eq outwin (selected-window))
+		(goto-char desired-visible-point)
+	      (set-window-point outwin desired-visible-point))))
 
 	;; The setup function is called before compilation-set-window-height
 	;; so it can set the compilation-window-height buffer locally.
 	(if compilation-process-setup-function
 	    (funcall compilation-process-setup-function))
-	(compilation-set-window-height outwin)
+	(and outwin (compilation-set-window-height outwin))
 	;; Start the compilation.
 	(if (fboundp 'start-process)
 	    (let ((proc
@@ -2490,11 +2491,12 @@ (defun compilation-goto-locus (msg mk end-mk)
 	      (display-buffer (marker-buffer msg))))
 	 (highlight-regexp (with-current-buffer (marker-buffer msg)
 			     ;; also do this while we change buffer
-			     (compilation-set-window w msg)
+			     (and w (compilation-set-window w msg))
 			     compilation-highlight-regexp)))
     ;; Ideally, the window-size should be passed to `display-buffer'
     ;; so it's only used when creating a new window.
-    (unless pre-existing (compilation-set-window-height w))
+    (when (and (not pre-existing) w)
+      (compilation-set-window-height w))
 
     (if from-compilation-buffer
         ;; If the compilation buffer window was selected,
@@ -2605,9 +2607,9 @@ (defun compilation-find-file (marker filename directory &rest formats)
     (while (null buffer)    ;Repeat until the user selects an existing file.
       ;; The file doesn't exist.  Ask the user where to find it.
       (save-excursion            ;This save-excursion is probably not right.
-        (let ((pop-up-windows t))
-          (compilation-set-window (display-buffer (marker-buffer marker))
-                                  marker)
+        (let* ((pop-up-windows t)
+	       (w (display-buffer (marker-buffer marker))))
+          (and w (compilation-set-window w marker))
           (let* ((name (read-file-name
                         (format "Find this %s in (default %s): "
                                 compilation-error filename)

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Thu, 31 Jan 2013 10:14:13 -0500

> -    (setq outwin (display-buffer outbuf))
> +    (setq outwin (display-buffer outbuf)) ; Note: OUTWIN may be nil

`display-buffer' says:

   Return the window chosen for displaying BUFFER-OR-NAME,
   or nil if no such window is found.

which mostly means that it only returns nil if it couldn't find any
window to display the buffer, which is exceedingly rare.  Most/all
callers assume that display-buffer will display the buffer somewhere
(they sometimes disregard to return value, but when they don't they
almost systematically assume the return value is non-nil).

If you look further in the docstring you'll also see:

   Then it calls each function in the combined function list in turn,
   passing the buffer as the first argument and the combined alist as
   the second argument, until one of the functions returns non-nil.

Which again hints at the fact that nil is not treated as a valid return
value of display-buffer except when everything else failed.

IOW returning nil from display-buffer will inevitably bump into bugs.
Generally if you don't want to display a buffer, the best way to do that
is by not calling display-buffer.

So maybe the best approach is to extend compile.el such that it can be
told to do its job without displaying the compilation buffer.  If you do
that, try to take into account that this usage pattern could be useful
in other contexts than ggtags.el, for example users might prefer to not
see the compilation buffer and just be moved to the first error
automatically, and have C-x ` output the error message in the echo area
(maybe, accompanied by the number of errors left).


        Stefan

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

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Thu, 31 Jan 2013 23:21:41 +0800

On 2013-01-31 23:14 +0800, Stefan Monnier wrote:
> So maybe the best approach is to extend compile.el such that it can be
> told to do its job without displaying the compilation buffer.  If you do
> that, try to take into account that this usage pattern could be useful
> in other contexts than ggtags.el, for example users might prefer to not
> see the compilation buffer and just be moved to the first error
> automatically, and have C-x ` output the error message in the echo area
> (maybe, accompanied by the number of errors left).

Thanks, Stefan, for the detailed info. I will provide such patch in the
weekend.

Leo

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Tue, 05 Feb 2013 18:58:18 +0800

[Message part 1 (text/plain, inline)]

Hi Stefan,

On 2013-01-31 23:14 +0800, Stefan Monnier wrote:
> So maybe the best approach is to extend compile.el such that it can be
> told to do its job without displaying the compilation buffer.  If you do
> that, try to take into account that this usage pattern could be useful
> in other contexts than ggtags.el, for example users might prefer to not
> see the compilation buffer and just be moved to the first error
> automatically, and have C-x ` output the error message in the echo area
> (maybe, accompanied by the number of errors left).

The attached two patches (against emacs-24) implement:

1. A new variable compilation-dont-display-buffer to prevent calling
   display-buffer.

2. Display a message when calling compilation-next-error like this:
   Error: 2/623

Thanks for comments.

Leo

[0001-New-variable-compilation-dont-display-buffer.patch (text/x-patch, attachment)]

[0002-Display-current-error-rank-total.patch (text/x-patch, attachment)]

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Tue, 05 Feb 2013 19:57:51 +0800

On 2013-02-05 18:58 +0800, Leo Liu wrote:
> 2. Display a message when calling compilation-next-error like this:
>    Error: 2/623

Sadly this second patch doesn't account for the fact that some
compilation messages are removed later on by font-lock.

Leo

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

From: Juri Linkov <juri <at> jurta.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Wed, 06 Feb 2013 01:25:37 +0200

> 1. A new variable compilation-dont-display-buffer to prevent calling
>    display-buffer.

Some users of `async-shell-command' want the same feature of
not displaying the output buffer.  From the old discussion
I got the impression that such customization should be possible
by customizing `display-buffer-alist' and associating
the buffer name (such as *compilation* or *Async Shell Command*)
with an inaction to skip window display.

(But it still need to check `outwin' for null values in your patch
for the case when `display-buffer' will return nil.)

> 2. Display a message when calling compilation-next-error like this:
>    Error: 2/623

I think it would be nice to display the same in the mode line.

> Sadly this second patch doesn't account for the fact that some
> compilation messages are removed later on by font-lock.

`grep' used to remove parts of grep/compilation messages,
but now there shouldn't be such a problem in grep's font-lock.
Do you have a test case that would demonstrate this problem
in compilation's font-lock?

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

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Wed, 06 Feb 2013 09:19:51 +0800

[Message part 1 (text/plain, inline)]

On 2013-02-06 07:25 +0800, Juri Linkov wrote:
> Some users of `async-shell-command' want the same feature of
> not displaying the output buffer.  From the old discussion
> I got the impression that such customization should be possible
> by customizing `display-buffer-alist' and associating
> the buffer name (such as *compilation* or *Async Shell Command*)
> with an inaction to skip window display.

Would be nice to see how to do it using display-buffer-alist. From my
understanding and as Stefan suggested, the best thing to do is not to
call display buffer if the intention is not to display it.

>> 2. Display a message when calling compilation-next-error like this:
>>    Error: 2/623
>
> I think it would be nice to display the same in the mode line.

Yes I agree but let's get the count of errors right first.

>> Sadly this second patch doesn't account for the fact that some
>> compilation messages are removed later on by font-lock.
>
> `grep' used to remove parts of grep/compilation messages,
> but now there shouldn't be such a problem in grep's font-lock.
> Do you have a test case that would demonstrate this problem
> in compilation's font-lock?

I mean the 'compilation-message' property. In my second patch, the count
is based on each compilation-message properties inserted but it is
removed in, for example, these lines:

        Grep started at Wed Feb  6 09:11:06
        Grep finished (matches found) at Wed Feb  6 09:11:06

Here is the latest patches in one diff:
http://bpaste.net/show/npDaKs5Wvuk2AxSWgOiV

The total error count is still incorrect because (compilation-next-error
-1 nil (point-max)) doesn't find me the last real error but:

        Grep finished (matches found) at Wed Feb  6 09:11:06

[bug13594.png (image/png, attachment)]

[Message part 3 (text/plain, inline)]

Leo

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

From: Juri Linkov <juri <at> jurta.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Wed, 06 Feb 2013 12:12:34 +0200

> Would be nice to see how to do it using display-buffer-alist.

(add-to-list 'display-buffer-alist '("\\*compilation\\*" ignore-t (nil)))

where `ignore-t' is like existing `ignore' but returns t instead of nil:

(defun ignore-t (&rest _ignore)
  (interactive)
  t)

Maybe such trivial function already exists but with another name?

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Wed, 06 Feb 2013 10:35:31 -0500

> (add-to-list 'display-buffer-alist '("\\*compilation\\*" ignore-t (nil)))
> where `ignore-t' is like existing `ignore' but returns t instead of nil:
> (defun ignore-t (&rest _) t)

Problem is that the functions in display-buffer-alist are supposed to
return either the window they used or nil (to mean that display-buffer
should try the next candidate function).

So returning t is incorrect and can/will lead to bugs further down where
the caller does not expect a t value (most callers of display-buffer
don't expect a nil return value either).


        Stefan

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

From: Juri Linkov <juri <at> jurta.org>
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: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Thu, 07 Feb 2013 01:40:47 +0200

>> (add-to-list 'display-buffer-alist '("\\*compilation\\*" ignore-t (nil)))
>> where `ignore-t' is like existing `ignore' but returns t instead of nil:
>> (defun ignore-t (&rest _) t)
>
> Problem is that the functions in display-buffer-alist are supposed to
> return either the window they used or nil (to mean that display-buffer
> should try the next candidate function).
>
> So returning t is incorrect and can/will lead to bugs further down where
> the caller does not expect a t value (most callers of display-buffer
> don't expect a nil return value either).

Since there are more buffer names that users might want to not display
(e.g. "*Async Shell Command*") it makes sense to improve the
buffer-displaying framework with a new feature that would allow the user
to associate a buffer name with an inaction for which `display-buffer'
will return nil (since nil is a valid return value it's a bug when callers
of `display-buffer' don't check for nil, these callers should be fixed).

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Thu, 07 Feb 2013 08:36:56 -0500

> will return nil (since nil is a valid return value it's a bug when callers
> of `display-buffer' don't check for nil, these callers should be fixed).

It's a valid return value, but only when display-buffer is *unable to
display the buffer*.  It is *very* rare to be unable to do so.  E.g. it
will never happen unless at least one of pop-up-frame-function or
display-buffer-fallback-action is changed.

So it's no wonder that most callers don't bother checking for a nil
return value.

Maybe a way around that is to use a special window that's never
displayed.  But that might introduce more trouble than it's trying
to solve.


        Stefan

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

From: Juri Linkov <juri <at> jurta.org>
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: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Fri, 08 Feb 2013 10:10:17 +0200

> It's a valid return value, but only when display-buffer is *unable to
> display the buffer*.  It is *very* rare to be unable to do so.  E.g. it
> will never happen unless at least one of pop-up-frame-function or
> display-buffer-fallback-action is changed.

Trying to do (setq display-buffer-fallback-action nil)
and `M-x compile RET' goes to re-arrange the wrong window
(that displays "*scratch*" in `emacs -Q') because the nil WINDOW arg
of `set-window-start' defaults to the selected window,  so yes,
a nil value is not a good thing to return from display-buffer.

> Maybe a way around that is to use a special window that's never
> displayed.  But that might introduce more trouble than it's trying
> to solve.

Trying to use an internal window:

(add-to-list 'display-buffer-alist '("\\*compilation\\*" display-buffer-ignore (nil)))
(defun display-buffer-ignore (&rest _ignore) (frame-root-window))

fails with `(wrong-type-argument window-live-p #<window 0x286f258>)',
so this is not possible to do without changes to the window framework
to add a new window type for live hidden windows.

Message #44 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: Juri Linkov <juri <at> jurta.org>, 13594 <at> debbugs.gnu.org,
	Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;	[PATCH] compilation-start doesn't consider
	nil OUTWIN
Date: Fri, 08 Feb 2013 10:59:48 +0100

> It's a valid return value, but only when display-buffer is *unable to
> display the buffer*.  It is *very* rare to be unable to do so.  E.g. it
> will never happen unless at least one of pop-up-frame-function or
> display-buffer-fallback-action is changed.

To make it happen you have to make all existing windows dedicated and
display some other buffer, inhibit popping up new windows, and inhibit
popping up new frames.

martin

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Fri, 08 Feb 2013 09:36:29 -0500

>> Maybe a way around that is to use a special window that's never
>> displayed.  But that might introduce more trouble than it's trying
>> to solve.
> Trying to use an internal window:

No, I really meant a window that's not displayed, not the root-window.
E.g. a window on a separate frame with the frame marked invisible.


        Stefan

Message #50 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: Juri Linkov <juri <at> jurta.org>, 13594 <at> debbugs.gnu.org,
	Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;	[PATCH] compilation-start doesn't consider
	nil OUTWIN
Date: Sat, 09 Feb 2013 10:22:28 +0100

> No, I really meant a window that's not displayed, not the root-window.
> E.g. a window on a separate frame with the frame marked invisible.

I'm currently investigating this idea when fitting a frame to a buffer
before the frame is displayed at all.  But I wouldn't recommend it in
the context of the present thread - any calls to `display-buffer' should
provide some visual feedback.

In principle, `display-buffer' could always return a window, reusing a
dedicated one or making a new frame, if necessary.  OTOH, the while loop
in `display-buffer' could easily give up when one of the functions it
calls returns a special value, say 'skip, and return nil in that case.

The problem is how to make callers of `display-buffer' (and more
seriously `pop-to-buffer' and `switch-to-buffer') aware of the fact that
no window was found, maybe deliberately.

I think the only correct solution is to have the caller add an alist
entry (or an extra argument to `display-buffer') say 'may-fail, whose
semantics are:

- If 'may-fail is non-nil, allow returning a nil value - I, the caller,
  already know how to handle that.

- If 'may-fail is nil or doesn't exist, return some window at any cost.

martin

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

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Sun, 10 Feb 2013 12:01:10 +0200

> I think the only correct solution is to have the caller add an alist
> entry (or an extra argument to `display-buffer') say 'may-fail, whose
> semantics are:
>
> - If 'may-fail is non-nil, allow returning a nil value - I, the caller,
>   already know how to handle that.
>
> - If 'may-fail is nil or doesn't exist, return some window at any cost.

But such some window at any cost should be harmless when the caller goes
to use the returned window e.g. to get its buffer with `window-buffer', etc.
This is why using a hidden window is better, despite its invisibility
the window will be still correct in all its properties.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;	[PATCH] compilation-start doesn't consider
	nil OUTWIN
Date: Sun, 10 Feb 2013 18:32:37 +0100

> But such some window at any cost should be harmless when the caller goes
> to use the returned window e.g. to get its buffer with `window-buffer', etc.

Returning the selected window is harmless.

> This is why using a hidden window is better, despite its invisibility
> the window will be still correct in all its properties.

Deleting the last visible Emacs frame and subsequently switching off
your machine is not entirely harmless.

martin

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

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Mon, 11 Feb 2013 11:28:59 +0200

>> But such some window at any cost should be harmless when the caller goes
>> to use the returned window e.g. to get its buffer with `window-buffer', etc.
>
> Returning the selected window is harmless.

Only if it displays the requested buffer.

Do you think it is possible to implement a special "hidden" window type
so callers could operate on it invisibly to the user?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: 24.2.92;	[PATCH] compilation-start doesn't consider
	nil OUTWIN
Date: Mon, 11 Feb 2013 18:31:09 +0100

>> Returning the selected window is harmless.
>
> Only if it displays the requested buffer.

We could make it do that.  That is, even for (inhibit-same-window . t)
and the case where the selected window is dedicated, we could display it
there if we don't have another choice.

> Do you think it is possible to implement a special "hidden" window type
> so callers could operate on it invisibly to the user?

Not really.  If you call `with-selected-window' on such a window and get
stuck in it, the display routines would probably have to find their way
out of such a situation.

We could, as Stefan proposed, use the root window of an invisible frame
for this.  But as I mentioned earlier, this has the disadvantage that
you have to somehow clean up that frame when you delete the last visible
frame.  Officially, `delete-frame' should handle this case but at least
here on Windows XP it certainly doesn't.  And I'm quite sure that we can
find at least one window manager where sampling the visibility of frames
is not 100% reliable.

martin

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

From: Leo Liu <sdl.web <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juri Linkov <juri <at> jurta.org>, 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Tue, 12 Feb 2013 01:55:08 +0800

On 2013-02-12 01:31 +0800, martin rudalics wrote:
>> Do you think it is possible to implement a special "hidden" window type
>> so callers could operate on it invisibly to the user?
>
> Not really.  If you call `with-selected-window' on such a window and get
> stuck in it, the display routines would probably have to find their way
> out of such a situation.
>
> We could, as Stefan proposed, use the root window of an invisible frame
> for this.  But as I mentioned earlier, this has the disadvantage that
> you have to somehow clean up that frame when you delete the last visible
> frame.  Officially, `delete-frame' should handle this case but at least
> here on Windows XP it certainly doesn't.  And I'm quite sure that we can
> find at least one window manager where sampling the visibility of frames
> is not 100% reliable.
>
> martin

What happens if we just return a minibuffer window to display-buffer?
(still ugly as hell)

Leo

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

From: Leo Liu <sdl.web <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juri Linkov <juri <at> jurta.org>, 13594 <at> debbugs.gnu.org,
	Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Thu, 14 Feb 2013 16:22:49 +0800

On 2013-02-12 01:55 +0800, Leo Liu wrote:
> What happens if we just return a minibuffer window to display-buffer?
> (still ugly as hell)

Have we reached an impasse? Is it advisable to go back to what Stefan
originally suggested?

Cheers,
Leo

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, martin rudalics <rudalics <at> gmx.at>,
	13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Thu, 14 Feb 2013 09:15:49 -0500

>> What happens if we just return a minibuffer window to display-buffer?
>> (still ugly as hell)
> Have we reached an impasse? Is it advisable to go back to what Stefan
> originally suggested?

Basically, as it currently stands "don't display at all" can be done in
2 ways:
- make it work only for those callers that are prepared for it: for this
  case, we could simply define a t return value (returned from an
  ACTION) to mean "not displayed".  Ideally, display-buffer would return
  nil in this case, but returning t is OK as well.
- make it work everywhere: then we need display-buffer to return
  a "dummy" window (i.e. an object that behaves like a window object
  but that is not displayed).

I'm beginning to think the best choice is the first option: it requires
no changes right away, and we can progressively change callers so that
they can handle the "not displayed" case.


        Stefan

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Tue, 19 Mar 2013 23:39:54 +0800

On 2013-02-14 22:15 +0800, Stefan Monnier wrote:
> Basically, as it currently stands "don't display at all" can be done in
> 2 ways:
> - make it work only for those callers that are prepared for it: for this
>   case, we could simply define a t return value (returned from an
>   ACTION) to mean "not displayed".  Ideally, display-buffer would return
>   nil in this case, but returning t is OK as well.
> - make it work everywhere: then we need display-buffer to return
>   a "dummy" window (i.e. an object that behaves like a window object
>   but that is not displayed).
>
> I'm beginning to think the best choice is the first option: it requires
> no changes right away, and we can progressively change callers so that
> they can handle the "not displayed" case.

Does this roughly follow your idea? i.e. document display-buffer to
allow non-window return value (I also get rid of mentioning nil). In
compile.el, handle non-window return value. The attached patch does
these two. (I'll prepare a thorough patch tomorrow.).

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index b82afc67..8edfe487 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1638,7 +1638,8 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
 	     (list command mode name-function highlight-regexp))
 	(set (make-local-variable 'revert-buffer-function)
 	     'compilation-revert-buffer)
-	(set-window-start outwin (point-min))
+	(when (windowp outwin)
+	  (set-window-start outwin (point-min)))
 
 	;; Position point as the user will see it.
 	(let ((desired-visible-point
@@ -1647,15 +1648,18 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
 		   (point-max)
 		 ;; Normally put it at the top.
 		 (point-min))))
-	  (if (eq outwin (selected-window))
-	      (goto-char desired-visible-point)
-	    (set-window-point outwin desired-visible-point)))
+	  (cond
+	   ((windowp outwin)
+	    (set-window-point outwin desired-visible-point))
+	   ((eq outwin (selected-window))
+	    (goto-char desired-visible-point))))
 
 	;; The setup function is called before compilation-set-window-height
 	;; so it can set the compilation-window-height buffer locally.
 	(if compilation-process-setup-function
 	    (funcall compilation-process-setup-function))
-	(compilation-set-window-height outwin)
+	(and (windowp outwin)
+	     (compilation-set-window-height outwin))
 	;; Start the compilation.
 	(if (fboundp 'start-process)
 	    (let ((proc
diff --git a/lisp/window.el b/lisp/window.el
index 63d75f60..e96c8c60 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5368,7 +5368,8 @@ (defun display-buffer (buffer-or-name &optional action frame)
   "Display BUFFER-OR-NAME in some window, without selecting it.
 BUFFER-OR-NAME must be a buffer or the name of an existing
 buffer.  Return the window chosen for displaying BUFFER-OR-NAME,
-or nil if no such window is found.
+or a non-nil value to mean one of the actions forbids displaying
+the buffer.
 
 Optional argument ACTION, if non-nil, should specify a display
 action.  Its form is described below.
@@ -5394,7 +5395,9 @@ (defun display-buffer (buffer-or-name &optional action frame)
 `display-buffer-fallback-action' (in order).  Then it calls each
 function in the combined function list in turn, passing the
 buffer as the first argument and the combined alist as the second
-argument, until one of the functions returns non-nil.
+argument, until one of the functions returns non-nil.  If the
+value is not a window object, the search stops and no buffer is
+displayed.
 
 If ACTION is nil, the function list and the alist are built using
 only the other variables mentioned above.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Tue, 19 Mar 2013 23:12:08 -0400

>> Basically, as it currently stands "don't display at all" can be done in
>> 2 ways:
>> - make it work only for those callers that are prepared for it: for this
>> case, we could simply define a t return value (returned from an
>> ACTION) to mean "not displayed".  Ideally, display-buffer would return
>> nil in this case, but returning t is OK as well.
>> - make it work everywhere: then we need display-buffer to return
>> a "dummy" window (i.e. an object that behaves like a window object
>> but that is not displayed).
>> 
>> I'm beginning to think the best choice is the first option: it requires
>> no changes right away, and we can progressively change callers so that
>> they can handle the "not displayed" case.

> Does this roughly follow your idea? i.e. document display-buffer to
> allow non-window return value (I also get rid of mentioning nil). In
> compile.el, handle non-window return value. The attached patch does
> these two. (I'll prepare a thorough patch tomorrow.).

It only does one half: change a few callers to handle a non-window
return value.  But the other half is important: the non-window return
value should only be possible if the caller announces that it's ready to
handle it.


        Stefan


> diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
> index b82afc67..8edfe487 100644
> --- a/lisp/progmodes/compile.el
> +++ b/lisp/progmodes/compile.el
> @@ -1638,7 +1638,8 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
>  	     (list command mode name-function highlight-regexp))
>  	(set (make-local-variable 'revert-buffer-function)
>  	     'compilation-revert-buffer)
> -	(set-window-start outwin (point-min))
> +	(when (windowp outwin)
> +	  (set-window-start outwin (point-min)))
 
>  	;; Position point as the user will see it.
>  	(let ((desired-visible-point
> @@ -1647,15 +1648,18 @@ (defun compilation-start (command &optional mode name-function highlight-regexp)
>  		   (point-max)
>  		 ;; Normally put it at the top.
>  		 (point-min))))
> -	  (if (eq outwin (selected-window))
> -	      (goto-char desired-visible-point)
> -	    (set-window-point outwin desired-visible-point)))
> +	  (cond
> +	   ((windowp outwin)
> +	    (set-window-point outwin desired-visible-point))
> +	   ((eq outwin (selected-window))
> +	    (goto-char desired-visible-point))))
 
>  	;; The setup function is called before compilation-set-window-height
>  	;; so it can set the compilation-window-height buffer locally.
>  	(if compilation-process-setup-function
>  	    (funcall compilation-process-setup-function))
> -	(compilation-set-window-height outwin)
> +	(and (windowp outwin)
> +	     (compilation-set-window-height outwin))
>  	;; Start the compilation.
>  	(if (fboundp 'start-process)
>  	    (let ((proc
> diff --git a/lisp/window.el b/lisp/window.el
> index 63d75f60..e96c8c60 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -5368,7 +5368,8 @@ (defun display-buffer (buffer-or-name &optional action frame)
>    "Display BUFFER-OR-NAME in some window, without selecting it.
>  BUFFER-OR-NAME must be a buffer or the name of an existing
>  buffer.  Return the window chosen for displaying BUFFER-OR-NAME,
> -or nil if no such window is found.
> +or a non-nil value to mean one of the actions forbids displaying
> +the buffer.
 
>  Optional argument ACTION, if non-nil, should specify a display
>  action.  Its form is described below.
> @@ -5394,7 +5395,9 @@ (defun display-buffer (buffer-or-name &optional action frame)
>  `display-buffer-fallback-action' (in order).  Then it calls each
>  function in the combined function list in turn, passing the
>  buffer as the first argument and the combined alist as the second
> -argument, until one of the functions returns non-nil.
> +argument, until one of the functions returns non-nil.  If the
> +value is not a window object, the search stops and no buffer is
> +displayed.
 
>  If ACTION is nil, the function list and the alist are built using
>  only the other variables mentioned above.

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Wed, 20 Mar 2013 12:37:26 +0800

On 2013-03-20 11:12 +0800, Stefan Monnier wrote:
> It only does one half: change a few callers to handle a non-window
> return value.  But the other half is important: the non-window return
> value should only be possible if the caller announces that it's ready to
> handle it.

So add to display-buffer an optional arg like the following?

(display-buffer BUFFER-OR-NAME &optional ACTION FRAME HANDLE-NONWINDOW)

display-buffer currently does not checking; it just passes back the
non-nil value to the caller. WDYT?

Leo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
	[PATCH] compilation-start doesn't consider nil OUTWIN
Date: Wed, 20 Mar 2013 08:51:52 -0400

>> It only does one half: change a few callers to handle a non-window
>> return value.  But the other half is important: the non-window return
>> value should only be possible if the caller announces that it's ready to
>> handle it.
> So add to display-buffer an optional arg like the following?
> (display-buffer BUFFER-OR-NAME &optional ACTION FRAME HANDLE-NONWINDOW)

That's one possibility, yes.  Tho adding an argument doesn't sound
much fun.  So I'd prefer if it could be passed via ACTION.

> display-buffer currently does not checking; it just passes back the
> non-nil value to the caller. WDYT?

That's OK.  The whole point is that the code (e.g. in
display-buffer-alist) that returns the non-window value needs to be able
to decide whether it's safe to do so.


        Stefan

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: 24.2.92;
 [PATCH] compilation-start doesn't consider nil OUTWIN
Date: Sun, 17 Nov 2013 13:18:44 +0800

On 2013-03-20 20:51 +0800, Stefan Monnier wrote:
> That's one possibility, yes.  Tho adding an argument doesn't sound
> much fun.  So I'd prefer if it could be passed via ACTION.

I have read this bug thread again. I am confused by this decision. Why
do we want to tell display-buffer to do nothing (via ACTION or extra
arg) when we can choose not to call it? Isn't not calling it better?

Leo

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

From: martin rudalics <rudalics <at> gmx.at>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#13594: 24.2.92;	[PATCH] compilation-start doesn't consider
 nil OUTWIN
Date: Sun, 17 Nov 2013 10:48:16 +0100

>> That's one possibility, yes.  Tho adding an argument doesn't sound
>> much fun.  So I'd prefer if it could be passed via ACTION.
>
> I have read this bug thread again. I am confused by this decision. Why
> do we want to tell display-buffer to do nothing (via ACTION or extra
> arg) when we can choose not to call it? Isn't not calling it better?

Stefan proposes to handle the case where the application wants to
display the buffer but `display-buffer' is not able to do so.  Ever
since, all callers of `display-buffer' I know of silently assumed that
the latter would display the buffer and return its window despite the
fact that it was possible that the buffer would not get displayed.

Stefan's proposal would correct that misunderstanding although now these
might result from the fact that if no argument is "passed via ACTION",
`display-buffer' could use the selected window, harming an application's
assumptions provided via setting inhibit-same-window to non-nil.  We at
least would have to document such fact but it's an "incompatible change"
nevertheless.  I think this is a minor evil and should be fairly rare as
well.

Now if an application and/or user do not want to display the buffer in
the first case, `display-buffer' should not be called.  If, however, the
call cannot be avoided, we should add a second (user) action which
avoids entering the loop in `display-buffer' and returns nil immediately
provided the first action was set (that is, the calling application at
least pretends to know how to handle a nil return value).

martin

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: Planning Emacs-24.4
Date: Sun, 17 Nov 2013 15:53:27 -0500

>> So, it's getting time for Emacs-24.4.
>> I'd like to freeze the code before the end of this year (I'm thinking of
>> mid-december).
>> If you have some code you'd like to see included in Emacs-24.4, then
>> please install it "now", and if it's not ready yet, then tell me, so we
>> can see how to accommodate it.
> I hope http://debbugs.gnu.org/13594 get fixed this time.

IIRC, the way to fix this is:
- document a parameter that can be passed via ACTION which basically
  declares "the caller is prepared to handle a non-window return value
  if display-buffer decides that the buffer should not be displayed".
- document that if this new parameter is set, the display-buffer-alist
  rules can simply return t if they want the buffer to not be displayed.
- change compile.el to pass this new parameter and then to handle
  a t return value of display-buffer.

Can you take care of that?  The first two are just documentation
changes, and the third is basically the patch you originally submitted
in that bug-report, except that outwin will be t rather than nil (tho
I recommend to just test whether it's `windowp').


        Stefan

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 16:41:46 +0800

[Message part 1 (text/plain, inline)]

Implemented as requested. I have also briefly tested with ggtags and it
worked. Comments welcome. Thanks.

[13594.diff (text/x-patch, attachment)]

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

From: Leo Liu <sdl.web <at> gmail.com>
To: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 17:53:21 +0800

On 2013-11-18 16:41 +0800, Leo Liu wrote:
> +	  (when (eq outwin (selected-window))

Fixed locally as:

(when (and (windowp outwin)
           (not (eq outwin (selected-window))))
  ...)

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

From: Andreas Schwab <schwab <at> suse.de>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 11:00:03 +0100

Leo Liu <sdl.web <at> gmail.com> writes:

> (when (and (windowp outwin)
>            (not (eq outwin (selected-window))))

No need to test for windowp.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 18:17:39 +0800

On 2013-11-18 18:00 +0800, Andreas Schwab wrote:
> No need to test for windowp.

We permit return value t so must test windowp.

Leo

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

From: Andreas Schwab <schwab <at> suse.de>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 11:26:53 +0100

Leo Liu <sdl.web <at> gmail.com> writes:

> On 2013-11-18 18:00 +0800, Andreas Schwab wrote:
>> No need to test for windowp.
>
> We permit return value t so must test windowp.

Which return value?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 18:35:10 +0800

On 2013-11-18 18:26 +0800, Andreas Schwab wrote:
> Which return value?
>
> Andreas.

display-buffer can return a non-nil non-window value (typically t).

See the documentation change to window.el in the patch.

Leo

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

From: Andreas Schwab <schwab <at> suse.de>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 11:38:42 +0100

Leo Liu <sdl.web <at> gmail.com> writes:

> display-buffer can return a non-nil non-window value (typically t).

How is that relevant? t can never be eq selected-window.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

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

> Implemented as requested. I have also briefly tested with ggtags and it
> worked. Comments welcome. Thanks.

Why didn't you implement the may-fail part?  IIUC `display-buffer'
should *not* return nil unless may-fail has been set.  So if may-fail is
not set, `display-buffer' should either create a new window, a new
frame, or reuse some window at any cost.

And there's no use for `display-buffer' returning t.

martin

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 19:09:47 +0800

On 2013-11-18 18:38 +0800, Andreas Schwab wrote:
> How is that relevant? t can never be eq selected-window.
>
> Andreas.

Exactly. We want to call set-window-point when outwin is a window but
not the selected one.

Leo

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

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 19:16:46 +0800

On 2013-11-18 18:46 +0800, martin rudalics wrote:
> Why didn't you implement the may-fail part?  IIUC `display-buffer'
> should *not* return nil unless may-fail has been set.  So if may-fail is
> not set, `display-buffer' should either create a new window, a new
> frame, or reuse some window at any cost.
>
> And there's no use for `display-buffer' returning t.
>
> martin

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.

But I'll wait for Stefan to explain what his intention is.

Leo

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

From: Andreas Schwab <schwab <at> suse.de>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 12:25:15 +0100

Leo Liu <sdl.web <at> gmail.com> writes:

> Exactly. We want to call set-window-point when outwin is a window but
> not the selected one.

Thanks, I now see my error.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 19:59:18 +0800

On 2013-11-18 19:25 +0800, Andreas Schwab wrote:
> Thanks, I now see my error.
>
> Andreas.

Sorry, I probably shouldn't omit set-window-point.

Leo

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

From: martin rudalics <rudalics <at> gmx.at>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 14:19:22 +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.  Returning t when calling `display-buffer' without may-fail
set doesn't improve anything.  And if my-fail is set, we can return nil
because the caller is prepared for it.  And you still don't handle the
case where a user doesn't want to see the buffer in the first place.

So please

(1) Provide two actions designators may-fail and do-fail, say.

(2) When may-fail is set and no window is found, return nil.  When
    may-fail is not set, return the 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.

martin

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 08:55:44 -0500

>> Implemented as requested. I have also briefly tested with ggtags and it
>> worked.  Comments welcome.  Thanks.

Thank you.  Two comments:
1- You can/should use nil instead of `ignore'.
2- I'm not sure `may-fail' is the right name.  After all, it's not
   really a failure, but rather a conscious (and successful) decision to
   not display the buffer.  I don't have a good counter-proposition, tho
   ("no-display-ok" is what comes to my mind, but I don't like it too
   much either).

> Why didn't you implement the may-fail part?  IIUC `display-buffer'
> should *not* return nil unless may-fail has been set.  So if may-fail is
> not set, `display-buffer' should either create a new window, a new
> frame, or reuse some window at any cost.

AFAICT, display-buffer does already try pretty hard.  I think that if
display-buffer returns nil in a context where may-fail is nil, it's not
a bug in display-buffer but in some of the ACTIONS, and I see no reason
why `display-buffer' should try and cover up the problem.

> And there's no use for `display-buffer' returning t.

You mean, it should return nil (and never t) if the return value is not
a window?
I guess it would indeed be cleaner, yes,


        Stefan

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

From: Leo Liu <sdl.web <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 22:56:56 +0800

On 2013-11-18 21:19 +0800, martin rudalics wrote:
> (1) Provide two actions designators may-fail and do-fail, say.
>
> (2) When may-fail is set and no window is found, return nil.  When
>     may-fail is not set, return the 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.
>
> martin

Hi Martin,

I wonder if at this point you can take over fixing this bug. I am
unfamiliar with windowing. So I might not be able to propose a fix in
perspective.

BTW I use this action to suppress displaying the compilation window and
it works.

  (cons (lambda (buf action)
          (and (assq 'may-fail (cdr action))
               (with-current-buffer buf
                 (derived-mode-p 'ggtags-global-mode))))
        (list (lambda (&rest _) t)))

The only thing I want is a way to tell compile.el not to pop up the
window.

Leo

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

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

> I wonder if at this point you can take over fixing this bug. I am
> unfamiliar with windowing. So I might not be able to propose a fix in
> perspective.

I thought you intially wanted to fix the problem that a caller cannot
handle a nil return value from `display-buffer'.  But Stefan says that
it's not necessary to do that and I agree with him.  So your fix is OK
but I'd just make the last line of `display-buffer' something like

(when (windowp window) window)

and you don't have to talk about a return value of t.  Returning t sounds
not very intuitive when a function fails to accomplish something.

martin

Message #143 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: Mon, 18 Nov 2013 16:32:25 +0100

> AFAICT, display-buffer does already try pretty hard.  I think that if
> display-buffer returns nil in a context where may-fail is nil, it's not
> a bug in display-buffer but in some of the ACTIONS, and I see no reason
> why `display-buffer' should try and cover up the problem.

Fully agreed.  I just misunderstood the intentions of the patch.

martin

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

From: Leo Liu <sdl.web <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 23:48:07 +0800

[Message part 1 (text/plain, inline)]

On 2013-11-18 23:20 +0800, martin rudalics wrote:
> I thought you intially wanted to fix the problem that a caller cannot
> handle a nil return value from `display-buffer'.  But Stefan says that
> it's not necessary to do that and I agree with him.  So your fix is OK
> but I'd just make the last line of `display-buffer' something like
>
> (when (windowp window) window)
>
> and you don't have to talk about a return value of t.  Returning t sounds
> not very intuitive when a function fails to accomplish something.

OK, thank you for the quick response. I have re-worked the patch based
on Stefan's and your comments. Please review it. Thanks.

Leo

[13594.diff (text/x-patch, attachment)]

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

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

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 19:33:23 -0500

> OK, thank you for the quick response. I have re-worked the patch based
> on Stefan's and your comments. Please review it. Thanks.

Fine by me, thank you (I don't like `non-window-ok' either, but again
I have nothing better to suggest for replacement).


        Stefan

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

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Tue, 19 Nov 2013 02:54:19 +0200

>> OK, thank you for the quick response. I have re-worked the patch based
>> on Stefan's and your comments. Please review it. Thanks.
>
> Fine by me, thank you (I don't like `non-window-ok' either, but again
> I have nothing better to suggest for replacement).

A good name depends on how the users will customize it.

Currently display-buffer supports these actions:

 `display-buffer-same-window'
 `display-buffer-reuse-window'
 `display-buffer-pop-up-frame'
 `display-buffer-pop-up-window'
 `display-buffer-use-some-window'

Then a new action could have a name:

 `display-buffer-no-window'

The existing ALIST entries are:

 `inhibit-same-window'
 `inhibit-switch-frame'

Then a new property could be:

 `allow-no-window'

And the new action `display-buffer-no-window' could check
if `allow-no-window' is non-nil then it will return t
(for which `display-buffer' will return nil to the caller).

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

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

On 2013-11-19 08:33 +0800, Stefan Monnier wrote:
> Fine by me, thank you (I don't like `non-window-ok' either, but again
> I have nothing better to suggest for replacement).
>
>
>         Stefan

I have committed the change use the name no-display-ok. I consider this
bug fixed and will close it in next days. Thank you for the help.

On 2013-11-19 08:54 +0800, Juri Linkov wrote:
[snipped 6 lines]
> A good name depends on how the users will customize it.
>
> Currently display-buffer supports these actions:
>
>  `display-buffer-same-window'
>  `display-buffer-reuse-window'
>  `display-buffer-pop-up-frame'
>  `display-buffer-pop-up-window'
>  `display-buffer-use-some-window'
>
> Then a new action could have a name:
>
>  `display-buffer-no-window'
>
> The existing ALIST entries are:
>
>  `inhibit-same-window'
>  `inhibit-switch-frame'
>
> Then a new property could be:
>
>  `allow-no-window'
>
> And the new action `display-buffer-no-window' could check
> if `allow-no-window' is non-nil then it will return t
> (for which `display-buffer' will return nil to the caller).

Hi Juri,

I am not too sure about those things so I will stop messing with them.
But I am happy to accommodate whatever changes made in this area.

Thanks,
Leo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 18 Nov 2013 22:38:51 -0500

> Then a new property could be:
>  `allow-no-window'

I"m not fond of it, but it's maybe the least bad so far.


        Stefan

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

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

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

> I have committed the change use the name no-display-ok.

Thanks.  Please consider adding a NEWS entry and describing the feature
in the Elisp manual.

martin

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

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Wed, 20 Nov 2013 02:55:21 +0200

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

Do you think `display-buffer-no-window' should return 'fail instead of t
when the user overrides the default action?

Then it could be defined as:

(defun display-buffer-no-window (buffer alist)
  (when (cdr (assq 'allow-no-window alist))
    'fail))

And the user customization:

(add-to-list 'display-buffer-alist '("\\*compilation\\*" display-buffer-no-window (nil)))

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

From: Leo Liu <sdl.web <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Wed, 20 Nov 2013 10:51:10 +0800

On 2013-11-19 15:42 +0800, martin rudalics wrote:
> Thanks.  Please consider adding a NEWS entry and describing the feature
> in the Elisp manual.

Done.

Leo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: martin rudalics <rudalics <at> gmx.at>, Leo Liu <sdl.web <at> gmail.com>,
 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Tue, 19 Nov 2013 22:26:18 -0500

> Do you think `display-buffer-no-window' should return 'fail instead of t
> when the user overrides the default action?

I don't think it really matters (and IIUC the current code doesn't care
abut the distinction).

> Then it could be defined as:
> (defun display-buffer-no-window (buffer alist)
>   (when (cdr (assq 'allow-no-window alist))
>     'fail))
> And the user customization:
> (add-to-list 'display-buffer-alist '("\\*compilation\\*"
>  display-buffer-no-window (nil)))

Sounds fine.


        Stefan

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

From: martin rudalics <rudalics <at> gmx.at>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Wed, 20 Nov 2013 08:33:43 +0100

>> Thanks.  Please consider adding a NEWS entry and describing the feature
>> in the Elisp manual.
> 
> Done.

Thanks, martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Wed, 20 Nov 2013 08:34:04 +0100

> Do you think `display-buffer-no-window' should return 'fail instead of t
> when the user overrides the default action?

It certainly would indicate the intentions more clearly.

> Then it could be defined as:
>
> (defun display-buffer-no-window (buffer alist)
>   (when (cdr (assq 'allow-no-window alist))
>     'fail))
>
> And the user customization:
>
> (add-to-list 'display-buffer-alist '("\\*compilation\\*" display-buffer-no-window (nil)))

Exactly.

martin

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

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, Leo Liu <sdl.web <at> gmail.com>,
 13594 <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Thu, 21 Nov 2013 02:30:27 +0200

>> Then it could be defined as:
>> (defun display-buffer-no-window (buffer alist)
>>   (when (cdr (assq 'allow-no-window alist))
>>     'fail))
>> And the user customization:
>> (add-to-list 'display-buffer-alist '("\\*compilation\\*"
>>  display-buffer-no-window (nil)))
>
> Sounds fine.

This patch adds a new action to window.el and also adds support
for not displaying a window for the buffer `*Async Shell Command*'
of `async-shell-command' that will be possible to customize with

(add-to-list 'display-buffer-alist '("\\*Async Shell Command\\*"
                                     display-buffer-no-window (nil)))

=== modified file 'lisp/window.el'
--- lisp/window.el	2013-11-20 02:44:38 +0000
+++ lisp/window.el	2013-11-21 00:30:00 +0000
@@ -5501,6 +5501,9 @@ (defun display-buffer (buffer-or-name &o
     argument - a new window.  The function is supposed to adjust
     the width of the window; its return value is ignored.
 
+ `allow-no-window' -- A non-nil value allows the user to override
+    the default action and not display the buffer in a window.
+
 The ACTION argument to `display-buffer' can also have a non-nil
 and non-list value.  This means to display the buffer in a window
 other than the selected one, even if it is already displayed in
@@ -5830,6 +5833,16 @@ (defun display-buffer-use-some-window (b
 	(unless (cdr (assq 'inhibit-switch-frame alist))
 	  (window--maybe-raise-frame (window-frame window)))))))
 
+(defun display-buffer-no-window (buffer alist)
+  "Display BUFFER in no window.
+If ALIST has a non-nil `allow-no-window' entry, then don't display
+a window at all.  This makes possible to override the default action
+and avoid displaying the buffer.  It is assumed that when the caller
+specifies a non-nil `allow-no-window' then it can handle a nil value
+returned from `display-buffer' in this case."
+  (when (cdr (assq 'allow-no-window alist))
+    'fail))
+
 ;;; Display + selection commands:
 (defun pop-to-buffer (buffer &optional action norecord)
   "Select buffer BUFFER in some window, preferably a different one.

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2013-10-30 02:45:53 +0000
+++ lisp/simple.el	2013-11-21 00:30:04 +0000
@@ -2820,7 +2820,7 @@ (defun shell-command (command &optional
 		  ;; which comint sometimes adds for prompts.
 		  (let ((inhibit-read-only t))
 		    (erase-buffer))
-		  (display-buffer buffer)
+		  (display-buffer buffer '(nil (allow-no-window . t)))
 		  (setq default-directory directory)
 		  (setq proc (start-process "Shell" buffer shell-file-name
 					    shell-command-switch command))

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Mon, 02 Dec 2013 13:33:15 +0800

On 2013-11-21 08:30 +0800, Juri Linkov wrote:
> This patch adds a new action to window.el and also adds support
> for not displaying a window for the buffer `*Async Shell Command*'
> of `async-shell-command' that will be possible to customize with

What's the status of this bug? Should I close it or is there something
pending?

Thanks,
Leo

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

From: Juri Linkov <juri <at> jurta.org>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 13594 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Tue, 03 Dec 2013 03:19:39 +0200

>> This patch adds a new action to window.el and also adds support
>> for not displaying a window for the buffer `*Async Shell Command*'
>> of `async-shell-command' that will be possible to customize with
>
> What's the status of this bug? Should I close it or is there something
> pending?

I installed the patch.  Please have a look and close this bug
if everything is fixed.

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594-done <at> debbugs.gnu.org
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Tue, 03 Dec 2013 11:23:20 +0800

Fixed in 24.4

On 2013-12-03 09:19 +0800, Juri Linkov wrote:
> I installed the patch.  Please have a look and close this bug
> if everything is fixed.

Thanks for the improvement.

Leo

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: 13594 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#13594: Planning Emacs-24.4
Date: Tue, 03 Dec 2013 08:56:27 +0100

> I installed the patch.  Please have a look and close this bug
> if everything is fixed.

Thanks, martin

Previous Next

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