bug#17666: 24.3.91; [regression] call-process in read-only buffers

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Roland Winkler]

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

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Stefan Monnier]

> 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

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Roland Winkler]

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

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Glenn Morris]

"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)))

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Glenn Morris]

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

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Stefan Monnier]

>> > 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"

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Roland Winkler]

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".

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Eli Zaretskii]

> Date: Mon, 02 Jun 2014 13:45:25 -0400
> Cc: 17666@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.

bug#17666: 24.3.91; [regression] call-process in read-only buffers

[Stefan Monnier]

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