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

[Juri Linkov <juri@linkov.net>]

>>> Thanks. However, I've meant this also for synchronous
>>> `shell-command'. You have implemented this only for asynchronous.
>>>
>>> The synchronous `shell-command' does not suffer from the buffer width
>>> restriction. But there might be use cases to set a fixed width, for
>>> example if you want to get a well-defined output layout.
>>
>> Oh, I don't know what to do in case when only the current limit
>> on the output of asynchronous commands should be increased, but
>> the output of synchronous commands needs to be left unlimited.
>> I have no idea how to customize it in this case.
>
> 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.

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