From: Tom Lord <lord@emf.net>
Cc: guile-devel@gnu.org
Subject: Re: Unicode and Guile
Date: Sat, 25 Oct 2003 17:03:18 -0700 (PDT) [thread overview]
Message-ID: <200310260003.RAA10375@morrowfield.regexps.com> (raw)
In-Reply-To: <xfyu15xgs82.fsf@csserver.evansville.edu> (message from Stephen Compall on 25 Oct 2003 18:08:45 +0100)
> From: Stephen Compall <s11@member.fsf.org>
> UTF-16 seems to offer the worst of
> both worlds.
[being both wide compared to 8-bit characters and involving
variable length unicode character encodings, I presume.]
It's culturually discriminatory to regard utf-16 as worse than utf-8
in those regards.
Or, put differently, for many potential users, utf-16 is the best of
both worlds: it optimizes the size of the most common characters (for
some users), and it can also handle any Unicode character.
> As for the semantics, I submit the way Emacs does it: node (elisp)Text
> Representations, or
> http://www.gnu.org/manual/elisp-manual-21-2.8/html_node/elisp_542.html
What do the index arguments to STRING-REF and STRING-SET refer to?
Byte positions or character positions?
(Personally, I think they refer to byte positions and that new errors
can result from them (if the index isn't at a character boundary).
(Too bad that (1+ index) no longer means (next-character string
index)). There's a need for a new type, `text', which acts like the
text contents of an emacs buffer and has (yes I agree) pretty much the
Emacs interface. It should all be designed so that, internally,
people can write new ways to represent text objects and multiple text
object representations can coexist in the same application (just like
emacs). There's no good reason not to throw in attributes, overlays,
and markers for text objects too (just like emacs). ("There's nothing
new under the sun.") And, eventually, people should mostly stop
using the STRING? type altogether except internally to implementations
of TEXT? and as a way to represent non-textual strings of bytes.
"Everything is UTF-32" isn't going to be practical for a long time and
then, after it is, the first roughly homonoid space-aliens to show up
with news of a life-filled galaxy will mean UTF-32 won't be practical
all over again :-)
-t
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2003-10-26 0:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-21 17:15 Unicode and Guile Andy Wingo
2003-10-25 17:08 ` Stephen Compall
2003-10-26 0:03 ` Tom Lord [this message]
2003-10-26 12:34 ` Which Encoding? (was Re: Unicode and Guile) Stephen Compall
2003-10-31 13:25 ` Unicode and Guile Andy Wingo
2003-11-03 13:35 ` text buffers (was Re: Unicode and Guile) Stephen Compall
2003-11-03 20:34 ` Tom Lord
2003-11-04 10:04 ` Stephen Compall
2003-11-03 20:31 ` Unicode and Guile Tom Lord
2003-11-06 18:16 ` Andy Wingo
2003-11-11 19:02 ` Tom Lord
2003-11-12 0:29 ` Marius Vollmer
2003-11-12 1:40 ` Tom Lord
2003-11-12 2:30 ` Marius Vollmer
2003-11-12 4:03 ` Tom Lord
2003-11-12 16:59 ` Marius Vollmer
2003-11-17 16:17 ` Andy Wingo
2003-11-12 0:06 ` Marius Vollmer
2003-11-12 1:27 ` Tom Lord
2003-10-31 13:16 ` Andy Wingo
2003-11-02 21:23 ` Kevin Ryde
2003-11-26 20:35 ` Mikael Djurfeldt
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/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200310260003.RAA10375@morrowfield.regexps.com \
--to=lord@emf.net \
--cc=guile-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.
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).