Expose textDocument/selectionRange as an interactive command

[matklad]

LSP has this method:

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_selectionRange

Roughly, it returns a stack of nested AST nodes that contain point. The primary intended use-case for this API is syntax-aware selection: the user presses shortcut, and the selection is extended to the next bigger node. This allows the user to quickly select any desired syntactical construct.

In Emacs, a similar functionality is provided by expand-region package, https://github.com/magnars/expand-region.el, but that is based on approximating the syntax tree, and doesn't return correct results in all cases.

Somewhat related, Emacs recently gained support for tree sitter, which provides an alternative for textDocument/selectionRange, and there's even a PR to support that from expandRegion magnars/expand-region.el#279. treesit-based implementation is probably usually the better default way to implement this feature, but lsp-based impl would be nice for completeness.

With two different provides for this logical functionality, eglot and treesit, perhaps it makes sense to add a first-class interactive command for this to eglot, essentially bringing expand-region functionality into core?

[matklad]

Why this matters: subjectively, "semantic selection" is one of the biggest "bang-for-buck" semantic features in terms of usefulness, so my personal valuation for this is not "nice to have", but rather "essential feature".

[adonovan]

This snippet of code worked for me using gopls, the Go LSP server.

I stole the C-= keybinding from magnars/expand-region.el. It would be nice to define the corresponding C-- shrink-selection operation as demonstrated in VS Code in this video, but I suspect it's a little trickier.

(defun eglot-expand-selection ()
  "Expand the current selection to the enclosing unit of syntax,
 as furnished by an LSP textDocument/selectionRange request." 
  ;; TODO(adonovan): add corresponding unexpand.
  (interactive)
  (let* ((resp (eglot--request (eglot--current-server-or-lose)
			       :textDocument/selectionRange
			       `(:textDocument ,(eglot--TextDocumentIdentifier) :positions [,(eglot--pos-to-lsp-position)])))
	 (selection-range (elt resp 0)) ; LSP SelectionRange 
	 (current-range (cons (point) (if (use-region-p) (mark) (point))))
	 (new-range (eglot-range-region (plist-get selection-range :range))))
    ;; Walk down the linked list until we find an enclosing element.
    ;; We define enclosing as a proper superinterval.
    (while (let ((new-start (car new-range))
		 (new-end   (cdr new-range))
		 (cur-start (car current-range))
		 (cur-end   (cdr current-range)))	     
	     (not (and (<= new-start cur-start)
		       (>= new-end   cur-end)
		       (> (- new-end new-start) (- cur-end cur-start)))))
      (setq selection-range (plist-get selection-range :parent))
      (setq new-range (eglot-range-region (plist-get selection-range :range))))
    ;; Finally set the selection.
    (goto-char (car new-range))
    (set-mark (cdr new-range))
    (activate-mark)))

Perhaps this could be added to eglot.

[adonovan]

@joaotavora, any objections to adding this function as is?

[joaotavora]

Not sure. You could argue it falls within the policy of Eglot being a gateway to LSP-enhanced functionality and plugging in its own commands when there isn't a build in command that can be plugging into this. But the "policy" also states that its much better when an existing Emacs package responsible for some UI thing already exists, and in that case Eglot is just the UI-LSP glue.

If no such package exists, then Eglot may add its own commands, but usually when it is something quite valuable (think eglot-rename or M-x eglot-inlay-hints-mode).

The fundamental idea is that Eglot shouldn't really bring new/foreign UI paradigms into Emacs: I don't have time to maintain them and that's the job of other packages.

So you should propose this in the bug tracker and gather more comments, especially from the people concerned and experienced with the ergonomics of theses kinds of functions. Notice that we already have mark-sexp and many such commands, and it has arguments for extending/repeating. Whatever you create should more or less follow the same principle.