From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: Re: interesting encryption/encoding allout problem Date: Sat, 11 Nov 2006 18:56:20 -0500 Message-ID: <2cd46e7f0611111556p26580e10q5940d2d89bb27a0a@mail.gmail.com> References: <2cd46e7f0611102135o17cc805ei8e863ab26dd60013@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1163289403 21512 80.91.229.2 (11 Nov 2006 23:56:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 11 Nov 2006 23:56:43 +0000 (UTC) Cc: Emacs-Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 12 00:56:41 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Gj2iC-00017l-2u for ged-emacs-devel@m.gmane.org; Sun, 12 Nov 2006 00:56:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gj2iB-0000Gu-EY for ged-emacs-devel@m.gmane.org; Sat, 11 Nov 2006 18:56:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gj2i1-0000FF-1e for emacs-devel@gnu.org; Sat, 11 Nov 2006 18:56:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gj2hy-0000EG-OS for emacs-devel@gnu.org; Sat, 11 Nov 2006 18:56:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gj2hy-0000ED-L8 for emacs-devel@gnu.org; Sat, 11 Nov 2006 18:56:22 -0500 Original-Received: from [64.233.182.190] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gj2hy-0005Qb-N0 for emacs-devel@gnu.org; Sat, 11 Nov 2006 18:56:22 -0500 Original-Received: by nf-out-0910.google.com with SMTP id d4so1731958nfe for ; Sat, 11 Nov 2006 15:56:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b72mh3YgAhiVnSPbmS8uXQHtC3UDi0Svk/RaDGBCF2VoE40tiZqgGCcKMNttNgEvK7x5/NUWSPi8GeMkXggmKoSpYmCkCCZQpfHIa380FeUHmZsqgib6FNkHGIJ4vJSDgF6FEgNO/p5wza6qk32rre5PYW22Q2Lr9wfpetFagHQ= Original-Received: by 10.78.128.11 with SMTP id a11mr4422255hud.1163289380964; Sat, 11 Nov 2006 15:56:20 -0800 (PST) Original-Received: by 10.78.198.11 with HTTP; Sat, 11 Nov 2006 15:56:20 -0800 (PST) Original-To: "Kim F. Storm" In-Reply-To: Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:62084 Archived-At: On 11/11/06, Kim F. Storm wrote: > I guess this problem means that we should not install your latest > patches to do the topic encryption. that's right - don't check it in. i do think those fixes are correct, but fail to address the issue you cite, below. i also believe i have a fairly sensible fix for that additional problem, and hope to have a patch for it tomorrow or monday. i'm glad you asked - now i can simply make the patch against the currently checked-in version of allout.el, without complicating anybody's life. (if anyone is interested - i plan to have allout always check whether text being encrypted needs coding system accomodation different than that prevailing for the buffer. if so, the user is prompted for the coding system (using select-safe-coding-system), and then the new coding system is preserved using a file local variable setting for buffer-file-coding-system. (fortunately, allout already has a mechanism for establishing and changing the settings of such things.) the normal safe-local-variable properties will cause people visiting a file with such a setting to be prompted to accept the setting, so that they'll be alerted that the setting is in effect. the situation rarely should occur, and i think that's the best i can do to provide for such a complicated character encoding situation...) ken > "Ken Manheimer" writes: > > > i'm struggling with an interesting coding-system problem presented by > > allout's topic encryption feature, and wondering whether anyone has > > suggestions. > > > > the problem occurs when non-ascii text, which requires an alternative > > coding system, exists only within a topic or topics that are encrypted. > > allout auto-encrypts unencrypted topics, and i can make allout do > > select-safe-coding-system to promote the proper coding system setting > > during encryption. > > > > the problem is that encryption of the text removes the need for the > > alternate coding system. when the file is next visited, all the non-ascii > > characters are encrypted, which is coding-system agnostic. the default > > coding system is used, and (unless the default happens to be tailored for > > it) decryption of the topics will deliver the non-ascii text into the wrong > > coding system. > > > > perhaps the thing i'm missing is the right way to save the text so the > > alternate coding system is recovered despite the absence of any text which > > requires it. is that possible? might i need to have allout set some local > > file variable to preserve the coding-system? > > > > i think the same problem occurs for whole-buffer encryption, when some of > > the encrypted text is non-ascii. > > -- > > ken > > ken.manheimer@gmail.com > > http://myriadicity.net > > -- > Kim F. Storm http://www.cua.dk -- ken ken.manheimer@gmail.com http://myriadicity.net