bug#39138: 28.0.50; Add variables for shell command output buffer names

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Tino Calancha]

Severity: wishlist

IMO, the two strings, `*Shell Command Output*' and
`*Async Shell Command*', deserve variables with their docstrings.

--8<-----------------------------cut here---------------start------------->8---
commit 4a436b46621f0c0016c1a374a3c22dff0be39391
Author: Tino Calancha <tino.calancha@gmail.com>
Date:   Tue Jan 14 22:28:22 2020 +0100

    Add variables for shell command output buffer names
    
    Buffers `*Shell Command Output*' and `*Async Shell Command*'
    have been around since a long time; used across several libraries,
    they are de facto output buffers for shell commands.
    
    * lisp/simple.el (shell-command-buffer-name)
    (shell-command-buffer-name-async): New variables.
    * lisp/dired-aux.el
    * lisp/gnus/gnus-sum.el
    * lisp/gnus/gnus-win.el
    * lisp/ibuf-ext.el
    * lisp/net/tramp.el: Use them.
    
    * etc/NEWS (Changes in Emacs 28.1): Announce this change.
    
    * doc/emacs/misc.texi (Single Shell)
    * doc/misc/tramp.texi (Remote processes):
    Update manual.

diff --git a/doc/emacs/misc.texi b/doc/emacs/misc.texi
index ab3318c4a2..3d443e5d2f 100644
--- a/doc/emacs/misc.texi
+++ b/doc/emacs/misc.texi
@@ -724,13 +724,15 @@ Single Shell
 
 @kindex M-!
 @findex shell-command
+@vindex shell-command-buffer-name
   @kbd{M-!} (@code{shell-command}) reads a line of text using the
 minibuffer and executes it as a shell command, in a subshell made just
 for that command.  Standard input for the command comes from the null
 device.  If the shell command produces any output, the output appears
-either in the echo area (if it is short), or in an Emacs buffer named
-@file{*Shell Command Output*}, displayed in another window (if the
-output is long).  The variables @code{resize-mini-windows} and
+either in the echo area (if it is short), or in an Emacs buffer,
+displayed in another window (if the output is long).  The name of
+this buffer is stored in the variable @code{shell-command-buffer-name}.
+The variables @code{resize-mini-windows} and
 @code{max-mini-window-height} (@pxref{Minibuffer Edit}) control when
 Emacs should consider the output to be too long for the echo area.
 
@@ -757,15 +759,16 @@ Single Shell
 
 @kindex M-&
 @findex async-shell-command
+@vindex shell-command-buffer-name-async
   A shell command that ends in @samp{&} is executed
 @dfn{asynchronously}, and you can continue to use Emacs as it runs.
 You can also type @kbd{M-&} (@code{async-shell-command}) to execute a
 shell command asynchronously; this is exactly like calling @kbd{M-!}
 with a trailing @samp{&}, except that you do not need the @samp{&}.
-The default output buffer for asynchronous shell commands is named
-@samp{*Async Shell Command*}.  Emacs inserts the output into this
-buffer as it comes in, whether or not the buffer is visible in a
-window.
+The variable @code{shell-command-buffer-name-async} stores the name
+of the default output buffer for asynchronous shell commands.
+Emacs inserts the output into this buffer as it comes in,
+whether or not the buffer is visible in a window.
 
 @vindex async-shell-command-buffer
   If you want to run more than one asynchronous shell command at the
@@ -803,7 +806,7 @@ Single Shell
 see what keys are in the buffer.  If the buffer contains a GnuPG key,
 type @kbd{C-x h M-| gpg @key{RET}} to feed the entire buffer contents
 to @command{gpg}.  This will output the list of keys to the
-@file{*Shell Command Output*} buffer.
+buffer named @code{shell-command-buffer-name}.
 
 @vindex shell-file-name
   The above commands use the shell specified by the variable
diff --git a/doc/misc/tramp.texi b/doc/misc/tramp.texi
index 049b240b60..0d6efa4f3f 100644
--- a/doc/misc/tramp.texi
+++ b/doc/misc/tramp.texi
@@ -3213,7 +3213,7 @@ Remote processes
 @end example
 
 @command{tail} command outputs continuously to the local buffer,
-@file{*Async Shell Command*}
+named @code{shell-command-buffer-name-async}
 
 @kbd{M-x auto-revert-tail-mode @key{RET}} runs similarly showing
 continuous output.
diff --git a/etc/NEWS b/etc/NEWS
index d5a1d27267..aac80fd263 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -34,6 +34,11 @@ are found by 'configure'
 \f
 * Changes in Emacs 28.1
 
++++
+** The new variables 'shell-command-buffer-name' and
+'shell-command-buffer-name-async' store the default buffer names
+for the output of shell commands.
+
 \f
 * Editing Changes in Emacs 28.1
 
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 0069c1744d..aaa2f797de 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -684,7 +684,7 @@ dired-do-async-shell-command
 for each command to terminate before running the next command.
 In shell syntax this means separating the individual commands with `;'.
 
-The output appears in the buffer `*Async Shell Command*'."
+The output appears in the buffer `shell-command-buffer-name-async'."
   (interactive
    (let ((files (dired-get-marked-files t current-prefix-arg nil nil t)))
      (list
@@ -723,7 +723,7 @@ dired-do-shell-command
 
 If COMMAND ends in `&', `;', or `;&', it is executed in the
 background asynchronously, and the output appears in the buffer
-`*Async Shell Command*'.  When operating on multiple files and COMMAND
+`shell-command-buffer-name-async'.  When operating on multiple files and COMMAND
 ends in `&', the shell command is executed on each file in parallel.
 However, when COMMAND ends in `;' or `;&' then commands are executed
 in the background on each file sequentially waiting for each command
@@ -731,7 +731,7 @@ dired-do-shell-command
 `dired-do-async-shell-command' that automatically adds `&'.
 
 Otherwise, COMMAND is executed synchronously, and the output
-appears in the buffer `*Shell Command Output*'.
+appears in the buffer `shell-command-buffer-name'.
 
 This feature does not try to redisplay Dired buffers afterward, as
 there's no telling what files COMMAND may have changed.
diff --git a/lisp/gnus/gnus-sum.el b/lisp/gnus/gnus-sum.el
index a59e8b359d..f6c1ae7c73 100644
--- a/lisp/gnus/gnus-sum.el
+++ b/lisp/gnus/gnus-sum.el
@@ -12281,7 +12281,7 @@ gnus-summary-pipe-output
   (interactive (gnus-interactive "P\ny"))
   (require 'gnus-art)
   (let* ((articles (gnus-summary-work-articles n))
-	 (result-buffer "*Shell Command Output*")
+	 (result-buffer shell-command-buffer-name)
 	 (all-headers (not (memq sym '(nil r))))
 	 (gnus-save-all-headers (or all-headers gnus-save-all-headers))
 	 (raw (eq sym 'r))
diff --git a/lisp/gnus/gnus-win.el b/lisp/gnus/gnus-win.el
index 36b2835036..baa3146e64 100644
--- a/lisp/gnus/gnus-win.el
+++ b/lisp/gnus/gnus-win.el
@@ -142,7 +142,7 @@ gnus-buffer-configuration
     (pipe
      (vertical 1.0
 	       (summary 0.25 point)
-	       ("*Shell Command Output*" 1.0)))
+	       (shell-command-buffer-name 1.0)))
     (bug
      (vertical 1.0
 	       (if gnus-bug-create-help-buffer '("*Gnus Help Bug*" 0.5))
diff --git a/lisp/ibuf-ext.el b/lisp/ibuf-ext.el
index bfb9787a96..c9ca1f8742 100644
--- a/lisp/ibuf-ext.el
+++ b/lisp/ibuf-ext.el
@@ -504,7 +504,7 @@ ibuffer-backward-filter-group
   (ibuffer-forward-line 0))
 
 (defun ibuffer--maybe-erase-shell-cmd-output ()
-  (let ((buf (get-buffer "*Shell Command Output*")))
+  (let ((buf (get-buffer shell-command-buffer-name)))
     (when (and (buffer-live-p buf)
                (not shell-command-dont-erase-buffer)
                (not (zerop (buffer-size buf))))
@@ -517,7 +517,7 @@ shell-command-pipe
    :opstring "Shell command executed on"
    :before (ibuffer--maybe-erase-shell-cmd-output)
    :modifier-p nil)
-  (let ((out-buf (get-buffer-create "*Shell Command Output*")))
+  (let ((out-buf (get-buffer-create shell-command-buffer-name)))
     (with-current-buffer out-buf (goto-char (point-max)))
     (call-shell-region (point-min) (point-max)
                        command nil out-buf)))
@@ -542,7 +542,7 @@ shell-command-file
    :modifier-p nil)
   (let ((file (and (not (buffer-modified-p))
                    buffer-file-name))
-        (out-buf (get-buffer-create "*Shell Command Output*")))
+        (out-buf (get-buffer-create shell-command-buffer-name)))
     (unless (and file (file-exists-p file))
       (setq file
             (make-temp-file
diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
index a7c9b34d29..51fa88653a 100644
--- a/lisp/net/tramp.el
+++ b/lisp/net/tramp.el
@@ -3658,8 +3658,8 @@ tramp-handle-shell-command
 	    (current-buffer))
 	   (t (get-buffer-create
 	       (if asynchronous
-		   "*Async Shell Command*"
-		 "*Shell Command Output*")))))
+		   shell-command-buffer-name-async
+		 shell-command-buffer-name)))))
 	 (error-buffer
 	  (cond
 	   ((bufferp error-buffer) error-buffer)
diff --git a/lisp/simple.el b/lisp/simple.el
index f9f1efcc98..01cb7d0de8 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3319,6 +3319,14 @@ undo-outer-limit-truncate
     (setq buffer-undo-list nil)
     t))
 \f
+;;;; Shell commands
+
+(defvar shell-command-buffer-name "*Shell Command Output*"
+  "Name of the output buffer for shell commands.")
+
+(defvar shell-command-buffer-name-async "*Async Shell Command*"
+  "Name of the output buffer for asynchronous shell commands.")
+
 (defvar shell-command-history nil
   "History list for some commands that read shell commands.
 
@@ -3383,7 +3391,7 @@ read-shell-command
 (defcustom async-shell-command-buffer 'confirm-new-buffer
   "What to do when the output buffer is used by another shell command.
 This option specifies how to resolve the conflict where a new command
-wants to direct its output to the buffer `*Async Shell Command*',
+wants to direct its output to the buffer `shell-command-buffer-name-async',
 but this buffer is already taken by another running shell command.
 
 The value `confirm-kill-process' is used to ask for confirmation before
@@ -3510,14 +3518,14 @@ async-shell-command
 Like `shell-command', but adds `&' at the end of COMMAND
 to execute it asynchronously.
 
-The output appears in the buffer `*Async Shell Command*'.
+The output appears in the buffer `shell-command-buffer-name-async'.
 That buffer is in shell mode.
 
 You can configure `async-shell-command-buffer' to specify what to do
-when the `*Async Shell Command*' buffer is already taken by another
+when the `shell-command-buffer-name-async' buffer is already taken by another
 running shell command.  To run COMMAND without displaying the output
 in a window you can configure `display-buffer-alist' to use the action
-`display-buffer-no-window' for the buffer `*Async Shell Command*'.
+`display-buffer-no-window' for the buffer `shell-command-buffer-name-async'.
 
 In Elisp, you will often be better served by calling `start-process'
 directly, since it offers more control and does not impose the use of
@@ -3553,12 +3561,12 @@ shell-command
 directory in the prompt.
 
 If COMMAND ends in `&', execute it asynchronously.
-The output appears in the buffer `*Async Shell Command*'.
+The output appears in the buffer `shell-command-buffer-name-async'.
 That buffer is in shell mode.  You can also use
 `async-shell-command' that automatically adds `&'.
 
 Otherwise, COMMAND is executed synchronously.  The output appears in
-the buffer `*Shell Command Output*'.  If the output is short enough to
+the buffer `shell-command-buffer-name'.  If the output is short enough to
 display in the echo area (which is determined by the variables
 `resize-mini-windows' and `max-mini-window-height'), it is shown
 there, but it is nonetheless available in buffer `*Shell Command
@@ -3672,7 +3680,7 @@ shell-command
 	  (if (string-match "[ \t]*&[ \t]*\\'" command)
 	      ;; Command ending with ampersand means asynchronous.
               (let* ((buffer (get-buffer-create
-                              (or output-buffer "*Async Shell Command*")))
+                              (or output-buffer shell-command-buffer-name-async)))
                      (bname (buffer-name buffer))
                      (proc (get-buffer-process buffer))
                      (directory default-directory))
@@ -3824,7 +3832,7 @@ shell-command-on-region
 				      error-buffer display-error-buffer
 				      region-noncontiguous-p)
   "Execute string COMMAND in inferior shell with region as input.
-Normally display output (if any) in temp buffer `*Shell Command Output*';
+Normally display output (if any) in temp buffer `shell-command-buffer-name';
 Prefix arg means replace the region with it.  Return the exit code of
 COMMAND.
 
@@ -3843,7 +3851,7 @@ shell-command-on-region
 If the output is short enough to display in the echo area
 \(determined by the variable `max-mini-window-height' if
 `resize-mini-windows' is non-nil), it is shown there.
-Otherwise it is displayed in the buffer `*Shell Command Output*'.
+Otherwise it is displayed in the buffer `shell-command-buffer-name'.
 The output is available in that buffer in both cases.
 
 If there is output and an error, a message about the error
@@ -3853,7 +3861,7 @@ shell-command-on-region
 command's output.  If the value is a buffer or buffer name,
 erase that buffer and insert the output there; a non-nil value of
 `shell-command-dont-erase-buffer' prevent to erase the buffer.
-If the value is nil, use the buffer `*Shell Command Output*'.
+If the value is nil, use the buffer `shell-command-buffer-name'.
 Any other non-nil value means to insert the output in the
 current buffer after START.
 
@@ -3921,7 +3929,7 @@ shell-command-on-region
                                            (list t error-file)
                                          t)))
             ;; It is rude to delete a buffer that the command is not using.
-            ;; (let ((shell-buffer (get-buffer "*Shell Command Output*")))
+            ;; (let ((shell-buffer (get-buffer shell-command-buffer-name)))
             ;;   (and shell-buffer (not (eq shell-buffer (current-buffer)))
             ;; 	 (kill-buffer shell-buffer)))
             ;; Don't muck with mark unless REPLACE says we should.
@@ -3929,12 +3937,12 @@ shell-command-on-region
         ;; No prefix argument: put the output in a temp buffer,
         ;; replacing its entire contents.
         (let ((buffer (get-buffer-create
-                       (or output-buffer "*Shell Command Output*"))))
+                       (or output-buffer shell-command-buffer-name))))
           (set-buffer-major-mode buffer) ; Enable globalized modes (bug#38111)
           (unwind-protect
               (if (and (eq buffer (current-buffer))
                        (or (not shell-command-dont-erase-buffer)
-                           (and (not (eq buffer (get-buffer "*Shell Command Output*")))
+                           (and (not (eq buffer (get-buffer shell-command-buffer-name)))
                                 (not (region-active-p)))))
                   ;; If the input is the same buffer as the output,
                   ;; delete everything but the specified region,
--8<-----------------------------cut here---------------end--------------->8---

In GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
 of 2020-01-14 built on calancha-pc.dy.bbexcite.jp
Repository revision: 06caa3b7e5e9fe91b6918f8567adbd5501d6dbdd
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Michael Albinus]

Tino Calancha <tino.calancha@gmail.com> writes:

> --- a/lisp/net/tramp.el
> +++ b/lisp/net/tramp.el
> @@ -3658,8 +3658,8 @@ tramp-handle-shell-command
>  	    (current-buffer))
>  	   (t (get-buffer-create
>  	       (if asynchronous
> -		   "*Async Shell Command*"
> -		 "*Shell Command Output*")))))
> +		   shell-command-buffer-name-async
> +		 shell-command-buffer-name)))))
>  	 (error-buffer
>  	  (cond
>  	   ((bufferp error-buffer) error-buffer)

OK for me. However, I will tweak this a little bit once committed, in
order to keep Tramp's backward compatibility. Likely like this:

(or (bound-and-true-p shell-command-buffer-name-async) "*Async Shell Command*")

etc. Plus a comment, which Emacs version has introduced the variables,
in order to know when this compatibility hack can be removed.

Best regards, Michael.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Robert Pluim]

>>>>> On Tue, 14 Jan 2020 23:43:00 +0100, Michael Albinus <michael.albinus@gmx.de> said:

    Michael> Tino Calancha <tino.calancha@gmail.com> writes:
    >> --- a/lisp/net/tramp.el
    >> +++ b/lisp/net/tramp.el
    >> @@ -3658,8 +3658,8 @@ tramp-handle-shell-command
    >> (current-buffer))
    >> (t (get-buffer-create
    >> (if asynchronous
    >> -		   "*Async Shell Command*"
    >> -		 "*Shell Command Output*")))))
    >> +		   shell-command-buffer-name-async
    >> +		 shell-command-buffer-name)))))
    >> (error-buffer
    >> (cond
    >> ((bufferp error-buffer) error-buffer)

    Michael> OK for me. However, I will tweak this a little bit once committed, in
    Michael> order to keep Tramp's backward compatibility. Likely like this:

    Michael> (or (bound-and-true-p shell-command-buffer-name-async) "*Async Shell Command*")

    Michael> etc. Plus a comment, which Emacs version has introduced the variables,
    Michael> in order to know when this compatibility hack can be removed.

Tino, would it be possible to add text back in the manual saying what
the default values of these new variables are? People reading it
inside Emacs can obviously just inspect their values, but not everyone
reads inside Emacs.

Robert

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Tue, 14 Jan 2020 22:31:34 +0100
> 
> IMO, the two strings, `*Shell Command Output*' and
> `*Async Shell Command*', deserve variables with their docstrings.

Any rationale why we should add variables for these?  Who would want
to change the names, and why?

And even if we do provide such variables, I see no need to document
them in the manual.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Tino Calancha]

On Wed, 15 Jan 2020, Eli Zaretskii wrote:

>> From: Tino Calancha <tino.calancha@gmail.com>
>> Date: Tue, 14 Jan 2020 22:31:34 +0100
>>
>> IMO, the two strings, `*Shell Command Output*' and
>> `*Async Shell Command*', deserve variables with their docstrings.
>
> Any rationale why we should add variables for these?
I found nicer use a variable across libraries than repeat the same
string over and over.
I think, having the variable might encourage deeper library devs writing
a function launching a shell command, to use that same output buffer name.

As you see, no strong arguments; I am fine keeping the things as they are 
;-)

> Who would want to change the names, and why?
I expect no one.

> And even if we do provide such variables, I see no need to document
> them in the manual.
I agree; I would prefer not mention them in the manual.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Juri Linkov]

>> Who would want to change the names, and why?
> I expect no one.

Then they should be defined with defconst.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Michael Albinus]

Tino Calancha <tino.calancha@gmail.com> writes:

>> Any rationale why we should add variables for these?
> I found nicer use a variable across libraries than repeat the same
> string over and over.
> I think, having the variable might encourage deeper library devs writing
> a function launching a shell command, to use that same output buffer name.
>
> As you see, no strong arguments; I am fine keeping the things as they
> are ;-)

Any clue how to proceed? Either we apply the change, or the bug shall be
closed with nofix.

(I have no strong preference)

Best regards, Michael.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Stefan Kangas]

tags 39138 + moreinfo
thanks

Michael Albinus <michael.albinus@gmx.de> writes:

> Tino Calancha <tino.calancha@gmail.com> writes:
>
>>> Any rationale why we should add variables for these?
>> I found nicer use a variable across libraries than repeat the same
>> string over and over.
>> I think, having the variable might encourage deeper library devs writing
>> a function launching a shell command, to use that same output buffer name.
>>
>> As you see, no strong arguments; I am fine keeping the things as they
>> are ;-)
>
> Any clue how to proceed? Either we apply the change, or the bug shall be
> closed with nofix.
>
> (I have no strong preference)
>
> Best regards, Michael.

This seems to have stalled.  Is anyone still interested in this change,
or should the bug be closed?

Best regards,
Stefan Kangas

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 18 May 2020 21:08:13 -0700
> Cc: Tino Calancha <tino.calancha@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 39138@debbugs.gnu.org
> 
> This seems to have stalled.  Is anyone still interested in this change,
> or should the bug be closed?

It sounds like the best consensus we could have is to make defconsts
out of these strings, to avoid having many identical copies of them.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> This seems to have stalled.  Is anyone still interested in this change,
>> or should the bug be closed?
>
> It sounds like the best consensus we could have is to make defconsts
> out of these strings, to avoid having many identical copies of them.

Right.  Tino, could you take a look at that and see if it makes sense to
send an updated patch?

Best regards,
Stefan Kangas

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Tino Calancha]

On Tue, 19 May 2020, Stefan Kangas wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> This seems to have stalled.  Is anyone still interested in this change,
>>> or should the bug be closed?
>>
>> It sounds like the best consensus we could have is to make defconsts
>> out of these strings, to avoid having many identical copies of them.
>
> Right.  Tino, could you take a look at that and see if it makes sense to
> send an updated patch?

TBH, I am not that much interested in this change (even if I opened it).
Since yesterday I am again w/ bug#39121 which provides more value.

Also, I have in my TODO list to open a bug for `iconify-frame', which 
gives me some problems in one of my laptops (under investigation).

Please, feel free to get ownership of the present bug if you find it 
useful, or close it as won't fix.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Lars Ingebrigtsen]

Tino Calancha <tino.calancha@gmail.com> writes:

> IMO, the two strings, `*Shell Command Output*' and
> `*Async Shell Command*', deserve variables with their docstrings.

Skimming the thread, the rough consensus here was that this was a good
idea, but that these should be constants instead.  So I've applied the
patch to Emacs 28 and then adjusted the variable/constant bit.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Juri Linkov]

>> IMO, the two strings, `*Shell Command Output*' and
>> `*Async Shell Command*', deserve variables with their docstrings.
>
> Skimming the thread, the rough consensus here was that this was a good
> idea, but that these should be constants instead.  So I've applied the
> patch to Emacs 28 and then adjusted the variable/constant bit.

Oh, I noticed that the patch provided by Tino removed all mentions of
shell buffer names from the documentation.  While technically this is fine,
I tried to look from the point of view of users, and realized that it's
highly unlikely that the users might be interested to know the name of
the constant 'shell-command-buffer-name', whereas it's very important
for users to learn that the default name of the shell output buffer is
"*Shell Command Output*".

So it would be better to revert all changes in the documentation, and
anyway in https://debbugs.gnu.org/39138#16 Eli already asked not to mention
these variables in the manual.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Oh, I noticed that the patch provided by Tino removed all mentions of
> shell buffer names from the documentation.  While technically this is fine,
> I tried to look from the point of view of users, and realized that it's
> highly unlikely that the users might be interested to know the name of
> the constant 'shell-command-buffer-name', whereas it's very important
> for users to learn that the default name of the shell output buffer is
> "*Shell Command Output*".

I don't really see why?  If the user is using one of these commands, of
course they'll see the buffer names themselves.  If they're writing
code, they should be using 'shell-command-buffer-name', and not the
string "*Shell Command Output*".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Juri Linkov]

>> Oh, I noticed that the patch provided by Tino removed all mentions of
>> shell buffer names from the documentation.  While technically this is fine,
>> I tried to look from the point of view of users, and realized that it's
>> highly unlikely that the users might be interested to know the name of
>> the constant 'shell-command-buffer-name', whereas it's very important
>> for users to learn that the default name of the shell output buffer is
>> "*Shell Command Output*".
>
> I don't really see why?  If the user is using one of these commands, of
> course they'll see the buffer names themselves.

Often they don't see the buffer names - when the shell output is less
than 16 lines long, then the shell buffer is not displayed, so users
need to know the shell buffer name to be able to switch to it.  They need
to learn the buffer name from the User Manual.

> If they're writing code, they should be using 'shell-command-buffer-name',
> and not the string "*Shell Command Output*".

I completely agree that Emacs Lisp programmers need to know the new way
of using the shell buffer name via the new constant to reduce typos
in buffer names.  So the new constant should be explained in the
Emacs Lisp Reference Manual.

But the problem is that these constants are currently described
in the User Manual that make no sense to end users - users need
to know the buffer names, not internal constant names.

bug#39138: 28.0.50; Add variables for shell command output buffer names

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Often they don't see the buffer names - when the shell output is less
> than 16 lines long, then the shell buffer is not displayed, so users
> need to know the shell buffer name to be able to switch to it.  They need
> to learn the buffer name from the User Manual.

Yeah, it might make sense to mention the (default value of) the
variables in the user manual.

I've now reintroduced the buffer names in the user manual (but also
mentioned the variables parenthetically).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no