From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#20241: 25.0.50; `setq' with only one argument Date: Wed, 25 Nov 2015 17:22:12 +0000 Message-ID: <20151125172211.GH2007@acm.fritz.box> References: <20151124180452.GB1840@acm.fritz.box> <20151124210956.GC1840@acm.fritz.box> <20151125094155.GB2007@acm.fritz.box> <20151125110755.GC2007@acm.fritz.box> <20151125154030.GF2007@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1448472107 16126 80.91.229.3 (25 Nov 2015 17:21:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 17:21:47 +0000 (UTC) Cc: John Wiegley , 20241@debbugs.gnu.org, Artur Malabarba To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 25 18:21:34 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1a1dl7-0000Z4-Lg for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Nov 2015 18:21:33 +0100 Original-Received: from localhost ([::1]:46760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1dl8-000710-Sh for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Nov 2015 12:21:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1dkf-0006Ej-Oa for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 12:21:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1dkc-00081V-Di for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 12:21:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1dkc-00081R-AP for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 12:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a1dkb-0003BT-Tb for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 12:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Nov 2015 17:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20241 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20241-submit@debbugs.gnu.org id=B20241.144847203012187 (code B ref 20241); Wed, 25 Nov 2015 17:21:01 +0000 Original-Received: (at 20241) by debbugs.gnu.org; 25 Nov 2015 17:20:30 +0000 Original-Received: from localhost ([127.0.0.1]:53032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1dk5-0003AU-0w for submit@debbugs.gnu.org; Wed, 25 Nov 2015 12:20:29 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:45265) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1djk-0003A0-1x for 20241@debbugs.gnu.org; Wed, 25 Nov 2015 12:20:27 -0500 Original-Received: (qmail 2447 invoked by uid 3782); 25 Nov 2015 17:20:06 -0000 Original-Received: from acm.muc.de (p5B146B74.dip0.t-ipconnect.de [91.20.107.116]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 25 Nov 2015 18:20:06 +0100 Original-Received: (qmail 22679 invoked by uid 1000); 25 Nov 2015 17:22:12 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109240 Archived-At: Hello, Drew. On Wed, Nov 25, 2015 at 08:27:43AM -0800, Drew Adams wrote: [ .... ] > But if you can DTRT now - analyze the code sufficiently and fix > it properly or contact the author for an opinion - then that's > the thing to do. That's already been done with the Emacs core, and that's what I'd like to do with elpa. But code over which we have no control might be problematic. > Or if you just leave the code as is, but ensure that a runtime > error is raised, that is also TRT. It takes care of THIS bug, > but it does not fix that bug (indicated by the error occurrence). That would mean the users will suffer an error rather than the maintainers. And the Emacs team will get blamed for the breakage. [ .... ] > > > IMO, the bug should be fixed to raise an _error at runtime_, > > > for both interpreted and byte-compiled code. I think that a compiler generating a runtime error for a compile time problem isn't a good idea. [ .... ] > The byte-compiler is not just some QA tool to check whether i's > are dotted and t's are crossed. No, but that is a significant part of its job spec. [ .... ] > > Why is this topic suddenly seeming complicated? :-( > I don't think it's complicated. `setq' should raise an error > when it is passed an odd number of arguments. _That's all._ > The error should be raised when `setq' is invoked, obviously. There are several different behaviours possible in both the interpreter and compiler: 1. Interpreter: (a) Current behviour: silently insert a nil into the `setq'. (b) Throw an error (current new behaviour in emacs-25). (c) Issue a warning, but continue otherwise with (a). 2. Compiler: (a) Silently compile code which slips in a nil (current behaviour). (b) Issue a warning, but compile in the nil. (c) Issue an error, but compile in the nil. (current new behaviour in emacs-25.) (d) Issue an error, and abort the compilation: (i) immediately. (ii) at the end of the source file. (e) Issue an error, and generate code to: (i) issue a warning, but carry on with the nil. (ii) throw an error. You seem to favour 1(b) and, I think, 2(d)(ii) or 2(e)(ii). I favour 1(b) and probably 2(c), possibly 2(e)(i). To me, these possibilities are complicated. It's not a technical problem, it's a social problem: who's going to be notified of the problem and when. I would far rather maintainers were hassled than users. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).