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: Sat, 04 Aug 2018 21:34:48 +0300 Message-ID: <83zhy2rnef.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> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1533407587 8749 195.159.176.226 (4 Aug 2018 18:33:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Aug 2018 18:33:07 +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 Sat Aug 04 20:33:03 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 1fm1MK-00029X-Te for ged-emacs-devel@m.gmane.org; Sat, 04 Aug 2018 20:33:01 +0200 Original-Received: from localhost ([::1]:55924 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fm1OR-0003Kx-Kv for ged-emacs-devel@m.gmane.org; Sat, 04 Aug 2018 14:35:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fm1OF-0003KM-RB for emacs-devel@gnu.org; Sat, 04 Aug 2018 14:35:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fm1OC-0008Sg-Ni for emacs-devel@gnu.org; Sat, 04 Aug 2018 14:34:59 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fm1OC-0008Sa-Jy; Sat, 04 Aug 2018 14:34:56 -0400 Original-Received: from [176.228.60.248] (port=4982 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fm1OC-0001VZ-4M; Sat, 04 Aug 2018 14:34:56 -0400 In-reply-to: <87effevy41.fsf@gmx.de> (message from Michael Albinus on Sat, 04 Aug 2018 19:29:50 +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:228178 Archived-At: > From: Michael Albinus > Cc: drew.adams@oracle.com, fgunbin@fastmail.fm, emacs-devel@gnu.org > Date: Sat, 04 Aug 2018 19:29:50 +0200 > > find-file-asynchronously is defined to be file-related (as of now): > > --8<---------------cut here---------------start------------->8--- > Documentation: > Non-nil means visit file asynchronously when called interactively. > If it is a regular expression, it must match the file name to be > visited. This behavior is toggled by a prefix argument to the > interactive call. > --8<---------------cut here---------------end--------------->8--- It's okay for the variable to accept a regexp value, because it allows to customize the variable once and then benefit from the value for many invocations. 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. > > In any case, why should there be a separate command to force just the > > file-related commands work asynchronously? > > I don't speak a bout a separate command. I speak about the user option, > which I have introduced for the find-file family of commands. I believe > the name find-file-asynchronously is too tight (doesn't cover save-buffer > and friends), and execute-command-asynchronously is too wide (because it > shall configure file-related command behavior, with the regexp as value). 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.