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: Sun, 22 Nov 2015 21:50:57 +0200 Message-ID: <83y4dp24pq.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> <83si3z4s5n.fsf@gnu.org> <83mvu74nhm.fsf@gnu.org> <83d1v34hba.fsf@gnu.org> <83io4u2aze.fsf@gnu.org> <8337vx3kp6.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448221895 21168 80.91.229.3 (22 Nov 2015 19:51:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 19:51:35 +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 Sun Nov 22 20:51:23 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 1a0afL-0000VG-FV for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 20:51:15 +0100 Original-Received: from localhost ([::1]:57264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0afL-00034Z-Li for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 14:51:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0afH-00034G-Tm for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:51:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0afC-0004IK-Rg for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:51:11 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:46383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0afC-0004IG-JO for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:51:06 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NY800900F45V200@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sun, 22 Nov 2015 21:51:04 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY8009ZLF54QT30@a-mtaout22.012.net.il>; Sun, 22 Nov 2015 21:51:04 +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:195061 Archived-At: > From: Philipp Stephani > Date: Sun, 22 Nov 2015 19:37:43 +0000 > Cc: tzz@lifelogs.com, aurelien.aptel+emacs@gmail.com, emacs-devel@gnu.org > > I think we shouldn't make the terminology more confusing. If we say > "UTF-8", we should mean "UTF-8 as defined in the Unicode standard", not the > Emacs extension of UTF-8. That's all. I agree, and that's how I use "UTF-8". The internal representation used by Emacs is called "utf-8-emacs" or "emacs-internal". > We say that we accept valid UTF-8 encoded strings; anything else > might produce invalid UTF-8 on output. > > Couldn't we just say "it behaves as if encoding and decoding were done using > the utf-8-unix coding system"? Because I think that's what this boils down to. Not sure what you mean by "utf-8-unix", or why it would be better to say that. I think this makes the issue harder to understand, because it involves a reference to the encoding/decoding stuff, something that module authors might not be fluent with. > > No matter what we expect or tolerate, we need to state that. > > No, we don't. When the callers violate the contract, they cannot > expect to know in detail what will happen. If they want to know, they > will have to read the source. > > So you want this to be unspecified or undefined behavior? That might be OK (we > already have that in several places), but we still need to state what the > contract is. You can call it "undefined behavior" if you want. Personally, I don't think that's accurate: "undefined" means anything can happen, whereas Emacs at least promises to output the original bytes unchanged, as long as the text modifications didn't touch them. > > An Emacs string is a sequence of integers. > > No, it's a sequence of bytes. > > From > https://www.gnu.org/software/emacs/manual/html_node/elisp/String-Basics.html: > "In Emacs Lisp, characters are simply integers ... A string is a fixed sequence > of characters" That's the _User_ manual, it simplifies things to avoid too much complexity. > How a string is represented internally shouldn't be the concern of module > authors. Indeed. But it does concern us, the developers of Emacs internals. > No, I will definitely fix it. Thank you.