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: emacs-25 f708cb2: Clarify doc string of 'transpose-sexps' Date: Fri, 4 Nov 2016 11:00:39 -0700 (PDT) Message-ID: <83cd67b5-cb42-4fea-b6be-21e9ec8075a7@default> References: <20161104095223.23249.72530@vcs.savannah.gnu.org> <20161104095223.631AB22012D@vcs.savannah.gnu.org> <8737j7e3r5.fsf@gmx.net> <87y40zckn9.fsf@gmx.net> <977b7eaa-1c5f-4d8b-be5d-33ec73f5a962@default> <87twbncgve.fsf@gmx.net> <3687e9ab-658b-49b9-b766-8658d5c48374@default> <87pombceyc.fsf@gmx.net> 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 1478282515 27326 195.159.176.226 (4 Nov 2016 18:01:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 4 Nov 2016 18:01:55 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 04 19:01:51 2016 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 1c2int-0003ZY-FJ for ged-emacs-devel@m.gmane.org; Fri, 04 Nov 2016 19:01:25 +0100 Original-Received: from localhost ([::1]:40174 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2inw-00075s-DX for ged-emacs-devel@m.gmane.org; Fri, 04 Nov 2016 14:01:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2inM-00075h-AH for emacs-devel@gnu.org; Fri, 04 Nov 2016 14:00:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2inL-00085D-8l for emacs-devel@gnu.org; Fri, 04 Nov 2016 14:00:52 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:50023) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c2inH-0007xX-7x; Fri, 04 Nov 2016 14:00:47 -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 uA4I0fmS029276 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 4 Nov 2016 18:00:42 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uA4I0fcU001737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 4 Nov 2016 18:00:41 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uA4I0fng003865; Fri, 4 Nov 2016 18:00:41 GMT In-Reply-To: <87pombceyc.fsf@gmx.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.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] 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:209161 Archived-At: > > It is not unreasonable to be clear and brief. I repeat: > > if the doc means "the innermost sexp containing point" then > > it should just say that. That's not being pedantic; it's > > being clear. >=20 > So is the following (combining Eli's changes with my correction and > your clarification) then clear enough? >=20 ... > If the innermost sexp containing point is a list or string, you > cannot transpose that sexp with another sexp. ... LGTM. But as one reader I would still want to know what "cannot" means here - what happens if you try? Eli has replied in the bug thread that there are several possible behaviors (effects), so I guess we can't usefully say what it means. Dommage. Here's a thought: Are any of the behaviors resulting from trying that useful? If so, then they should perhaps be documented. And if not, why don't we check for that situation and raise an error if you try? It is really not great to tell someone they "cannot" or "must not" etc. do something without raising an error that really enforces "cannot" etc. Sure, if you try, the result won't transpose the sexps, so technically you "cannot" transpose sexps in this case. But I'd sooner see a clear error than just some unpredictable behavior. (Unpredictable from reading the doc. There are multiple possibilities, and we won't be detailing them in the doc.)