From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Wed, 19 Apr 2017 10:54:55 -0400 Message-ID: References: <83a89gq3us.fsf@gnu.org> <87bmtjiv0w.fsf_-_@lifelogs.com> <83o9xjn06c.fsf@gnu.org> <87shmeb5ln.fsf_-_@lifelogs.com> <83y3w5z1ez.fsf@gnu.org> <87lgr6yakj.fsf@lifelogs.com> <87wpamww9k.fsf@lifelogs.com> <8337daggnj.fsf@gnu.org> <87d1cdwxt6.fsf@lifelogs.com> <83tw5pg1q3.fsf@gnu.org> <87zifhulc2.fsf@lifelogs.com> <83h91og80k.fsf@gnu.org> <87pogbuhoe.fsf@lifelogs.com> <834lxndmd9.fsf@gnu.org> <87efwrug6z.fsf@lifelogs.com> <83bmrscvdb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492613723 8712 195.159.176.226 (19 Apr 2017 14:55:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Apr 2017 14:55:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 19 16:55:16 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d0r0k-000244-CH for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2017 16:55:14 +0200 Original-Received: from localhost ([::1]:48623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0r0q-0005yA-27 for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2017 10:55:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0r0g-0005uU-BX for emacs-devel@gnu.org; Wed, 19 Apr 2017 10:55:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0r0c-0006t8-FW for emacs-devel@gnu.org; Wed, 19 Apr 2017 10:55:10 -0400 Original-Received: from [195.159.176.226] (port=52874 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d0r0c-0006se-9J for emacs-devel@gnu.org; Wed, 19 Apr 2017 10:55:06 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d0r0S-0001fI-R7 for emacs-devel@gnu.org; Wed, 19 Apr 2017 16:54:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 17 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:9625lAdJfuEAQ5zvx2vnyT2CPJM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:214123 Archived-At: > I think it's important to discuss the expected results, because we > could avoid encoding the string, either inside or outside of the > functions, and just use its bytes instead, disregarding their > interpretation as characters. The question is: would that yield what > users will want and expect? The answer could be YES in some use cases > and NO in others. Indeed, in some cases we might want to work on multibyte text without encoding it at all. Maybe we could have an argument specifying that the caller intends to operate on the internal encoding. But what shouldn't be in those functions is encoding/decoding: if encoding/decoding is needed, then it should be done before/after calling the functions. Stefan