> On Jan 29, 2025, at 9:50 AM, Michael Albinus <michael.albi...@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
