[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q on using shell mode remotely
From: |
Kevin Rodgers |
Subject: |
Re: Q on using shell mode remotely |
Date: |
Tue, 01 Aug 2006 17:52:03 -0600 |
User-agent: |
Thunderbird 1.5.0.5 (Windows/20060719) |
Drew Adams wrote:
Kevin Rodgers wrote:
Why can't you just add a time pattern to telnet-prompt-pattern, which is
used to set the buffer-local value of comint-prompt-pattern:
(eval-after-load "telnet"
'(setq telnet-prompt-pattern
(concat telnet-prompt-pattern
"\\([12]?[0-9]:[0-5][0-9][ap]m\\)?")))
Thanks again. I didn't know about `telnet-prompt-pattern'. I used `C-h m'
and searched for "prompt", but the only occurences there are
`comint-next-prompt' and `comint-previous-prompt'. I found nothing in the
manual either. (I should have just used completion or apropos to look for a
"telnet-" prompt variable.)
I'll use `telnet-prompt-pattern', myself, to hack this problem,
Please let us know if it works. Looking at telnet.el:
1. M-x telnet runs telnet-program via make-comint, with
telnet-initial-filter as the process filter, then calls telnet-mode.
2. telnet-mode sets the buffer-local value of comint-prompt-regexp to
telnet-prompt-pattern.
3. telnet-initial-filter calls invokes
telnet-check-software-type-initialize, then resets the process filter
to telnet-filter.
a. If telnet-check-software-type-initialize sees "unix" in its STRING
argument, it resets telnet-prompt-pattern to comint-prompt-regexp;
then regardless of STRING, it resets comint-prompt-regexp to
telnet-prompt-pattern.
So it seems that (3) could prevent (2) from accomplishing its intended
effect, if (3) ran before (2).
Then, comint.el ignores comint-prompt-regexp anyway unless
comint-use-prompt-regexp is non-nil -- but it is nil by default, and
telnet doesn't set it. So comint is assigning `field' text properties
to distinguish program (csh) output such as prompts from user input.
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.
--
Kevin