From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: giving `setq-local' the same signature as `setq' Date: Thu, 19 Mar 2015 10:25:19 -0700 (PDT) Message-ID: <6e39610c-c64d-412c-9024-e4116589fbec@default> References: <0471cc2e-84d4-4a15-88b6-92a980e2949e@default> <87bnjp3tkv.fsf@gmail.com> <7455a7dd-8c32-4681-95a0-6d09f50ac169@default> <87vbhx2d8k.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1426785989 2548 80.91.229.3 (19 Mar 2015 17:26:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Mar 2015 17:26:29 +0000 (UTC) Cc: Jordon Biondo , rms@gnu.org, Stefan Monnier , emacs-devel@gnu.org To: Oleh Krehel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 19 18:26:16 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YYeCz-0003EF-NP for ged-emacs-devel@m.gmane.org; Thu, 19 Mar 2015 18:26:13 +0100 Original-Received: from localhost ([::1]:40358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYeCy-0005Up-Nw for ged-emacs-devel@m.gmane.org; Thu, 19 Mar 2015 13:26:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYeCK-0005Lf-3a for emacs-devel@gnu.org; Thu, 19 Mar 2015 13:25:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYeCC-00082y-H7 for emacs-devel@gnu.org; Thu, 19 Mar 2015 13:25:32 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:24867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYeCC-00082p-AE; Thu, 19 Mar 2015 13:25:24 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2JHPLYb005550 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Mar 2015 17:25:22 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2JHPJ2D013164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Mar 2015 17:25:19 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2JHPJTO010029; Thu, 19 Mar 2015 17:25:19 GMT In-Reply-To: <87vbhx2d8k.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:184023 Archived-At: > > You can do the same for `let*', if you like: > > (let ((foo fooval)) > > (let ((phlop phlopval)) > > (let ((toto totoval)) > > ...))) >=20 > Now you've just lead yourself into a trap. This is similar to > one-var-per-setq: > (let* ((foo fooval) > (phlop phlopval) > (toto totoval)) > ...) No, one var per `let' would be as I showed it - 3 `let's for 3 bindings. Using `let*' with multiple vars is analogous to using `setq' with multiple vars. `setq' assigns and `let*' binds, but they both let you give values to multiple variables. Or to only one variable at a time - your choice. > This is similar to multi-var-per-setq: > (let* (foo fooval > phlop phlopval > toto totoval) > ...) No, that is simply malformed code. > >> It also gives an anchor to quickly navigate to the variable > >> to get its value. > > > > How so? Please elaborate. >=20 > With C-M-n and C-M-p you can navigate to the big fat paren by which the > variable resides (after setq). OK. > >> In a setq list of 10 items, by item 5 it is already unclear which is t= he > >> variable and which is the value. In my opinion, it's not worth > >> complicating the code maintenance just to save a few chars. > > > > This is why it is good that you have the choice. >=20 > You're wrong here. I don't have the choice. Just yesterday I was debuggin= g > my AUCTEX config. It wasn't pleasant to navigate 5-variable setq > statements, some of which took the whole page. That problem is independent of this discussion, unless you are referring to the convenience of your using `C-M-p' to move to individual assignments. One can write bad code, with 473 `setq's in a row or with a single `setq' that has 473 assignments. Being able to group assignments in a single `setq' does not require anyone to use many assignments in a row. > > I find it clearer to let `setq' do the grouping, instead of implicit or > > explicit `progn'. But I put each var & value pair on a separate line: > > > > (setq foo fooval > > phlop phlopval ; Maybe this one needs a comment. > > toto totoval) > > > > I don't do this to save characters (e.g. for typing). I do it to make > > the code clearer and maintenance less error prone and easier. For me, > > at least. >=20 > Imagine that you want to comment out `phlop phlopval', which is a > multi-line statement. If it was bounded by parens, you could do it in an > easy and error-free way. Otherwise, you have to manually select the regio= n. Actually, `phlop phlopval' is a single line, and can be commented out simpl= y. But I take your point. Yes, the style I prefer can mean extra typing. To me it's worth it, for the sake of clearer code (IMO). But you don't need to write code the way I prefer. And you don't need to maintain my code. If you work with a team to create and maintain code, then it can help to decide what the team prefers, in terms of coding style. That's not limited to this discussion about `setq'. What is germain to this discussion is that different teams can choose what they want, wrt using separate `setq's for multiple assignments. What you propose is that for the sake of "consistency" there must be, in effect, only one team: the choice should be made for Emacs Lisp as a whole, instead of letting those who use it decide. I prefer that Emacs Lisp be consistent with, well, LISP in this regard. Multiple assignments for `setq' have been around since the 60s in Lisp (but no, they were not in Lisp 1.5). At least two of us like it that way.