tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to autoload Tramp methods


From: Eshel Yaron
Subject: Re: How to autoload Tramp methods
Date: Tue, 08 Oct 2024 18:23:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Michael Albinus <michael.albinus@gmx.de> writes:

> Eshel Yaron <me@eshelyaron.com> writes:
>
>> One option that comes to mind is something like:
>>
>> diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
>> index 8961b872a8a..a82a3e564d8 100644
>> --- a/lisp/net/tramp.el
>> +++ b/lisp/net/tramp.el
>> @@ -1794,7 +1794,12 @@ tramp-dissect-file-name
>>                   :port port :localname localname :hop hop))
>>        ;; The method must be known.
>>        (unless (or nodefault non-essential
>> -                  (assoc method tramp-methods))
>> +                  (assoc method tramp-methods)
>> +                      (when-let ((enable-fun
>> +                                  (intern-soft
>> +                                   (format "tramp-enable-%s-method" 
>> method)))
>> +                                 ((functionp enable-fun)))
>> +                        (funcall enable-fun)))
>>          (tramp-user-error
>>           v "Method `%s' is not known" method))
>>        ;; Only some methods from tramp-sh.el do support multi-hops.
>>
>> Then in foo-tramp I could define tramp-enable-foo-method, have it return
>> non-nil, give it an autoload cookie, and that's it.  How would you feel
>> about such an approach?
>
> The idea is good. However, tramp-dissect-file-name is the most often
> calles function in Tramp (a workhorse), I wouldn't like to make it
> heavier.

Makes sense, although I'd be surprised if this makes any noticeable
performance difference: in the common case of a method that is already
in tramp-methods, there's no runtime cost; for methods that are not yet
in tramp-methods, there's a one-time cost.  For bogus methods, there's a
tiny added cost of one intern-soft, and these calls are just about to
error out anyway.  Still, maybe there's a better way to do this.

Perhaps a slightly nicer interface would be:

diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
index 8961b872a8a..586999aebcb 100644
--- a/lisp/net/tramp.el
+++ b/lisp/net/tramp.el
@@ -1794,7 +1794,13 @@ tramp-dissect-file-name
                     :port port :localname localname :hop hop))
          ;; The method must be known.
          (unless (or nodefault non-essential
-                     (assoc method tramp-methods))
+                     (assoc method tramp-methods)
+                      (when-let ((params-fun
+                                  (intern-soft
+                                   (format "tramp-%s-method-params" method)))
+                                 ((functionp params-fun))
+                                 (params (funcall params-fun)))
+                        (push (cons method params) tramp-methods)))
            (tramp-user-error
             v "Method `%s' is not known" method))
          ;; Only some methods from tramp-sh.el do support multi-hops.

Here the contract of tramp-foo-method-params would be that it is called
with no arguments (or maybe with the method name as a sole argument?)
and returns a list of parameters that is used as the cdr of a
tramp-methods entry.  This way extensions just need to provide an
autoloaded function that returns some parameters, no need to worry about
how and when exactly to modify tramp-methods.

> How about defining and autoloading tramp-enable-foo-method, and *also*
> adding in foo-tramp.el
>
> ;;;###autoload
> (tramp-enable-method "foo")
>
> In order to avoid loading foo-tramp due to this call, you must autoload
> the *implementation* of tramp-enable-foo-method, like
>
> ;;;###autoload
> (progn (defun tramp-enable-foo-method ()
>   "Enable connection to foo."
>   (add-to-list 'tramp-methods
>              `("foo"
>                ...))))

Interesting, wouldn't autoloading the call to tramp-enable-method end up
loading Tramp to define tramp-enable-method during Emacs start up?


Thanks,

Eshel



reply via email to

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