On Jan 29, 2025, at 9:50 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
One thing that is unclear to me: do the `connection-local' settings
have any effect without a matching `connection-properties'?
No. Both is needed.
In fact I find that once the connection-local profile/variables are set, future connections proceed as async, with "-t -t". When the final piece (connection-properties) is installed, the "-t -t" is dropped. So while both may be needed, the first connection-local set seem to alter the connection details, inhibiting the interactive shell version. Also, why
is it `tramp-direct-async-process' in one place and just
"direct-async" in the other?
History. People tend to modify the rather complex structure of tramp-methods in their config, which is error prone. That's why I have added the possibility to overwrite tramp-methods arguments by connection properties. tramp-methods arguments are alwys symbols, starting with 'tramp-'. Connection properties are always strings, w/o a leading "tramp-". So this is the result. This mapping is explained in the Tramp manual.
I did eventually find this in the manual, but far away from where I looked (in fact I used consult-info). It would be very helpful if the docstring for tamp-connection-properties method that some properties are mapped in this way.
BTW, I'd prefer to enable direct-async _only_ for the
processes my
package creates, not for _all_ SSH processes, leaving that to
the
user.
How do *your* processes differ from user processes? Is there
something
special in the remote file name, or so?
Do you mean the file name of the remote process executable itself?
No, I mean the "remote" part of a remote file name, like "/ssh:host". The name of a remote process executable isn't checked.
Oh right. That's of course how make-process knows to make a remote process. Yes, this is distinct and I know it in advance (usually "python[3]" or
"ipython"). Would the idea be to update the regex in
`tramp-connection-properties' to target only these executable names?
No. I have no idea yet how to fulfill your request. Perhaps you can use the macro setq-connection-local in order to wrap your calls to direct asyn processes, setting connection-local variable tramp-direct-async-process temporarily only. To be investigated.
I was thinking of changing the :application in the profile selection criteria from 'tramp to something unique to my package. Unfortunately again here the docs don't seem to give much guidance. The closest I found is the docstring of connection-local-criteria-alist, which mentions:
Property names might be ‘:application’, ‘:protocol’, ‘:user’ and ‘:machine’. The property value of ‘:application’ is a symbol, all other property values are strings.
which gives no hint as to how the connection/application details are set up. I'm imagining I could just locally set, in my process buffers, the variable connection-local-default-application to a unique name that matches my connection profile. Does that sound possible?
It seems there must be some combination of settings that gives binary
data ✓; signals ✓.
Well, it looks like we must think about rewriting signal handling for direct async processes. One idea is to send the respective control character directly. The posting on SX gives useful information, indeed.
Yes, my other message describes some progress I made. I actually think if TRAMP can get the PID from a direct-async process, this should work well (modulo the interrupt issue I mention there).
Thanks for your work on TRAMP!
JD
|