Switching back to Emacs causes the warning "recentf mode: Non-character input-event".

[3rd3]

Description

When reactivating Emacs I often get the following warning: recentf mode: Non-character input-event. I couldn't find a way to reliably reproduce the warning.

System Info

• OS: darwin
• Emacs: 25.1.50.1
• Spacemacs: 0.105.14
• Spacemacs branch: master (rev. a298a5a)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

((ibuffer :variables ibuffer-group-buffers-by nil)
 (ranger :variables ranger-ignored-extensions
         '("mkv" "iso" "mp4" "avi" "mp4" "mkv" "zip" "rar" "exe" "ps" "webm" "png" "jpg" "jpeg" "tif" "tiff" "ics" "dmg" "swf" "gz" "m4a")
         ranger-max-preview-size 4 ranger-cleanup-eagerly t)
 (latex :variables latex-enable-auto-fill t)
 org git github version-control finance extra-langs markdown emacs-lisp haskell html javascript ipython-notebook shell-scripts java
 (haskell :variables haskell-enable-ghc-mod-support nil haskell-enable-ghci-ng-support t haskell-enable-hindent-style "gibiansky" haskell-enable-shm-support nil)
 (c-c   :variables c-c  -enable-clang-support t)
 gtags
 (python :variables python-test-runner 'pytest)
 (clojure :variables clojure-enable-fancify-symbols t)
 (shell :variables shell-default-height 20 shell-default-position 'bottom shell-enable-smart-eshell t shell-default-shell 'eshell)
 evil-commentary)

[3rd3]

This appears to be related to the recentf lockfile bug #5186. The mini-buffer asks what to do about the lock. When one overlooks the warning, the buffer gets confused by other input events (possibly command, tab keys or the mouse?). Disabling lockfiles using (setq create-lockfiles nil) does the trick for now.

[andreimc]

I get it as well

[3rd3]

There might be ways to handle input in these kinds of cases without getting an error: http://emacs.stackexchange.com/questions/12468/making-read-char-input-robust

But this is appears to be just a minor bug (unless it also occurs in different situations). #5186 is more important.

[fsegouin]

Same issue here :(

[socketwiz]

It's just started happening for me 2 days ago as well :(

[Kukunin]

👍 affects me as well

[fabrik42]

Me too, since 2 days. :I

[paultopia]

Me too, as of yesterday...

[3rd3]

Interestingly this bug has never occurred to me in a long time now. However, I don't know what I changed since then. Perhaps try updating both Emacs (to 25.2.1) and Spacemacs (to 0.200.9) and also recompile all packages (try calling spacemacs/recompile-elpa, or alternatively delete all .elc files from elpa subdirectories).

[Reapor-Yurnero]

Any stable solution now？ I meet this problem every time I open emacs after sleep the computer.

[paultopia]

it just started happening again to me out of nowhere today.

[fladd]

I have the same issue since a week. Any solution for it?

[dangom]

Adding the following to your init is not a solution, but works around the issue. Shouldn't have any unintended consequences unless editing the same file simultaneously in multiple editors - i guess.

  (defun ask-user-about-lock (file other-user)
  "A value of t says to grab the lock on the file."
   t)

[mijoharas]

I'm getting this issue now on latest develop. Is anyone else still suffering from it.

[dsedivec]

I have gotten this error recently, within the past week at least. I usually get the error in this ticket's title after Emacs asks me if I want to steal the lock file, particularly if I don't notice the prompt and just (I think) C-g over it (because I have no idea what's going on and I just want to edit my file).

On my Mac I suspect this is caused by the host name changing due to DHCP and VPN (Tunnelblick, OpenVPN). When I first come out of sleep my host name is probably something like foo.local, then after macOS gets DHCP going it becomes foo.myhomedomain.com, then my VPN kicks in a few seconds later and changes the host name to foo.mycompany.com. When I come out of sleep I am betting Emacs creates a lock file with, say, foo.local in the file name, then it goes to touch the lock file again a little later, but now the host name has changed so it doesn't think it owns the lock file with foo.local in it anymore.

I came to this hypothesis after noticing it only happens when I come out of sleep, and that the host name in the file it's asking about doesn't match the output of "hostname".

[kimonoki]

Also getting this on the latest develop with GUI after I tried to run emacs from terminal a few times.

[iamriel]

I am experiencing this also and it is similar with @dsedivec 's case , when I come out of sleep but in my case sleep also includes when I don't do anything with emacs for a period of time.

[emmanuj]

I'm experiencing this in master. Happens when my macs comes out of sleep. I have split windows but it only happens in one buffer at a time.

[denisse-dev]

I'm having this problem in development branch.

[neo-anderson]

Adding the following to your init is not a solution, but works around the issue. Shouldn't have any unintended consequences unless editing the same file simultaneously in multiple editors - i guess.

  (defun ask-user-about-lock (file other-user)
  "A value of t says to grab the lock on the file."
   t)

I faced this issue too with a single user, single emacs instance (dev branch). @dangom 's code "fixed" it for me.

[lschuetze]

I have the problem in version [email protected] (spacemacs). My Macbook Pro is docked into a docking station that is connected via LAN. The WLAN is a different network. When changing between both networks my host name changes also.

Whenever my laptop wakes up from sleeping and I have an open spacemacs the recentf warning will appear.

[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!

[pprevos]

I am getting the same issue on Emacs 27.1. I added @dangom 's workaround.

[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!