bug#35055: 27.0.50; async-shell-command truncates output lines

[Juri Linkov <juri@linkov.net>]

>>> I don't believe there is a conflict. The main use case will be to
>>> increase the output width of a shell command, in order not to loose
>>> information. People will do this by setting a large value, say
>>> 1024. This will be used for both the synchronous and asynchronous case.
>>
>> The same value will increase the output width of async shell commands,
>> but decrease the output width of synchronous shell commands from unlimited.
>
> Yes. You must set a proper value, large enough.
>
>>> And then there's the use case to have a fixed output width for special
>>> commands, in order to get a deterministic layout. This won't be applied
>>> globally, neither for synchronous nor for asynchronous
>>> `shell-command'. Rather, `shell-command-width' will be let-bound.
>>>
>>> And we have the advantage, that synchronous `shell-command' behaves
>>> consistently, for both the local and remote case.
>>>
>>> So I don't see a problem.
>>
>> If output truncation will apply to shell-command-on-region,
>> especially with its REPLACE arg, this would be a big problem.
>> After filtering the buffer contents with a shell command,
>> parts of the buffer will be lost.
>
> No. You can always undo the effect on buffer.

When it's customized to a width more than the window's width,
the user won't notice that the output was truncated and data lost.

We shouldn't cause data loss when unsuspecting users will customize this
option to increase the output width of async or remote shell commands.

There is already data loss in the output of async commands that are truncated.
A new option was intended to reduce data loss by allowing less truncation.

OTOH, currently there is no data loss in synchronous shell commands
that often are used to operate on the buffer's contents by using
shell-command-on-region where output is inserted to a file buffer and saved.

We shouldn't allow data loss in synchronous shell commands
at the cost of reducing data loss in async/remove shells.

There is no need for the new option to be consistent across
both synchronous and async/remote operations.

What we could do is to make clear the scope of the new option
in the documentation:

diff --git a/doc/emacs/misc.texi b/doc/emacs/misc.texi
index 7d7065a441..2f1a33e202 100644
--- a/doc/emacs/misc.texi
+++ b/doc/emacs/misc.texi
@@ -775,6 +775,13 @@ Single Shell
 displayed only when the command generates output, set
 @code{async-shell-command-display-buffer} to @code{nil}.
 
+@vindex shell-command-width
+  The option @code{shell-command-width} defines the number of display
+columns available for output of asynchronous or remote shell commands.
+A positive integer tells the shell to use that number of columns for
+command output.  The default value is @code{nil} that means to use
+the same number of columns as provided by the shell.
+
 @kindex M-|
 @findex shell-command-on-region
   @kbd{M-|} (@code{shell-command-on-region}) is like @kbd{M-!}, but
diff --git a/lisp/simple.el b/lisp/simple.el
index 160c433845..30d111a70b 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3352,7 +3352,7 @@ async-shell-command-display-buffer
   :version "26.1")
 
 (defcustom shell-command-width nil
-  "Number of display columns available for asynchronous shell command output.
+  "Number of display columns available for asynchronous/remote shell command.
 If nil, use the shell default number (usually 80 columns).
 If a positive integer, tell the shell to use that number of columns for
 command output."