Re: inhibit-eol-conversion affects call-process marking buffers modified

[Kenichi Handa]

gerd.moellmann@t-online.de (Gerd Moellmann) writes:
> Erik Naggum <erik@naggum.net> writes:
>>  (let ((inhibit-eol-conversion t)
>>        (buffer (generate-new-buffer "testing")))
>>    (call-process "true" nil buffer nil)
>>    (buffer-modified-p buffer))
>>  => t

> (Fortunately, it wasn't as difficult to debug as I thought at first.)

> The reason for buffer-modified-p returning t in the test case is that
> call-process calls insert_1_both for 0 chars read (~line 780)

>           if (! CODING_MAY_REQUIRE_DECODING (&process_coding))
>             insert_1_both (bufptr, nread, nread, 0, 1, 0);

> and insert_1_both always increments the buffer modified counter.

> One possible solution is to make insert_1_both simply return when
> NCHARS == 0.

> Kenichi, could you please check this?  Are there cases where
> insert_1_both may be called intentionally with NCHARS == 0, maybe
> for the side effect of moving the gap?

No.  But, isn't it better to change callproc.c so that it
doesn't call insert_1_both if NREAD is zero.  Actually, at
the later code (line 810), we do:

                if (process_coding.produced > 0)
                  insert_1_both (decoding_buf, process_coding.produced_char,
                                 process_coding.produced, 0, 1, 0);

I think changing such very deep function as insert_1_both
requires much more consideration.

---
Ken'ichi HANDA
handa@etl.go.jp