[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47168: 28.0.50; Infinite recursion in project-root
From: |
Dmitry Gutov |
Subject: |
bug#47168: 28.0.50; Infinite recursion in project-root |
Date: |
Wed, 17 Mar 2021 04:47:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 |
Hi Juri,
On 15.03.2021 19:04, Juri Linkov wrote:
When for some reason the argument of 'project-root' becomes nil,
for example, when the current buffer is not under version control,
then
(project-root (project-current))
goes into infinite recursion:
Debugger entered--Lisp error: (error "Lisp nesting exceeds
‘max-lisp-eval-depth’")
project-root(nil)
project-roots(nil)
...
project-root(nil)
project-roots(nil)
...
Note that the right way to write this code is either
(project-root (project-current t))
or
(when-let ((project (project-current)))
(project-root project))
so we only see this when the programmer failed to account for the
absence of current project.
Still, it would be nice to never show a backtrace like this, even in
those cases.
The idea here was to keep compatibility with backends which implement
project-roots and not project-root (perhaps the built-in vc backend in
Emacs 27), as well as let the clients call either project-root or
project-roots, also for backward compatibility purposes. Worst case, we
can give up on that and require all 3rd party code standardize on
project-root and have all users install the latest project.el from ELPA.
But perhaps we still can have it both ways?
Stefan, any chance there's a relatively non-dirty way we can check
whether there is a non-default implementation for the generic function
with given args, before calling it? That would allow us to break recursion.