Re: [GNU ELPA] New package: tramp-locproc

[Michael Albinus]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

Hi Björn,

>> I would like to submit a new package to GNU ELPA: tramp-locproc.
>>
>
> Why not make this a opt-in tramp-module? I wonder if a longer name would
> be better as it does speak better for it self. Why not tramp-local-process?

I don't want to add it to Tramp proper, because it implements something
out of the canonical remote files spec. Moreover, for the "sshfs"
method, it overwrites the default implementation. This might confuse
people.

And I don't know whether it is mature enough to be used. First, I'd like
to get user feedback.

About the package name ... I thought indeed to use the longer one, as
you've proposed. Finally, I've decided for the shorter one. I don't see
a disadvantage, people decide to use a package based on the description,
not on the name.

>> Beside the obvious advantage to run local processes over remote files,
>> there is also the disadvantage that file names are adapted in order to
>> reflect their local mount location.
>
> When displayed in Emacs or for the processes executed?

Both.

>>     ;; Replace handler functions.
>>     (setcdr (assq 'exec-path val) #'tramp-locproc-handle-exec-path)
>>     (setcdr (assq 'make-process val) #'tramp-locproc-handle-make-process)
>>     (setcdr (assq 'process-file val) #'tramp-locproc-handle-process-file)
>>     (setcdr (assq 'shell-command val) #'tramp-locproc-handle-shell-command)
>>     (setcdr (assq 'start-file-process val) 
>> #'tramp-handle-start-file-process)))
>
> You it be possible to make this a default or fallback action depending
> on the users intention? E.g. by using a prefix arg to invert the
> default.
>
> The default then being either to call the command as a local process by
> default or explicitly by using a prefix argument.

Might be an extension for later. But I fear people get confused. The
don't call `make-process' directly, the call something like `compile' or
`grep-find', which have their own idea of prefix arguments.

So we'll need rather an explict enable/disable knob. Added to the TODO.

Best regards, Michael.