bug-gnu-emacs
[Top][All Lists]
Advanced

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

address@hidden (Gerd Moellmann) writes:
> Erik Naggum <address@hidden> 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
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]