tramp

tramp

[Miles Bader]

Is tramp in the current emacs CVS (2002-08-02) supposed to work?

I've tried a bunch of different filenames, and invariably tramp gets
confused and just hangs waiting for a prompt or something.  When I use
^G to interrupt it, and look at the `*tramp...*' buffer, I see a shell
prompt (but apparently tramp never realized it).


For instance, visiting:

`/sudo:root@localhost:/etc':

   Shows the following messages:

      tramp: Opening connection for `root' using `sudo'...
      tramp: Processing actions
      tramp: Waiting 60s for prompt from remote shell
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Found remote shell prompt.
      tramp: Waiting 30s for remote `/bin/sh' to come up...
      Quit

  [Seeing `Found remote shell prompt' immediately followed by 
   `Waiting 30s for remote `/bin/sh' to come up' seems ... odd.]

  Looking in the `*tramp/sudo root@localhost*' buffer, I see:

     sh-2.05b# 


`/su:root@localhost:/etc':

   Shows the following messages:

      tramp: Opening connection for `root' using `su'...
      tramp: Processing actions
      tramp: Waiting 60s for prompt from remote shell
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      Password: 
      Password: .
      Password: ..
      Password: .......
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
      tramp: Looking for pattern .*ogin: *
      tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
      tramp: Looking for pattern ^.*\(Permission denied.\|Login [Ii]ncorrect\|Received signal [0-9]+\|Connection \(refused\|closed\)\|Sorry, try again.\|Name or service not known\).*
      tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
      Quit

   [Note that even though the above appears as if it's asking a user
    question, it doesn't seem to accept any input; I have to interrupt
    it to do anything]

   Looking in the `*tramp/su root@localhost*' buffer, I see:


      mcspd15:~# 

   [that's a blank line at the beginning].


Trying to use the `ssh' method to connect to `fp-ssh.gnu.org' gives
similar results to the latter, but without the password prompt (I have
ssh setup to not require a password).

Thanks,

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: tramp

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Is tramp in the current emacs CVS (2002-08-02) supposed to work?
>
> I've tried a bunch of different filenames, and invariably tramp gets
> confused and just hangs waiting for a prompt or something.  When I use
> ^G to interrupt it, and look at the `*tramp...*' buffer, I see a shell
> prompt (but apparently tramp never realized it).

Yes, I think so.

> For instance, visiting:
>
> `/sudo:root@localhost:/etc':
>
>    Shows the following messages:
>
>       tramp: Opening connection for `root' using `sudo'...
>       tramp: Processing actions
>       tramp: Waiting 60s for prompt from remote shell
>       tramp: Looking for pattern ^.*\([pP]assword\|passphrase.*\):
>       tramp: Looking for pattern .*ogin: *
>       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*

This looks like your shell-prompt-pattern.  Is it?

>       tramp: Found remote shell prompt.
>       tramp: Waiting 30s for remote `/bin/sh' to come up...
>       Quit
>
>   [Seeing `Found remote shell prompt' immediately followed by 
>    `Waiting 30s for remote `/bin/sh' to come up' seems ... odd.]

Heh :-)  First, Tramp logs in to the remote system and waits for any
old shell prompt.  But for proper operation, Tramp needs a Bourneish
shell, so it issues "exec /bin/sh" first thing.  Of course, after
this Tramp again has to wait for a shell prompt...

Maybe I should make this clearer in the messages.  But how?

>   Looking in the `*tramp/sudo root@localhost*' buffer, I see:
>
>      sh-2.05b# 

At this point, Tramp is again waiting for shell-prompt-pattern, and
this shell prompt does not match the regexp above.

Could this be the case?

It used to be that Tramp tried to grok some common shell prompts in
addition to shell-prompt-pattern.  Maybe I should re-add this feature.

>       tramp: Looking for pattern Are you sure you want to continue connecting (yes/no)\? *
>       Quit
>
>    [Note that even though the above appears as if it's asking a user
>     question, it doesn't seem to accept any input; I have to interrupt
>     it to do anything]

Hm.  Maybe this "looking for pattern" stuff should be removed from
the default debugging messages.

>    Looking in the `*tramp/su root@localhost*' buffer, I see:
>
>
>       mcspd15:~# 
>
>    [that's a blank line at the beginning].

Looks like the same shell prompt problem.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> >       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
> 
> This looks like your shell-prompt-pattern.  Is it?

Ah, perhaps it is.  Since shell-prompt-pattern is basically not used anymore,
I had forgotten that I had one.  However, in this case it's still clearly
wrong, since it's not _my_ shell that's being started, but root's.

> At this point, Tramp is again waiting for shell-prompt-pattern, and
> this shell prompt does not match the regexp above.
> 
> It used to be that Tramp tried to grok some common shell prompts in
> addition to shell-prompt-pattern.  Maybe I should re-add this feature.

I think it _definitely_ should match common shell prompts, as
`shell-prompt-pattern' is quite likely to be wrong, for the reasons I gave
above:

 (1) It's not used by shell-mode anymore, so it's going to suffer bit-rot.

 (2) In many cases, a shell started by tramp will be in a `different
     context' than a normal user-shell, and so will have a different
     prompt anyway.

Probably it ought to be possible to modify this on a per-connection-type and
per-machine basis (but presumably that will be handled by the whizzy config
mechanism that will added to address other problems, right?).

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: tramp

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> >       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
>> 
>> This looks like your shell-prompt-pattern.  Is it?
>
> Ah, perhaps it is.  Since shell-prompt-pattern is basically not used anymore,
> I had forgotten that I had one.  However, in this case it's still clearly
> wrong, since it's not _my_ shell that's being started, but root's.

Right.

>> At this point, Tramp is again waiting for shell-prompt-pattern, and
>> this shell prompt does not match the regexp above.
>> 
>> It used to be that Tramp tried to grok some common shell prompts in
>> addition to shell-prompt-pattern.  Maybe I should re-add this feature.
>
> I think it _definitely_ should match common shell prompts, as
> `shell-prompt-pattern' is quite likely to be wrong, for the reasons I gave
> above:

Okay, Tramp now has its own variable, tramp-shell-prompt-pattern,
that users can set.  The default value is the same as the default
value for shell-prompt-pattern, so it should match the prompts that
your examples showed.

>  (1) It's not used by shell-mode anymore, so it's going to suffer bit-rot.

Ah.  Hm.  shell-mode just assumes that everything on the last line is
a prompt, right?  Hm.  But I think it's not possible for Tramp to
assume something similar.

It is vital for Tramp to wait until it sees a shell prompt before
sending something to the remote shell.  If you send input to the
remote shell too early, things go wrong in a quite horrible way
(depending on the remote login program that you are using).

But maybe waiting for the shell prompt is not the right thing to do.
What could Tramp do instead?

(After Tramp has ascertained that it is indeed talking to the remote
shell, it sets the shell prompt to a special value and then uses
that, and this mechanism works well.  I haven't heard any complaints,
yet, at least :-)

>  (2) In many cases, a shell started by tramp will be in a `different
>      context' than a normal user-shell, and so will have a different
>      prompt anyway.
>
> Probably it ought to be possible to modify this on a per-connection-type and
> per-machine basis (but presumably that will be handled by the whizzy config
> mechanism that will added to address other problems, right?).

Is it really necessary to modify the regexp like this?  Isn't it
enough for the user to set one value which covers all alternatives?

If possible, I would like to avoid having too many parameters that
are based on method or machine.

But I'm having similar arguments about tramp-remote-path.  It's also
just one variable, and people are requesting me to make it
configurable on a per-host basis.  But I think it is sufficient to
have one global value which contains all the directories on all the
hosts.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: tramp

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Tramp now has its own variable, tramp-shell-prompt-pattern, that users
> can set.  The default value is the same as the default value for
> shell-prompt-pattern, so it should match the prompts that your examples
> showed.

I just tried tramp /su:localhost:/etc again today, and it works!

Startup's a bit slow though; it'd be nice if all the file-downloading
&c could be omitted on a local connection (presumably that couldn't be
the default, but it could be configurable).  Actually it would be nice
to be able to say, for _any_ specific host/user/method combo `I've
already installed tools x&y, here's where you can find them.  Yet
another job for the whizzy per-method/machine/user configuration alist.
[I guess there are probably variables for this; I've not checked.]

> shell-mode just assumes that everything on the last line is a prompt,
> right?  Hm.  But I think it's not possible for Tramp to assume something
> similar.

Probably not.

> It is vital for Tramp to wait until it sees a shell prompt before
> sending something to the remote shell.  If you send input to the
> remote shell too early, things go wrong in a quite horrible way
> (depending on the remote login program that you are using).
> 
> But maybe waiting for the shell prompt is not the right thing to do.
> What could Tramp do instead?

I don't know; is simply waiting for _some_ output too optimistic?

> >  (2) In many cases, a shell started by tramp will be in a `different
> >      context' than a normal user-shell, and so will have a different
> >      prompt anyway.
> >
> > Probably it ought to be possible to modify this on a
> > per-connection-type and per-machine basis (but presumably that will be
> > handled by the whizzy config mechanism that will added to address
> > other problems, right?).
> 
> Is it really necessary to modify the regexp like this?  Isn't it
> enough for the user to set one value which covers all alternatives?

Perhaps, but I think for me, it's more natural to think in little bits,
for concrete cases, rather than trying to cover all cases with one mondo
regexp.

It's also possible that there will in fact be conflicts, though I haven't
any personal experience of any (e.g., host X uses a shell prompt that
actually matches some other non-shell prompt login output on host Y).

> If possible, I would like to avoid having too many parameters that
> are based on method or machine.
> 
> But I'm having similar arguments about tramp-remote-path.  It's also
> just one variable, and people are requesting me to make it configurable
> on a per-host basis.  But I think it is sufficient to have one global
> value which contains all the directories on all the hosts.

I think this is a much more dangerous assumption than in the prompt case,
since what is a trusted directory on one host may not be on another.

Since there definitely are parameters which will have to be host/method
specific, and that you're better off simply making a general mechanism by
which _all_ parameters can be set on a host/method specific manner.

E.g., just an alist containing machine/method/user specs, and variables
and values, which tramp will run down and do
  (set (make-local-variable VAR) val)
inside the tramp work buffer.  Then the code can use simple variables,
but the user still gets max flexibility where needed.

An example format might be:

  ((SPEC (VAR . VAL) ...) ...)

where SPEC is either a regexp matching the hostname, or a tuple like
(HOST USER METHOD) where the components are regexps or nil (meaning
match anything).

That's what I want.

[I haven't looked at tramp's code though, so perhaps the above is not a
workable solution.]

Thanks,

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: tramp

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Since there definitely are parameters which will have to be host/method
> specific, and that you're better off simply making a general mechanism by
> which _all_ parameters can be set on a host/method specific manner.
> 
> E.g., just an alist containing machine/method/user specs, and variables
> and values, which tramp will run down and do
>   (set (make-local-variable VAR) val)
> inside the tramp work buffer.  Then the code can use simple variables,
> but the user still gets max flexibility where needed.
> 
> An example format might be:
> 
>   ((SPEC (VAR . VAL) ...) ...)
> 
> where SPEC is either a regexp matching the hostname, or a tuple like
> (HOST USER METHOD) where the components are regexps or nil (meaning
> match anything).
> 
> That's what I want.
> 

So do I.

I have actually very few remote machines I connect to, so I would
like to be able to configure tramp for each of those with the
optimal set of parameters (and faster connect times).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

New start up splash screen annoyance...

[Sascha Wilde]

Hi *,

basically I like the idea of a configurable start-up behavior.  But
the current implementation is IMNSHO very flawed:

- First and most annoying: starting Emacs with an file to visit as
  argument no longer works as expected.  Without doing any configuration
  you always get the new splash screen and of cause C-l or starting
  editing doesn't make it go away.  You can switch to the buffer with
  the file using C-x C-b, but the splash screen doesn't tell you that.

I would like to have the old behavior back:  if a file name was given
on the command line the user definitely wants to edit that file, and
so any editing/movement/redraw command should switch to that files
buffer immediately.  In case people don't agree on that, the splash
screen should at least mention how to enter the buffer.

- Second, and maybe even worse: None of the settings for
  initial-buffer-choice restores the old behavior.  One might expect,
  that setting initial-buffer-choice to t (open *scratch* buffer)
  would be the right choice, but it isn't.  If set that way, the
  annoying behavior described above stays with the only differences,
  that the *scratch* buffer is opened and stays, even if a file to
  edit was given on start-up.

One would expect that at least one value of initial-buffer-choice
would restore the old behavior, which many of use are used to and
which at least me likes best: open *scratch* as default but open the
buffer(s) for the given files from the command line if there were
any. 

The only working solution is to set inhibit-splash-screen to t
and leave initial-buffer-choice nil -- which is a pity as the new
possibility of customizing the default behavior is lost.

- Third, as setting inhibit-splash-screen is the only (and as far as I
  can see not ell documented) way to get back the old behavior, it is
  a (minor) annoyance that inhibit-splash-screen not only turns of the
  splash screen, but the initial message in the *scratch* buffer too.
  Actually I never understood why this two things are configured by
  only one variable.

cheers
sascha
-- 
Sascha Wilde
    "Liebet eure Feinde, vielleicht schadet das ihrem Ruf" 
    (Stanislaw Jerzy Lec)

Re: New start up splash screen annoyance...

[Richard Stallman]

    I would like to have the old behavior back:  if a file name was given
    on the command line the user definitely wants to edit that file, and
    so any editing/movement/redraw command should switch to that files
    buffer immediately.

I changed this because I want beginners to see the splash screen,
and beginners often have the habit of passing a file name.

      In case people don't agree on that, the splash
    screen should at least mention how to enter the buffer.

That is a good point.  We should make this easier.  Maybe typing SPC
on the splash screen should bury or kill it.  Also, we should say how
to do this, if we can fit it in.

    - Second, and maybe even worse: None of the settings for
      initial-buffer-choice restores the old behavior.

Given that we have another variable to do that,
who cares whether this variable can do that?
Why do you care?

    - Third, as setting inhibit-splash-screen is the only (and as far as I
      can see not ell documented) way to get back the old behavior, it is
      a (minor) annoyance that inhibit-splash-screen not only turns of the
      splash screen, but the initial message in the *scratch* buffer too.
      Actually I never understood why this two things are configured by
      only one variable.

We could change it not to affect the initial message in *scratch*.
However, if *scratch* is not the initial buffer, is that message
really needed anyway?  Maybe we should just get rid of it.

Re: New start up splash screen annoyance...

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     I would like to have the old behavior back:  if a file name was given
>     on the command line the user definitely wants to edit that file, and
>     so any editing/movement/redraw command should switch to that files
>     buffer immediately.
>
> I changed this because I want beginners to see the splash screen,
> and beginners often have the habit of passing a file name.

The way Emacs currently handles the splash screen is completely
unsatisfactory, because it gives the impression that the splash screen
is being displayed *instead of* the file specified by the user (and
thus implies that Emacs is unable to process command line arguments.)

The way other programs handle this is to (1) display the splash screen
in a small, floating X window, (2) provide a check box on the splash
screen saying "Display splash screen on startup" or something similar,
and (3) a prominent button saying "OK" or similar to dismiss the
splash screen.

Using a small, floating X window lets the user see that the command
line argument was processed correctly, since the main X window is
visible behind the splash screen panel.  In our case, it may be better
to use a pop-to-buffer.  Providing a check box makes it easy to
dismiss the splash screen, which in my experience almost everyone ends
up doing, since a splash screen gets annoying after the first time you
see it (and you shouldn't have to read the documentation to find out
how to disable it!)

Re: New start up splash screen annoyance...

[Juri Linkov]

> The way Emacs currently handles the splash screen is completely
> unsatisfactory, because it gives the impression that the splash screen
> is being displayed *instead of* the file specified by the user (and
> thus implies that Emacs is unable to process command line arguments.)

Yes, this looks like a bug, and this is confusing for beginners who don't
know how to turn this behavior off.

> The way other programs handle this is to (1) display the splash screen
> in a small, floating X window,

Clicking on the close button to close the floating X window is no less
annoying solution that typing a key to close the current startup screen.

> (2) provide a check box on the splash screen saying "Display splash
> screen on startup" or something similar, and

Now there is a link on the startup screen leading to customization,
so it is easier now to disable the startup screen.  But still this doesn't
remove the problem, because customization is not always desirable.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: New start up splash screen annoyance...

[Richard Stallman]

    > The way Emacs currently handles the splash screen is completely
    > unsatisfactory, because it gives the impression that the splash screen
    > is being displayed *instead of* the file specified by the user (and
    > thus implies that Emacs is unable to process command line arguments.)

    Yes, this looks like a bug, and this is confusing for beginners who don't
    know how to turn this behavior off.

The best way is: don't specify a file name argument when you start
Emacs.  That kind of argument is supported for compatibility with
other editors, but it is not the recommended way to use Emacs.
Experienced Emacs users generally don't do it anyway.

Re: New start up splash screen annoyance...

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > The way Emacs currently handles the splash screen is completely
>     > unsatisfactory, because it gives the impression that the splash screen
>     > is being displayed *instead of* the file specified by the user (and
>     > thus implies that Emacs is unable to process command line arguments.)
>
>     Yes, this looks like a bug, and this is confusing for beginners who don't
>     know how to turn this behavior off.
>
> The best way is: don't specify a file name argument when you start
> Emacs.  That kind of argument is supported for compatibility with
> other editors, but it is not the recommended way to use Emacs.

So what is the recommended way to use Emacs when one wants to edit a
file and has no Emacs session started already?  And why would I start
an Emacs session when I don't want to edit anything?

> Experienced Emacs users generally don't do it anyway.

Huh?  If I start Emacs, why should I not specify what file I want to
edit as an experienced user?

-- 
David Kastrup

Re: New start up splash screen annoyance...

[Richard Stallman]

    So what is the recommended way to use Emacs when one wants to edit a
    file and has no Emacs session started already?

If you have no Emacs running, type `emacs'.
Otherwise, resume your existing Emacs.

Then type C-x C-f FILE RET.

    > Experienced Emacs users generally don't do it anyway.

    Huh?  If I start Emacs, why should I not specify what file I want to
    edit as an experienced user?

Because nearly always you already have an Emacs running.
It is a bad idea to teach yourself habits that presume
you don't have an Emacs running, because that would lead
you to kill Emacs and restart it, or to start multiple Emacs jobs.

Over 20 years of Emacs experience shows that it is important to teach
beginners to unlearn the habit of finding a file by typing `emacs FILE'.

Re: New start up splash screen annoyance...

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     So what is the recommended way to use Emacs when one wants to edit a
>     file and has no Emacs session started already?
>
> If you have no Emacs running, type `emacs'.
> Otherwise, resume your existing Emacs.
>
> Then type C-x C-f FILE RET.
>
> It is a bad idea to teach yourself habits that presume
> you don't have an Emacs running, because that would lead
> you to kill Emacs and restart it, or to start multiple Emacs jobs.
>
> Over 20 years of Emacs experience shows that it is important to teach
> beginners to unlearn the habit of finding a file by typing `emacs FILE'.

What you say may have been true 20 years ago.

On modern computers, Emacs starts up so quickly and uses such an
insignificant amount of memory that there is basically much no
difference between starting a new Emacs and returning to a
pre-existing Emacs session.

Folding emacsclient into emacs (was: New start up splash screen annoyance...)

[Bill Wohler]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     So what is the recommended way to use Emacs when one wants to edit a
>>     file and has no Emacs session started already?
>>
>> If you have no Emacs running, type `emacs'.
>> Otherwise, resume your existing Emacs.
>>
>> Then type C-x C-f FILE RET.
>>
>> It is a bad idea to teach yourself habits that presume
>> you don't have an Emacs running, because that would lead
>> you to kill Emacs and restart it, or to start multiple Emacs jobs.
>>
>> Over 20 years of Emacs experience shows that it is important to teach
>> beginners to unlearn the habit of finding a file by typing `emacs FILE'.
>
> What you say may have been true 20 years ago.
>
> On modern computers, Emacs starts up so quickly and uses such an
> insignificant amount of memory that there is basically much no
> difference between starting a new Emacs and returning to a
> pre-existing Emacs session.

Agreed.

Not only that, consider other legitimate use cases such as "sudo emacs
FILE" or "ssh SOME_REMOTE_MACHINE; emacs -nw FILE". Emacs would start
up as fast as vi if it weren't for the blasted splash screen that
needs to be dismissed.

I like David's idea of "Welcome! To learn about Emacs, press F1 C-a or
use the Help/About menu." And it can go in the mini-buffer where it
will not contribute to the principle of least astonishment (or most
annoyance, whatever the case may be).

Here's something completely different: If it hurts when the user does
something, don't let them do it.

Many programs today will attach themselves to an existing process when
started. Emacs can do the same thing. If the "emacs" executable
detects an existing process on the local machine owned by the same
user in the same session (X server), and the -nw option is not
specified, it can behave like emacsclient; otherwise, it starts a new
process.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Folding emacsclient into emacs

[David Kastrup]

Bill Wohler <wohler@newt.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> On modern computers, Emacs starts up so quickly and uses such an
>> insignificant amount of memory that there is basically much no
>> difference between starting a new Emacs and returning to a
>> pre-existing Emacs session.
>
> Agreed.

Not here.

> Not only that, consider other legitimate use cases such as "sudo
> emacs FILE" or "ssh SOME_REMOTE_MACHINE; emacs -nw FILE".

C-x C-f /sudo::FILE RET
C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET

> Here's something completely different: If it hurts when the user
> does something, don't let them do it.
>
> Many programs today will attach themselves to an existing process
> when started. Emacs can do the same thing. If the "emacs" executable
> detects an existing process on the local machine owned by the same
> user in the same session (X server), and the -nw option is not
> specified, it can behave like emacsclient; otherwise, it starts a
> new process.

Emacs is not multi-threaded, so there are legitimate use cases to have
several Emacs sessions open.  Actually, another argument against the
"there need only be one" claim.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Tramp (was: Folding emacsclient into emacs)

[Bill Wohler]

David Kastrup <dak@gnu.org> wrote:

> C-x C-f /sudo::FILE RET
> C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET

How about if I want to run "M-x svn-status RET / RET" as root locally.

How about if I want to run "M-x svn-status RET DIRECTORY RET" as either
me or as root on a remote machine? Note that the remote machine is
configured to not accept ssh connections as root--you have to log in as
another user first. I tried "M-x svn-status RET /ssh:host:~wohler RET"
and that produced a view of my home directory on localhost.

Also, I read in the manual (for tramp version 2.1.11) about
tramp-default-proxies-alist so that one can edit files as root on a
remote host, but that variable does not appear to be available in tramp
2.0.55 (in Emacs 22).

Thanks again.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Tramp

[David Kastrup]

Bill Wohler <wohler@newt.com> writes:

> David Kastrup <dak@gnu.org> wrote:
>
>> C-x C-f /sudo::FILE RET
>> C-x C-f /ssh:SOME_REMOTE_MACHINE:FILE RET
>
> How about if I want to run "M-x svn-status RET / RET" as root
> locally.

M-x svn-status RET /sudo::/ RET

> How about if I want to run "M-x svn-status RET DIRECTORY RET" as either
> me or as root on a remote machine?

M-x svn-status RET /ssh:root@SOME_REMOTE_MACHINE:FILE RET

> Note that the remote machine is configured to not accept ssh
> connections as root--you have to log in as another user first.

> I tried "M-x svn-status RET /ssh:host:~wohler RET" and that produced
> a view of my home directory on localhost.

Then there is something wrong and you should file a proper bug report.

> Also, I read in the manual (for tramp version 2.1.11) about
> tramp-default-proxies-alist so that one can edit files as root on a
> remote host, but that variable does not appear to be available in
> tramp 2.0.55 (in Emacs 22).

You can use multihop methods.

-- 
David Kastrup

Re: Tramp

[Michael Albinus]

Bill Wohler <wohler@newt.com> writes:

> How about if I want to run "M-x svn-status RET / RET" as root locally.
>
> How about if I want to run "M-x svn-status RET DIRECTORY RET" as either
> me or as root on a remote machine? Note that the remote machine is
> configured to not accept ssh connections as root--you have to log in as
> another user first. I tried "M-x svn-status RET /ssh:host:~wohler RET"
> and that produced a view of my home directory on localhost.

All this should be possible with Tramp 2.1, which is integrated in the
Emacs trunk.

> Also, I read in the manual (for tramp version 2.1.11) about
> tramp-default-proxies-alist so that one can edit files as root on a
> remote host, but that variable does not appear to be available in tramp
> 2.0.55 (in Emacs 22).

Emacs 22.x won't be upgraded to Tramp 2.1 I suspect. So you must
either use Emacs 23.0.50 (that is the Emacs trunk from CVS), or
install Tramp 2.1 in parallel to Emacs 22.

> Thanks again.

Best regards, Michael.