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: Sun, 5 Aug 2018 08:36:23 -0700 (PDT) Message-ID: <39939ea5-a7c2-400a-9ac1-4df7cf4fcb42@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>> <<837el6t8r3.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1533484042 27575 195.159.176.226 (5 Aug 2018 15:47:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Aug 2018 15:47:22 +0000 (UTC) Cc: michael.albinus@gmx.de, eliz@gnu.org, fgunbin@fastmail.fm, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 05 17:47:17 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 1fmLFS-00072l-OY for ged-emacs-devel@m.gmane.org; Sun, 05 Aug 2018 17:47:15 +0200 Original-Received: from localhost ([::1]:59038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fmLHZ-000106-Gu for ged-emacs-devel@m.gmane.org; Sun, 05 Aug 2018 11:49:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fmL5C-0007Yx-U8 for emacs-devel@gnu.org; Sun, 05 Aug 2018 11:36:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fmL5B-0006ll-OG for emacs-devel@gnu.org; Sun, 05 Aug 2018 11:36:38 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:46378) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fmL56-0006iu-47; Sun, 05 Aug 2018 11:36:32 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w75FZDjJ161354; Sun, 5 Aug 2018 15:36:26 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=Emv7zotmiQj7CFLZgoJidab7iobKJNZskH1M9Jw32d0=; b=wZc80im2Vi9FrmBnPy9Ht82kIh9pfJGq/DRWfpvK1micAIBxV+cgABgzwlKLjE24Mvnr Iid47Pq4OVc4xJf/8S5U49PdP179zIgeKFTTErcuxDM21fvoGmiX5Tq8y5wpFc5FmFCP dgPLHRjAyb1CQOuGMxoECL1eLGBtaw+OwaCwOpEqEqE8zdsZiQFwfDlvHQ0eHdpL8vqw 0N0p3x3YT1gV/B7x7epO3W2hTwi8tg/OoZynFB10YGrwor8q5y2s/uYD39ZSQJXqGz7V 51sC1cAnFBcUAk0YsDideusZxFKpE97F+yl6WnFopU9A6F5J2gC/WAgJF9w/UYw0tKqf zg== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2kn43njb6c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 05 Aug 2018 15:36:26 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w75FaOb6011163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 5 Aug 2018 15:36:25 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w75FaNGB029410; Sun, 5 Aug 2018 15:36:23 GMT In-Reply-To: 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=29 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-1808050173 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 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:228193 Archived-At: > > Even `C-u' (`universal-argument') is not a prefix argument. It is a co= mmand > > that begins reading a prefix argument and that, possibly together with= other > > commands (such as `digit-argument') provides that prefix argument to a > > followup command. >=20 > We think of C-u as beginning a prefix argument, without exception. > Sometimes the prefix argument consists of C-u and nothing but C-u. If your point is that my "possibly" needs to be scoped only to the "other c= ommands", and that `C-u' _always_ provides a prefix arg, even when alone, t= hen yes, of course - that's what I meant for the scope of the "possibly". My point was really that `C-u' is a key sequence, not a prefix argument. `C-u', along with other prefix-arg forming keys (e.g., digits) provides a p= refix argument to a command. I don't see those keys as _being_ a prefix arg= ument. But sure, the two could be identified to some extent, when speaking = loosely. The doc describes/defines "raw prefix argument" and "numeric prefix argumen= t", which is the "numeric value" of the raw prefix argument. Those are Lisp= values, which include conses, atoms like `-', and integers. They are not k= ey sequences. When talking about the key sequences, we (I, at least) distinguish "plain `= C-u'", which provides a prefix arg of `(4)', double plain `C-u', which prov= ides an arg of `(16)', and so on. Other key sequences provide different raw= prefix args. I think it could make sense to speak of `C-u', `C-u C-u', `C-u 3 4', `M--',= etc. as "prefix-arg key sequences" or "prefix arg-providing key sequences"= or some such. But I think it would be misleading (except perhaps in certai= n contexts where the difference was already made clear) to speak of them as= "prefix arguments". Just one opinion. > However, I agree it is clearest NOT to think of C-x RET c > as a prefix argument. The prefix argument is a specific kind of value > and that is not how C-x RET c works. Yes. And in particular (IMO, at least), a prefix arg is a Lisp value - just= one of those values documented as such, which doesn't include (so far) any= key-sequence Lisp values. I'm not trying to be pedantic. I think it helps users to keep the terminolo= gy clear, here.=20 It's OK with me if someone providing help to another says, e.g., "use a pla= in prefix arg to do XYZ", meaning "use plain `C-u' to do XYZ". That's fine,= as long as both understand what is meant.=20 But I don't think the Emacs doc should talk that way, in general. It's bett= er for the doc to keep these things separate - key sequences are not prefix= args. And wrt this discussion, `C-x RET c' is neither a prefix argument nor a key= sequence that provides a prefix arg. IIUC, it has nothing to do with a pre= fix arg. It is _not_ like `C-u' or `M--'. At most, `C-x RET c' could be said to be a key sequence that always precede= s (is always followed by) another key sequence, which it reads.=20 It's not a _prefix key_, because it's not bound to a keymap. The key sequen= ce that follows it is not looked up in a map that `C-x RET c' is bound to. = Instead, that following key sequence is read by the command bound to `C-x R= ET c', and then invoked. (And `C-x RET c' can set some context for that fol= lowing command - bind variables or whatever.) It's the behavior of a key sequence such as `C-x RET c' (or rather its comm= and) that's being discussed here. AFAIK, we don't have a name for such key = sequences/commands/behavior. Until now, the only instance of such a thing (= AFAIK) was `C-x RET c'. Now there might be a second: `C-x &'. Is it perhaps time to come up with some terminology/concepts for this, and = to document it? And maybe to come up with some constructs that make defining such key seque= nces/commands/behavior easier for users? We added `define-minor-mode' to capture the programming cliche of defining= a minor mode. Perhaps something like that could help here. Dunno whether i= t would be jumping the gun or overkill to do that now, since there has been= so little use of the cliche, so far. (I.e., unlike defining a minor mode, = it's not really a cliche yet - just a rarely used technique.)