unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#3957: split window for remote commands through eshell
@ 2009-07-28 19:03 Colin Williams
  2009-07-29 15:42 ` Stefan Monnier
  0 siblings, 1 reply; 4+ messages in thread
From: Colin Williams @ 2009-07-28 19:03 UTC (permalink / raw)
  To: bug-gnu-emacs

Basically, any time a remote command gets executed through eshell, if
the frame is a single window it gets split into two windows.
Essentially, this is because tramp does its magic through
shell-command, which pops up a window if the output is too large to
fit in the minibuffer.

My first reaction was to wrap the relevant call to shell-command in a
save-window-excursion, but there seem to be some problems with that.
I'm currently trying to figure out how to prevent the root split, so
things like new frames are blocked as well.

It was suggested that I send the bug to this list so that a task would
be created that could be tracked.

Colin






^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#3957: split window for remote commands through eshell
  2009-07-28 19:03 bug#3957: split window for remote commands through eshell Colin Williams
@ 2009-07-29 15:42 ` Stefan Monnier
  2014-01-20 13:18   ` Michael Albinus
  0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2009-07-29 15:42 UTC (permalink / raw)
  To: Colin Williams; +Cc: 3957

> Basically, any time a remote command gets executed through eshell, if
> the frame is a single window it gets split into two windows.
> Essentially, this is because tramp does its magic through
> shell-command, which pops up a window if the output is too large to
> fit in the minibuffer.

I think the problem is not really in Tramp since Tramp just implements
shell-command according to its docstring; C-h v shell-command RET:

  [...]
  Execute string command in inferior shell; display output, if any.

I.e. the problem is that Eshell shouldn't use shell-command but
something else.
[ And probably shell-command should not be a file operation
  (i.e. shouldn't go through find-file-name-handler), instead it should
  use process-file or start-file-process. ]

> I'm currently trying to figure out how to prevent the root split, so
> things like new frames are blocked as well.

I think the right fix might be to make eshell-external-command (and
eshell-remote-command) use process-file or start-file-process.

Tho for async commands (that end in &), shell-command's behavior to open
a separate window/buffer for the command's output probably makes a lot
of sense.  So maybe this bug-report is only for remote commands that
don't end in &.


        Stefan





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#3957: split window for remote commands through eshell
  2009-07-29 15:42 ` Stefan Monnier
@ 2014-01-20 13:18   ` Michael Albinus
  2014-01-28 10:22     ` Michael Albinus
  0 siblings, 1 reply; 4+ messages in thread
From: Michael Albinus @ 2014-01-20 13:18 UTC (permalink / raw)
  To: Colin Williams; +Cc: 3957

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Colin,

>> Basically, any time a remote command gets executed through eshell, if
>> the frame is a single window it gets split into two windows.
>> Essentially, this is because tramp does its magic through
>> shell-command, which pops up a window if the output is too large to
>> fit in the minibuffer.
>
> I think the problem is not really in Tramp since Tramp just implements
> shell-command according to its docstring; C-h v shell-command RET:
>
>   [...]
>   Execute string command in inferior shell; display output, if any.
>
> I.e. the problem is that Eshell shouldn't use shell-command but
> something else.
> [ And probably shell-command should not be a file operation
>   (i.e. shouldn't go through find-file-name-handler), instead it should
>   use process-file or start-file-process. ]
>
>> I'm currently trying to figure out how to prevent the root split, so
>> things like new frames are blocked as well.
>
> I think the right fix might be to make eshell-external-command (and
> eshell-remote-command) use process-file or start-file-process.

Since Emacs 24.3, eshell-remote-command is not used
anymore. eshell-external-command calls start-file-process. This should
have fixed the issue, could you, please, check? Something like this:

~ $ cd /sudo::
/sudo:root@uw001237:/root $ ls -al /
total 155
drwxr-xr-x  22 root           root      4096 2013-12-05  2013 .
drwxr-xr-x  22 root           root      4096 2013-12-05  2013 ..
drwxr-xr-x   2 root           root      4096 2013-10-29  2013 bin
drwxr-xr-x   4 root           root      2048 2013-12-05  2013 boot
drwxr-xr-x  16 root           root      4360 2014-01-20 12:04 dev
drwxr-xr-x 176 root           root     12288 2014-01-14 15:45 etc
drwxr-xr-x   6 root           root      4096 2013-01-16  2013 home
lrwxrwxrwx   1 root           root        37 2013-12-05  2013 initrd.img -> /boot/initrd.img-3.2.0-58-generic-pae
lrwxrwxrwx   1 root           root        37 2013-11-15  2013 initrd.img.old -> /boot/initrd.img-3.2.0-57-generic-pae
drwxr-xr-x  24 root           root      4096 2014-01-06 13:16 lib
drwx------   2 root           root     16384 2012-07-23  2012 lost+found
drwxr-xr-x   2 root           root      4096 2014-01-14 11:35 media
drwxr-xr-x   2 root           root      4096 2012-04-19  2012 mnt
drwxr-xr-x   3 root           root      4096 2012-07-23  2012 opt
dr-xr-xr-x 227 root           root         0 2014-01-10 10:35 proc
drwx------  10 root           root      4096 2013-11-11  2013 root
drwxr-xr-x  28 root           root      1040 2014-01-14 07:14 run
drwxr-xr-x   2 root           root     12288 2013-10-29  2013 sbin
drwxr-xr-x   2 root           root      4096 2012-03-05  2012 selinux
drwxr-xr-x   2 root           root      4096 2012-07-23  2012 srv
drwxr-xr-x  13 root           root         0 2014-01-10 10:35 sys
drwxrwxrwt  19 root           root     57344 2014-01-20 14:13 tmp
drwxr-xr-x  10 root           root      4096 2012-07-23  2012 usr
drwxr-xr-x  14 root           root      4096 2014-01-10 10:34 var
lrwxrwxrwx   1 root           root        33 2013-12-05  2013 vmlinuz -> boot/vmlinuz-3.2.0-58-generic-pae
lrwxrwxrwx   1 root           root        33 2013-11-15  2013 vmlinuz.old -> boot/vmlinuz-3.2.0-57-generic-pae

> Tho for async commands (that end in &), shell-command's behavior to open
> a separate window/buffer for the command's output probably makes a lot
> of sense.  So maybe this bug-report is only for remote commands that
> don't end in &.

There is no special handling for asynchronous remote processes in
eshell, they behave like local asynchronous processes. If we want to
treat asynchronous processes differently than the current behaviour, we
might check eshell-do-eval. However, I don't see a need for it. That
would require another bug report.

>         Stefan

Best regards, Michael.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#3957: split window for remote commands through eshell
  2014-01-20 13:18   ` Michael Albinus
@ 2014-01-28 10:22     ` Michael Albinus
  0 siblings, 0 replies; 4+ messages in thread
From: Michael Albinus @ 2014-01-28 10:22 UTC (permalink / raw)
  To: Colin Williams; +Cc: 3957-done

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

> Since Emacs 24.3, eshell-remote-command is not used
> anymore. eshell-external-command calls start-file-process. This should
> have fixed the issue, could you, please, check?

No response, so I'm closing this bug. Feel free to reopen if it doesn't
work as expected.

Best regards, Michael.





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-01-28 10:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-28 19:03 bug#3957: split window for remote commands through eshell Colin Williams
2009-07-29 15:42 ` Stefan Monnier
2014-01-20 13:18   ` Michael Albinus
2014-01-28 10:22     ` Michael Albinus

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).