Re: Introducing thread-safe Tramp

[Michael Albinus]

Drew Adams <address@hidden> writes:

Hi Drew,

>> > You didn't answer wrt why we shouldn't just define additional commands
>> > and let users create async/sync toggle commands using them (and
>> > binding them to the same muscle-memory keys), or why we shouldn't also
>> > create such toggle commands (toggling with a prefix arg), but not
>> > necessarily bind them to the standard keys right away. IOW, what we
>> > usually do.
>
> I understand that you feel that. Why not find that out from users,
> over a period of time? If users end up binding the toggle commands I
> described, in place of the traditional file-operation bindings, then
> we'll know just how important and convenient such dispatching is. If
> only some users do that, and with only one or a couple of the file
> commands, then we'll have info to direct how best to accommodate that
> need.
>
> Just a suggestion.

I don't believe it will work in practice to observe users how they use
the new feature. How could we collect data about the usage patterns?

Furthermore, I don't believe we need a new set of file visiting commands
for the asynchronous case. The existing commands work well, customized
by the (now named so) `execute-file-commands-asynchronously' user option.

I don't expect the key sequence "C-x &" to be applied very often. It
exists just in case you want to visit a file synchronously or
asynchronously the other way as specified by that option.

>> It is common practice to change the behavior of a command by a prefix, 
>
> What does "a prefix" even mean, here? What's prefixing what?

[...]

Agreed, "prefix" might be misleading. Until we have a better term, I've
changed that to "key sequence C-x & prior the interactive command
invocation". This doesn't read fluid in the documentation, and I'm
prepared to change it once we have better wording.

> It's about defining a particular kind of command. Perhaps some good
> new programming constructs can be found, to help out here. Maybe a
> command-defining macro, to bundle up the technique nicely. Or maybe
> we're hinting at a variant of or a new form for a keymap.

All agreed, but from my side I'd like to postpone this. Everybody is
invited to contribute here.

Best regards, Michael.