Re: A femtolisp based emacs clone

[Stefan Monnier]

> To your point, my biggest disappointment with emacs is its
> client-server model.  We have tramp.  We have remote-X.  For
> high-latency connections, though, I always revert to terminal emuiation.
> For some reason, it's the most responsive.  Hurrah for 1982.  

Indeed.  I think you could get the best of both worlds by using an
approach similar to Tramp but running a little tramp-daemon on the other
end, such that we can use a more efficient communication protocol
(e.g. when saving a file we could locally diff it against the last
version (of which the remote daemon would also keep a copy), and then
only send the diff).

This said, even using such a daemon it might be difficult to get good
performance: part of the problem is the number of round-trips.
E.g. when saving a file we have to check if the file was modified in the
mean time and whether saving into a new inode would change the owner
(etc...), which each require a round-trip.  To get rid of these
round-trips, we'd have to shortcut this code and delegate the
higher-level "save file" operation to the remote server, which then has
to perform those tasks but still obeying the locally set customizations
about how to do each one of those tasks.

> not a new idea: arguably screen, sed, and ed do it.  But there's no
> editor I know designed for unreliable, slow connections, which often as
> not is what the Internet still is .  

IIRC the plan9 editor was designed with such a client/server idea.
How well did it work in such high-latency situations I don't know, tho.


        Stefan