eglot--connect: Symbol’s function definition is void: project-name

Question

eglot--connect: Symbol’s function definition is void: project-name

jaybarra opened this issue a year ago · comments

Jay Barra commented a year ago

Environment

Emacs for Mac 28.2
eglot-1.13

Reproduction Steps

Ensure the clangd LSP server is installed and available in path
Delete or rename ~/.emacs.d
Recreate ~/.emacs.d directory
Recreate ~/.emacs.d/init.el with the following contents

;;; init.el --- Minimum eglot example
;;; Commentary:
;;; Code:

(unless (fboundp 'package-activate-all) (package-initialize))

;;; init.el ends here

Open Emacs
M-x package-install RET eglot RET
M-x make-directory RET eglot-mre RET
C-x C-f ~/eglot-mre/main.c RET
Fill with the following

/* main.c */
int main(int argc, char *argv[]) {
  return 0;
}

C-x C-s
M-x eglot and receive this error in the *Messages* buffer
eglot--connect: Symbol’s function definition is void: project-name

João Távora · Answer 1 · Thu Mar 30 2023 19:13:12 GMT+0800 (China Standard Time)

Reproduced. The problem goes away simply restarting Emacs.

I don't understand why project.el is being loaded as part of the package-install process of Eglot.

João Távora · Answer 2 · Thu Mar 30 2023 19:18:53 GMT+0800 (China Standard Time)

I don't understand why project.el is being loaded as part of the package-install process of Eglot.

Or rather, I do understand that, eglot.el has a (require 'project) which is run at compilation time.
But I don't understand why is it that, if project.el is a dependency of Eglot, and thus must be installed before, why it isn't in place already when this require happens.

Maybe @monnier can shed some light?

Basil L. Contovounesios · Answer 3 · Thu Mar 30 2023 19:41:14 GMT+0800 (China Standard Time)

Is this [similar to] https://bugs.gnu.org/61048 ?

I.e. is Emacs 28.2 picking up the built-in project that lacks project-name, rather than the more recent version of project required by Eglot?

João Távora · Answer 4 · Thu Mar 30 2023 19:51:31 GMT+0800 (China Standard Time)

I.e. is Emacs 28.2 picking up the built-in project that lacks project-name, rather than the more recent version of project required by Eglot?

Yes. And this can happen if you have previously loaded the build in project.el before you issue M-x package-install RET eglot RET. But in this recipe, you'll notice that (featurep 'project) reports nil in the beginning. So at a certain point, the old built-in project.el is loaded, when, AFAICT only eglot.el 's compilation require s it. And by that time, the new version should have been installed already, becasue project.el is a dependency of eglot.el.

Is this [similar to] https://bugs.gnu.org/61048 ?

I'll have a look.

João Távora · Answer 5 · Thu Mar 30 2023 20:35:33 GMT+0800 (China Standard Time)

Is this [similar to] https://bugs.gnu.org/61048 ?

I don't think so. I think there the problem was the failure to pull in a transitive dependency right?

Here, it's -- I presume -- not having the right load-path setup by the time that the (require 'project) happens.

monnier · Answer 6 · Thu Mar 30 2023 21:07:41 GMT+0800 (China Standard Time)

Or rather, I do understand that, `eglot.el` has a `(require 'project)` which is run at compilation time. But I don't understand why it is that, if `project.el` is a dependency of Eglot, and thus must be installed before, why it isn't in place already when this `require` happens. Maybe @monnier can shed some light?

AFAIK `package.el` has code that intends to handle this correctly, so it sounds like either a bug in that code, or some funny interaction somewhere causes `project.el` to be loaded somehow before `package.el` tweaks the load path to include the updated `project` package.

João Távora · Answer 7 · Thu Mar 30 2023 21:12:46 GMT+0800 (China Standard Time)

In the meantime, I think the best is for eglot to replace (require 'project) with (load "project") right? It's a bit unidiomatic, but I see no better way to protect users against this.

The problem can still happen very easily if you decide to M-x package-install RET eglot after doing some project.el things.

Unless we force the dependent libraries to be loaded after each package-install. Not pretty, but safer.

monnier · Answer 8 · Thu Mar 30 2023 21:28:15 GMT+0800 (China Standard Time)

In the meantime, I think the best is for `eglot` to replace `(require 'project)` with `(load "project")` right? It's a bit unidiomatic, but I see no better way to protect users against this.

In theory that should not be necessary because `package.el` should itself reload `project.el` after setting up the new path (if `project.el` had been loaded earlier).

João Távora · Answer 9 · Thu Mar 30 2023 21:31:21 GMT+0800 (China Standard Time)

In theory that should not be necessary because package.el should
itself reload project.el after setting up the new path (if
project.el had been loaded earlier).

So can you follow Jay's reproduction recipe and find out why this
isn't happening?

João

monnier · Answer 10 · Fri Mar 31 2023 03:39:16 GMT+0800 (China Standard Time)

So can you follow Jay's reproduction recipe and find out why this isn't happening?

I don't have much time to dig into this now. Maybe the best bet is to `M-x report-emacs-bug` with this recipe (and put me in X-Debbug-Cc`) so there's less risk that I forget about it.

João Távora · Answer 11 · Mon Apr 03 2023 07:29:05 GMT+0800 (China Standard Time)

Done, here's the report.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62576

In the meaning, i think I'll put the load statements there.

João Távora · Answer 12 · Tue Apr 04 2023 05:53:20 GMT+0800 (China Standard Time)

In the meaning, i think I'll put the load statements there.

This is now in Eglot 1.14, I've just tested this recipe and it doesn't error anymore. Please test and report back here to reopen if it doesn'twork.

Aiden Loyd · Answer 13 · Wed Apr 26 2023 06:36:53 GMT+0800 (China Standard Time)

I just ran into this, and I had to explicitly (require 'eglot) before doing anything (I was originally using the autoloaded eglot function to load the library). I'm not sure if this can be fixed, or if it will just need to be mentioned as a workaround.

EDIT: A Minimum Reproducible Example is in the works, I apologize, I posted this hastily.
EDIT 2: I could not quite reproduce with a basic example, my guess is that my issue was dependent on my particular setup (the straight package manager, in particular). If anyone does run into this issue, where any of the project.el functions are being used from the built in version, rather than the version installed with eglot, just make sure to run (require 'eglot) somewhere so that the new version of project.el is used.

João Távora · Answer 14 · Wed Apr 26 2023 06:49:49 GMT+0800 (China Standard Time)

I just ran into this

Can you explain exactly how you ran into this? There are many possible ways to "run into this". Your require eglot doesn't make much sense.

So please, if you can, provide a Minimum Reproducible Example just like @jaybarra did.

Josep Bigorra · Answer 15 · Wed May 10 2023 17:11:59 GMT+0800 (China Standard Time)

For people using ELPACA (i am on Emacs 28.2), you need to install project first:

  (defun my-eglot-organize-imports () (interactive)
         (eglot-code-actions nil nil "source.organizeImports" t))

  (use-package project :demand t)
  
  (use-package eglot
    :demand t
    :after (project projectile)
    :hook (
           (scala-mode . eglot-ensure)
           (sh-mode . eglot-ensure)
           (python-mode . eglot-ensure)
           (java-mode . eglot-ensure)
           (yaml-mode . eglot-ensure)
           (haskell-mode . eglot-ensure)
           (go-mode . eglot-ensure)
           (dockerfile-mode . eglot-ensure)
           )
    :config
    (add-hook 'before-save-hook 'my-eglot-organize-imports nil t)
    (add-hook 'before-save-hook 'eglot-format-buffer)
    )