Hi Bastien, On Tue, Mar 20, 2012 at 17:23, Bastien <b...@gnu.org> wrote: > Hi Suvayu, > > suvayu ali <fatkasuvayu+li...@gmail.com> writes: > >> I wanted to comment earlier but it slipped my mind, sorry about that. >> >> I am not sure if this patch is quite corect. It removes the let bind and >> instead conditionally uses setq to bind it to t. From the docs I see the >> variable becomes buffer local when set in any fashion, but does that >> still mean it is okay to use setq? >> >> I can imagine in a complicated publishing project, an org file might >> need to set the value to something. I suppose this will override any >> such custom config. Is my analysis correct? It might be worth thinking >> about before applying the patch. >> >> Is a conditional let binding possible, it might be the safer choice in >> that case. > > I applied a patch into hotfix-7.8.06 using the let binding -- let me > know if this works correctly.
I don't think this works. The problem (thanks to Nick again for the analysis earlier in the thread[1] :-)) is the let bind happens before tex.el is loaded. So when it is loaded eventually, the defvar fails which in turn triggers the backtrace. The setq in the body works but could possibly mess up someone's custom config as I mentioned in my earlier post. I hope you see the no-win situation now (:-p), hence my apprehension about the fix earlier. That said, I guess you have two choices: 1. Leave the bug unsolved, hoping there will be a cleaner solution later. After all, there is a very simple workaround on the user side, do (load "tex.el") before using org-latex. 2. The second choice would be to partially fix the bug with the setq, but potentially break a future unsuspecting user with a non-standard config. If it were up to me, I would probably prefer option one. I hope this clears up everything. Footnotes: [1] <http://thread.gmane.org/gmane.emacs.orgmode/53128/focus=53152> <http://thread.gmane.org/gmane.emacs.orgmode/53128/focus=53156> -- Suvayu Open source is the future. It sets us free.
