GNU bug report logs - #20241
25.0.50; `setq' with only one argument

Previous Next

Full log

Message #40 received at 20241 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Artur Malabarba <bruce.connor.am <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 20241 <at> debbugs.gnu.org
Subject: Re: bug#20241: 25.0.50; `setq' with only one argument
Date: Tue, 24 Nov 2015 21:09:56 +0000

Hello, Artur.

On Tue, Nov 24, 2015 at 07:26:16PM +0000, Artur Malabarba wrote:
> On 24 Nov 2015 6:04 pm, "Alan Mackenzie" <acm <at> muc.de> wrote:
> > There were, after all, only five uses of this
> > "feature" in the entire Emacs code base.  And one of these was in
> > .../obsolete.

> A few months ago Stefan changed save-excursion to no longer restore the
> mark. IIRC (though I may be forgetting), there were zero uses of this in
> the codebase, and he even asked about it on the list and nobody said "I use
> this".
> Still, after the change was applied, some issues came up on a couple of
> highly used packages out there, and my guess is that more will come up once
> 25 is released.

> I'm not speaking against that change. It was a good change because it fixed
> more problems than it created. And the same is true here. This change will
> be good.

> However, if there are 5 uses of it in the core, then it's likely there are
> 30 or 100 uses of it in the wild. This change _will_ break things. So it is
> my opinion that it should go in the master branch. The feature freeze
> exists for a reason.

This is a bug fix.  One might debate whether or not allowing implicit
nils in setq is a bug or not.  But the consequence was that our byte
compiler was broken.  Maybe not badly broken, but broken nonetheless.

On finding a bug, I always try to fix not just the bug itself, but the
cause of the bug.  It seems clear to me that the ultimate cause of the
broken byte compiler was the lack of a check on `setq'.

> The emacs 25 branch should only get the warning, instead. A warning really
> goes a long way, and it doesn't break anything.

A warning does indeed go a long way.  However, the breakage which will
happen out in the field is not serious.  A small number of .el files
will fail to compile, and will do so with a clear error message.  I
suspect a larger number of bugs will be revealed than working code
broken.

I favour leaving the situation as it is.  However, it is for John to
decide.  If he comes round to the view that an error is too strong, I am
willing to turn it back into a warning.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.