Re: EBrowse obsolete?

[Stefan Monnier]

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

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.

>> [ Reminds me that I've wished for an Emacs where the `buffer_text`
>>   object is remote, so you can open a 10GB remote file, navigate
>>   inside of it, and edit it without having to transfer the whole 10GB.  ]
> Hmm. Could you please elaborate a little bit, how this ought to work?
> Unless there is a remote Emacs instance?

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


        Stefan