From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Mon, 06 Oct 2014 19:58:08 +0200 Organization: Organization?!? Message-ID: <87ppe5cc7j.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <8738b1drzt.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412618351 22831 80.91.229.3 (6 Oct 2014 17:59:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2014 17:59:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 06 19:59:03 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XbCYo-0000Cl-Sq for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 19:59:03 +0200 Original-Received: from localhost ([::1]:53465 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCYo-0005f4-ER for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 13:59:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCYL-0005XC-EF for emacs-devel@gnu.org; Mon, 06 Oct 2014 13:58:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbCYC-00024A-Ue for emacs-devel@gnu.org; Mon, 06 Oct 2014 13:58:33 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:42522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbCYC-00023p-Nx for emacs-devel@gnu.org; Mon, 06 Oct 2014 13:58:24 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XbCY9-0008FP-PG for emacs-devel@gnu.org; Mon, 06 Oct 2014 19:58:21 +0200 Original-Received: from x2f3b340.dyn.telefonica.de ([2.243.179.64]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Oct 2014 19:58:21 +0200 Original-Received: from dak by x2f3b340.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Oct 2014 19:58:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 22 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f3b340.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:Tdh5CUwaAN59QOUogEcQ3cPv5UE= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175031 Archived-At: David Kastrup writes: > Eli Zaretskii writes: > >> Btw, Emacs doesn't expose the internal representation of these bytes >> easily to Lisp programs. That is, whenever any program tries to >> access the character at that position, it gets the original raw byte >> that was there before the string was read from outside. A Lisp >> program needs some very tricky and deliberate techniques to access the >> internal representation of such bytes. (It isn't "overlong", btw, we >> just represent the 128 bytes as codepoints in the 0x3fffXX range, and >> encode it in UTF-8 with 5 bytes.) > > Oh. Didn't we use 3byte surrogate words (also not valid Unicode but > encodable as 3 bytes) here? Actually, one could even use overlong encodings of 0--127 (to represent raw bytes 128--255) and use only two bytes that way, but that's really asking for reencoding trouble. -- David Kastrup