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