rustic
rustic copied to clipboard
brotzeit
`rustic-format-file` hangs on Windows
On Emacs-28.1 for Windows (emacs-version : Emacs 28.1 (build 2, x86_64-w64-mingw32) of 2022-04-21) when running M-x rustic -format-file the command does not terminate until C-c is pressed.
Some debugging learned that the process-status keeps in the 'run state. I could not repeat it when experimenting running rustfmt with the same arguments in the scratch buffer.
It smells like rustfmt detects the input file is opened and waiting for input, but it could be another reason why it decides to hang around till I press C-c. (and that does not explain why on Linux in WSL2 it works fine).
Yes, that works fine. I should have mentioned that. That's what I found puzzling prompting me to dig a bit deeper but I got stuck because ert-runner does not work properly either (on Windows), got sidetracked and then my time ran out.
I just tried it on my windows machine and it works for me. Did you try it in different projects ?
You could comment the code in rustic-format-file step by step and see what's actually causing the problem. I'm sorry but as I can't reproduce I don't know how to help.
Same issue on the same OS and version of Emacs.
To me it looks like rustfmt Emacs processes endlessly runs even though the rustfmt.exe command exits immediately. I believe this is because rustic-make-process is setting the process coding system to 'utf-8-emacs-unix which then causes mismatches for signals on non-unix systems.
Unless I'm missing something setting this to default-process-coding-system should more reliably ensure that the appropriate coding system gets used here across different environments. The change resolved the issue on my end.
Opened a PR with that change. #426
@ptillemans Can you try that on your end as well?
Hi, I'm experiencing this issue on Windows as well. The fix PR that was merged only adds to the problem, since when I try to call rustic-cargo-run (as well as potentially other rustic functions) with the current code (as of the PR), the command seems to run but I get an error saying that the wrong type argument was passed to the set-process-coding-system function. Following this error message, every attempt to call rustic-cargo-run fails.
I've tried fixing the issue and found that changing the DECODING argument to a symbol but leaving the ENCODING argument causes this error to disappear. However, this change causes the original problem, which is rustic-format-file hanging, to resurface. I'm curious what you guys had as the value of default-process-coding-system - my setup has this variable set to (utf-8-dos . utf-8-unix), which I think is due to some settings I have to prefer utf-8 encoding. Running an unconfigured instance with emacs -Q gives (undecided-dos . undecided-unix).
It was probably premature to introduce a 'fix' since I don't think we fully understand what's causing this problem and I was acting on a hunch. Sorry about that.
I had similar behavior and circumstances as what you are reporting: when using emacs 28.2 (on Windows 11 - 10.0.25201 Build 25201) from the main GNU FTP server with Rustic prior to the change in #426 I was experiencing the hang and the PR did fix the issue for me (I'm also able to run rustic-cargo-run without any issues). The value of default-process-coding-system for me on there has been (utf-8-dos . utf-8-unix) and still is although I experimented with others without much success.
However, I recently tried a fresh install of emacs on a fresh copy of the same OS and found I encountered the same behavior as yourself (wrong argument type error). After using (set-process-coding-system process (car default-process-coding-system) (cdr default-process-coding-system)) in place of the previous change in rustic-make-process the issue was resolved and I also no longer had the hanging behavior. In fact, using the pre #426 line of (set-process-coding-system process 'utf-8-emacs-unix 'utf-8-emacs-unix) also no longer results in hanging for me in this case.
It might be useful to gather more information across our environments to get a better idea of what we might be able to attribute the differences to. I'm attaching the output of M-x report-emacs-bug on my end (executing in the emacs session where I am no longer experiencing the hanging issue):
I've also opened up a PR to revert #426 since it's now known to cause issues: #457
I was using Emacs 28.1 and updated to Emacs 28.2, still same problem. Here is my bug report (using (set-process-coding-system process 'utf-8-emacs-unix 'utf-8-emacs-unix)).
rustic-bug-report.txt
Hi,
I am currently having the hanging issue. But, as a note, for me only happens when the lsp server is up and running. If the server is shutdown, I don't have the issue. The change mentioned above by @ns-mkusper of (set-process-coding-system ...) doesn't seem to make a difference.
With debug-on-entry it runs to completion.
