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: Should mode commands be idempotent? Date: Tue, 26 Sep 2017 10:55:28 -0700 (PDT) Message-ID: <2564c62e-a419-45d8-809f-433a6f7c3808@default> References: <9f11a3c6-b113-4bf6-9dab-f894b2ad77b5@default> <55da155a-03b1-d3ed-4036-12e5a60fa26c@gmail.com> <950166e7-2766-8a3e-1bc2-a93a356f652c@gmail.com> <118feee3-5787-43b7-9c9b-06907a16a448@default> 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 1506448549 16890 195.159.176.226 (26 Sep 2017 17:55:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Sep 2017 17:55:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: John Wiegley , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 26 19:55:42 2017 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 1dwu55-0003gL-PK for ged-emacs-devel@m.gmane.org; Tue, 26 Sep 2017 19:55:39 +0200 Original-Received: from localhost ([::1]:50522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwu5D-0007G8-6B for ged-emacs-devel@m.gmane.org; Tue, 26 Sep 2017 13:55:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwu56-0007G2-Fo for emacs-devel@gnu.org; Tue, 26 Sep 2017 13:55:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwu51-0004p1-Hp for emacs-devel@gnu.org; Tue, 26 Sep 2017 13:55:40 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:26774) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dwu51-0004oc-68 for emacs-devel@gnu.org; Tue, 26 Sep 2017 13:55:35 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8QHtUw2013154 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Sep 2017 17:55:32 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v8QHtUwF013799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Sep 2017 17:55:30 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8QHtT2M020304; Tue, 26 Sep 2017 17:55:30 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6776.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 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:218803 Archived-At: > FWIW, I can't off the top of my head think of a reason why > (foo-mode 1) followed by (foo-mode 1) should do something > different than just calling it once. Just what do you have in mind, for the meaning here of "do something different"? Are we saying that the state of the Emacs session after the second call should be identical to the state after the first call? Just what kind of "identical" would be meant? As I said: Beyond that, just what kind of "idempotence" is in view? What program state do we expect must be identical if a mode is turned on more than once? And what do we mean by "identical" here? Are we proposing a rule that a mode should not establish any state that can be preserved and updated each time the mode is turned on? Or are we proposing something much less than that? "Idempotence" is a big word. Just what do folks have in mind for it, for the proposed rule? (No answer to that, except from RMS, who said it doesn't matter. In which case the rule doesn't mean anything either. Anyone can claim "idempotence" for any code, for some meaning of "idempotence" or "identical". A guideline of "Be idempotent!" with no explanation is useless.) Would you argue, for example, that `foo-mode' should not be allowed to count how many invocations in a row it has had? (Why?) A silly example, perhaps. The point is that: 1. Such a rule is not needed. We've all agreed that it is _already_ generally respected, in any usual sense. We haven't seen examples of why the rule is needed - what we hope to gain by it. No one has pointed to an existing mode that is _intentionally_ non-idempotent, i.e., that feels it needs to do something different for subsequent turn-ons. The only example given of a mode that does something different was `visual-line-mode', where it was agreed that the behavior is a bug and is not intended or needed for the mode. 2. If such a rule were really needed then we'd need to say what we mean by it: just what kinds of state change are allowed for subsequent mode turn-ons. Or else we'd need to claim that _no_ changes are allowed, something that is virtually impossible to achieve, let alone verify. I haven't seen a lot of motivation given for this purported rule. But please try putting it into English, so we can see what's really being proposed. If it is just something like "Make sure your mode is idempotent" then see above, both #1 and #2.