From: storm@cua.dk (Kim F. Storm)
Cc: handa@m17n.org
Subject: Re: [HELP] (bug?) Saving a buffer without any conversion?
Date: 16 Jan 2003 23:52:18 +0100 [thread overview]
Message-ID: <5xd6mwoggt.fsf@kfs2.cua.dk> (raw)
In-Reply-To: <1659-Wed15Jan2003193004+0200-eliz@is.elta.co.il>
"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > From: storm@cua.dk (Kim F. Storm)
> > Date: 15 Jan 2003 14:27:23 +0100
> >
> > E.g. add this to the doc string for `set-process-filter':
> >
> > If the process' input coding system is no-conversion or raw-text, the
> > string argument to the filter function is a unibyte string; otherwise
> > it is a multibyte string. Use `string-as-multibyte' on a unibyte
> > string before inserting it in a multibyte buffer.
> >
> > Note: If the sole purpose of the filter is to insert received data
> > into a specific buffer, it is better NOT to define a process filter,
> > but instead set the process' buffer to that buffer.
>
> The issue involved is not specific to process filters, so it should
> probably be mentioned in other doc strings as well, like in that of
> `insert'.
Well, I added something to set-process-filter, but I'm quite unsure
what to add to `insert's doc string which already says this about the
issue:
If the current buffer is multibyte, unibyte strings are converted
to multibyte for insertion (see `unibyte-char-to-multibyte').
If the current buffer is unibyte, multibyte strings are converted
to unibyte for insertion.
It seems very odd that we have to suggest to use string-as-multibyte
(or string-as-unibyte) to convert strings prior to insertion when the
doc string says it does that automatically. I guess it has to say
something about buffer coding systems here, but what ...?
Handa-san, maybe you can tell the "true story" ?
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
next prev parent reply other threads:[~2003-01-16 22:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-13 17:52 [HELP] (bug?) Saving a buffer without any conversion? Mario Lang
2003-01-14 1:00 ` Kim F. Storm
2003-01-14 6:06 ` Eli Zaretskii
2003-01-14 6:46 ` Mario Lang
2003-01-14 18:37 ` Eli Zaretskii
2003-01-14 16:19 ` Stefan Monnier
2003-01-15 1:16 ` Kenichi Handa
2003-01-15 11:02 ` Kim F. Storm
2003-01-15 10:59 ` Kenichi Handa
2003-01-15 13:27 ` Kim F. Storm
2003-01-15 16:30 ` Eli Zaretskii
2003-01-16 22:52 ` Kim F. Storm [this message]
2003-01-17 2:35 ` Kenichi Handa
2003-01-16 1:18 ` Kenichi Handa
2003-01-17 9:23 ` Richard Stallman
2003-01-17 11:07 ` Kenichi Handa
2003-01-15 16:59 ` Mario Lang
2003-01-15 23:27 ` Richard Stallman
2003-01-16 6:45 ` Kenichi Handa
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5xd6mwoggt.fsf@kfs2.cua.dk \
--to=storm@cua.dk \
--cc=handa@m17n.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).