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: Sat, 21 Nov 2015 11:29:24 +0200 Message-ID: <83si3z4s5n.fsf@gnu.org> References: <83k2ptq5t3.fsf@gnu.org> <87h9kxx60e.fsf@lifelogs.com> <877flswse5.fsf@lifelogs.com> <8737wgw7kf.fsf@lifelogs.com> <87io5bv1it.fsf@lifelogs.com> <87egfzuwca.fsf@lifelogs.com> <876118u6f2.fsf@lifelogs.com> <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <837fld6lps.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448098228 1840 80.91.229.3 (21 Nov 2015 09:30:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2015 09:30:28 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 21 10:30:16 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 1a04Up-0003Tn-4X for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 10:30:15 +0100 Original-Received: from localhost ([::1]:51621 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a04Uo-0003AU-9U for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2015 04:30:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a04Uk-00039m-BC for emacs-devel@gnu.org; Sat, 21 Nov 2015 04:30:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a04Uh-0000zE-48 for emacs-devel@gnu.org; Sat, 21 Nov 2015 04:30:10 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:39354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a04Ug-0000yc-TE for emacs-devel@gnu.org; Sat, 21 Nov 2015 04:30:07 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NY500H00R2HLI00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 21 Nov 2015 11:29:35 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY500HQMRPB8J80@a-mtaout22.012.net.il>; Sat, 21 Nov 2015 11:29:35 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:194932 Archived-At: > From: Philipp Stephani > Date: Sat, 21 Nov 2015 09:01:12 +0000 > Cc: tzz@lifelogs.com, aurelien.aptel+emacs@gmail.com, emacs-devel@gnu.org > > Let me summarize the issues I see: The internal Emacs encoding can change > between versions (command in mule-conf.el), therefore we shouldn't use it in > the module API. IIUC this rules out make_multibyte_string: it only accepts the > internal encoding. Therefore I proposed to always have users specify the > encoding explicitly and then use code_convert_string_norecord to create the > Lisp string objects. Would that work? (We probably then need another set of > functions for unibyte strings.) I'm not sure I'm following, so let's take a step back, okay? My comments were about using build_string and make_string in 2 functions defined in emacs-module.c: module_make_function and module_make_string. Both of these emacs-module.c functions produce strings for consumption by Emacs, AFAIU: the former produces a doc string of a function defined by a module, which will be used by various documentation-related functions and commands within Emacs, the latter produces a string to be passed to Emacs Lisp code for use as any other Lisp string. Do you agree so far? If you agree, then in both cases the strings these functions return should be in the internal representation of strings used by Emacs, not in some encoding like UTF-8 or ISO-8859-1. (We could also use encoded strings, but that would require Lisp programs using module functions to always decode any strings they receive, which is less efficient and more error-prone.) (Btw, I don't think we should worry about changing the internal representation of characters in Emacs, because make_multibyte_string will be updated as needed.) This is what my comments were about. I think that you, by contrast, are talking about the encoding of the _input_ strings, in this case the 'documentation' argument to module_make_function and 'str' argument to module_make_string. My assumption was that these arguments will always have to be in UTF-8 encoding; if that assumption is true, then no decoding via code_convert_string_norecord is necessary, since make_multibyte_string will DTRT. We can (and probably should) document the fact that all non-ASCII strings must be UTF-8 encoded as a requirement of the emacs-module interface. If you are thinking about accepting strings encoded in other encodings, I'd consider this an extension, to be added later if needed. After all, a module can easily convert to UTF-8 by itself, using facilities such as iconv. In any case, code_convert_string_norecord cannot be the complete solution, because it accepts Lisp string objects, not C strings. You still need to create a Lisp string (but this time using make_unibyte_string). The point is to always use either make_unibyte_string or make_multibyte_string, and never build_string or make_string; the latter 2 should only be used for fixed ASCII-only strings. I hope this clarifies the issue.