Some commands, like `dd`, cause emacs to enter in a stuck state

[meditans]

Description :octocat:

I cannot use several complex keybindings, both expicitly related to vim-mode editing and not: eg, I cannot use dd to delete a line, or C to change the line after the point, or even C-<backspace> to backward delete a word.

Reproduction guide :beetle:

• Start Emacs
• Open a file, and write some lines
• Try to delete a line with dd

Observed behaviour: :eyes: :broken_heart: Emacs enters in a stuck state, in which movement functions don't work. I can however leave that stuck state with C-g. Interestingly, in that stuck state the cursor is a filled block half of the height it normally is.

Expected behaviour: :heart: :smile: The commands should work :P

System Info :computer:

• OS: gnu/linux
• Emacs: 25.1.1
• Spacemacs: 0.105.21
• Spacemacs branch: nil (rev. cce0213)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(emacs-lisp git github version-control latex markdown erc gnus dash extra-langs spotify elm agda racket rust purescript yaml themes-megapack syntax-checking
            (spell-checking :variables spell-checking-enable-auto-dictionary t)
            (org :variables org-enable-github-support t)
            (evil-snipe :variables evil-snipe-enable-alternate-f-and-t-behaviors t evil-snipe-scope 'visible)
            (shell :variables shell-default-shell 'eshell shell-enable-smart-eshell t)
            (haskell :variables haskell-completion-backend 'intero)
            (auto-completion :variables auto-completion-enable-help-tooltip t auto-completion-enable-sort-by-usage t auto-completion-complete-with-key-sequence "jk" auto-completion-enable-snippets-in-popup t)
            (mu4e :variables mu4e-installation-path "/home/carlo/engine/mu-0.9.16/mu4e/"))

[TheBB]

Can you repro with 24.5?

[meditans]

I should add that I'm not always able to reproduce this. As I encounter the bug again will add more precise instructions.

[bmag]

the cursor is a filled block half of the height it normally is

When typing dd to delete a line, that's how the looks after the first d and before the second d is typed. This indicates the stuck state happens between the two presses.

not always able to reproduce this

This hints that either: 1) a timer is executed randomly and it just happens to be during dd, or 2) dd sometimes triggers loading of a lazy-loaded component ("sometimes" depends on whether the component was already loaded earlier or not).

Does the bug happens only once per Emacs session, or does it happens several times in the same session?

For how long is Emacs stuck? ~2 seconds or ~30 seconds or more than a minute?

[oneyb]

Same here (except emacs 24.5; spacemacs v0.105.22; and the layers). Same (albeit general) instructions. Difficult to reproduce. Do you have xclip-mode on and xclip installed? I have a feeling that this has something to do with the emacs hanging when inserting yanked text into the system's clipboard. I've encountered this elsewhere and the solution was:

(setq x-select-enable-clipboard nil)

Which sucks!

[meditans]

Hi @oneyb! No, I have neither the xclip program nor the xclip-mode package installed. Fortunately

(setq x-select-enable-clipboard nil)

works for me as a (temporary) workaround!

@bmag emacs was stuck indefinitely, so I had to restart it every time. Again, the main factor which seems to correlate with this bug for me is suspending my laptop: after wake up, the bug has more possibilities to appear than after a clean boot.

[cserb]

Same here (0.300.0@26.2) and (setq x-select-enable-clipboard nil) helps

[JLTastet]

This does not seem to be a Spacemacs-specific issue, since other programs like pass cannot write to the clipboard either when this bug occurs. I suspect this is due to Gnome (maybe only the Wayland version). For me, a temporary workaround (to "unfreeze" the clipboard) consists in copying some text to it using Ctrl-C outside of emacs. Then the clipboard can be written to again, and both emacs and pass continue working normally. @cserb Which desktop are you using? Can you test if this workaround works for you?

[cserb]

@JLTastet I can confirm the workaround works for me (using Gnome with Wayland)

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

[archduck]

This is happening for me, exactly as described above (dd shows a half cursor, CPU usage spikes, C-g is able to cancel it).

I'm convinced it's something to do with the clipboard, because typing " _ d works fine (i.e. using the black hole register).

I do have xclip installed. which xclip shows xclip: aliased to xclip -r -selection c (in case the aliasing has any relevance here). I use xclip all the time in the terminal with no issues.

And now, oddly enough, after confirming that deleting to the black hole register works fine, regular dd is working again. But looking in the kill ring, I only see entries from after the black holing, as if the whole thing got cleared.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!