On 4/30/11 Apr 30 -5:14 PM, Eric S Fraga wrote: > Robert Goldman <rpgold...@sift.info> writes: > >> On 4/29/11 Apr 29 -1:21 PM, Nick Dokos wrote: > > [...] > >>> amsmath conflicts with wasysym (redefines \iint), so you have to >>> redefine your headers to omit wasysym or include amsmath *first*: for >>> some reason, if you \usepackage{amsmath} *before* you >>> \usepackage{wasysym}, the error does not arise -- presumably, amsmath >>> assumes that \iint is not defined beforehand, whereas wasysym does not >>> make that assumption. >> >> The not-very-tasty solution I came up with was to put the following into >> the local variables list at the foot of my file: >> >> # org-export-latex-default-packages-alist: (("AUTO" "inputenc" t) ("T1" >> "fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t) ("" "longtable" nil) >> ("" "float" nil) ("" "wrapfig" nil) ("" "soul" t) ("" "t1enc" t) ("" >> "textcomp" t) ("" "marvosym" t) ("" "amsmath" t) ("" "wasysym" t) ("" >> "latexsym" t) ("" "amssymb" t) >> ("colorlinks=true,pdfstartview=FitV,linkcolor=blue,citecolor=blue,urlcolor=blue" >> "hyperref" nil) "\\tolerance=1000") >> >> I put this in the file, rather than in my configuration, because it is >> specific to the formatting of this file, and because I share this >> document with others, who need to be able to export from it w/o having >> to reconfigure their org-mode installations. >> >> I figure that someone can probably suggest a solution that is nicer than >> that! >> >> Best, >> r > > From earlier this year on the mailing list, below is a solution > which works if you more often than not want amsmath; i.e. it's not a > solution for the use case you specify in which you want to share a > single file etc. However, it's worth repeating this solution for other > use cases.
Is there any documentation any where about how people use Org-mode in collaborative authoring? I find myself not on solid ground understanding how to ensure that my colleagues have the same configuration. For now, I resort to entries in the local variables list, but this may not be the best solution.... One could hijack the directory locals, but that seems like The Wrong Thing --- we should leave that to the individual user for his/her preferences. Possibly set up something that would be layered, so that there are dir-locals that optionally load user-specific settings /after/ the dir-locals (i.e., a second layer of dir-locals)? Is anyone else trying to do stuff like this? best, r