[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inhibit-eol-conversion affects call-process marking buffers modified
From: |
Kenichi Handa |
Subject: |
Re: inhibit-eol-conversion affects call-process marking buffers modified |
Date: |
Fri, 26 Oct 2001 21:49:49 +0900 (JST) |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.0.107 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) |
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