[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: where to put eol kludge

From: Kenichi Handa
Subject: Re: where to put eol kludge
Date: Fri, 16 May 2003 22:06:36 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

In article <address@hidden>, Thien-Thi Nguyen <address@hidden> writes:
>    I'd like to avoid introducing "#ifdef VMS" newly in a
>    function that doesn't have it currently.

> fully agreed.  generally this might be re-conceptualized as "#if
> CODING_STOPS_AT_LAST_EOL", where vms just happens to be one beneficiary
> (maybe there will be others).  the word "stops" is not 100% accurate,
> unfortunately.

Please note that this problem is not related to the task of
encoding_coding.  It's wrong to bring in the unrelated task
in encoding_coding.

And, encoding-coding is used also for encode-coding-region
and encode-coding-string that don't have to pay attention to
this problem.

In addition, the chunking is introduced not only by
encode_coding but by annotate functions which may produce a
very short chunk that doesn't contain a newline.

So, I think we should handle it in the place of "file

>   struct coding_system
>   { ...
>     /* Last EOL.  */
>     char *last_eol;
>     /* Number of bytes to carry over after the last EOL encountered.  */
>     int carry_over_bytes;
>   #endif
>   };

> then macros EMIT_ONE_BYTE and EMIT_TWO_BYTES would set last_eol,
> and encode_coding would need:

>   coding-> carry_over_bytes = coding->produced - coding->last_eol;
>   #endif

encode_coding is designed so that it can be called with
different input buffer.  So, if we handle this problem in
encode_coding, we have to remember carry over bytes
themselves (not only the length) in the struct coding_system
by allocating a memory for them, copy them, and re-copy them
to the output buffer on the next encoding.  It's so
inefficient.  Even if we do that, it can't solve the problem
of thr short chunk produced by an annotate function.

So, I strongly suggest to forget about changing
encode_coding in such a way.

Here's a suggestion to solve this problem.

(1) Detect this problem in configure, and define, say,
    WRITE_ADD_NEWLINE on a problematic system.

(2) Write a different version of emacs_write in sysdep.c for
    such a system.  It keeps carry over bytes in a static
    buffer, and flushes out the bytes when called with
    NBYTES == 0.

(3) Modify e_write to to call emacs_write with NBYTES == 0
    at the end.

Ken'ichi HANDA

reply via email to

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