From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Fri, 23 Oct 2015 10:05:05 +0300 Message-ID: <83lhaurroe.fsf@gnu.org> References: <56117F37.9060808@dancol.org> <56259FDD.8040401@dancol.org> <87zizeme8k.fsf@tromey.com> <5625B166.3080104@dancol.org> <86zizdczhp.fsf@stephe-leake.org> <562968CA.60101@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1445583938 9144 80.91.229.3 (23 Oct 2015 07:05:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 07:05:38 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, tom@tromey.com, stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 23 09:05:32 2015 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 1ZpWPn-0007HP-0q for ged-emacs-devel@m.gmane.org; Fri, 23 Oct 2015 09:05:27 +0200 Original-Received: from localhost ([::1]:36492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpWPm-0003ZJ-8V for ged-emacs-devel@m.gmane.org; Fri, 23 Oct 2015 03:05:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpWPU-0003Vr-MB for emacs-devel@gnu.org; Fri, 23 Oct 2015 03:05:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpWPP-0007BX-UA for emacs-devel@gnu.org; Fri, 23 Oct 2015 03:05:08 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:64746) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpWPP-0007Ao-Mh for emacs-devel@gnu.org; Fri, 23 Oct 2015 03:05:03 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NWN00K00VMWJZ00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 23 Oct 2015 10:05:02 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWN00K8HVODIS20@a-mtaout21.012.net.il>; Fri, 23 Oct 2015 10:05:02 +0300 (IDT) In-reply-to: <562968CA.60101@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:192453 Archived-At: > Cc: Stephen Leake , > Tom Tromey , Eli Zaretskii , > Emacs development discussions > From: Daniel Colascione > Date: Thu, 22 Oct 2015 15:52:58 -0700 > > > * expose fast read-only string access (not sure how do-able this is > > considering the encoding problem) > > > > > > If the internal Emacs encoding is not defined, then we probably > > shouldn't expose it to modules. What should modules do with such string > > access? They could only treat the contents as opaque byte arrays. > > Agreed, although there may be a reasonable case for an API that provides > direct access to strings that happen to be ASCII (or UTF-8) and that > runs a conversion otherwise, all transparently. Not sure what you mean here. First, the internal representation is a superset of UTF-8, so if we can provide direct access to UTF-8, why not let modules access the internal representation? Second, if by "UTF-8" you mean a unibyte string encoded in strict UTF-8, then why limit that to UTF-8? Standard C runtime can handle many different encodings, including multibyte ones, it is not limited to UTF-8 (although UTF-8 is easier for certain tasks). Therefore, I think access to unibyte strings (a.k.a. "byte streams") should not be limited at all, and letting modules access multibyte strings in their internal representation would be a significant bonus we shouldn't easily give up on.