From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Wed, 19 Apr 2017 11:48:10 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <871ssos8jp.fsf@lifelogs.com> 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> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492618970 3994 195.159.176.226 (19 Apr 2017 16:22:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Apr 2017 16:22:50 +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 18:22:44 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 1d0sNN-0000pa-W4 for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2017 18:22:42 +0200 Original-Received: from localhost ([::1]:49317 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0sNR-0008Ub-K0 for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2017 12:22:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0sNL-0008UJ-4G for emacs-devel@gnu.org; Wed, 19 Apr 2017 12:22:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0sNH-0005FY-4O for emacs-devel@gnu.org; Wed, 19 Apr 2017 12:22:39 -0400 Original-Received: from [195.159.176.226] (port=34516 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d0sNG-0005F5-U3 for emacs-devel@gnu.org; Wed, 19 Apr 2017 12:22:35 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d0rpy-0004gS-OR for emacs-devel@gnu.org; Wed, 19 Apr 2017 17:48:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 53 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:aZEQ4rR8AEW6cyF87ZqqXO3+DTo= 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:214133 Archived-At: On Wed, 19 Apr 2017 10:54:55 -0400 Stefan Monnier wrote: On Wed, 19 Apr 2017 17:41:52 +0300 Eli Zaretskii wrote: >> 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. SM> Indeed, in some cases we might want to work on multibyte text without SM> encoding it at all. Maybe we could have an argument specifying that the SM> caller intends to operate on the internal encoding. SM> But what shouldn't be in those functions is encoding/decoding: if SM> encoding/decoding is needed, then it should be done before/after calling SM> the functions. That's exactly what's happening, except it's done in C code, by extract_data_from_object() before the function is called. So I can make it a requirement. But I think there's two distinct use cases: "Emacs to Emacs buffer/string" and "Emacs to non-Emacs file/string" and maybe they should be considered separately. Eli wrote: >> But if we pass buffer text, we could always encode using >> buffer-file-coding-system, and IMO that would be the expected result >> (provided that the user didn't want to use the internal >> representation). We do this in the likes of write-region, so why not >> here? Right, I think user expectations are important here. Lars wrote: >> The less confusion in this area the better, and especially for >> encryption functions where you really want to get the correct text back >> again, I think it would be better, long-term, to not allow non-unibyte >> text inputs. Not allow them where? Just the new stuff I'm adding? Or also `secure-hash' and `md5' etc? Or anything that deals with crypto (which could also affect EPG)? If it's just the code in my patch, let me know what I need to change in the way it calls extract_data_from_object() and I'll adjust the code, the tests, and the docs. IIUC Stefan wants the call to fail if the string or buffer is mulibyte and Lars agreed? But we can also look to define a payload structure that would express the coding system, unibyte/multibyte, etc. better. Ted