Re: [O] Variable settings in .emacs VS cross device portability.
Yu yu_...@gmx.at writes: code). The emacs-documentation doesn't mention it, but apparently this works also in shebang'ed files, by moving the single line form (`-*- ... -*-') to the second line. [2] [1] http://www.gnu.org/software/emacs/manual/html_node/emacs/File-Variables.html [2] http://www.lugaru.com/man/File.Variables.html Choosing File Modes (info (emacs) Choosing Modes) info:emacs#Choosing%20Modes When the first line starts with `#!', you usually cannot use the `-*-' feature on the first line, because the system would get confused when running the interpreter. So Emacs looks for `-*-' on the second line in such files as well as on the first line.
Re: [O] Variable settings in .emacs VS cross device portability.
Eric S Fraga e.fr...@ucl.ac.uk writes: Thomas S. Dye t...@tsdye.com writes: [...] If you (and the receiver) tangle your export-settings source code block to init.el (:tangle init.el), then execute something like the following source code block #+begin_src sh emacs -Q -l init.el examplebug.org #+end_src you should be able to ensure that the receiver will get the same result you get. Of course, anything in your .emacs (or other initialization files) that is needed to produce the results will need to be included in export-settings. hth, Tom Thanks Tom! Actually, I must apologise. Your message addresses the OP's initial question but somehow the thread has diverged from that and it's probably my fault it has... Sorry! Hi Eric, No worries. I tried and failed to get buffer local variables to do what I wanted, as it appears you have, too. My failure probably has to do with my ignorance as much as anything, but Dan's analysis and your thread convinced me that it wasn't all me. I found it liberating to work on an Org mode file that would run in a precisely defined environment, separate from the environmental mish-mash that feels comfortable to me in my everyday work. At any rate, I appreciate your good humor, even when I sound dull and off point. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Variable settings in .emacs VS cross device portability.
Thomas S. Dye t...@tsdye.com writes: [...] If you (and the receiver) tangle your export-settings source code block to init.el (:tangle init.el), then execute something like the following source code block #+begin_src sh emacs -Q -l init.el examplebug.org #+end_src you should be able to ensure that the receiver will get the same result you get. Of course, anything in your .emacs (or other initialization files) that is needed to produce the results will need to be included in export-settings. hth, Tom Thanks Tom! Actually, I must apologise. Your message addresses the OP's initial question but somehow the thread has diverged from that and it's probably my fault it has... Sorry! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.300.g9b820)
Re: [O] Variable settings in .emacs VS cross device portability.
Nick Dokos nicholas.do...@hp.com writes:
[...]
Good question (I mean the *How* question): I believe this is a bug and
it has to do with the problem that Dan Davison identified and (as it
turns out) partially fixed a year ago (see
http://thread.gmane.org/gmane.emacs.orgmode/35439/focus=36878 for those
details).
In a nutshell, the problem is that many export operations happen in
temporary buffers. These buffers do not automatically inherit local
[...]
Nick,
Many thanks for this analysis. My gut feeling was indeed correct
(whew!), probably because I subconsciously remembered reading the thread
from Dan Davison.
The quick-and-dirty hack would be to call Dan's cloning function in the
call to with-temp-buffer, but that's not enough:
org-export-latex-fontify-headline does the temp-buffer thingie as well
and needs the same treatment. That seems to make *this* case work but I'm
almost 100% sure that that won't be enough in the general case either:
there are probably other places where temp buffers are created to do
some processing like this. They will also be subject to this problem.
I must admit I am confused as to the point of #+BIND now. I had thought
the whole purpose was to set variables to be used during the export
process but now it seems this is not the case. Or it is only the case
for some subset of the variables that may affect the export process.
I don't care whether I need to use file local variables, #+BIND, or any
other mechanism but it would be nice to have some mechanism! So, can
anybody suggest any hack around this problem? I am not terribly worried
about this as it only causes me difficulties now and again when I have a
specific type of document I need to generate for
dissemination. Usually, my default settings are fine. However, it
would be nice to have some solution to this.
I can have an emacs lisp code block which gets executed to set
the values of those variables. This works (see attachment), so long as
I don't have any other controls for settings these variables, including
file local variables or #+BIND. However, I need to manually execute
this code block if it is hidden away in a not-exported region of the
document. Otherwise, it clogs up the text (but such is life!).
Note, however, that this changes the variable value globally and so will
affect exporting of any other subsequent org documents unless they have
their own settings. Not *good* but good enough for my own use case for
the moment... and, actually, having explicit settings for export
variables in every *important* document is probably not a bad
idea. Ummm, need to think about this.
#+TITLE: examplebug.org
#+AUTHOR:Eric S Fraga
#+EMAIL: e.fr...@ucl.ac.uk
#+DATE: 2012-01-09 Mon
* Formatting tags :example:
When exporting, the default is to put tags in bold. I want a box around them.
# the following is used to set some variables which affect export to latex
#+name: export-settings
#+begin_src emacs-lisp :exports results :results silent
(setq org-export-latex-tag-markup babel: \\fbox{%s})
#+end_src
Anyway, thanks again,
eric
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
: using Org-mode version 7.8.03 (release_7.8.03.293.g36cc)
Re: [O] Variable settings in .emacs VS cross device portability.
Hi Eric,
Eric S Fraga e.fr...@ucl.ac.uk writes:
Nick Dokos nicholas.do...@hp.com writes:
[...]
Good question (I mean the *How* question): I believe this is a bug and
it has to do with the problem that Dan Davison identified and (as it
turns out) partially fixed a year ago (see
http://thread.gmane.org/gmane.emacs.orgmode/35439/focus=36878 for those
details).
In a nutshell, the problem is that many export operations happen in
temporary buffers. These buffers do not automatically inherit local
[...]
Nick,
Many thanks for this analysis. My gut feeling was indeed correct
(whew!), probably because I subconsciously remembered reading the thread
from Dan Davison.
The quick-and-dirty hack would be to call Dan's cloning function in the
call to with-temp-buffer, but that's not enough:
org-export-latex-fontify-headline does the temp-buffer thingie as well
and needs the same treatment. That seems to make *this* case work but I'm
almost 100% sure that that won't be enough in the general case either:
there are probably other places where temp buffers are created to do
some processing like this. They will also be subject to this problem.
I must admit I am confused as to the point of #+BIND now. I had thought
the whole purpose was to set variables to be used during the export
process but now it seems this is not the case. Or it is only the case
for some subset of the variables that may affect the export process.
I don't care whether I need to use file local variables, #+BIND, or any
other mechanism but it would be nice to have some mechanism! So, can
anybody suggest any hack around this problem? I am not terribly worried
about this as it only causes me difficulties now and again when I have a
specific type of document I need to generate for
dissemination. Usually, my default settings are fine. However, it
would be nice to have some solution to this.
I can have an emacs lisp code block which gets executed to set
the values of those variables. This works (see attachment), so long as
I don't have any other controls for settings these variables, including
file local variables or #+BIND. However, I need to manually execute
this code block if it is hidden away in a not-exported region of the
document. Otherwise, it clogs up the text (but such is life!).
Note, however, that this changes the variable value globally and so will
affect exporting of any other subsequent org documents unless they have
their own settings. Not *good* but good enough for my own use case for
the moment... and, actually, having explicit settings for export
variables in every *important* document is probably not a bad
idea. Ummm, need to think about this.
If you (and the receiver) tangle your export-settings source code block
to init.el (:tangle init.el), then execute something like the following
source code block
#+begin_src sh
emacs -Q -l init.el examplebug.org
#+end_src
you should be able to ensure that the receiver will get the same result
you get.
Of course, anything in your .emacs (or other initialization files) that
is needed to produce the results will need to be included in
export-settings.
hth,
Tom
#+TITLE: examplebug.org
#+AUTHOR:Eric S Fraga
#+EMAIL: e.fr...@ucl.ac.uk
#+DATE: 2012-01-09 Mon
* Formatting tags :example:
When exporting, the default is to put tags in bold. I want a box around
them.
# the following is used to set some variables which affect export to latex
#+name: export-settings
#+begin_src emacs-lisp :exports results :results silent
(setq org-export-latex-tag-markup babel: \\fbox{%s})
#+end_src
Anyway, thanks again,
eric
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Variable settings in .emacs VS cross device portability.
2012/1/31 Eric S Fraga e.fr...@ucl.ac.uk: Eric Schulte eric.schu...@gmx.com writes: [...] File Local Variables [1] make it possible to explicitly specify the values of variables from within the text of a .org file. This can be placed in a single line at the top of a file for small changes or in a larger section at the end of the file. Eric, this doesn't always seem to work, at least not for me. BIND always works but certain org variables seem to be ignored when set using local file variables. The variables I refer to are often, maybe always (?), related to export functions. My gut feeling is that this has something to do with a copy of the file being made for the export and maybe emacs not getting a chance to set local variables for that copy? Grasping at straws here, mind you ;-) For #+BIND the org manual is probably not quite clear. The Concept Index page says: : * #+BIND:Export options. (line 19) 12.2 Export options says: : #+BIND:lisp-var lisp-val, e.g.: org-export-latex-low-levels itemize : You need to confirm using these, or configure `org-export-allow-BIND' So basically, #+BIND only applies to export, though the manual maybe slightly underemphasizes that fact. Did you try the general emacs syntax for file variables, Eric Schulte mentioned? [1] For me that worked (except that non-safe variables require confirmation in order to avoid text files executing harmful code). The emacs-documentation doesn't mention it, but apparently this works also in shebang'ed files, by moving the single line form (`-*- ... -*-') to the second line. [2] [1] http://www.gnu.org/software/emacs/manual/html_node/emacs/File-Variables.html [2] http://www.lugaru.com/man/File.Variables.html
Re: [O] Variable settings in .emacs VS cross device portability.
Hi Eric,
Eric S Fraga wrote:
herewith is a minimal example that illustrates the problem I have with
exporting and file local variables. The attached file re-defines
org-export-latex-tag-markup to use a box instead of bold for tags. When
I visit the file, Emacs does indeed set the variable to what I
want. However, this setting is ignored on export.
Actually, in this case, the BIND is also ignored on export even though
the variable does change to the specified value after export!
I am very confused, to say the least. *How* can I get file local
behaviour when exporting with org? Am I doing something silly
somewhere? (highly likely given my past track record ;-) Do others see
different behaviour?
I'm up to date (as of this morning) with org and latest emacs as of last
week.
Thanks,
eric
# -*- org-export-latex-tag-markup: locally set: \\fbox{%s}; -*-
#+TITLE: examplebug.org
#+AUTHOR:Eric S Fraga
#+EMAIL: e.fr...@ucl.ac.uk
#+DATE: 2012-01-09 Mon
#+bind: org-export-latex-tag-markup bound: \\fbox{%s}
* Formatting tags :example:
When exporting, the default is to put tags in bold. I want a box around
them.
I almost never play(ed) with local variables and bind variables, but I wanted
to confirm what you see:
the local variable is the one set by your bind; but it has no impact on the
exported LaTeX file...
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Variable settings in .emacs VS cross device portability.
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: [...] I almost never play(ed) with local variables and bind variables, but I wanted to confirm what you see: the local variable is the one set by your bind; but it has no impact on the exported LaTeX file... Best regards, Seb Thanks for the confirmation. At least I am not going completely crazy ;-) Does the local variable setting defined in the file take effect before you export? Thanks again, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.288.ga3e5f)
Re: [O] Variable settings in .emacs VS cross device portability.
Hi Eric,
Eric S Fraga wrote:
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:
I almost never play(ed) with local variables and bind variables, but I
wanted to confirm what you see:
the local variable is the one set by your bind; but it has no impact on the
exported LaTeX file...
Thanks for the confirmation. At least I am not going completely crazy
;-)
Does the local variable setting defined in the file take effect before
you export?
After saving your file to disk, and opening it:
┏
┃ org-export-latex-tag-markup is a variable defined in `org-latex.el'.
┃ Its value is locally set: \\fbox{%s}
┃ Original value was \\textbf{%s}
┃ Local in buffer examplebug.org; global value is
┃ what is in my Emacs config file
┃
┃ This variable is a file local variable.
┗
After exporting it to LaTeX, answering yes to the question about allowing to
BIND variables:
┏
┃ org-export-latex-tag-markup is a variable defined in `org-latex.el'.
┃ Its value is bound: \\fbox{%s}
┃ Original value was \\textbf{%s}
┃ Local in buffer examplebug.org; global value is
┃ what is in my Emacs config file
┗
So, yes to your above question...
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Variable settings in .emacs VS cross device portability.
Eric S Fraga e.fr...@ucl.ac.uk wrote: Hello all, herewith is a minimal example that illustrates the problem I have with exporting and file local variables. The attached file re-defines org-export-latex-tag-markup to use a box instead of bold for tags. When I visit the file, Emacs does indeed set the variable to what I want. However, this setting is ignored on export. Actually, in this case, the BIND is also ignored on export even though the variable does change to the specified value after export! I am very confused, to say the least. *How* can I get file local behaviour when exporting with org? Am I doing something silly somewhere? (highly likely given my past track record ;-) Do others see different behaviour? Good question (I mean the *How* question): I believe this is a bug and it has to do with the problem that Dan Davison identified and (as it turns out) partially fixed a year ago (see http://thread.gmane.org/gmane.emacs.orgmode/35439/focus=36878 for those details). In a nutshell, the problem is that many export operations happen in temporary buffers. These buffers do not automatically inherit local variables, so the global setting is in force. Dan introduced a clone local variables function and arranged for it to be called in org-export-preprocess-string. However, the latter function operates on a temp buffer, so when it returns (it returns the contents of the temp buffer as as a string), the buffer is gone - and so are the local variables. The latex exporter then continues mucking around with the returned string. The org-export-latex-markup variable is used in the function org-export-latex-keywords-maybe. At the relevant moment, the call stack looks like this: , | org-export-latex-keywords-maybe() | org-export-latex-fontify-headline(#( Formatting tags :example: 1 16 ...)) | org-export-latex-subcontent(...) | org-export-latex-sub(...) | org-export-latex-global(...) | (let* (...) (set-buffer buffer) (erase-buffer) (org-install-letbind) ... (org-export-latex-global (with-temp-buffer (insert string-for-export)) ...) ...) | org-export-as-latex(nil nil nil *Org LaTeX Export*) | org-export-as-latex-to-buffer(nil) | call-interactively(org-export-as-latex-to-buffer) ` Note that org-export-latex-global is called with a temp buffer and neither it nor any of its successors clones local variables. So you end up in org-export-latex-keywords-maybe with the global settings in force. The quick-and-dirty hack would be to call Dan's cloning function in the call to with-temp-buffer, but that's not enough: org-export-latex-fontify-headline does the temp-buffer thingie as well and needs the same treatment. That seems to make *this* case work but I'm almost 100% sure that that won't be enough in the general case either: there are probably other places where temp buffers are created to do some processing like this. They will also be subject to this problem. Nick I'm up to date (as of this morning) with org and latest emacs as of last week. Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.285.g646b3)
Re: [O] Variable settings in .emacs VS cross device portability.
Eric Schulte eric.schu...@gmx.com writes: [...] File Local Variables [1] make it possible to explicitly specify the values of variables from within the text of a .org file. This can be placed in a single line at the top of a file for small changes or in a larger section at the end of the file. Eric, this doesn't always seem to work, at least not for me. BIND always works but certain org variables seem to be ignored when set using local file variables. The variables I refer to are often, maybe always (?), related to export functions. My gut feeling is that this has something to do with a copy of the file being made for the export and maybe emacs not getting a chance to set local variables for that copy? Grasping at straws here, mind you ;-) I have no idea how to debug such behaviour but I have experienced this for a long time now. Any hints would be welcome, of course! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.283.g171ea)
[O] Variable settings in .emacs VS cross device portability.
Hello! I was wondering if there is a possibility to make org-files fully portable in behaviour (especially when exporting) between different emacs installations. When reading the mailing list or other writing about org-mode, commonly suggestions of the type just add (setq org-foo bar) to your .emacs. This however creates a dependency on the local setup of the variables, which likely will be a problem, when sharing the file with someone. My current solution is to use a template file with #+BIND: and #+PROPERTY: lines in a setup section rather than setting anything in configuration files. However, is there some way to turn a user-variable dependent file into a portable file? I was thinking of something along the lines of dumping user-specified variables into a list of #+BIND lines and, if necessary, the magic -*- var: value -*- line at the start of the file (or, less elegant because of spreading options across different positions in the file) the commented local variables structure near the end of the file. The latter two variants only apply if I am right about #+BIND lines applying only during export (whereas the magic emacs lines should create buffer-local bindings). king regards, Yu
Re: [O] Variable settings in .emacs VS cross device portability.
Yu yu_...@gmx.at writes: Hello! I was wondering if there is a possibility to make org-files fully portable in behaviour (especially when exporting) between different emacs installations. When reading the mailing list or other writing about org-mode, commonly suggestions of the type just add (setq org-foo bar) to your .emacs. This however creates a dependency on the local setup of the variables, which likely will be a problem, when sharing the file with someone. My current solution is to use a template file with #+BIND: and #+PROPERTY: lines in a setup section rather than setting anything in configuration files. However, is there some way to turn a user-variable dependent file into a portable file? I was thinking of something along the lines of dumping user-specified variables into a list of #+BIND lines and, if necessary, the magic -*- var: value -*- line at the start of the file (or, less elegant because of spreading options across different positions in the file) the commented local variables structure near the end of the file. The latter two variants only apply if I am right about #+BIND lines applying only during export (whereas the magic emacs lines should create buffer-local bindings). Aloha Yu, I favor Eric Schulte's solution for reproducible research, which you can find here: http://www.jstatsoft.org/v46/i03 The trick is to launch a fresh instance of Emacs and supply it with an initialization file tailored to the content. Eric uses a Makefile for this, and I've been able to copy and tweak his Makefile for use on other projects. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Variable settings in .emacs VS cross device portability.
Yu yu_...@gmx.at writes: Hello! I was wondering if there is a possibility to make org-files fully portable in behaviour (especially when exporting) between different emacs installations. File Local Variables [1] make it possible to explicitly specify the values of variables from within the text of a .org file. This can be placed in a single line at the top of a file for small changes or in a larger section at the end of the file. Cheers, When reading the mailing list or other writing about org-mode, commonly suggestions of the type just add (setq org-foo bar) to your .emacs. This however creates a dependency on the local setup of the variables, which likely will be a problem, when sharing the file with someone. My current solution is to use a template file with #+BIND: and #+PROPERTY: lines in a setup section rather than setting anything in configuration files. However, is there some way to turn a user-variable dependent file into a portable file? I was thinking of something along the lines of dumping user-specified variables into a list of #+BIND lines and, if necessary, the magic -*- var: value -*- line at the start of the file (or, less elegant because of spreading options across different positions in the file) the commented local variables structure near the end of the file. The latter two variants only apply if I am right about #+BIND lines applying only during export (whereas the magic emacs lines should create buffer-local bindings). king regards, Yu Footnotes: [1] http://www.gnu.org/software/emacs/manual/html_node/emacs/Specifying-File-Variables.html -- Eric Schulte http://cs.unm.edu/~eschulte/
