From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Introducing thread-safe Tramp Date: Sun, 05 Aug 2018 18:06:49 +0300 Message-ID: <83y3dksvhy.fsf@gnu.org> References: <8736wa9c5s.fsf@gmx.de> <87wotkn6do.fsf@gmx.de> <874lgn8x6l.fsf@gmx.de> <87sh44pisz.fsf@gmx.de> <87a7qbitc7.fsf@gmx.de> <878t5tdsfc.fsf@gmx.de> <83wotcpzub.fsf@gnu.org> <87bmaiuwml.fsf@gmx.de> <877el6uwio.fsf@gmx.de> <83bmaitbwu.fsf@gnu.org> <87a7q2w4gd.fsf@gmx.de> <838t5mt9wb.fsf@gnu.org> <87muu2w2c2.fsf@gmx.de> <83600qt8mi.fsf@gnu.org> <87in4qw1fl.fsf@gmx.de> <834lgat6fy.fsf@gnu.org> <87effevy41.fsf@gmx.de> <83zhy2rnef.fsf@gnu.org> <871sbdw389.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1533481500 27850 195.159.176.226 (5 Aug 2018 15:05:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Aug 2018 15:05:00 +0000 (UTC) Cc: fgunbin@fastmail.fm, drew.adams@oracle.com, emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 05 17:04:55 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 1fmKaU-0007Az-Kr for ged-emacs-devel@m.gmane.org; Sun, 05 Aug 2018 17:04:54 +0200 Original-Received: from localhost ([::1]:58899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fmKcb-0007bf-8U for ged-emacs-devel@m.gmane.org; Sun, 05 Aug 2018 11:07:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fmKcU-0007bX-UB for emacs-devel@gnu.org; Sun, 05 Aug 2018 11:07:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fmKcR-00043S-Mk for emacs-devel@gnu.org; Sun, 05 Aug 2018 11:06:58 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fmKcR-000439-IY; Sun, 05 Aug 2018 11:06:55 -0400 Original-Received: from [176.228.60.248] (port=4763 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fmKcR-0004tg-58; Sun, 05 Aug 2018 11:06:55 -0400 In-reply-to: <871sbdw389.fsf@gmx.de> (message from Michael Albinus on Sun, 05 Aug 2018 11:51:34 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:228190 Archived-At: > From: Michael Albinus > Cc: drew.adams@oracle.com, fgunbin@fastmail.fm, emacs-devel@gnu.org > Date: Sun, 05 Aug 2018 11:51:34 +0200 > > > But "C-x &" affects just the next command, so all you need is for it > > to produce a boolean value, and have the next command work > > asynchronously or not according to that value. Which probably means > > "C-x &" should not bind find-file-asynchronously, but some other > > variable, and that variable had better had a name that is not limited > > to file operations, for us to be able to use it with other commands. > > Because once we extend "C-x &" to non-file commands, it will not > > "know" what command will be invoked after it, so it won't be able to > > know it should bind find-file-asynchronously or something else. It > > should therefore bind a variable which affects any command. > > Nobody hinders us to bind several variables in > universal-async-argument. If that produces expected results in practice, that'd be fine, yes. > > For the variable which tailors find-file, save-buffer, etc., I agree > > that it should not just say "find-file". > > execute-file-commands-asynchronously sounds okay to me. But that's > > just part of the broader issue of invoking commands asynchronously. > > I've changed it accordingly. Pushed to the feature/tramp-thread-safe > branch, in order to have the same code basis we're speaking about. Thanks.