From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#29857: 27.0.50; error: "Loading `nil': old-style backquotes detected!" Date: Sat, 30 Dec 2017 14:34:09 +0000 Message-ID: References: <87d131ftal.fsf@web.de> <87y3lkgvsm.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11c01276f9cd7f05618fa454" X-Trace: blaine.gmane.org 1514644399 3966 195.159.176.226 (30 Dec 2017 14:33:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Dec 2017 14:33:19 +0000 (UTC) Cc: 29857@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 30 15:33:14 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVICG-0000Zb-AT for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Dec 2017 15:33:12 +0100 Original-Received: from localhost ([::1]:56345 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eVIED-00027w-J3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Dec 2017 09:35:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eVIE6-00027o-73 for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2017 09:35:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eVIE2-0000Ay-VU for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2017 09:35:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48617) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eVIE2-0000Am-Ov for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2017 09:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eVIE2-0005O1-Hy for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2017 09:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Dec 2017 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29857 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29857-submit@debbugs.gnu.org id=B29857.151464446820650 (code B ref 29857); Sat, 30 Dec 2017 14:35:02 +0000 Original-Received: (at 29857) by debbugs.gnu.org; 30 Dec 2017 14:34:28 +0000 Original-Received: from localhost ([127.0.0.1]:57298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVIDU-0005Mz-81 for submit@debbugs.gnu.org; Sat, 30 Dec 2017 09:34:28 -0500 Original-Received: from mail-qt0-f172.google.com ([209.85.216.172]:35227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVIDR-0005Mg-4o for 29857@debbugs.gnu.org; Sat, 30 Dec 2017 09:34:25 -0500 Original-Received: by mail-qt0-f172.google.com with SMTP id u10so56901483qtg.2 for <29857@debbugs.gnu.org>; Sat, 30 Dec 2017 06:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XtEPz01rK8pSYGT1VN5vIckBizK9Ll671fBJABfHf+o=; b=Rbe90O49HJ/oBAV27jLzRjOpwjimYYWvyTUFrD5vY4qHik1A+pazGIXfuDTK3iSJXu PiUjTgnjtW1YpGFzE2EtpicQcolJqiEEdeDi/31T/EPUJ/9WidgXnwa/IogDD13Upvhq VQpDS1YEKgQJHgcmbeC8JRqnvGbMXo7o+H0qAAxNTB9pziLpjbnz7wF3DmQw00R/ZsHA S1qVoZIvsAxK8gM+qwUGlodTPGE/gwy87j/G3gd+Dink1r6LMsMOJknfn1fm1TpIlogf 43OLX8Ea+sFmlqjVL9AATnsAVzxOs5envmrVN9cPumVwNTYlEjUh7mlfd7wQyxwklCG9 Pzkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XtEPz01rK8pSYGT1VN5vIckBizK9Ll671fBJABfHf+o=; b=Wuqn+XjXO7sP1pEpQYN84KiwiVmTXuGJM9ZBGKFnuFyKXk1gvccV51T9vlvWgVRuci ywQ26uSLc17kW8/IPv+MZXNems/Ono25FlhQ1y3E/5nrbMAydDCGGy6GpJ9cPcZP+fA5 Suy+tUciPR6YdPYiZINtvcNKfWbCv5h9OYaNEgoUhHqd5anOha2YYHQdjYLADDEyagrw wlOp82cXwmoVfHuJHmiZ5NFe1M8Wy/yxgvJhkK8RSFAiXrGBpaMnUPMSa78G+jp6IEne h4UgERcmOcM+dV7zvNkdZRYW/PzN5gYe+6jkBKIZ80tsInc6vLCn1c50dcRw8Gz8cfAu iAwA== X-Gm-Message-State: AKGB3mL2YD3kDS9b4M5FPQzwtJdD+LuQYhTDZraXcThizUBxBjLaGwcn ByPif5DXqYLc1O9FqTJWagqWcB41rsOwoDTzork= X-Google-Smtp-Source: ACJfBos/4Vory5jkbQBpNfaWSfp5/EDLVaIkC683hB5JFGUpH5or0FoxqplNS8pP4PFty9x9CBNZkVtf/OKaS52xGiE= X-Received: by 10.200.46.149 with SMTP id h21mr49262419qta.73.1514644459604; Sat, 30 Dec 2017 06:34:19 -0800 (PST) In-Reply-To: <87y3lkgvsm.fsf@web.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:141618 Archived-At: --001a11c01276f9cd7f05618fa454 Content-Type: text/plain; charset="UTF-8" Michael Heerdegen schrieb am Sa., 30. Dez. 2017 um 15:00 Uhr: > Philipp Stephani 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). --001a11c01276f9cd7f05618fa454 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Michae= l Heerdegen <michael_heerdeg= en@web.de> schrieb am Sa., 30. Dez. 2017 um 15:00=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> writes:<= br>
>=C2=A0 Also, the error message saying loading `nil'
>=C2=A0 failed is confusing, it took me a while to find out where I trie= d to
>=C2=A0 load `nil' (nowhere).
>
> It would be reasonable and easy to remove the "Loading `nil'&= quot; part in
> the case where no file is being loaded.

Yes, I think that would be good.

=C2=A0

>=C2=A0 Finally, let me say that `read' raising such errors about ol= d-style
>=C2=A0 backquotes, may it be justified or not, breaks "el-search&q= uot; which relies
>=C2=A0 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.=C2=A0 It would mean that the "construct" after any ba= ckquote
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

=C2=A0 `(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<= br> there is no relation with this issue).

But in this occurrence:

#+begin_src emacs-lisp
(defmacro bar (form)
=C2=A0 `(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).=C2=A0 One could w= ork
around this...there are always workarounds.=C2=A0 To need to do that would = be
very bad.

OK
=C2=A0

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

=C2=A0

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

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



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