Re: EBrowse obsolete?

[Michael Albinus <michael.albinus@gmx.de>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>>> Indeed, I don't think we can hope to get good performance with an
>>> approach like that of Tramp which works hard to try and avoid requiring
>>> installation of a "Emacs server" on the other end.
>>
>> FTR, there are proposals to use a remote Emacs instance as server. This
>> approach sounds interesting, but due to the disadvantages, and the
>> amount of work, I've never tired a prototype.
>
> The issue is not just what's running on the remote host, but what's the
> protocol between the two (not just at the byte-level but in terms of
> what kinds of operations/data/events go back and forth).

I've discussed this a while ago with Mattias Engdegård. His proposal was
to have a protocol on sexp level, that means the client sends

(file-exists-p localname)

and the remote server responds with

t

On both sides, the Lisp reader would be active.

> Tramp's flexibility depends on the design of `file-name-handlers-alist`.
> In some cases (such as a quick edit to a very large remote file), that's
> a very significant restriction.

Sure, but we're able to extend the file-name-handler-alist protocol. For
example by a function which is activated by a remote default-directory,
and sends local file names, being relative or absolute, back and forth.

This wouldn't even need a remote Emacs server, but only a proper
implementation in Tramp and other file name handlers.

> I was taking it for granted that the remote host would be running some
> Emacs-specific server, yes.  I think that'd be the easy part :-)
> The harder part is to decide which operations should take place on which
> side, and what information to send when between the two sides.  [ And of
> course, actually writing the code to make it work without breaking too
> much existing uses nor significantly slowing down the normal local
> use case.  ]

Yep. But we could do it iteratively: Add magic functions as needed. To
be honest, I do it already internally. Tramp's list of magic functions
is extended by (taken from tramp-sh.el)

    (tramp-get-home-directory . tramp-sh-handle-get-home-directory)
    (tramp-get-remote-gid . tramp-sh-handle-get-remote-gid)
    (tramp-get-remote-uid . tramp-sh-handle-get-remote-uid)
    (tramp-set-file-uid-gid . tramp-sh-handle-set-file-uid-gid)

Simply, because there are different implementations for different Tramp
backends, and the mechanism is available :-) Other, non-Tramp file name
handlers are not affected, because every file name handler, which is
called for a function it doesn't know, falls back to the default
implementation.

So if you have a function `my-own-bulk-operation', which looks for a
handler of it in case of a remote default directory, it would do. (Well,
Tramp is a bit of picky for the functions, and it shall at least know
that there is such a magic function -- otherwise, it moans).

>         Stefan

Best regards, Michael.