Can't make clangd work with tramp [not enough info yet]

[Ergus]

[ ] Server used: clangd
[ ] Emacs version: 28.1
[ ] Eglot version: 20210410.1942
[ ] Eglot installation method: package.el
[ ] Using Doom: NO

LSP transcript (mandatory, unless Emacs inoperable)

[stderr] I[14:51:10.483] clangd version 10.0.1 
[stderr] I[14:51:10.484] PID: 264338
[stderr] I[14:51:10.485] Working directory: /gpfs/projects/bsc28/bsc28860/tools/nanos6_cluster
[stderr] I[14:51:10.485] argv[0]: clangd
[stderr] I[14:51:10.485] Starting LSP over stdin/stdout

Backtrace (mandatory, unless no error message seen or heard):

... Paste the backtrace if you have it here ...
 signal(wrong-type-argument ("inserted-chars 232"))
  tramp-signal-hook-function(wrong-type-argument ("inserted-chars 232"))
  signal(wrong-type-argument ("inserted-chars 232"))
  tramp-handle-insert-file-contents("/scp:mn3:/tmp/tramp.qBnoB9" nil nil nil nil)
  apply(tramp-handle-insert-file-contents ("/scp:mn3:/tmp/tramp.qBnoB9" nil nil nil nil))
  tramp-sh-file-name-handler(insert-file-contents "/scp:mn3:/tmp/tramp.qBnoB9" nil nil nil nil)
  apply(tramp-sh-file-name-handler insert-file-contents ("/scp:mn3:/tmp/tramp.qBnoB9" nil nil nil nil))
  tramp-file-name-handler(insert-file-contents "/scp:mn3:/tmp/tramp.qBnoB9" nil nil nil nil)
  insert-file-contents("/scp:mn3:/tmp/tramp.qBnoB9" nil nil nil nil)
  insert-file-contents-literally("/scp:mn3:/tmp/tramp.qBnoB9")
  tramp-sh-handle-make-process(:name "EGLOT (nanos6_cluster/c++-mode)" :command ("sh" "-c" "stty raw > /dev/null; clangd") :connection-type pipe :coding utf-8-emacs-unix :noquery t :stderr #<buffer *EGLOT (nanos6_cluster/c++-mode) stderr*> :file-handler t)
  apply(tramp-sh-handle-make-process (:name "EGLOT (nanos6_cluster/c++-mode)" :command ("sh" "-c" "stty raw > /dev/null; clangd") :connection-type pipe :coding utf-8-emacs-unix :noquery t :stderr #<buffer *EGLOT (nanos6_cluster/c++-mode) stderr*> :file-handler t))
  tramp-sh-file-name-handler(make-process :name "EGLOT (nanos6_cluster/c++-mode)" :command ("sh" "-c" "stty raw > /dev/null; clangd") :connection-type pipe :coding utf-8-emacs-unix :noquery t :stderr #<buffer *EGLOT (nanos6_cluster/c++-mode) stderr*> :file-handler t)
  apply(tramp-sh-file-name-handler make-process (:name "EGLOT (nanos6_cluster/c++-mode)" :command ("sh" "-c" "stty raw > /dev/null; clangd") :connection-type pipe :coding utf-8-emacs-unix :noquery t :stderr #<buffer *EGLOT (nanos6_cluster/c++-mode) stderr*> :file-handler t))
  tramp-file-name-handler(make-process :name "EGLOT (nanos6_cluster/c++-mode)" :command ("sh" "-c" "stty raw > /dev/null; clangd") :connection-type pipe :coding utf-8-emacs-unix :noquery t :stderr #<buffer *EGLOT (nanos6_cluster/c++-mode) stderr*> :file-handler t)
  make-process(:name "EGLOT (nanos6_cluster/c++-mode)" :command ("sh" "-c" "stty raw > /dev/null; clangd") :connection-type pipe :coding utf-8-emacs-unix :noquery t :stderr #<buffer *EGLOT (nanos6_cluster/c++-mode) stderr*> :file-handler t)

(...)

Minimal configuration (mandatory)

Just installed eglot and called it (`M-x eglot`). When asked for a server name I manually inserted `clangd`

(use-package eglot :defer t)

[joaotavora]

Just installed eglot and called it (M-x eglot). When asked for a server name I manually inserted clangd

Much better, this tells me that the template still needs work. Or perhaps you didn't read it thoroughly?

Think with me: If I put that line like that in my Emacs right now do you think that I will be able to see the supposed bug as it happened to you? For one, I don't even have use-package. Really read the advice there.

#### Minimal configuration (mandatory)
<!-- Are you using Doom Emacs or Spacemacs Emacs or some very special
     pimped-out Emacs?  That's fine, but for this report we need you
     to replicate the problem with **as clean an Emacs run as
     possible**.
     
     Some people submit whole Git repositories with a sandboxed
     configuration.  That's fine, but sometimes simply Git-cloning the
     Eglot repo somewhere to your hard drive and a running this from
     the shell is more than enough: -->
     

 /path/to/a/certain/version/of/emacs -Q -f package-initialize -L /path/to/git-cloned/eglot -l eglot.el

 
 <!-- You can then add some lines of setup like: -->
 

 (add-to-list 'eglot-server-programs '(foo-mode "foo-server"))
 (setq eglot-special-option-2000 '(foo bar with the airplane)) 
 (some-clearly-identified-third-party-package)
 ;; Add some clear descriptions of M-x commands executed  executed
 ;; If your bug relies of the contents of files such as 
 ;; .dir-locals.el or some project file with some specific content
 ;; also do include their contents in separate code blocks.

 
 <!-- For some bugs it this may seem like overkill but believe us,
      very often what seems like a "clear issue" is actually specific
      to some details of your setup. Having a runnable reproduction
      not only "proves" your bug to us but also allows us to spend all
      our effort fixing the bug instead of struggling to understand
      your issue.  (this well-worded paragraph taken from Rollup's bug
      tracker, BTW)-->

Tell me what's unclear.

[Ergus]

Joao;

I just open a remote file in a project and made M-x eglot according to the documentation:

Should just work. Try `M-x eglot` in a buffer visiting a remote file on a server where you've also installed the language server. Only supported on Emacs 27.1.

So basically just installed eglot and did that. As there is not ccls in the remote server eglot asked for a server name and I inserted clangd (that is installed and working).

As simple as that.

[joaotavora]

You're not following. That works for some people but not you. For example, the automatic tests use TRAMP and those tests are passing as far as I know. Why is this discrepancy? We dont' know!

How can we know? Well, you can turn off your computer, put it in a cardboard box, pack it nicely, also send the network, your passwords and everything, and send it over the mail to my address, along with instructions on how to put everything together. Then I can see the problem happening in front of me, debug it, and shout AHA I'VE FOUND THE BUG.

Do you prefer that? Should I send my address?

If we don't have that, all you have are our powers of intelligence to figure out a way so that I can reproduce the problem as it happened to you. Do you think there's enough information in your bug report to help me do that? I think not.

Sometimes users like you get lucky. Maybe I or someone else have lots of time available and try to guess what happened to you. But I don't have time now, and I think that users of a package can do something since they have the computer where the bug happens in front of them.

Every OSS software package I know operates on a system like this. I took this example from RollupJS, for example. Even Emacs has such a system, just read the M-x report-emacs-bug template. Whenever I have a complex bug with SLY and a Lisp server for example, I have to provide a clear reproduction recipe to Eli Zaretskii, Emacs's maintainer.

So please try to understand my position. I suppose you're a programmer, right? If you were me, what would you do?

[joaotavora]

But don't take it from me. Read this: https://stackoverflow.com/help/minimal-reproducible-example

[Ergus]

Looking at the backtrace it seems that the problem comes from the tramp-handle-insert-file-contents and the condition-case there. The error wrong-type-argument... comes only from fileio.c:4720 function insert-file-contents called in tramp-sh-handle-make-process:

* insert-file-contents("/scp:mn3:/tmp/tramp.7MTvPb" nil nil nil nil)
  insert-file-contents-literally("/scp:mn3:/tmp/tramp.7MTvPb")
  tramp-sh-handle-make-process(:name "EGLOT (nanos6_cluster/c++-mode)" :command ("sh" "-c" "stty raw > /dev/null; clangd") :connection-type pipe :coding utf-8-emacs-unix :noquery t :stderr #<buffer *EGLOT (nanos6_cluster/c++-mode) stderr*> :file-handler t)

but after-insert-file-set-coding returns inserted and in this case RANGED_FIXNUMP (0, insval, ZV - PT) should be returning false so probably insval is out of range. Maybe the point is at the end of the buffer (I suppose a temporal one)?.

Sorry, but I can't be more specific. For me all are minimal-reproducible-example because eglot with tramp has never worked and my setup is very minimal, no configs, no weird customs in the remote system, no hooks, anything as I said before.

[joaotavora]

The question is not you telling me your config is minimal. I need recipe that is minimal, complete, and reproducible. Just as the stack overflow article explains.

Look, I'm not saying no-one is ever going to look at this. Maybe you'll get lucky, maybe they will. I'm not saying there is not bug, I'm even saying that likely it is a bug. But it's hard to work from this, and I'm not being paid to work on this (if you happen to be rich and want to sponsor a full investigation on this let me know, I might change my mind :-) ).

Maybe the point is at the end of the buffer (I suppose a temporal one)?.

Who knows? All those files are in your computer!

As I explained, I'm going to close this one. It doesn't have the requisites to be an issue in the new way I'm trying to organize this bug tracker. You're welcome to open a discussion in https://github.com/joaotavora/eglot/discussions or keep discussing even with the close state (i.e. I'm not locking the issue).

[jimporter]

This is actually the same thing I see in #662 (same error and everything). @Ergus, what platforms are you testing this on (i.e. the client running Emacs and server running clangd)? I noticed this on a Windows 10 client SSHing to a Linux server, but it's possible this happens on all platforms. I've been working on narrowing this down to something easy to reproduce, since I think it's a bug in Emacs.

I mentioned it briefly in the other issue, but the issue seems to be some sort of race condition when copying the stderr output to the "events" buffer. If I remove the relevant code from jsonrpc.el, everything appears to work fine. I'll add some more info over on #662 to keep all my investigations in one spot...

[joaotavora]

Thanks @jimporter, let's continue in #662, where I see you have a nice and short recipe.