all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Kenichi Handa <handa@m17n.org>
Cc: emacs-devel@gnu.org
Subject: Re: where to put eol kludge
Date: Fri, 16 May 2003 22:06:36 +0900 (JST)	[thread overview]
Message-ID: <200305161306.WAA06706@etlken.m17n.org> (raw)
In-Reply-To: <E19Ge6O-0007qf-00@colo.agora-net.com> (message from Thien-Thi Nguyen on Fri, 16 May 2003 08:14:20 -0400)

In article <E19Ge6O-0007qf-00@colo.agora-net.com>, Thien-Thi Nguyen <ttn@glug.org> 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
writing".

>   struct coding_system
>   { ...
>   #ifdef CODING_CARRIES_AFTER_LAST_EOL
>     /* 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:

>   #ifdef CODING_CARRIES_AFTER_LAST_EOL
>   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
handa@m17n.org

  reply	other threads:[~2003-05-16 13:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15 23:05 where to put eol kludge Thien-Thi Nguyen
2003-05-15 23:49 ` Kenichi Handa
2003-05-16 10:20   ` Thien-Thi Nguyen
2003-05-16 11:07     ` Kenichi Handa
2003-05-16 12:14       ` Thien-Thi Nguyen
2003-05-16 13:06         ` Kenichi Handa [this message]
2003-05-19 14:50           ` Thien-Thi Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200305161306.WAA06706@etlken.m17n.org \
    --to=handa@m17n.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.