GNU bug report logs - #17666
24.3.91; [regression] call-process in read-only buffers

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 17666 in the body.
You can then email your comments to 17666 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: "Roland Winkler" <winkler <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 02 Jun 2014 10:01:52 -0500

evaluate the following with emacs -Q

;; running a process with no output via call-process
;; in any read-only buffer will do
(with-temp-buffer
  (let ((buffer-read-only t))
    (call-process "true" nil t)))

No problem with emacs 24.3

24.3.91:  Buffer is read-only: #<killed buffer>



In GNU Emacs 24.3.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
 of 2014-05-12 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Ubuntu 12.04.4 LTS

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.ISO-8859-15
  locale-coding-system: iso-latin-9-unix

Major mode: Lisp Interaction

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 17666 <at> debbugs.gnu.org
Subject: Re: bug#17666: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 02 Jun 2014 12:18:08 -0400

> evaluate the following with emacs -Q

> ;; running a process with no output via call-process
> ;; in any read-only buffer will do
> (with-temp-buffer
>   (let ((buffer-read-only t))
>     (call-process "true" nil t)))

> No problem with emacs 24.3

I do not remember this being changed consciously, but the change does
sound like a bug fix: you should bind inhibit-read-only if you want to
insert text into a read-only buffer, and call-process shouldn't be
an exception.


        Stefan

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

From: "Roland Winkler" <winkler <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17666 <at> debbugs.gnu.org
Subject: Re: bug#17666: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 2 Jun 2014 11:25:14 -0500

On Mon Jun 2 2014 Stefan Monnier wrote:
> > evaluate the following with emacs -Q
> 
> > ;; running a process with no output via call-process
> > ;; in any read-only buffer will do
> > (with-temp-buffer
> >   (let ((buffer-read-only t))
> >     (call-process "true" nil t)))
> 
> > No problem with emacs 24.3
> 
> I do not remember this being changed consciously, but the change does
> sound like a bug fix: you should bind inhibit-read-only if you want to
> insert text into a read-only buffer, and call-process shouldn't be
> an exception.

But what is the problem if a process does not have any output?
(Certainly, throwing an error makes sense for processes which do
create output in a read-only buffer.)

Roland

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

From: Glenn Morris <rgm <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 17666 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17666: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 02 Jun 2014 13:37:14 -0400

"Roland Winkler" wrote:

>> > (with-temp-buffer
>> >   (let ((buffer-read-only t))
>> >     (call-process "true" nil t)))
[...]
> But what is the problem if a process does not have any output?

If you know it isn't going to produce any output, why don't you just
discard the output instead of sending it to a read-only buffer (which is
something that really doesn't make sense)?

(with-temp-buffer
   (let ((buffer-read-only t))
     (call-process "true" nil nil)))

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

From: Glenn Morris <rgm <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 17666 <at> debbugs.gnu.org
Subject: Re: bug#17666: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 02 Jun 2014 13:45:25 -0400

Anyway, it's the prepare_to_modify_buffer in call_process what does it.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 17666 <at> debbugs.gnu.org
Subject: Re: bug#17666: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 02 Jun 2014 13:57:21 -0400

>> > evaluate the following with emacs -Q
>> > ;; running a process with no output via call-process
>> > ;; in any read-only buffer will do
>> > (with-temp-buffer
>> >   (let ((buffer-read-only t))
>> >     (call-process "true" nil t)))
>> > No problem with emacs 24.3
>> I do not remember this being changed consciously, but the change does
>> sound like a bug fix: you should bind inhibit-read-only if you want to
>> insert text into a read-only buffer, and call-process shouldn't be
>> an exception.
> But what is the problem if a process does not have any output?

Ah.. eh.. hmm.. yeah.. that case!
Well, then better make sure your process does output something!


        Stefan "who skipped the "true" part, obviously.  Sorry"

Message #25 received at 17666-done <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17666-done <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17666: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 2 Jun 2014 13:14:15 -0500

On Mon Jun 2 2014 Glenn Morris wrote:
> If you know it isn't going to produce any output, why don't you
> just discard the output instead of sending it to a read-only
> buffer (which is something that really doesn't make sense)?

Certainly, there are various ways around this.

In my case, I cannot remember anymore in all detail why I wrote the
code the way I did.  I expect that I was really *expecting* to have
no output.  Also, in my case, the call of call-process is associated
with a buffer that is most often read-only. So using a read-only
buffer for the process output was probably my cheap solution to keep
track of "really no output".

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17666 <at> debbugs.gnu.org, winkler <at> gnu.org
Subject: Re: bug#17666: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 02 Jun 2014 21:34:55 +0300

> Date: Mon, 02 Jun 2014 13:45:25 -0400
> Cc: 17666 <at> debbugs.gnu.org
> 
> Anyway, it's the prepare_to_modify_buffer in call_process what does it.

Actually, I think the problem is that the code there calls
decode_coding_c_string even if we read zero bytes from the process.
With some coding-systems, this will insert something into the buffer,
so the call to prepare_to_modify_buffer is justified.

But I agree that the previous behavior was sweeping a subtle bug under
the carpet.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 17666 <at> debbugs.gnu.org
Subject: Re: bug#17666: 24.3.91; [regression] call-process in read-only buffers
Date: Mon, 02 Jun 2014 14:42:50 -0400

>> evaluate the following with emacs -Q
>> ;; running a process with no output via call-process
>> ;; in any read-only buffer will do
>> (with-temp-buffer
>> (let ((buffer-read-only t))
>> (call-process "true" nil t)))
>> No problem with emacs 24.3

This should be fixed in emacs-24 now, thank you,


        Stefan

Previous Next

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