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: Sun, 24 Sep 2017 10:26:57 -0700 (PDT) Message-ID: <76b52493-ec33-4a95-8378-03500def37de@default> References: << > <<9f11a3c6-b113-4bf6-9dab-f894b2ad77b5@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 1506274033 5120 195.159.176.226 (24 Sep 2017 17:27:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 24 Sep 2017 17:27:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 24 19:27:08 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 1dwAgO-0000u9-0w for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2017 19:27:08 +0200 Original-Received: from localhost ([::1]:38878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwAgV-0002Rj-EH for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2017 13:27:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwAgJ-0002PI-RA for emacs-devel@gnu.org; Sun, 24 Sep 2017 13:27:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwAgG-0002qU-NJ for emacs-devel@gnu.org; Sun, 24 Sep 2017 13:27:03 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:46128) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dwAgG-0002q4-Dt; Sun, 24 Sep 2017 13:27:00 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8OHQxnL006456 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 24 Sep 2017 17:26:59 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8OHQxY6019704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 24 Sep 2017 17:26:59 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8OHQwH6011983; Sun, 24 Sep 2017 17:26:58 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: userv0022.oracle.com [156.151.31.74] 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:218752 Archived-At: > > > Users expect major modes to be idempotent. Any time one is not, it > > > will cause them surprises. We should treat that as a bug and fix it > > > to be idempotent. > > > > Yes. You're talking about code distributed with Emacs, no doubt. > > > > And any 3rd-party library (if there were any) that might have > > such a mode function would be well advised to make clear to its > > users that the function is not idempotent, and explain why: > > what to expect and why. >=20 > I think that approach isn't strong enough to give users predictable > behavior. We should say that all major modes and minor modes are > idempotent; then, if any fails to be, it will clearly be a bug. 1. Are you talking about a convention only for code distributed with Emacs? If so, see above. It's fine for Emacs Dev to consider that a bug. An author/maintainer has every right to define what "bug" means for their software. But I think at least some here are talking about a convention for Emacs _users_ to follow, e.g., for 3rd-party code, not just for code distributed with Emacs. In that case, I don't see it as appropriate for an Emacs convention to call out what constitutes a bug. Certainly, some 3rd-party code might not _intend_ to have a non-idempotent mode. And in that case, the maintainer might well prefer to fix that unintentional behavior, as a bug. (Some code that tests a mode and lets an author know that it is in some way not idempotent could be useful in that case.) But the rule being discussed seems to go beyond saying only that if your mode doesn't _intend_ to be non-idempotent then you might want to consider making it idempotent. We seem to be on the verge of prescribing non-idempotence as a no-no. 2. 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? In general it means that an operation "can be applied multiple times without changing the result beyond the initial application" (Wikipedia). Just what do you have in mind wrt what is meant by the "result" in this context? Program state has lots of aspects that can be affected by Lisp code, including code that turns on a mode. Which parts of the state of an Emacs session - and its persistent context (e.g, disk files, websites,...) - would you allow to be changed, i.e., to _not_ be considered as part of the "result" of turning on a mode, without violating your idempotence rule?