bug#30213: 26.0.91; shell buffer not displayed when not erased and async-shell-command-display-buffer is used

["Basil L. Contovounesios" <contovob@tcd.ie>]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Date: Tue, 23 Jan 2018 18:53:13 +0000
>> Cc: 30213@debbugs.gnu.org
>> 
>> * lisp/simple.el (shell-command): Display async command buffer on
>> process output for every invocation, not just the first. (bug#30213)
>> ---
>>  lisp/simple.el | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>> 
>> diff --git a/lisp/simple.el b/lisp/simple.el
>> index 3ac6b86381..20e22bf98f 100644
>> --- a/lisp/simple.el
>> +++ b/lisp/simple.el
>> @@ -3551,9 +3551,7 @@ shell-command
>>                      (add-function :before (process-filter proc)
>>                                    (lambda (process _string)
>>                                      (let ((buf (process-buffer process)))
>> -                                      (when (and (zerop (buffer-size buf))
>> -                                                 (string= (buffer-name buf)
>> -                                                          bname))
>> +                                      (when (string= (buffer-name buf) bname)
>>                                          (display-buffer buf))))))))
>>  	    ;; Otherwise, command is executed synchronously.
>>  	    (shell-command-on-region (point) (point) command
>
> Looks like you are removing the feature we just introduced in Emacs
> 26, see commit 85512e7: it shows the shell buffer only if there is
> some output there.  Or am I missing something?

This feature is implemented by the surrounding add-function advice on
the process filter, which I am not removing.  Here is my patch in the
surrounding context of the async-shell-command-display-buffer switch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: diff.diff --]
[-- Type: text/x-diff, Size: 1021 bytes --]

diff --git a/lisp/simple.el b/lisp/simple.el
index 3ac6b86381..20e22bf98f 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3549,13 +3549,11 @@ shell-command
                   (if async-shell-command-display-buffer
                       (display-buffer buffer '(nil (allow-no-window . t)))
                     (add-function :before (process-filter proc)
                                   (lambda (process _string)
                                     (let ((buf (process-buffer process)))
-                                      (when (and (zerop (buffer-size buf))
-                                                 (string= (buffer-name buf)
-                                                          bname))
+                                      (when (string= (buffer-name buf) bname)
                                         (display-buffer buf))))))))
 	    ;; Otherwise, command is executed synchronously.
 	    (shell-command-on-region (point) (point) command
 				     output-buffer nil error-buffer)))))))

[-- Attachment #3: Type: text/plain, Size: 1107 bytes --]


When async-shell-command-display-buffer is non-nil, the output buffer is
displayed immediately.  Otherwise, the buffer is displayed by the
(advised) process filter, which should only be invoked for
output-producing shell commands[1].  For example, the Unix null command
M-& : RET does not invoke the process filter.

Without my patch, the process filter advice only displays the output
buffer if it is already empty, i.e. if no previous shell-command
invocation has written output to the process buffer.  This guard seems
to contradict the purpose of a non-nil shell-command-dont-erase-buffer
setting.

So, my patch continues to allow the immediate display of the output
buffer, irrespective of command output, when
async-shell-command-display-buffer is non-nil, as well as the deferred
and repeated display of the output buffer, irrespective of
shell-command-dont-erase-buffer and subject to command output, when
async-shell-command-display-buffer is nil.

[1] This assumption is based on observation, not expertise in process
    filters; I cannot guarantee the absence of obscure edge cases.

-- 
Basil