[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Q on using shell mode remotely
From: |
Drew Adams |
Subject: |
RE: Q on using shell mode remotely |
Date: |
Wed, 2 Aug 2006 08:42:00 -0700 |
> (eval-after-load "telnet"
> '(setq telnet-prompt-pattern
> (concat telnet-prompt-pattern
> "\\([12]?[0-9]:[0-5][0-9][ap]m\\)?")))
>
> I'll use `telnet-prompt-pattern', myself, to hack this problem,
Please let us know if it works.
It works perfectly. Thanks, Kevin.
Looking at telnet.el:
I didn't have time to track down why it works, but it does, so I'm happy.
> but it would
> be good if there were a variable that dealt with $rprompt somehow.
I don't see how it could. The remote csh presumably displays $rprompt
on the right side of the screen via terminal escape codes or simple
ASCII control characters; but the telnet subprocess is discarding that
data, either explicitly via telnet-filter or implicitly via process-
connection-type. So you end up with $rprompt displayed immediately
adjacent to $prompt in your *telnet-HOST* buffer, and you've got to
account for that via telnet-prompt-regexp.
Yes, but if the telnet subprocess can discard the control characters or
whatever, then it could also, say, discard the $rprompt stuff. I'm not
saying it should do that systematically, but it might be good to have an
option to do so.
Anyway, thanks again.
BTW, I filed a bug, to see if we can't 1) make `telnet-prompt-pattern' into
a user option, like `shell-prompt-pattern', and 2) get more visibility for
some of the telnet-specific stuff like `telnet-prompt-pattern' in `C-h m'.
Dired mode describes options and commands, for instance, and that's quite
helpful.