unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Artur Malabarba <bruce.connor.am@gmail.com>
Cc: 20241@debbugs.gnu.org
Subject: bug#20241: 25.0.50; `setq' with only one argument
Date: Tue, 24 Nov 2015 21:09:56 +0000	[thread overview]
Message-ID: <20151124210956.GC1840@acm.fritz.box> (raw)
In-Reply-To: <CAAdUY-+nrZN7qMjpWZjQ53XXxtYVH2h2w6sgFLjhMZUbNHpT6g@mail.gmail.com>

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





  reply	other threads:[~2015-11-24 21:09 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 14:53 bug#20241: 25.0.50; `setq' with only one argument Drew Adams
2015-04-01 16:41 ` Stefan Monnier
     [not found] ` <mailman.3138.1427900048.31049.bug-gnu-emacs@gnu.org>
2015-11-23 14:31   ` Alan Mackenzie
2015-11-23 18:44     ` Glenn Morris
2015-11-23 18:54       ` Glenn Morris
2015-11-23 22:05         ` John Wiegley
2015-11-23 19:31       ` Alan Mackenzie
2015-11-24 11:32         ` Alan Mackenzie
2015-11-24 17:38         ` Glenn Morris
2015-11-24 18:04           ` Alan Mackenzie
2015-11-24 19:26             ` Artur Malabarba
2015-11-24 21:09               ` Alan Mackenzie [this message]
2015-11-25  1:46                 ` John Wiegley
2015-11-25  9:41                   ` Alan Mackenzie
2015-11-25 10:36                     ` Artur Malabarba
2015-11-25 11:07                       ` Alan Mackenzie
2015-11-25 11:13                         ` Artur Malabarba
2015-11-25 11:28                           ` Alan Mackenzie
2015-11-25 15:18                         ` Drew Adams
2015-11-25 15:40                           ` Alan Mackenzie
2015-11-25 16:27                             ` Drew Adams
2015-11-25 17:22                               ` Alan Mackenzie
2015-11-25 18:28                                 ` Drew Adams
2015-11-25 19:06                                   ` John Wiegley
2015-11-25 19:21                                     ` John Mastro
2015-11-25 19:22                                     ` Drew Adams
2015-11-25 19:34                                     ` Artur Malabarba
2015-11-25 19:40                                       ` John Wiegley
2015-11-25 20:20                                         ` Artur Malabarba
2015-11-25 20:37                                           ` John Wiegley
2015-11-26 11:07                                             ` Alan Mackenzie
2015-11-25 20:58                                         ` Alan Mackenzie
2015-11-25 21:19                                           ` Drew Adams
2015-11-25 21:52                                           ` John Wiegley
2015-11-26  0:21                                     ` Johan Bockgård
2015-11-26  8:58                                       ` Andreas Schwab
2015-11-26 12:06                                         ` Alan Mackenzie
2015-11-26 16:38                                           ` Artur Malabarba
2015-11-26 21:19                                             ` Alan Mackenzie
2015-11-27  0:07                                               ` Artur Malabarba
2015-11-25 13:11                       ` Nicolas Richard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151124210956.GC1840@acm.fritz.box \
    --to=acm@muc.de \
    --cc=20241@debbugs.gnu.org \
    --cc=bruce.connor.am@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).