Open matta opened 2 days ago
eglot-x requires Eglot version 1.16. I guess package-vc-install makes sure the availability of the correct dependencies. Have you tried that?
eglot-x requires Eglot version 1.16. I guess package-vc-install makes sure the availability of the correct dependencies. Have you tried that?
It does not seem to in practice. This is how I install eglot-x in my init.el:
(unless (package-installed-p 'eglot-x)
(package-vc-install "https://github.com/nemethf/eglot-x"))
I wonder if my leaving package-install-upgrade-built-in
to its default value (nil
) has anything to do with it.
I do know that package-install
(without the "vc") will complain about unmet dependencies. The bleeding edge magit package requires updates to built-in packages, and it did refuse to install without those dependencies being met. I solved the problem by not running a bleeding edge magit.
This might be worth chasing down. I find it a little surprising that one way of installing a package apparently enforces version requirements for dependencies and another doesn't. Then again, the popular alternative package installer straight.el
never checks for versions of dependencies. Another, "elpaca" does, and I found that it was annoying because many packages aren't built with this use case in mind (e.g. they update version requirements in the source on "release" and have bogus version metadata in their git HEAD, or never update their source and rely only on git tags). So, there might be practical reasons for this behavior, too.
TLDR: I've
(setq eglot-x-enable-snippet-text-edit nil)
to work around this problem. The rest of this report is there as a record of how I arrived at this solution, and as a list of other ways to address this.In a Go source file, I get this error when I run
M-x eglot-format-buffer
:I'm using:
In that version of eglot there is an
eglot--range-region
function. Perhaps eglot-x should use that ifeglot-range-region
is missing?Alternatively, if, by policy, eglot-x isn't compatible with Emacs 29.3's default eglot version, perhaps catch this an issue an error about it? That could save time for others. For example, if eglot-x was on melpa (#1), the proper version dependencies could be expressed.
The situation with upgrading built-in packages is a bit of a pain (see https://www.gnu.org/software/emacs/manual/html_node/emacs/Package-Installation.html), but I have options for upgrading eglot to 1.17 (the current GNU Elpa version), if I must (but I'd rather not...if I want bleeding edge eglot I'd just assume run bleeding edge Emacs too)