From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Introducing thread-safe Tramp Date: Sat, 4 Aug 2018 15:41:36 -0700 (PDT) Message-ID: <297a37f1-5eb0-4fec-876b-e716c634de14@default> 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> <7c28f9d8-e2bb-4778-ab92-92707f12718f@default> <87r2jew2fd.fsf@gmx.de> <87a7q2vxsu.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1533422426 3623 195.159.176.226 (4 Aug 2018 22:40:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Aug 2018 22:40:26 +0000 (UTC) Cc: Eli Zaretskii , fgunbin@fastmail.fm, emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 05 00:40:22 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 1fm5Dh-0000pV-Li for ged-emacs-devel@m.gmane.org; Sun, 05 Aug 2018 00:40:21 +0200 Original-Received: from localhost ([::1]:56499 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fm5Fm-0002y4-Cr for ged-emacs-devel@m.gmane.org; Sat, 04 Aug 2018 18:42:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fm5F9-0002xe-B5 for emacs-devel@gnu.org; Sat, 04 Aug 2018 18:41:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fm5F8-0004hY-2v for emacs-devel@gnu.org; Sat, 04 Aug 2018 18:41:51 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:48916) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fm5F4-0004bV-9Y; Sat, 04 Aug 2018 18:41:46 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w74Mdd1t135271; Sat, 4 Aug 2018 22:41:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=D5E21Z7ed3W+e8iraZAnCYepZBluX7tcqq2qKHPm5yY=; b=4RplBEpiDV3MrrSoXSWmzBetqkXhd9GZoxwtBAD9OlnCholbfqBjsVeW3Ol3xm7KxSQ1 nmFww1++rrWOQkdoa06vuJ32/YPM0udnToOUPudG3SQGTUS72It6UEBuNs4qUEHvBGaw SKlq4Z3bkpJ8ZXaVpafq/HsjQcb8h08aJBZIpM4jdlCJAeL+t2L9jQNYkoV/HnKRuq8v mibR9AQ63l9TA/pT0r14oeAq0mdSq19dD9k/v0F1qlSTkB8OCK8If6hB3VNqES+OOCiY KlcICfRx7g9gHScBXYzcNH5uF2bgfQkOk675bMHUkwEeTuU2AFhvQyr9al70d9KtD96W Mg== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2kn3jssbyc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 04 Aug 2018 22:41:39 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w74MfcUV000790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 4 Aug 2018 22:41:38 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w74MfbVY010015; Sat, 4 Aug 2018 22:41:37 GMT In-Reply-To: <87a7q2vxsu.fsf@gmx.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4717.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8975 signatures=668707 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808040252 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 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:228179 Archived-At: > > 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. >=20 > Because I believe this is more convenient.=20 I understand that you feel that. Why not find that out from users, over a p= eriod 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, a= nd 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. > It is common practice to change the behavior of a command by a prefix,=20 What does "a prefix" even mean, here? What's prefixing what? It's common practice to sometimes change command behavior according to a _p= refix argument_. There's no prefix argument involved here (except possibly = before the second key sequence - the one that is read by `C-x &'). Certainl= y `C-x &' is not, itself, a prefix argument.=20 Nor is there any _prefix key_ involved here. `C-x &' is not bound to a keym= ap. I don't see how `C-x &' is a prefix . And I don't see any common practice involved here. Rather, there is only on= e such use case I'm aware of: `C-x RET c'. > and this is what "C-x &" is good for. It *is* a prefix;=20 Again, what does "a prefix" even mean? `C-x &' is a key sequence. What is i= t a prefix of? It's not a _prefix key_ (it's not bound to a keymap). What c= an a key sequence be a prefix of, if not of a set of key sequences, if it i= s not a prefix key?=20 `C-x &' is a key sequence that's bound to a command that reads a key sequen= ce and invokes that second key sequence's command. And when reading the key= sequence it allows use of prefix argument. But in what way is key sequence= `C-x &' a "prefix" of something - what's that something that it prefixes? If I type the key `a' and then I type the key `b', `a' is not a prefix of `= b' in any usual sense. The behavior you have does not fit any of the curren= t uses of the word "prefix" in Emacs jargon/doc, I think. If you try to think of `C-x &' as some (new) kind of "prefix" then please s= tart by saying what it is a prefix of. > just the implementation varies. Implementation of what? The answer, from your statement, can only be "a pre= fix". But implementation of a prefix of what? What is this "a prefix" you s= peak of? > > Right. But this is still a new use case, I think. The `C-x RET c' case > > is pretty much the only other use of this technique, AFAIK. > > > > We document the use of prefix keys, i.e., binding a key to a > > keymap. We don't document this technique/cliche. Perhaps we should. >=20 > Agreed. Now, we have two special cases. I agree also with you to make > this technique more general, but since I'm in the muddy waters of > threads, I'd like to postpone it a bit (or somebody else does). If we > have the more general approach, it deserves documentation. Sounds good. Thanks for working on the threading feature. Sounds very good. I don't think this technique / programming cliche (used for `C-x RET c' and= proposed for `C-x &') should be passed off as somehow using a different ki= nd of prefix argument - no connection, IMO. Nor should the key sequence inv= olved be shoehorned into consideration as a prefix key. It's neither. I don't see any useful use of the word "prefix" here, but if there is one t= hen it needs to be defined explicitly, as some new kind of prefixing (start= ing by saying what gets prefixed). I think we agree that this technique/cliche is interesting and could be app= lied more widely by users (other use cases) or turned into something more g= eneral (making it easy for users to take advantage of, for their own key-re= ading commands, without going through the same implementation cliche explic= itly). One could even imagine (similarly to a prefix key whose keymap binding has = one or more prefix keys) applying the technique more than once in successio= n: a command that reads a key sequence (possibly with prefix arg) being its= elf read by a command that reads a key sequence (possibly with prefix arg). Whereas it is simple to move a keymap around, binding it to this or that pr= efix key (any of which might itself be in a keymap that is bound to a prefi= x key...), it's a bit more cumbersome (less modular) to combine things and = move them around with the technique in question.=20 It's about defining a particular kind of command. Perhaps some good new pro= gramming constructs can be found, to help out here. Maybe a command-definin= g macro, to bundle up the technique nicely. Or maybe we're hinting at a var= iant of or a new form for a keymap.=20 (Another thing that comes to (my) mind here, for some reason, are hydras...= )