This is a very strange issue and its cause is hard to determine. I often leave Emacs open for days, or even weeks at a time. My current emacs-uptime is 9 and a half days. That's pretty normal and sometimes it can be twice as long or longer.

However, sometimes when I run Emacs for this long and I happen to push Emacs particularly hard (running lots of processes, opening big files, using strange settings, etc.) something weird happens after some days. Emacs randomly blinks all of a sudden, like it's doing redisplay or something. This lasts for about a second or less. Thereafter, read-only text is not read-only anymore. I mean that any read-only text anywhere in Emacs is no longer read-only. REPL prompts, info buffers, help buffers, eshell prompts, buffers set to view-mode, any buffer in read-only-mode, anything else you can think of.

Basically, all read-only text becomes writable. At all, anywhere. I can accidentally clobber documentation by pressing a key that would normally do nothing or I can accidentally delete a REPL prompt which can screw up all kinds of things when developing. The only way around this issue (that I know of) is to restart Emacs. This is not always a viable solution. As you can see, this is a very annoying and often serious problem. But I cannot find anyone else online who has had this same issue.

So how can I determine what is causing this issue? And more importantly, how can I fix it?

Here is my emacs-version:

GNU Emacs 26.1 (build 5, x86_64-apple-darwin17.6.0, Carbon Version 158 AppKit 1561.4)
 of 2018-07-17

I.e., I'm on the Emacs Mac Port (by Yamamoto Mitsuharu) version 26.1. Also, my OS is macOS 10.13.6. I am happy to give more information about my setup as it becomes necessary.

  • You might get some help here (hope so), but you might also get some help with M-x report-emacs-bug. In either case, you probably will need to provide more info, preferably a recipe to repro the problem (which I realize would likely be hard to come up with).
    – Drew
    Commented Oct 1, 2018 at 14:25
  • Is this true for buffers where buffer-read-only is t and inhibit-read-only is nil? Is it true for text that has non-nil property read-only?
    – Drew
    Commented Oct 1, 2018 at 14:28
  • @Drew As I was testing those conditions, I realized that inhibit-read-only was set to t. After I reset this variable to nil using (setq inhibit-read-only nil), the problem seems to have gone away completely. I was not aware of this variable so I did not check it. If you make this an answer, I'll gladly accept it. Thank you!
    – GDP2
    Commented Oct 2, 2018 at 2:00
  • Done...........
    – Drew
    Commented Oct 2, 2018 at 3:14
  • To my knowledge, inhibit-read-only is intended to be dynamically-bound in order to temporarily allow modification of read-only text (where appropriate). In order for it to end up set 'permanently', I would speculate that some badly-behaved code is neither setting it in a temporary scope nor using condition-case to ensure it gets restored, and it got left that way after an error occurred? Someone might be able to suggest a valid reason for it, but it certainly sounds like a bug to me.
    – phils
    Commented Oct 2, 2018 at 9:47

1 Answer 1


Is this true for buffers where buffer-read-only is t and inhibit-read-only is nil? Is it true for text that has non-nil property read-only?

Check each of those situations, and if you still see a problem then consider filing a bug: M-x report-emacs-bug.

  • Thank you! As I wrote in my comment above, inhibit-read-only was bound globally and was thus causing the problem. After I reset the variable to nil, the problem was fixed. This is probably a bug, but now I at least know what the bug is and how to squash it ;)
    – GDP2
    Commented Oct 2, 2018 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.