From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Thu, 20 Apr 2017 22:58:09 +0300 Message-ID: <83h91ic0mm.fsf@gnu.org> References: <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> <871ssos8jp.fsf@lifelogs.com> <83y3uwb995.fsf@gnu.org> <83wpafbyk6.fsf@gnu.org> <83o9vraxow.fsf@gnu.org> <83mvbbavyp.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492718259 22415 195.159.176.226 (20 Apr 2017 19:57:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2017 19:57:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 20 21:57:36 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 1d1ICs-0005jd-Vi for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 21:57:35 +0200 Original-Received: from localhost ([::1]:55758 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1ICy-0000uz-HX for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 15:57:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1ICs-0000ut-CK for emacs-devel@gnu.org; Thu, 20 Apr 2017 15:57:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1ICo-0001W2-Gs for emacs-devel@gnu.org; Thu, 20 Apr 2017 15:57:34 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1ICo-0001Vu-DG; Thu, 20 Apr 2017 15:57:30 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3695 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1d1ICn-00016D-Jf; Thu, 20 Apr 2017 15:57:30 -0400 In-reply-to: (message from Stefan Monnier on Thu, 20 Apr 2017 13:25:43 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:214157 Archived-At: > From: Stefan Monnier > Date: Thu, 20 Apr 2017 13:25:43 -0400 > > > You can have predictability if you bind coding-system-for-write to > > whatever you want. > > Why would the casual coder do that? Casual coders won't. And why should they? > He'll just call the primitive, see > that it works for his use-case and not even realize that there's some > encoding/decoding, encouraging him along to way to overlook the big > difference between strings of chars and strings of bytes. I don't see any problem with that. Perhaps you could try explaining why you think there's a problem in this scenario. E.g., compare: . a C program reads a file encoded in Latin-1 and passes the text it read to a function that encrypts it and . an Emacs Lisp program reads a file encoded in Latin-1 into a buffer, then passes that buffer to a function that encrypts it How are these two different, from the user's POV? If they are not different, then in the 2nd case encoding the buffer in Latin-1 before passing the bytes to GnuTLS is TRT. > Lars understands this very well because Gnus's code is full of such > problems. Gnus us full of such problems because some Gnus contributors tried to fix problems with non-ASCII text without understanding what they are doing and how this stuff should work, and also because Gnus messes too much with unibyte text. Let's "learn from past mistakes" and not do this with these new functions.