Re: Introducing thread-safe Tramp

[Phil Sainty <psainty@orcon.net.nz>]

On 25/07/18 21:46, Michael Albinus wrote:
> Drew Adams <drew.adams@oracle.com> writes:
>> My a priori objection is the use of a prefix arg to indicate that
>> you want a separate thread.  I would prefer that users specify this
>> intention in some other way, and that we reserve the use of a
>> prefix arg for something else (future).
>
> I don't understand your reservation. 40+ years of Emacs, and there
> was no need yet for a prefix argument of find-file. I would be
> surprised if it happens next time.

At first glance I would lean towards Drew's viewpoint on the basis
that it seems to me that there may be a benefit in having a *common*
interface for saying "do a thing asynchronously" -- for all manner of
things which support that (now or in the future).  find-file may never
have acquired a prefix arg, but other commands which may support
asynchronous execution in the future might already use prefix args,
in which case there would end up being inconsistencies in how the
user invoked async behaviour for any given command.

The analog that springs to my mind is the command `append-next-kill'
(bound to C-M-w), which can be invoked in order to "Cause following
command, if it kills, to add to previous kill."

Acting asynchronously might be such a generic requirement that maybe
it makes sense to implement some similar facility to say "Cause the
following command, if it can act asynchronously, to do so."

We might have a user option meaning "commands should act asynchronously
if possible" which, at least in the early days, might be set to nil by
default; but invoking the "run the next command asynchronously" command
could bind that variable as non-nil for the duration of the following
command.

Then if it was a convention that functions implementing optional async
behaviour did so conditional on this variable, we could gain the
desired outcome not only for `find-file' but for anything else in the
future which implemented such support.

Individual libraries might implement their own additional user options
to enable users to specify default async behaviour for particular sets
of commands implemented by the library in question (e.g. `find-file'
and friends), and/or users could use advice to bind the "use async
behaviour" variable for specific commands if they wanted it for some
things but not others.

Ultimately I can envisage that async-supporting commands which are
initially synchronous-by-default may in the future end up being
asynchronous-by-default once this functionality is better established,
and so tying prefix arguments to such functionality now may end up
seeming short-sighted in the future?


-Phil