LSP port determination could be improved

[rah-gs]

Currently gdscript-eglot-contact looks for a config file with a hardcoded version (gdscript-eglot-version = 4 by default), and if it can't be found it returns nil and eglot won't connect. On my machine Godot 4.3 is installed so this fails by default, as the version is set to 4 but the config file is named with 4.3. I think this could be improved by

1. Searching the config dir for other files. It could look for the most recently modified file, as this would help things work automatically in the (unlikely) case that the user has multiple versions and config files lying around.
2. Setting a default port as a fallback (6005)

I could attempt to write a patch for this if you think it's the right approach

[okuriashi]

I just bumped into the same thing.

I did a small change in gdscript-eglot.el, so that one can set gdscript-eglot-version in a compatible way for 4.3 and older versions of the editor settings file. The naming logic changed from version 4.3 - https://github.com/godotengine/godot/pull/90875.

diff --git a/gdscript-eglot.el b/gdscript-eglot.el
index 1a1549e..9ba0ae3 100644
--- a/gdscript-eglot.el
+++ b/gdscript-eglot.el
@@ -38,9 +38,9 @@
   :group 'gdscript)

 ;;;###autoload
-(defcustom gdscript-eglot-version 4
+(defcustom gdscript-eglot-version "4"
   "The version of godot in use."
-  :type 'integer)
+  :type 'string)

 ;;;###autoload
 (defun gdscript-eglot-contact (_interactive)
@@ -60,7 +60,7 @@ https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01070.html."
            (cfg-buffer
             (find-file-noselect
              (expand-file-name
-              (format "godot/editor_settings-%d.tres"
+              (format "godot/editor_settings-%s.tres"
                       gdscript-eglot-version)
               cfg-dir)))
            (port

I then set gdscript-eglot-version to my Godot version in my config.el (I'm using doomemacs):

(after! gdscript-mode
  :config
  (setq gdscript-eglot-version "4.3"))

and Eglot is able to connect sucessfully.

[NathanLovato]

This comment suggested this issue should be resolved with #155, so I'm closing for now. Please let me know if that's not the case and we can always reopen the ticket.