From: Thien-Thi Nguyen <ttn@gnu.org>
Cc: David Smith <davidsmith@acm.org>,
emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
Jason Rumney <jasonr@gnu.org>
Subject: Re: [davidsmith@acm.org: [patch] url-hexify-string does not follow W3C spec]
Date: 01 Aug 2006 10:47:07 -0400 [thread overview]
Message-ID: <jkvepcwm1g.fsf@glug.org> (raw)
In-Reply-To: <wl1ws1f6tb.wl%mituharu@math.s.chiba-u.ac.jp>
YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> [review]
thanks, that was very pleasant to read.
> * Rev 1.14
> The argument is assumed to be either a sequence of characters or a
> sequence of octets depending on the multibyteness of the string.
> Incompatibility still remains for a multibyte string containing
> eight-bit-control or eight-bit-graphic, but usually negligible.
>
> I'm not sure if encoding with UTF-8 is really useful, but I don't
> strongly oppose it if compatibility for the unibyte case is preverved.
conversion to utf-8 is per the RFC, which seems to be the primary context for
this function; avoiding that conversion means noncompliance w/ the RFC.
i think rev 1.14 is almost ok; anything that deviates from the RFC should be
under user control (via optional arg) and should be documented. i assume that
(a) conversion of multibyte utf-8 is unconditionally desirable (a "negligible"
problem is no problem), and (b) that there exist non utf-8 unibyte encodings
that which callers wish to "hexify as is". please correct me if these
assumptions do not hold. on the other hand, if they do hold, how about:
(defun ... (string &optional unibyte-as-is-p)
...
(if (or (multibyte-string-p string)
(not unibyte-as-is-p))
(encode-coding-string string 'utf-8 t)
string)
...)
?
this way, RFC-compliance is the default, but suppressing the conversion to
utf-8 is still possible for unibyte strings by specifying UNIBYTE-AS-IS-P.
thi
next prev parent reply other threads:[~2006-08-01 14:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-30 13:14 [davidsmith@acm.org: [patch] url-hexify-string does not follow W3C spec] Richard Stallman
2006-07-30 20:24 ` Thien-Thi Nguyen
2006-07-31 0:59 ` YAMAMOTO Mitsuharu
2006-07-31 10:13 ` Thien-Thi Nguyen
2006-07-31 10:46 ` Jason Rumney
2006-07-31 16:08 ` Stefan Monnier
2006-07-31 16:35 ` David Smith
2006-07-31 20:49 ` Thien-Thi Nguyen
2006-08-01 3:55 ` YAMAMOTO Mitsuharu
2006-08-01 4:20 ` Stefan Monnier
2006-08-01 4:34 ` YAMAMOTO Mitsuharu
2006-08-01 6:50 ` Stefan Monnier
2006-08-01 7:14 ` Kenichi Handa
2006-08-01 14:32 ` Stefan Monnier
2006-08-01 8:42 ` Jason Rumney
2006-08-01 14:47 ` Thien-Thi Nguyen [this message]
2006-08-01 15:10 ` Stefan Monnier
2006-08-01 15:14 ` David Kastrup
2006-08-01 15:54 ` Stefan Monnier
2006-08-01 16:07 ` David Kastrup
2006-08-09 3:48 ` Kenichi Handa
2006-08-02 2:06 ` YAMAMOTO Mitsuharu
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=jkvepcwm1g.fsf@glug.org \
--to=ttn@gnu.org \
--cc=davidsmith@acm.org \
--cc=emacs-devel@gnu.org \
--cc=jasonr@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.