bug#20241: 25.0.50; `setq' with only one argument

[Alan Mackenzie]

Hello, John.

On Tue, Nov 24, 2015 at 05:46:23PM -0800, John Wiegley wrote:
> >>>>> Alan Mackenzie <acm@muc.de> writes:

> > 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.

> I would like it to appear in 25.1. I'm willing to err against caution this
> time. It would be stranger to me to have it go from a warning to an error
> within 25.x, which then means waiting until 26 for it to be an error.

> Now that it's in the release branch, how about we try out some large packages
> and see if it's actually a problem?

We won't see any problem in our own sources, because all the occurrences
here have been expunged.  Any problems will be with external libraries
(or possibly in *ELPA) which people expect just to download, compile and
run.  I think that was what Artur is worried about.

> Since I can't imagine anyone intentionally using this just to save
> themselves from typing "nil", I'd expect people would want to know
> that their setq is ill-formed. It might indicate a real problem.

Of the five non-error former occurrences, all were very old - the last
one was touched by Stefan in 2005 (according to git blame).  Some of
them, possibly all of them, were indeed deliberate: there was a space
left between the variable and the closing paren.

Personally, I think there will be very few in external sources, and we
are more likely to flag up real errors than break working code.

> John

-- 
Alan Mackenzie (Nuremberg, Germany).