From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: Introducing thread-safe Tramp Date: Wed, 25 Jul 2018 23:54:23 +1200 Message-ID: References: <8736wa9c5s.fsf@gmx.de> <87wotkn6do.fsf@gmx.de> <874lgn8x6l.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1532519612 1833 195.159.176.226 (25 Jul 2018 11:53:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2018 11:53:32 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 25 13:53:28 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fiIMA-0000Ng-Uq for ged-emacs-devel@m.gmane.org; Wed, 25 Jul 2018 13:53:27 +0200 Original-Received: from localhost ([::1]:48558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fiIOH-0001BN-Rs for ged-emacs-devel@m.gmane.org; Wed, 25 Jul 2018 07:55:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fiINM-0000eL-1r for emacs-devel@gnu.org; Wed, 25 Jul 2018 07:54:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fiINH-0000pw-0j for emacs-devel@gnu.org; Wed, 25 Jul 2018 07:54:38 -0400 Original-Received: from smtp-1.orcon.net.nz ([60.234.4.34]:40629) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fiING-0000dN-J7 for emacs-devel@gnu.org; Wed, 25 Jul 2018 07:54:34 -0400 Original-Received: from [150.107.172.83] (port=18664 helo=[192.168.20.103]) by smtp-1.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1fiIN5-0004EH-Nh for emacs-devel@gnu.org; Wed, 25 Jul 2018 23:54:27 +1200 In-Reply-To: <874lgn8x6l.fsf@gmx.de> Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 60.234.4.34 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:227797 Archived-At: On 25/07/18 21:46, Michael Albinus wrote: > Drew Adams 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