emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LSP vs Emacs indentation [Was: bug#64784: 30.0.50; Eglot: Lisp error


From: Theodor Thornhill
Subject: Re: LSP vs Emacs indentation [Was: bug#64784: 30.0.50; Eglot: Lisp error: (wrong-type-argument number-or-marker-p return) in eglot--post-self-insert-hook]
Date: Mon, 24 Jul 2023 20:13:04 +0200

Tassilo Horn <tsdh@gnu.org> writes:

> João Távora <joaotavora@gmail.com> writes:
>
> Hi João,
>
>> If your aim is to make the LSP side "win",
>
> Yes, please!
>
>> I don't think you should use the "trigger character" technique
>> specifically.  But in Emacs you can of course bind keys to commands
>> that invoke 'eglot-format' synchronously.
>>
>> Even better, I think the most correct way is to buffer-locally set
>> 'indent-line-function' and 'indent-region-function', so you can keep
>> the familiar feeling of TAB.
>
> I've now tried this:
>
>   (defun th/eglot-indent-line ()
>     (eglot-format (line-beginning-position) (line-end-position)))
>   
>   (defun th/eglot-format-setup ()
>     (setq-local indent-region-function #'eglot-format)
>     (setq-local indent-line-function #'th/eglot-indent-line))
>   
>   (add-hook 'eglot-managed-mode-hook #'th/eglot-format-setup)
>
> Basically, it works, but it seems rust-analyzer doesn't support
> formatting of only a range.
>
>   eglot--error: [eglot] Unsupported or ignored LSP capability 
> `:documentRangeFormattingProvider'
>
> No big deal, so now I tried just using eglot-format also an
> indent-line-function.  But indeed, then I cannot insert newlines
> anymore. :-)
>
> I'll try experimenting a bit more at some time.
>

One issue with this is that most/many formatters remove whitespace, and
for indentation _inserting_ whitespace is paramount.

Consider (| is the cursor)

```
func foo() {|}
```

Now if you type RET we'd expect some incantation of

```
func foo() {
  | 
}
```

to be the expected output, not the cursor at col 0, which is what
happens now. That means we'd have to do something like

```
(defun eglot-indent-line ()
  (eglot-format (line-beginning-position) (line-end-position))
  (eglot-newline-and-indent-according-to-mode))
```

Where the 'eglot-newline-and-indent-according-to-mode' has to calculate
the expected indentation. I don't understand how we'd expect the
formatters to do that indentation for us. They only care about code
already written, not code yet to be written. So if we'd have to
calculate that offset anyway, do we win much?

How about a hybrid approach, where eglot can take care of the formatting
part, but the "move cursor to indentation of parent + N spaces" is
handled by the respective major modes? This would make this contrived
example work:


```
func foo() {
   foo()|
      foo()
 foo()      
}
```
Now type RET, and output of the file would be:
```
func foo() {
  foo()
  |
  foo()
  foo()      
}
```

or

```
func foo() {
  if err != nil {|}
}
```
Now type RET, and output of the file would be:
```
func foo() {
  if err != nil {
    |
  }
}
```

The placement of the wrongly indented function calls are formatted by
eglot, and the indentation of the blank line is handled by emacs.

This diff will show a very naive example implementation of this.

Thanks,
Theo

@@ -1816,9 +1816,16 @@ 'eglot--ensure-list

 ;;; Minor modes
 ;;;
+
+(defun eglot-electric-newline ()
+  (interactive)
+  (eglot-format)
+  (newline-and-indent))
+
 (defvar eglot-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map [remap display-local-help] #'eldoc-doc-buffer)
+    (define-key map [remap newline] #'eglot-electric-newline)
     map))
 
 (defvar-local eglot--current-flymake-report-fn nil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]