[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 
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]