Open 0x6d6e647a opened 1 year ago
I tried using lsp-start-plain
but it won't run with the following error:
emacs: Terminal type "dumb" is not powerful enough to run Emacs.
Workaround to avoid losing work to this bug.
(defun void (&rest args))
(setq lsp-signature-function #'void)
This might be more easily fixed in the utility package (https://github.com/abo-abo/hydra/blob/master/lv.el).
@dgutov Thanks for taking the time to look at this. I don't disagree that the problem might be related to the hydra package if not directly the cause of it. I'll have to do further debugging on the issue but I currently suspect the problem is related to when/how the lv-wnd
variable is set when lsp-mode
creates the message buffer.
I haven't had time to deep dive on this issue but wanted to submit the bug as soon as possible in order to make people aware due to the potentially catastrophic consequences and offer my work around. I plan on working on this more and will link to this bug if I end up filing a bug against Hydra related to this issue.
Thank you for the bug report
lsp-mode
related packages.M-x lsp-start-plain
Bug description
When editing code with
lsp-mode
enabled and anlsp-lv-message
window appears showing signature documentation, if the window focus is changed while theLV
window is still visible, then after returning to the original window the contents of the buffer inside that window might be replaced (and possibly saved) with the documentation contents and then the buffer will be killed.Steps to reproduce
lsp-mode
enabled. I'll be usingpython-mode
in this example. The second window is running another buffer with contents.lsp-lv-message
window to appear. Assuming my cursor is at the end ofdict(
in the following example.lsp-lv-message
display window is open typeM-x
callshelm-M-x
. From Helm I callace-jump-word-mode
. Fromace-jump-word-mode
I jump into the second buffer. At this point usually thelsp-lv-mesage
buffer is no longer visable but the window that it was in is still there.lsp-lv-message
to appear, then the buffer's contents might be overwritten with the signature documentation which may also include saving the file the buffer is visiting with the signature documentation overwriting the file's contents. After this the buffer will be killed, sometimes wihtout ayes-or-no-p
prompt.I have experienced this in multiple different scenarios depending on how I changed focus to a different buffer which lead to variety of different outcomes. Regardless if the buffer's content's being overwritten and/or saved, the buffer will be killed at the end.
Since this does not trigger an error, I made the following changes to
lv.el
to launch the debugger whenkill-buffer
is called on a buffer with a name unlike" *LV*"
.I also disabled all byte-code and native compilation at the beginning of my
init.el
in case that made a difference or yielded better back traces:Expected behavior
Not killing the buffer possibly overwriting the buffer contents and saving over the file.
Which Language Server did you use?
python-lsp-server
with the following plugins enabled:black
ruff
mypy
OS
Linux
Error callstack
Anything else?
lsp_workspace_log.txt
lsp_log.txt