Remote mode not working due to CR/LF conversion #2375
Comments
|
Can you test by setting |
|
Hi @yyoncho, thanks a lot for your quick response. Unfortunately changing this setting doesn't change anything. Is there anything else that I can try? |
|
I researched that in the past but I didn't remember what was the solution if any. What we can try is to isolate an example and go and ask the tramp maintainer because I am not really familiar with these internal details. Also, the issue is env specific. I would try also changing the following line in tramp connection |
|
Hi @yyoncho: I tried changing the process coding system as you suggested, but still no improvement. I made an additional weird observation: |
|
@yyoncho: I just looked at the code, where set-process-coding-system is called and there's one thing, I don't understand. If I understand the code correctly, then start-file-process-shell-command is invoked before setting the coding system, which seems wrong to me. Shouldn't all the process settings be done before invoking start-file-process-shell-command? |
IMHO it should be fine since we haven't started writing to that process and that conversion is only an emacs thing. |
I am experiencing the same problem with clangd over tramp as I previously mentioned on #1845 (comment). I cannot share logs unfortunately, however I can confirm that the error message is the same "Expected , or } after object property" in lsp-log and when I examine the stdin of the clangd process on remote, I find seemingly correct JSON missing the last I can also confirm that every once in a while LSP does start successfully and the |
|
I recently started using lsp-mode. It works properly on my Linux box. However, yesterday I tried it on my macbook and got the same error. Specifically, my Linux box and MacBook remotely connect to the same Linux server and MacBook instance has the issue. |
If I understand you correctly, you have 2 different clients - Mac and Linux connecting to a remote Linux box and only one of them connects successfully? This could be a great way to reproduce. Can you please share more details about your emacs configuration and version on both clients as well as the lsp server version on the remote machine? |
|
@petr-tik yes, Mac and Linux laptops connect to the same remote Linux server and Mac has the issue. Here are the configurations: Linux laptop (working): Arch Linux, GNU Emacs 27.1, lsp-mode 20201206.1844 Emacs configuration for lsp-mode When error happened, the error message on remote Linux server says: |
|
I asked the tramp maintainer in emacs-devel, hopefully, soon we will come up with a solution. |
https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00498.html To clarify, I was echoing the original issue report
Both machines are also linux in my case, so I am not sure if the mac-specific fix will be enough. Fingers crossed. |
|
Can someone who can reproduce the issue jump into the emacs-devel thread? Michael is asking for that. |
|
my problems aren't mac-related, but I also have issues with clangd over tramp and have reproduced it with pyls before |
|
That could work too I guess. Let's hope it is the same issue. |
|
If Michael provides instructions and patches, I would like to try on my Mac. Just cannot guarantee response in real-time ... |
|
@yyoncho: I have been in contact with Michael regarding this issue. He seems to have a patch for lsp-mode, which might fix this. I will try it out on my side and feed back here, if it works for me. See the thread on the emacs-devel mailing list for details. |
|
Judging from this message, Michael fixed the issue in the tramp code and also changed his implementation of (defun lsp-tramp-connection (local-command &optional generate-error-file-fn)
"Create LSP stdio connection named name.
LOCAL-COMMAND is either list of strings, string or function which
returns the command to execute."
;; Force a direct asynchronous process.
(add-to-list 'tramp-connection-properties
(list (regexp-quote (file-remote-p default-directory))
"direct-async-process" t))
(list :connect (lambda (filter sentinel name environment-fn)
(let* ((final-command (lsp-resolve-final-function
local-command))
(_stderr (or (when generate-error-file-fn
(funcall generate-error-file-fn name))
(format "/tmp/%s-%s-stderr" name
(cl-incf lsp--stderr-index))))
(process-name (generate-new-buffer-name name))
(process-environment
(lsp--compute-process-environment environment-fn))
(proc (make-process
:name process-name
:buffer (format "*%s*" process-name)
:command final-command
:connection-type 'pipe
:coding 'no-conversion
:noquery t
:filter filter
:sentinel sentinel
:file-handler t)))
(cons proc proc)))
:test? (lambda () (-> local-command lsp-resolve-final-function
lsp-server-present?))))Martin, can you please confirm if it works for you and does that mean that |
|
@petr-tik: I have built emacs from the master branch about 2 weeks ago, which includes the latest tramp changes. I also had to change the implementation of the connection setup in lsp-mode, so both your questions are a 'yes'. Unfortunately there is no released version of Emacs/Tramp yet, which contains the necessary changes. I don't know, if the new implementation of lsp-tramp-connection is usable without the other tramp changes. |
|
Can you please confirm the SHA of tramp that fixes lsp-mode over tramp? I wanted to add something to docs/remote.md with troubleshooting instructions. @yyoncho would you be open to changing the definition of |
|
Thanks for reporting the issue. Same problem here with: Client (fedora core 33): Server (fedora core 32): The funny things is that sometime it works, without doing any thing :-) How can we try the updated tramp version? |
Same. I still haven't found a way to hunt the intermittent failure down.
2 options:
$ git clone git://git.savannah.gnu.org/tramp.git tramp_master
$ cd tramp_master/
$ autoconfAdd this to your config, I guess after tramp is loaded normally to override it. (add-to-list 'load-path "tramp_master")
(require 'tramp)If you try (2) - please report if that works, in which case @yyoncho we could add this clarification to the remote tutorial |
|
Unfortunately no safe conclusion can be made. The but the problem still remains. (no change in the After commenting out the |
|
@petr-tik: As Michael has fixed another issue, which arose in conjunction with magit and his Tramp changes, I have just pulled the latest version of Emacs and rebuilt. I can confirm, that remote lsp works with commit :9b31802e2d13cf8478c23d651741b54ffd4b984b. |
|
The new tramp connection code above only works for built-in tramp transports due to it's use of the new direct async process method. For example it doesn't work with docker-tramp. |
|
What is the current situation? I get this error on emacs |
|
@R0flcopt3r with modified lsp-tramp-connection and tramp v.2.5.2 pre, everything works fine for macos |
|
@tshu-w the Using the |
My current
For this error, maybe you could tried |
|
It does seem like that specific The last remaining problem is how insanely slow it is in a 1.5 mil LOC C++ project... Takes literal minutes to find definitions.. It seems to only spawn 5 threads on the remote machine, while At least it seems to be nice and stable for smaller projects. Like my advent of code project, it's nice and snappy, about as running it locally. Thanks a lot for your time, @tshu-w. |
That can be optimized on lsp-mode side by not loading the line content. We don't have other option but to do that synchronously. Eventually, if xref does not support that we may create an alternative solution that resolves the line content lazily |
|
slight update on the performance issues. it doesn't seem like it uses the lsp functionality at all when searching for this specific symbol I was on. Below are first a report for the remote project, and next is from the same project but locally. vs this locally: |
Hi, I add direct asynchronous process back to |
adds a custom lsp-tramp-connection that actually works. from @tshu-w, emacs-lsp/lsp-mode#2375 (comment)
|
FWIW, with the |
|
From lsp communication log from server side, I found the messages were truncated to 4096 bytes. After searching this number, I got this. I fix the stty issue in the remote tramp by add '-icanon'. It works with this comment under my linux box and emacs 28.2 tramp 2.5.3 |
Thanks for this comment. Since this will be a serious change to Tramp, which could affect asynchronous proresses at all, I'd appreciate if somebody could write an Emacs bug report via 'M-x report-emacs-bug'. We'll discuss the issue there. Note, that I won't discuss on github. |
|
What is the current situation on this bug? I have reported it on #843 but this issue seems to have more recent updates and is open. I am getting these issues on emacs Is it safe to assume lsp-mode changes to |
I have set up clangd for lsp-mode, which works fine, when the clangd server is on the same machine as emacs. I have also attempted to use this remotely. In this case both involved machines are Linux, Emacs version is 27.1. The definition of the lsp client is as follows:
I have written a small wrapper script as found somewhere on the internet, which redirects stdout and stderr of clangd to separate files. When trying to start the remote server, emacs endlessly displays 'clangd-remote: status: starting'. The stderr output of clangd contains the following information:
The stdout contains the expected initial contact string, which is rather long, so I won't paste it here. The interesting part is, that this string does not contain the CR characters after the initial Content-Length field, which are required by the LSP protocol. When starting clangd locally, these CR charaters are there. So I suspect, that TRAMP somehow swallows the CR characters, which causes clangd to complain about a wrong content length. I haven't found the place, where TRAMP converts line-endings, but I suspect, that the interaction between lsp-mode and TRAMP is somehow the problem.
The text was updated successfully, but these errors were encountered: