[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EBrowse obsolete?
From: |
Michael Albinus |
Subject: |
Re: EBrowse obsolete? |
Date: |
Sat, 23 Jul 2022 17:04:24 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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.
- Re: EBrowse obsolete?, (continued)
- Re: EBrowse obsolete?, Brian Cully, 2022/07/22
- Re: EBrowse obsolete?, Jim Porter, 2022/07/22
- Re: EBrowse obsolete?, Michael Albinus, 2022/07/23
- Re: EBrowse obsolete?, Michael Albinus, 2022/07/23
- Re: EBrowse obsolete?, Michael Albinus, 2022/07/23
- Re: EBrowse obsolete?, Michael Albinus, 2022/07/23
- Re: EBrowse obsolete?, Stefan Monnier, 2022/07/23
- Re: EBrowse obsolete?,
Michael Albinus <=
- Re: EBrowse obsolete?, Michael Albinus, 2022/07/23
- Re: EBrowse obsolete?, Visuwesh, 2022/07/21
- Re: EBrowse obsolete?, Po Lu, 2022/07/21
- Re: EBrowse obsolete?, Gerd Möllmann, 2022/07/22
- Re: EBrowse obsolete?, tomas, 2022/07/22
- Re: EBrowse obsolete?, Eli Zaretskii, 2022/07/22
- Re: EBrowse obsolete?, Tim Cross, 2022/07/21
- Re: EBrowse obsolete?, Gerd Möllmann, 2022/07/21
- Re: EBrowse obsolete?, Eli Zaretskii, 2022/07/21
- Re: EBrowse obsolete?, Po Lu, 2022/07/21