GNU bug report logs - #29857
27.0.50; error: "Loading `nil': old-style backquotes detected!"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29857 in the body.
You can then email your comments to 29857 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; error: "Loading `nil': old-style backquotes detected!"
Date: Tue, 26 Dec 2017 15:38:42 +0100

Hello,

Insert into a fresh buffer (e.g. *scratch*):

#+begin_src emacs-lisp
`(progn
   (add-to-list 'rcirc-client-commands ,(concat "/" (symbol-name command)))
   (defun ,(intern (concat "rcirc-cmd-" (symbol-name command)))
       (,@argument &optional process target)
     ,(concat docstring "\n\nNote: If PROCESS or TARGET are nil, the values given"
	      "\nby `rcirc-buffer-process' and `rcirc-target' will be used.")
     ,interactive-form
     (let ((process (or process (rcirc-buffer-process)))
	   (target (or target rcirc-target)))
       (ignore target) ; mark `target' variable as ignorable
       ,@body)))
#+end_src

(that's the body of the `defun-rcirc-command' macro in rcirc.el).  Put
point after the starting backquote character, at the position of the
outermost opening paren.  Then (read (current-buffer)) errors with

| Debugger entered--Lisp error: (error "Loading `nil': old-style backquotes detected!")
|   read(#<buffer *scratch*>)
|   [...]

I think raising this error is not justified, as there are no old-style
backquotes there AFAIK.  Also, the error message saying loading `nil'
failed is confusing, it took me a while to find out where I tried to
load `nil' (nowhere).

Finally, let me say that `read' raising such errors about old-style
backquotes, may it be justified or not, breaks "el-search" which relies
heavily on `read' at diverse buffer positions to succeed.


TIA,

Michael.



In GNU Emacs 27.0.50 (build 25, x86_64-pc-linux-gnu, GTK+ Version 3.22.24)
 of 2017-12-21 built on drachen
Repository revision: e45499a6c1bae4577af2e86397e9bab23fd63bf1
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description: Debian GNU/Linux testing (buster)

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 29857 <at> debbugs.gnu.org
Subject: Re: bug#29857: 27.0.50;
 error: "Loading `nil': old-style backquotes detected!"
Date: Fri, 29 Dec 2017 20:34:26 +0000

[Message part 1 (text/plain, inline)]

Michael Heerdegen <michael_heerdegen <at> web.de> schrieb am Di., 26. Dez. 2017
um 15:39 Uhr:

>
> Hello,
>
> Insert into a fresh buffer (e.g. *scratch*):
>
> #+begin_src emacs-lisp
> `(progn
>    (add-to-list 'rcirc-client-commands ,(concat "/" (symbol-name command)))
>    (defun ,(intern (concat "rcirc-cmd-" (symbol-name command)))
>        (,@argument &optional process target)
>      ,(concat docstring "\n\nNote: If PROCESS or TARGET are nil, the
> values given"
>               "\nby `rcirc-buffer-process' and `rcirc-target' will be
> used.")
>      ,interactive-form
>      (let ((process (or process (rcirc-buffer-process)))
>            (target (or target rcirc-target)))
>        (ignore target) ; mark `target' variable as ignorable
>        ,@body)))
> #+end_src
>
> (that's the body of the `defun-rcirc-command' macro in rcirc.el).  Put
> point after the starting backquote character, at the position of the
> outermost opening paren.  Then (read (current-buffer)) errors with
>
> | Debugger entered--Lisp error: (error "Loading `nil': old-style
> backquotes detected!")
> |   read(#<buffer *scratch*>)
> |   [...]
>
> I think raising this error is not justified, as there are no old-style
> backquotes there AFAIK.


It's somewhat subtle, but if you skip ` there is an oldstyle backquote
here. There's a comment in lread.c:
           Because it's more difficult to peek 2 chars ahead, a new-style
   ,@ can still not be used outside of a `, unless it's in the middle
   of a list.
That is, in the construct (,@argument the ,@ is oldstyle unless the ` has
been read before.


> Also, the error message saying loading `nil'
> failed is confusing, it took me a while to find out where I tried to
> load `nil' (nowhere).
>

It would be reasonable and easy to remove the "Loading `nil'" part in the
case where no file is being loaded.


>
> Finally, let me say that `read' raising such errors about old-style
> backquotes, may it be justified or not, breaks "el-search" which relies
> heavily on `read' at diverse buffer positions to succeed.
>
>
That's a bummer. It means that el-search currently relies on an
underspecified legacy feature. Could el-search be changed to always include
reading the initial ` in such cases?
Otherwise I'd accept introducing a variable to control whether oldstyle
backquotes should raise an error or get interpreted as newstyle. El-search
would need to adapt, though, because the newstyle interpretation is
different. However, that will need to happen anyway because at some point
in time (Emacs 28?) we want to get rid of oldstyle backquotes altogether.

[Message part 2 (text/html, inline)]

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 29857 <at> debbugs.gnu.org
Subject: Re: bug#29857: 27.0.50;
 error: "Loading `nil': old-style backquotes detected!"
Date: Sat, 30 Dec 2017 15:00:41 +0100

Philipp Stephani <p.stephani2 <at> gmail.com> writes:

> It's somewhat subtle, but if you skip ` there is an oldstyle backquote here. There's a
> comment in lread.c:
>            Because it's more difficult to peek 2 chars ahead, a new-style
>    ,@ can still not be used outside of a `, unless it's in the middle
>    of a list.
> That is, in the construct (,@argument the ,@ is oldstyle unless the ` has been read
> before.

Hmm, ok.
 
>  Also, the error message saying loading `nil'
>  failed is confusing, it took me a while to find out where I tried to
>  load `nil' (nowhere).
>
> It would be reasonable and easy to remove the "Loading `nil'" part in
> the case where no file is being loaded.

Yes, I think that would be good.
  
>  Finally, let me say that `read' raising such errors about old-style
>  backquotes, may it be justified or not, breaks "el-search" which relies
>  heavily on `read' at diverse buffer positions to succeed.
>
> That's a bummer. It means that el-search currently relies on an
> underspecified legacy feature. Could el-search be changed to always
> include reading the initial ` in such cases?

Not really.  It would mean that the "construct" after any backquote
can't be matched or replaced.

E.g. if you have a function `foo' accepting three arguments, and you
decide to change the definition of `foo' so that the meaning of the
second and third arguments are interchanged, you want to replace all
calls in your code with the rule

  `(foo ,a ,b ,c) -> `(foo ,a ,c ,b)

to adopt to the new signature.

(Note that the backquote here is part of `pcase' pattern semantics and
there is no relation with this issue).

But in this occurrence:

#+begin_src emacs-lisp
(defmacro bar (form)
  `(foo 1 1 ,@form))
#+end_src

this replacement rule would fail because the according form would be
unmatchable (and the backquoted thing doesn't match).  One could work
around this...there are always workarounds.  To need to do that would be
very bad.

> Otherwise I'd accept introducing a variable to control whether
> oldstyle backquotes should raise an error or get interpreted as
> newstyle.

That would be optimal for my case.

> El-search would need to adapt, though, because the newstyle
> interpretation is different.

In which way would el-search need to adapt?  It doesn't interpret code.
It is a tool for matching and transforming lists, which, in most cases,
happen to be code.  The user would need to know how `read' interprets
what's matched, of course.


Thanks,

Michael.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 29857 <at> debbugs.gnu.org
Subject: Re: bug#29857: 27.0.50;
 error: "Loading `nil': old-style backquotes detected!"
Date: Sat, 30 Dec 2017 14:34:09 +0000

[Message part 1 (text/plain, inline)]

Michael Heerdegen <michael_heerdegen <at> web.de> schrieb am Sa., 30. Dez. 2017
um 15:00 Uhr:

> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> >  Also, the error message saying loading `nil'
> >  failed is confusing, it took me a while to find out where I tried to
> >  load `nil' (nowhere).
> >
> > It would be reasonable and easy to remove the "Loading `nil'" part in
> > the case where no file is being loaded.
>
> Yes, I think that would be good.
>

OK, I've sent a patch to do that:
https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00901.html


>
> >  Finally, let me say that `read' raising such errors about old-style
> >  backquotes, may it be justified or not, breaks "el-search" which relies
> >  heavily on `read' at diverse buffer positions to succeed.
> >
> > That's a bummer. It means that el-search currently relies on an
> > underspecified legacy feature. Could el-search be changed to always
> > include reading the initial ` in such cases?
>
> Not really.  It would mean that the "construct" after any backquote
> can't be matched or replaced.
>
> E.g. if you have a function `foo' accepting three arguments, and you
> decide to change the definition of `foo' so that the meaning of the
> second and third arguments are interchanged, you want to replace all
> calls in your code with the rule
>
>   `(foo ,a ,b ,c) -> `(foo ,a ,c ,b)
>
> to adopt to the new signature.
>
> (Note that the backquote here is part of `pcase' pattern semantics and
> there is no relation with this issue).
>
> But in this occurrence:
>
> #+begin_src emacs-lisp
> (defmacro bar (form)
>   `(foo 1 1 ,@form))
> #+end_src
>
> this replacement rule would fail because the according form would be
> unmatchable (and the backquoted thing doesn't match).  One could work
> around this...there are always workarounds.  To need to do that would be
> very bad.
>

OK


>
> > Otherwise I'd accept introducing a variable to control whether
> > oldstyle backquotes should raise an error or get interpreted as
> > newstyle.
>
> That would be optimal for my case.
>

I've sent a patch for this as well:
https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00902.html


>
> > El-search would need to adapt, though, because the newstyle
> > interpretation is different.
>
> In which way would el-search need to adapt?  It doesn't interpret code.
> It is a tool for matching and transforming lists, which, in most cases,
> happen to be code.  The user would need to know how `read' interprets
> what's matched, of course.
>
>
>
Then I guess el-search should document the new behavior. Previously (up to
Emacs 26) (read "(,@ x)") returns (\,@ x), now (with the new variable) it
returns ((\,@ x)).
However, if el-search uses `read` for both the buffer text and the search
pattern, the interpretations should still match (within one version of
Emacs).

[Message part 2 (text/html, inline)]

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 29857 <at> debbugs.gnu.org
Subject: Re: bug#29857: 27.0.50;
 error: "Loading `nil': old-style backquotes detected!"
Date: Sat, 30 Dec 2017 23:33:55 +0100

Hi Philipp,

thanks for working on this.

>  > It would be reasonable and easy to remove the "Loading `nil'" part in
>  > the case where no file is being loaded.
>
>  Yes, I think that would be good.
>
> OK, I've sent a patch to do that:
> https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00901.html

Yes, that should be ok, I think.

>  > Otherwise I'd accept introducing a variable to control whether
>  > oldstyle backquotes should raise an error or get interpreted as
>  > newstyle.
>
>  That would be optimal for my case.
>
> I've sent a patch for this as well:
> https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00902.html

Thanks.  Looks like it does what I want.

> Then I guess el-search should document the new behavior. Previously
> (up to Emacs 26) (read "(,@ x)") returns (\,@ x), now (with the new
> variable) it returns ((\,@ x)).  However, if el-search uses `read` for
> both the buffer text and the search pattern, the interpretations
> should still match (within one version of Emacs).

Yes, it does.  I think there is no problem with this new behavior (well,
unless you either try to make use of old-style backquotes, or need the
semantics of old-style backquotes to transform old code that makes use
of old-style backquotes - I don't need to support these cases).


Thanks,

Michael.

Message #22 received at 29857-done <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 29857-done <at> debbugs.gnu.org
Subject: Re: bug#29857: 27.0.50;
 error: "Loading `nil': old-style backquotes detected!"
Date: Sun, 07 Jan 2018 13:26:46 +0000

[Message part 1 (text/plain, inline)]

Michael Heerdegen <michael_heerdegen <at> web.de> schrieb am Sa., 30. Dez. 2017
um 23:33 Uhr:

> Hi Philipp,
>
> thanks for working on this.
>
> >  > It would be reasonable and easy to remove the "Loading `nil'" part in
> >  > the case where no file is being loaded.
> >
> >  Yes, I think that would be good.
> >
> > OK, I've sent a patch to do that:
> > https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00901.html
>
> Yes, that should be ok, I think.
>
> >  > Otherwise I'd accept introducing a variable to control whether
> >  > oldstyle backquotes should raise an error or get interpreted as
> >  > newstyle.
> >
> >  That would be optimal for my case.
> >
> > I've sent a patch for this as well:
> > https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00902.html
>
> Thanks.  Looks like it does what I want.
>
>
OK, I've now pushed both patches to master.

[Message part 2 (text/html, inline)]

Previous Next

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