From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: feature request: reloading settings in an org file should reload file local variables Date: Tue, 14 Jan 2014 20:49:08 +0100 Message-ID: <22D334F3-1C94-42E9-9E95-5416734CF948@gmail.com> References: <87txd6pso2.fsf@pinto.chemeng.ucl.ac.uk> <2F4897D0-8F3B-4E26-A5C8-5FC51AFEFB91@gmail.com> <87ppnu60k0.fsf@alphaville.bos.redhat.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W39zD-00030a-5l for emacs-orgmode@gnu.org; Tue, 14 Jan 2014 14:49:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W39z8-0002Kg-4s for emacs-orgmode@gnu.org; Tue, 14 Jan 2014 14:49:19 -0500 Received: from mail-wg0-x232.google.com ([2a00:1450:400c:c00::232]:33243) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W39z7-0002KJ-UR for emacs-orgmode@gnu.org; Tue, 14 Jan 2014 14:49:14 -0500 Received: by mail-wg0-f50.google.com with SMTP id l18so852228wgh.17 for ; Tue, 14 Jan 2014 11:49:13 -0800 (PST) In-Reply-To: <87ppnu60k0.fsf@alphaville.bos.redhat.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nick Dokos Cc: emacs-orgmode@gnu.org On 14 Jan 2014, at 16:33, Nick Dokos wrote: > Carsten Dominik writes: >=20 >> Hi Eric, >>=20 >> On Jan 14, 2014, at 3:03 PM, Eric S Fraga wrote: >>=20 >>> Hello, >>>=20 >>> I constantly run into an annoying side effect of org's handling of >>> settings in a document. When writing a document for export, usually = to >>> LaTeX, I find myself playing around with the document wide >>> setting variables, e.g.=20 >>>=20 >>> #+options: toc:nil >>> #+latex_header: \usepackage{tikz} >>>=20 >>> and similar. Org requires me to re-load the document settings by >>> hitting C-c C-c on any such document setting line. This is fine. >>>=20 >>> The problem is that org appears to reset *all* variables to default >>> (custom?) settings. This includes variables that have been set = using >>> file local variables in the given document. Of particular note is = the >>> variable ~org-export-allow-bind-keywords~. I normally have this set = to >>> nil for safety reasons but wish to set this to t in some documents. = I >>> use something like this quite often on documents I *know* are safe: >>>=20 >>> ,---- >>> | # Local Variables: >>> | # org-confirm-babel-evaluate: nil >>> | # org-export-allow-bind-keywords: t >>> | # End: >>> `---- >>>=20 >>> The problem is that hitting C-c C-c on a settings line clears these >>> variables. Having the bind one reset is particularly confusing at >>> times. In the end, I have to kill the buffer and re-visit the file = to >>> have things set up properly. >>>=20 >>> Is it possible to have org reload the whole file when reloading >>> settings? Or not reset any variables at all? Either approach would = be >>> exhibit more consistent behaviour possibly? Obviously, the position = in >>> the file would have to be remembered should the file be reloaded >>> automatically. >>>=20 >>> This is not a major issue but a niggly one... >>=20 >> Could you try the following patch? >>=20 >> - Carsten >>=20 >> diff --git a/lisp/org.el b/lisp/org.el >> index 549f1f8..6fca255 100644 >> --- a/lisp/org.el >> +++ b/lisp/org.el >> @@ -20482,11 +20482,9 @@ This command does many different things, = depending on context: >> Also updates the keyword regular expressions." >> (interactive) >> ;; this will set the mode *and* set file local variables. >> - (normal-mode) >> - ;; but it may leave us in some unrelated mode >> - (unless (derived-mode-p "org-mode") >> - (org-mode)) >> - (message "Org-mode restarted")) >> + (funcall major-mode) >> + (hack-local-variables) >> + (message "Mode restarted")) >=20 >=20 > I thought this was fixed, originally with commit 5ea0228 > and after York Zhao found a problem (see the thread at > http://thread.gmane.org/gmane.emacs.orgmode/79187) > with commit 0911edfac881ab17a2cd1670f169ff4bdf1ac486 > and two subsequent commits by Achim to fix some problems: >=20 > commit e655e664bff9fb6e98478682f03e713f990acba5 > commit f2483ec4bbe196ab29ef6312b0d7c1c179a9eafe >=20 > Is this another maint vs master issue perhaps? >=20 > Nick >=20 >=20 Indeed, there were differences between maint and master. Now fixed in = both. - Carsten