GNU bug report logs - #20971
24.4; occur-1 makes my buffer read-only

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20971 in the body.
You can then email your comments to 20971 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex Schröder <kensanata <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4; occur-1 makes my buffer read-only
Date: Fri, 03 Jul 2015 09:21:55 +0000

[Message part 1 (text/plain, inline)]

I'm using isearch to search for something, then I use M-s o to run an occur
for my search term. This results in *Occur* being shown and in the buffer
I'm searching to be read-only. This is confusing. I think what people
intended was to make *Occur* read-only. But occur-mode already inherits
from special-mode which already does (setq buffer-read-only t).

I therefore propose to simply remove the (setq buffer-read-only t) line
from the end of occur-1 in replace.el. See attached patch.

[Message part 2 (text/html, inline)]

[fix_occur.patch (application/octet-stream, attachment)]

Message #8 received at 20971 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex Schröder <kensanata <at> gmail.com>
Cc: 20971 <at> debbugs.gnu.org
Subject: Re: bug#20971: 24.4; occur-1 makes my buffer read-only
Date: Fri, 03 Jul 2015 15:05:48 +0300

> From: Alex Schröder <kensanata <at> gmail.com>
> Date: Fri, 03 Jul 2015 09:21:55 +0000
> 
> I'm using isearch to search for something, then I use M-s o to run an occur for
> my search term. This results in *Occur* being shown and in the buffer I'm
> searching to be read-only.

I cannot reproduce this.  The buffer I was searching doesn't become
read-only.  Are you sure it's not one of your customizations?  Can you
see that in "emacs -Q"?

Message #11 received at 20971 <at> debbugs.gnu.org (full text, mbox):

From: Alex Schröder <kensanata <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20971 <at> debbugs.gnu.org
Subject: Re: bug#20971: 24.4; occur-1 makes my buffer read-only
Date: Fri, 03 Jul 2015 13:09:24 +0000

[Message part 1 (text/plain, inline)]

Indeed, the problem goes away with emacs -Q. I investigated further and
found that the culprit is display-buffer-function being set to
popwin:display-buffer. Thus, I can load my current config and evaluate
(setq display-buffer-function nil). The problem will disappear.

I still think that my patch is the right solution. The current code expects
display-buffer to behave in a certain way and Emacs gives us a ton of ways
to change that. Thus, we either need to explicitly set the current buffer,
or we can do away with trying to make *Occur* read-only. And really, who
needs that? Even if we don't set buffer-read-only, the buffer has no
self-insert-command bindings, and if you try to C-k the header, it will
still say "Text is read-only: #<buffer *Occur*>" because there is a
read-only text-property. And why shouldn't you delete matches?

Thus, as far as I can tell, my change makes the code more robust (no longer
depending on display-buffer to work in a particular way) and it has
practically no drawbacks.

[Message part 2 (text/html, inline)]

Message #14 received at 20971 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Alex Schröder <kensanata <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 20971 <at> debbugs.gnu.org
Subject: Re: bug#20971: 24.4; occur-1 makes my buffer read-only
Date: Mon, 30 Sep 2019 01:16:55 +0200

Alex Schröder <kensanata <at> gmail.com> writes:

> Indeed, the problem goes away with emacs -Q. I investigated further and found that the culprit is display-buffer-function
> being set to popwin:display-buffer. Thus, I can load my current config and evaluate (setq display-buffer-function nil). The
> problem will disappear.
>
> I still think that my patch is the right solution. The current code expects display-buffer to behave in a certain way and
> Emacs gives us a ton of ways to change that. Thus, we either need to explicitly set the current buffer, or we can do away
> with trying to make *Occur* read-only. And really, who needs that? Even if we don't set buffer-read-only, the buffer has no
> self-insert-command bindings, and if you try to C-k the header, it will still say "Text is read-only: #<buffer *Occur*>"
> because there is a read-only text-property. And why shouldn't you delete matches?
>
> Thus, as far as I can tell, my change makes the code more robust (no longer depending on display-buffer to work in a
> particular way) and it has practically no drawbacks.

I think *Occur* should definitely be read-only, so your first patch is
the wrong solution in my opinion.

On the other hand, I see no drawbacks with wrapping the relevant calls
in:

  (with-current-buffer occur-buf
       ...)

At the very least, that would make the intention of that code a bit more
clear.

But that entire part of the code is already wrapped in
(with-current-buffer occur-buf ...).  So why are we not in occur-buf
already?

Best regards,
Stefan Kangas

Message #19 received at 20971 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 20971 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Alex Schröder <kensanata <at> gmail.com>
Subject: Re: bug#20971: 24.4; occur-1 makes my buffer read-only
Date: Fri, 25 Sep 2020 16:04:37 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> I think *Occur* should definitely be read-only, so your first patch is
> the wrong solution in my opinion.
>
> On the other hand, I see no drawbacks with wrapping the relevant calls
> in:
>
>   (with-current-buffer occur-buf
>        ...)
>
> At the very least, that would make the intention of that code a bit more
> clear.
>
> But that entire part of the code is already wrapped in
> (with-current-buffer occur-buf ...).  So why are we not in occur-buf
> already?

I am guessing the reporter had some misbehaving code running off of
`display-buffer' that changed the current buffer:

            (display-buffer occur-buf)
            (when occur--final-pos
              (set-window-point
               (get-buffer-window occur-buf 'all-frames)
               occur--final-pos))
            (setq next-error-last-buffer occur-buf)
            (setq buffer-read-only t)
            (set-buffer-modified-p nil)
            (run-hooks 'occur-hook)))))))

So everything after displaying the buffer runs somewhere else.  We could
defensively re-wrap the rest in a with-current-buffer, but...  I think
the bug is in the code that changed the current buffer, really.

So I'm closing this bug report.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.