[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tramp mosh method
From: |
Ted Zlatanov |
Subject: |
Re: Tramp mosh method |
Date: |
Mon, 19 Nov 2012 11:39:43 -0500 |
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) |
On Mon, 19 Nov 2012 17:09:00 +0100 Michael Albinus <address@hidden> wrote:
MA> Ted Zlatanov <address@hidden> writes:
MA> Would you like to work on this?
>>
>> Yes, but last time I tried to grok tramp's internals, it took me a long
>> time.
MA> That's the educational part of my proposal :-) It would be great, if
MA> somebody but me would be familiar with Tramp's internals.
Have you documented how to write a new Tramp method? I remember with
tramp-imap.el it was quite a struggle for me. That being said, I would
love to learn Tramp as a long-term project.
>> Can you give me a function stub, which I will fill in, to do generic
>> filtering of process data before Tramp's handlers see it? If it's a
>> simple pipe function, I can write the code to filter ANSI sequences
>> out. I think it should simply be
>>
>> (defun tramp-io-filter data &optional term &rest options)
>>
>> Where DATA is the string, and TERM defaults to something minimal like
>> vt100.
MA> At a first glance, a process filter would do the job. But this might be
MA> a problem, because we use process filters already for running remote
MA> shells, see `tramp-handle-shell-command'. And for a given process, there
MA> can be only one filter function.
MA> Maybe we write an own `tramp-process-filter', which calls also
MA> `comint-output-filter' when indicated (by another hook). Or we use the
MA> `add-function' functionality mentioned recently by Stefan on
MA> emacs-devel, see
<http://thread.gmane.org/gmane.emacs.devel/153997/focus=154852>.
MA> This would restrict the mosh method to Emacs versions
MA> greater than 24.3, but so what.
Let's not restrict it to new Emacsen. I'd rather use
`tramp-process-filter' and support older Emacsen. It sounds like a
fairly simple refactoring, actually.
>> I'd rather not rely on external code for this because we need to be very
>> flexible, handling unexpected sequences and terminal bugs in the
>> future. I hope you agree.
MA> If we use the latter approach (`add-function'), we would be able to fix
MA> such errors in Emacs' trunk. Somehow, I hate code duplication ...
Me too, but this is not duplicating code. Those filters have a very
specific need and target interactive usage. We're trying to clean
everything out of the text stream. I suspect our code will be much
simpler if we don't try to coexist with other filters but simply clear
all escape sequences.
Ted