From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thierry Volpiatto Newsgroups: gmane.emacs.devel Subject: Re: org-crypt bug and other org inconveniences. Date: Wed, 20 Nov 2013 15:20:13 +0100 Organization: Emacs Helm Message-ID: <87bo1fkvdu.fsf@gmail.com> 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 1384957295 15764 80.91.229.3 (20 Nov 2013 14:21:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Nov 2013 14:21:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 20 15:21:40 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 1Vj8ex-0005Ii-If for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2013 15:21:39 +0100 Original-Received: from localhost ([::1]:54923 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj8ex-0006C3-3b for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2013 09:21:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj8dx-0004nO-6M for emacs-devel@gnu.org; Wed, 20 Nov 2013 09:20:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj8dr-0006Ed-N7 for emacs-devel@gnu.org; Wed, 20 Nov 2013 09:20:37 -0500 Original-Received: from mail-ea0-x230.google.com ([2a00:1450:4013:c01::230]:55739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj8dr-0006EM-Gk for emacs-devel@gnu.org; Wed, 20 Nov 2013 09:20:31 -0500 Original-Received: by mail-ea0-f176.google.com with SMTP id h14so1702359eaj.21 for ; Wed, 20 Nov 2013 06:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=sd6bYYQAvDOfjMRETCp/1L12ECT0T2KM9RqMmOf3hPo=; b=O7jYAA/yPb7EYjVl087PV9B0WqxjBQ7qGtr6c4XMb730wpVjeTIUrbwjSzce/a27co y2Kr42klQUi5F5C8oQewOaSRjwSjapKZ0TcWiymxSGUw4Gkl3n5o7/tA1EDS05LSfXI4 QFS+wvtcYC45J303yOc7pkZnVcn7wwMFLm2ixt5RthmWl01XGUS0fzlPKTwUqFV8JkMj AUZp5wRfVdYPEUQbuw0IDD/qHlVOoxgBqQmgEvFI9PUM4mV8omRCPBW8tmWbvGQo5cET NvQPoeMcjhQdRvYk2hw+UHJg4oE6Tfkcin8+QgaB4qMRMn79odRbIjqOkzmpFgiIgtN2 /03g== X-Received: by 10.14.103.69 with SMTP id e45mr1172713eeg.51.1384957229171; Wed, 20 Nov 2013 06:20:29 -0800 (PST) Original-Received: from dell-14z ([37.163.225.100]) by mx.google.com with ESMTPSA id z2sm60532423eee.7.2013.11.20.06.20.25 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 20 Nov 2013 06:20:28 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Wed, 20 Nov 2013 08:44:16 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::230 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:165438 Archived-At: Stefan Monnier writes: >>> 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". Agree. I have fixed all my code last year according to your warning. So probably it is good to keep the warning and fix all the code that trigger it ? The patch about org-crypt does this (It is in my .emacs for months now). >>> 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. Ok I will remember it, thanks. > 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. I have modified now most of the code during last two years. But part of this code is still from somebody else even if massively modified, so I don't know. -- Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997