bug#26947: Preserve read-only when debugger with let-bound inhibit-read-only t.

bug#26947: Preserve read-only when debugger with let-bound inhibit-read-only t.

[Keith David Bershatsky]

Entering the debugger when inhibit-read-only is let-bound to `t` causes all buffers to be read/write even though they may have `buffer-read-only` set to `t`.

Step #1:  Launch with emacs -q.

Step #2:  Navigate to the `*scratch*` buffer and set to read-only with C-x C-q.

Step #3:  Evaluate:  (let ((inhibit-read-only t)) (error "stop"))

Step #4:  Select the window display the `*scratch*` buffer and type something.  All open buffers are read/write.

Expected Behavior:  Protect buffers that have previously been set to `buffer-read-only` with `t`.

Workaround:  Add the following to the outset of the function `debug`:

(when inhibit-read-only
  (setq inhibit-read-only nil))

The workaround can be perfected to test for whether inhibit-read-only is let-bound to `t` and if it is then ...  I say that just in case someone wants `inhibit-read-only` to always be `t` and in that case the debugger shouldn't turn it off.

Here is the new thread on emacs.stackexchange.com:

https://emacs.stackexchange.com/questions/32829/inhibit-read-only-affects-all-buffers-when-backtrace-buffer-is-open

Thanks,

Keith

bug#26947: Preserve read-only when debugger with let-bound inhibit-read-only t.

[Stefan Monnier]

> Entering the debugger when inhibit-read-only is let-bound to `t` causes all
> buffers to be read/write even though they may have `buffer-read-only` set to
> `t`.
[...]
> (when inhibit-read-only
>   (setq inhibit-read-only nil))

Actually, the better option is probably to

    (let ((inhibit-read-only nil))

around debug, like we already do with various other variables.

Of course, this is a general problem with dynamic scoping.

Maybe a better solution would be for `debug` to use another thread, so
it's not affected by those dynamic bindings of the debugged code.


        Stefan

bug#26947: Preserve read-only when debugger with let-bound inhibit-read-only t.

[Keith David Bershatsky]

Yes, let-binding is indeed better than using `setq`.  Thank you.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [05-17-2017 06:34:15] <17 May 2017 09:34:15 -0400>
FROM:  Stefan Monnier <monnier@iro.umontreal.ca>
> 
> ***
> 
> Actually, the better option is probably to
> 
>     (let ((inhibit-read-only nil))
> 
> around debug, like we already do with various other variables.
> 
> ***

bug#26947: Preserve read-only when debugger with let-bound inhibit-read-only t.

[Lars Ingebrigtsen]

Keith David Bershatsky <esq@lawlist.com> writes:

> Entering the debugger when inhibit-read-only is let-bound to `t`
> causes all buffers to be read/write even though they may have
> `buffer-read-only` set to `t`.
>
> Step #1:  Launch with emacs -q.
>
> Step #2:  Navigate to the `*scratch*` buffer and set to read-only with C-x C-q.
>
> Step #3:  Evaluate:  (let ((inhibit-read-only t)) (error "stop"))
>
> Step #4: Select the window display the `*scratch*` buffer and type
> something.  All open buffers are read/write.

Full test case:

(progn
  (setq debug-on-error t
	buffer-read-only t)
  (let ((inhibit-read-only t)) (error "stop")))

This should now be fixed in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no