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

> Philipp Stephani <p.stephani2@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).