Hi Michael,
Michael Albinus <michael.albi...@gmx.de> writes:
> Eshel Yaron <m...@eshelyaron.com> writes:
>
>>> 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:
>>
>> 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.
>
> Even more complicate and error-prone.
>
> As said above, tramp-dissect-file-name is such an essential function in
> Tramp, that I won't add unrelated functionality. I fear collateral
> damages, and yes, this happened in the past already.
OK, but since this function asserts that a method is known and throws an
error otherwise, it seems like it's the only place that an extension
could hook into to be loaded just in time.
> The Tramp package should not try to check for external extensions. Such
> external extensions must plug into Tramp on their own. This was one of
> the motivations to create tramp-container.el, which has integrated
> existing ELPA packages like docker-tramp, kubernetes-tramp, and
> tramp-nspawn.
A good way to plug into Tramp is exactly what after :)
A facility for loading Tramp extensions just in time would help, but if
that's not forthcoming I guess I'll make do with what's available.
>>> 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?
>
> Yes, it would load tramp.el. But this is needed anyway, if you want
> Emacs to detect "/foo:host:/path/to/file" as remote file name.
Unfortunately loading Tramp at start up is not really viable. I don't
think it's necessary either: tramp-autoload-file-name-handler is in
file-name-handler-alist after start up, so Emacs does recognize
"/foo:host:/..." as a remote file name, and loads Tramp when needed.
> Another, minor, advantage of this approach is that Tramp would
> reconsider foo as possible candidate of method completion of "C-x C-f
> /fo TAB" even if tramp-dissect-file-name hasn't been called ever.
That's a nice bonus indeed.
Thanks for your help,
Eshel
