all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 35055@debbugs.gnu.org
Subject: bug#35055: 27.0.50; async-shell-command truncates output lines
Date: Mon, 01 Apr 2019 23:44:59 +0300	[thread overview]
Message-ID: <877ecd797c.fsf@mail.linkov.net> (raw)
In-Reply-To: <875zrym4eo.fsf@gmx.de> (Michael Albinus's message of "Mon, 01 Apr 2019 12:00:15 +0200")

>> 1. Open a wide frame and type:
>>
>> 2. `M-& ps aux RET'
>>
>> 3. observe that output lines are truncated at column 80
>
> In my case, output lines are truncated at column 89. In fact the
> truncation happens exactly at the size of the *Async Shell Command*
> buffer.

This is strange.  I tried in `emacs -Q' in a wide frame and
output lines of `ps aux' are always truncated at column 80.

Then I tried to affect the number of columns with the
environment variable COLUMNS, and when using

  M-& COLUMNS=89 ps aux

only then output lines are truncated at column 89.
Trying different values produced different truncation:

  COLUMNS=0 ps aux      - column 80
  COLUMNS=1 ps aux      - column 68
  COLUMNS=5 ps aux      - column 70
  COLUMNS=20 ps aux     - column 80
  COLUMNS=30 ps aux     - column 90
  COLUMNS=40 ps aux     - column 80
  COLUMNS=50 ps aux     - column 100
  COLUMNS=60 ps aux     - column 120
  COLUMNS=70 ps aux     - column 70
  COLUMNS=131071 ps aux - practically unlimited
  COLUMNS=131072 ps aux - again column 80 (looks like maximum reached)

i.e. dependency is not linear.

Also `M-x shell' uses `comint-term-environment' to set COLUMNS
to window-width, but it does this only initially,
so after resizing the shell window, COLUMNS remains
at the old initial value.

>> OTOH, there is no such problem with `M-! ps aux RET'
>> where lines are not truncated at all.
>>
>> So the question is: why `M-&' (async-shell-command) limits COLUMNS to 80,
>> even on wide frames, whereas `M-!' (shell-command) has no limitation.
>
> Internally, M-! uses `call-process', and M-& uses
> `start-file-process'. They have different implementations.
>
> Synchronous processes do not care about the buffer width. So you see
> untruncated output.
>
> Asynchronous processes care. They send the information about buffer
> dimensions with the function `set-process-window-size', see
> (info "(elisp) Process Buffers")
>
> There is the variable `window-adjust-process-window-size-function' which
> controls how the dimension information is given to the underlying
> process.

Thanks for the pointer to process-window-size functions.
I tried to debug them in `emacs -Q', not to affect its default
behavior with customization of async-shell-command-display-buffer
that complicates the issue more.

But it seems `set-process-window-size' has no effect on
the truncated columns.  I see that `set-process-window-size'
in `window--adjust-process-windows' is called with WIDTH
more than 80, but the output of `ps aux' is still truncated
to 80 columns in *Async Shell Command*.

> I'm not sure whether there exists already a configuration option to
> allow asynchronous shell commands using infinite line width, but it
> could be implemented this way.
>
> Note that for remote shell commands the situation is even worse, because
> it sets the process property `adjust-window-size-function' to nil,
> overwriting any setting in `window-adjust-process-window-size-function'.
> This affects even synchronous `shell-command' calls, because they are
> implemented Tramp internally as asynchronous process.

I had truncated output of remote `shell-command' for a long time
and thought that it's impossible to do anything with this,
but now that you mentioned remote shell commands, I tried
to affect their output with a quite large value of COLUMNS
and get untruncated output even on remote.





  reply	other threads:[~2019-04-01 20:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-30 21:55 bug#35055: 27.0.50; async-shell-command truncates output lines Juri Linkov
2019-04-01 10:00 ` Michael Albinus
2019-04-01 20:44   ` Juri Linkov [this message]
2019-04-02  9:27     ` Michael Albinus
2019-04-03 20:36       ` Juri Linkov
2019-04-04 20:59         ` Juri Linkov
2019-04-05 12:35           ` Michael Albinus
2019-04-06 20:47             ` Juri Linkov
2019-04-07  7:32               ` Michael Albinus
2019-04-07 20:15                 ` Juri Linkov
2019-04-08  7:39                   ` Michael Albinus
2019-04-08 20:23                     ` Juri Linkov
2019-04-13 10:45                       ` Michael Albinus
2019-04-13 21:48                         ` Juri Linkov
2019-04-14 17:55                           ` Michael Albinus
2019-04-14 19:41                             ` Juri Linkov
2019-04-15  7:47                               ` Michael Albinus
2019-04-16 20:39                                 ` Juri Linkov
2019-04-17  7:22                                   ` Michael Albinus
2019-04-17 20:13                                     ` Juri Linkov
2019-04-18  7:40                                       ` Michael Albinus
2019-04-18 20:51                                         ` Juri Linkov
2019-04-19  7:21                                           ` Michael Albinus
2019-04-30 21:17                                           ` Michael Albinus
2019-05-01 21:07                                             ` Juri Linkov
2019-05-02  9:02                                               ` Michael Albinus
2019-05-02 20:57                                                 ` Juri Linkov
2019-05-03  7:20                                                   ` Michael Albinus
2019-05-05 19:27                                                     ` Juri Linkov
2019-05-06  9:28                                                       ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877ecd797c.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=35055@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.