Debugger entered--Lisp error: (void-function eglot-range-region)

[matta]

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:

Debugger entered--Lisp error: (void-function eglot-range-region)
  eglot-range-region((:start (:line 291 :character 0) :end (:line 291 :character 6)) markers)
  #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_43>((:range (:start (:line 291 :character 0) :end (:line 291 :character 6)) :newText ""))
  eglot-x--apply-text-edits([(:range (:start (:line 291 :character 0) :end (:line 291 :character 6)) :newText "")])
  eglot-x--override-text-edits(#<subr eglot--apply-text-edits> [(:range (:start (:line 291 :character 0) :end (:line 291 :character 6)) :newText "")])
  apply(eglot-x--override-text-edits #<subr eglot--apply-text-edits> [(:range (:start (:line 291 :character 0) :end (:line 291 :character 6)) :newText "")])
  eglot--apply-text-edits([(:range (:start (:line 291 :character 0) :end (:line 291 :character 6)) :newText "")])
  eglot-format(nil nil)
  eglot-format-buffer()
  funcall-interactively(eglot-format-buffer)
  command-execute(eglot-format-buffer record)
  execute-extended-command(nil "eglot-format-buffer" nil)
  funcall-interactively(execute-extended-command nil "eglot-format-buffer" nil)
  command-execute(execute-extended-command)

I'm using:

• Emacs 29.3
• eglot-x git HEAD
• eglot 1.12.29 (the version that comes with Emacs 29.3)

In that version of eglot there is an eglot--range-region function. Perhaps eglot-x should use that if eglot-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)

[nemethf]

eglot-x requires Eglot version 1.16. I guess package-vc-install makes sure the availability of the correct dependencies. Have you tried that?

[matta]

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.

[nemethf]

I see three options.

1. Build a compatibility layer in eglot-x to support the older Eglot of Emacs-29.
2. Make eglot-x accepted into ELPA.
3. Wait the release of Emacs-30.

I prefer the third option, but I also plan to work on option 2 (issue #1), while not adding anything new to eglot-x that Emacs-30 does not support. So, I think I close this as "won't fix".