From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: org-crypt bug and other org inconveniences. Date: Wed, 20 Nov 2013 08:44:16 -0500 Message-ID: References: <87a9h0ie4n.fsf@gmail.com> <87bo1fcy94.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1384955074 19855 80.91.229.3 (20 Nov 2013 13:44:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Nov 2013 13:44:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thierry Volpiatto Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 20 14:44:39 2013 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 1Vj858-00032e-Kj for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2013 14:44:38 +0100 Original-Received: from localhost ([::1]:54760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj858-0008RY-9x for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2013 08:44:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj84y-0008O9-6B for emacs-devel@gnu.org; Wed, 20 Nov 2013 08:44:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj84o-0003hU-Ef for emacs-devel@gnu.org; Wed, 20 Nov 2013 08:44:28 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:15095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj84o-0003hO-BD for emacs-devel@gnu.org; Wed, 20 Nov 2013 08:44:18 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KWN/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFHO+KWN/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAs0EhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="38709123" Original-Received: from 206-248-165-141.dsl.teksavvy.com (HELO pastel.home) ([206.248.165.141]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Nov 2013 08:44:17 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E97AC60424; Wed, 20 Nov 2013 08:44:16 -0500 (EST) In-Reply-To: <87bo1fcy94.fsf@gmail.com> (Thierry Volpiatto's message of "Wed, 20 Nov 2013 08:45:27 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:165436 Archived-At: >> Note that this warning is not necessarily a problem. Actually, I tend >> to think we should just get rid of this warning (which I added, a few >> years ago). > Yes, setting a var locally already let-bounded works actually. > But it is not what the documentation say. > ,---- > | Making a variable buffer-local within a `let'-binding for that > | variable does not work reliably, unless the buffer in which you do > | this is not current either on entry to or exit from the `let'. > | This is because `let' does not distinguish between different kinds > | of bindings; it knows only which variable the binding was made for. > `---- The documentation is indeed rather conservative. But it is true that over the years many bugs were found in this area (and fixed). AFAIK there are no remaining bugs in this area (no proof of it, but I did try to consider "all possible cases"), *but* the "right behavior" in some cases is not always completely well-defined. E.g.: <...global value of x = 1...> (let ((x 2)) (make-local-variable 'x)) After this code (default-value 'x) should have value 1. But what about the buffer-local value of x? So the above comment basically tries to scare coders away from mixing let-bindings and buffer-local bindings, because "there be dragons". >> BTW, why not try to push Helm's support for Org to Org, i.e. make Org >> support Helm, rather than the other way around? > Sure, but I don't think org developers want to maintain/develop code > depending on external applications. > Emacs developers too I think, (AFAIK sending a patch to emacs handling > external dependencies have been always refused). If the interface is sufficiently clean and generic, I'd definitely consider it. Can't speak for Org people. Stefan PS: Last time we talked about including Helm in GNU ELPA, there were issues about copyright, IIRC. If those issues are mostly in the various mode-specific support files, we could focus on integrating the infrastructure part of Helm separately.