[O] Mobile org - add new items to org file
My org file on my computer is gtd.org which has 3 top level headings: * Tasks, * Projects and * Read and Review. If I add any entry to mobile org, sync it via dropbox and do a org-mobile-pull from my computer, the new entries go to a file called flagged.org. Is there any way to make the new entries go to my gtd.org file instead? Also: would it be possible to define where in gtd.org file the new entries should go, like some new entries should go under Tasks and some should go under Projects. Thanks.
Re: [O] Portable formatting of export?
Hi Klaus, Klaus-Dieter Bauer bauer.klaus.die...@gmail.com writes: This left me wondering however, if it is possible to create org files that will produce the same output on every machine, regardless of the local emacs customizations (of course assuming that no hacks of the export engine are part of the configuration). The authority on fully reproducible exports on this list is Thomas S. Dye. You might be able to find his posts searching for Aloha. I believe he has a per-project .el file with settings. You could also have settings in a Babel emacs-lisp block. I do that sometimes. Then use e.g. org-babel-load-file. In order to make the files more portable I have been trying to make changes affecting export with things like #+LATEX_HEADER: but e.g. changing the documentclass to scrartcl seems to be possible only by changing a customization variable (org-latex-classes). Customizatoins through org-latex-classes are a lot more comfortable than adding all those LaTeX headers IMO. Is it possible to make the export engine assume defaults for all customization variables for a file (preferably through an in-file setting) and to specify those customization inside the file? Yes. And you can always check that it works as expected with emacs -q. –Rasmus -- May the Force be with you
Re: [O] [RFC] Change some defcustoms into defcont
Dear Nicolas, On Oct 21, 2013, at 5:15 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Carsten Dominik carsten.domi...@gmail.com writes: The documentation of defconst says: Define SYMBOL as a constant variable. This declares that neither programs nor users should ever change the value. This constancy is not actually enforced by Emacs Lisp, but SYMBOL is marked as a special variable so that it is never lexically bound. So it is pretty clear about the intent of such a definition, which is to never change it - even though it does not enforce it. I must have been clear as mud, because that's exactly what I'm suggesting since the beginning of this thread: set DEADLINE and al. in stone, and never change them again. You also said things like That's exactly the point of the defconst: you can still modify the variable, but it sends a strong message to the user. Also, it's not about deprecation: code base should still rely on these variables. so maybe I picked one interpretation over the other. I have been pointing out, though, that it would not break previous changes if they were done with `setq', according to how defconst are handled. But I never intended to make it a feature, nor did I suggest that was desirable. As you have said, we still want to allow users in principle to change these variables. No, I haven't said such a thing. I said, verbatim, In principle, they mustn't be changed, which means quite the contrary. They have been defcustoms in the past, some people will have changed them. Their setup will break when they switch to a new version. Indeed. But that's easy to fix programmatically. That is why I object to changing their status. I think it causes unnecessary breakage, and we can prevent this by keeping them defcustom. Nothing is really gained by changing their status. It fixes at least a bug, prevents headaches by simplifying maintenance, makes Org syntax more portable and more cache friendly. I wouldn't call that nothing. Yes, sorry. By nothing I mean nothing we cannot achieve with documentation and a :set method. Since we will still rely on the variables, the advantage for maintenance is something I do not see. Cache friendliness I see, but I would think that if someone changes these variables, they will not keep changing them. Anyway, I have well understood that you don't want to change their status. So be it. OK, thank you. Regards - Carsten
[O] trying to write a guidebook for students using org , need help with formating
Hi all i decided to dive into the deep water and get rid of M$ word once and for all. I'm still an org novice but since i love org i choose org for the task. I'm trying to write a simple guidebook for my students in a GIS course. Everything works great apart for the life of me i cant get the hang of formatting and specifically how to insert (automatically?) line breaks so that its discrete lines and not a paragraph. i think one can use '\\' to indicate a line break but since its a guidebook form there are almost no paragraphs and most line are 1 liners, so it seems to me crazy to go over hundred lines of text and attach a \\ at the end. What am i missing here? i hope i made sense :) any help or documentation links would be really appreciated! I'm attaching a short example of my org file, note that where i want single lines i add a empty space between lines but still in the exporter it creates a paragraph out of these lines thx alot Z. ex_l1.1.org Description: Binary data
Re: [O] Bug: verbatim export of python code block with numpy array returns wrong value [8.2.1 (8.2.1-10-g9c1ef6-elpaplus @ /Users/sbagley/Dropbox/emacsd/elpa/org-plus-contrib-20131014/)]
Eric Schulte schulte.e...@gmail.com writes: Hi Steve, Is this a Python problem or is it numpy specific? Is repr() a numpy or a Python function i.e., could it replace str() in every Python code block or only when numpy is loaded? repr is a Python-thing and it's main feature, I guess, is eval(repr(object)) == object cf. below. So e.g. In [1]: import numpy as np In [2]: repr(np.array([1,2,3])) Out[2]: 'array([1, 2, 3])' In [3]: str(np.array([1,2,3])) Out[3]: '[1 2 3]' I'm not sure convinced that repr is necessarily better, tho. Here's the docstrings. In [4]: str? Type: type String Form:class 'str' Namespace: Python builtin Docstring: str(object='') - str str(bytes_or_buffer[, encoding[, errors]]) - str Create a new string object from the given object. If encoding or errors is specified, then the object must expose a data buffer that will be decoded using the given encoding and error handler. Otherwise, returns the result of object.__str__() (if defined) or repr(object). encoding defaults to sys.getdefaultencoding(). errors defaults to 'strict'. In [5]: ?repr Type: builtin_function_or_method String Form:built-in function repr Namespace: Python builtin Docstring: repr(object) - string Return the canonical string representation of the object. For most object types, eval(repr(object)) == object. –Rasmus -- Got mashed potatoes. Ain't got no T-Bone. No T-Bone
Re: [O] trying to write a guidebook for students using org , need help with formating
Xebar Saram zelt...@gmail.com writes: Hi all i decided to dive into the deep water and get rid of M$ word once and for all. I'm still an org novice but since i love org i choose org for the task. I'm trying to write a simple guidebook for my students in a GIS course. Everything works great apart for the life of me i cant get the hang of formatting and specifically how to insert (automatically?) line breaks so that its discrete lines and not a paragraph. i think one can use '\\' to indicate a line break but since its a guidebook form there are almost no paragraphs and most line are 1 liners, so it seems to me crazy to go over hundred lines of text and attach a \\ at the end. What am i missing here? Hi there, I've never used this, but I think `org-export-preserve-breaks' is the option you want. Try setting it in a single buffer with #+OPTIONS: \n:nil and see what happens... Eric
Re: [O] trying to write a guidebook for students using org , need help with formating
Xebar Saram zelt...@gmail.com writes: Hi all i decided to dive into the deep water and get rid of M$ word once and for all. I'm still an org novice but since i love org i choose org for the task. I'm trying to write a simple guidebook for my students in a GIS course. Everything works great apart for the life of me i cant get the hang of formatting and specifically how to insert (automatically?) line breaks so that its discrete lines and not a paragraph. i think one can use '\\' to indicate a line break but since its a guidebook form there are almost no paragraphs and most line are 1 liners, so it seems to me crazy to go over hundred lines of text and attach a \\ at the end. What am i missing here? Hi there, My quick fix for this was to save a macro and then bind it to a key. From init.el Saved macros ;; Saved macro - adds latex end-lines to verse passages (fset 'versify [?\C-a ?\C-e ?\\ ?\\ down]) (global-set-key (kbd s-v) 'versify) I can fix a lot of lines very quickly with this :-) atb Glyn
Re: [O] exclude certain tags from inheritance
Hi, Try setting org-use-tag-inheritance to ^[@#] Yours, Christian David Belohrad writes: Could someone help me to construct the expression such, that all tags starting with @ or # will be excluded from inheritance? many thanks .d.
Re: [O] trying to write a guidebook for students using org , need help with formating
On Tue, Oct 22, 2013 at 09:55:12AM +0200, Xebar Saram wrote: I'm trying to write a simple guidebook for my students in a GIS course. Everything works great apart for the life of me i cant get the hang of formatting and specifically how to insert (automatically?) line breaks so that its discrete lines and not a paragraph. i think one can use '\\' to indicate a line break but since its a guidebook form there are almost no paragraphs and most line are 1 liners, so it seems to me crazy to go over hundred lines of text and attach a \\ at the end. What am i missing here? i hope i made sense :) any help or documentation links would be really appreciated! I'm attaching a short example of my org file, note that where i want single lines i add a empty space between lines but still in the exporter it creates a paragraph out of these lines I think you are better off trying to do this with a specialised LaTeX class. A quick search led me to this TeX.SX question: http://tex.stackexchange.com/q/3852. You could also try using lists, just disable the bullets with an option in an #+attr_latex line. GL, -- Suvayu Open source is the future. It sets us free.
Re: [O] [RFC] Change some defcustoms into defcont
Hello, You also said things like That's exactly the point of the defconst: you can still modify the variable, but it sends a strong message to the user. Also, it's not about deprecation: code base should still rely on these variables. so maybe I picked one interpretation over the other. I don't see any contradiction. You can modify a defconst, but the strong message is you are not supposed to do that. I didn't suggest modifying these variables was expected. Anyway, I acknowledge I wasn't very clear. Yes, sorry. By nothing I mean nothing we cannot achieve with documentation and a :set method. This will not fix the bug. Since we will still rely on the variables, the advantage for maintenance is something I do not see. As a developer, you have to keep in mind that the string might be changed. Sometimes, it's easy to forget you cannot hardcode it, e.g. when writing a search regexp. I have done a similar mistake in ox-taskjuggler.el, where I expect the effort property to be named :EFFORT:. More things to remember, more potential bugs, more maintenance efforts. Cache friendliness I see, but I would think that if someone changes these variables, they will not keep changing them. Of course. I shouldn't have talked about cache since it makes me sound like a lazy person. I can work around the cache problem. Again my main concern was to move to a proper, Emacs-independent, /minimal/ core syntax, i.e., to define the Org format. For example, at the moment, external tools cannot rely on SCHEDULED: string to write even a basic Org file, because SCHEDULED: doesn't clearly belong to the syntax and, therefore, might be incompatible with some configurations. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Change some defcustoms into defcont
On Oct 22, 2013, at 11:52 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, You also said things like That's exactly the point of the defconst: you can still modify the variable, but it sends a strong message to the user. Also, it's not about deprecation: code base should still rely on these variables. so maybe I picked one interpretation over the other. I don't see any contradiction. You can modify a defconst, but the strong message is you are not supposed to do that. I didn't suggest modifying these variables was expected. Anyway, I acknowledge I wasn't very clear. Yes, sorry. By nothing I mean nothing we cannot achieve with documentation and a :set method. This will not fix the bug. Hi Nicolas, can you remind me what the bug was? The taskjuggler issue? Since we will still rely on the variables, the advantage for maintenance is something I do not see. As a developer, you have to keep in mind that the string might be changed. Sometimes, it's easy to forget you cannot hardcode it, e.g. when writing a search regexp. I have done a similar mistake in ox-taskjuggler.el, where I expect the effort property to be named :EFFORT:. More things to remember, more potential bugs, more maintenance efforts. Cache friendliness I see, but I would think that if someone changes these variables, they will not keep changing them. Of course. I shouldn't have talked about cache since it makes me sound like a lazy person. I can work around the cache problem. Again my main concern was to move to a proper, Emacs-independent, /minimal/ core syntax, i.e., to define the Org format. For example, at the moment, external tools cannot rely on SCHEDULED: string to write even a basic Org file, because SCHEDULED: doesn't clearly belong to the syntax and, therefore, might be incompatible with some configurations. Yes, as I said, I do see all these problems, but I also feel the responsibility to break as few as possible existing configurations. If you want, I can take a shot at documenting this properly. - Carsten Regards, -- Nicolas Goaziou
Re: [O] exclude certain tags from inheritance
Hi Christinan, thanks for hint. That one i've tested as first. doing (setq org-use-tag-inheritance ^[@#]) surprisingly, it does not do the expected stuff and all @xxx tags are still exported to the branches, where they are not supposed to be. At the same time I've tested this: (setq org-tags-exclude-from-inheritance '( @Adrian @LiShu@Martin)) and this one perfectly does the job when org-use-tag-inheritance is set to true. Trouble with this one is, that @ is basically followed by a name, and with every new name I have to for the moment manually add an item into exclude .d. Christian Moe m...@christianmoe.com writes: Hi, Try setting org-use-tag-inheritance to ^[@#] Yours, Christian David Belohrad writes: Could someone help me to construct the expression such, that all tags starting with @ or # will be excluded from inheritance? many thanks .d.
Re: [O] Create sub-directories and files from within org
On Mon, Oct 21, 2013 at 9:10 PM, John Kitchin jkitc...@andrew.cmu.edu wrote: You can do something like this: Neat! I will give it a shot. I might also try to incorporate it into a capture template.
Re: [O] trying to write a guidebook for students using org , need help with formating
Thank you all I think `org-export-preserve-breaks' is the option you want. Try setting it in a single buffer with #+OPTIONS:\n:nil and see what happens... that sounds interesting, but i couldn't understand how to use it (again im still an org novice:) ) do i stick this line at the start: #+OPTIONS:\n:nil is that ^^ syntax correct? best Z On Tue, Oct 22, 2013 at 12:39 PM, Suvayu Ali fatkasuvayu+li...@gmail.comwrote: On Tue, Oct 22, 2013 at 09:55:12AM +0200, Xebar Saram wrote: I'm trying to write a simple guidebook for my students in a GIS course. Everything works great apart for the life of me i cant get the hang of formatting and specifically how to insert (automatically?) line breaks so that its discrete lines and not a paragraph. i think one can use '\\' to indicate a line break but since its a guidebook form there are almost no paragraphs and most line are 1 liners, so it seems to me crazy to go over hundred lines of text and attach a \\ at the end. What am i missing here? i hope i made sense :) any help or documentation links would be really appreciated! I'm attaching a short example of my org file, note that where i want single lines i add a empty space between lines but still in the exporter it creates a paragraph out of these lines I think you are better off trying to do this with a specialised LaTeX class. A quick search led me to this TeX.SX question: http://tex.stackexchange.com/q/3852. You could also try using lists, just disable the bullets with an option in an #+attr_latex line. GL, -- Suvayu Open source is the future. It sets us free.
Re: [O] exclude certain tags from inheritance
David Belohrad da...@belohrad.ch writes: Hi Christinan, thanks for hint. That one i've tested as first. doing (setq org-use-tag-inheritance ^[@#]) That should probably be (setq org-use-tag-inheritance ^[^@#]) (i.e. anything *not* starting with @ or #). Untested. Nick surprisingly, it does not do the expected stuff and all @xxx tags are still exported to the branches, where they are not supposed to be. At the same time I've tested this: (setq org-tags-exclude-from-inheritance '( @Adrian @LiShu@Martin)) and this one perfectly does the job when org-use-tag-inheritance is set to true. Trouble with this one is, that @ is basically followed by a name, and with every new name I have to for the moment manually add an item into exclude .d. Christian Moe m...@christianmoe.com writes: Hi, Try setting org-use-tag-inheritance to ^[@#] Yours, Christian David Belohrad writes: Could someone help me to construct the expression such, that all tags starting with @ or # will be excluded from inheritance? many thanks .d. -- Nick
Re: [O] exclude certain tags from inheritance
Hei, Oops, sorry, a circumflex too few. Try: ^[^@#] - matches only strings whose first character is not @ or #. Yours, Christian David Belohrad writes: Hi Christinan, thanks for hint. That one i've tested as first. doing (setq org-use-tag-inheritance ^[@#]) surprisingly, it does not do the expected stuff and all @xxx tags are still exported to the branches, where they are not supposed to be. At the same time I've tested this: (setq org-tags-exclude-from-inheritance '( @Adrian @LiShu@Martin)) and this one perfectly does the job when org-use-tag-inheritance is set to true. Trouble with this one is, that @ is basically followed by a name, and with every new name I have to for the moment manually add an item into exclude .d. Christian Moe m...@christianmoe.com writes: Hi, Try setting org-use-tag-inheritance to ^[@#] Yours, Christian David Belohrad writes: Could someone help me to construct the expression such, that all tags starting with @ or # will be excluded from inheritance? many thanks .d.
[O] [BUG] Exporting to HTML a document with a #+CALL
Hello, I have to ask again about this issue: the following example document 8 * Function definition #+NAME: simp-func #+BEGIN_SRC emacs-lisp :var name=My name is... (format [You passed data] %S name) #+END_SRC * This is title of first section Call me: #+CALL: simp-func() 8 is not exported to HTML with message in minibuffer #+BEGIN_EXAMPLE Marker points into wrong buffer: #marker in no buffer #+END_EXAMPLE Org version: Org-mode version 8.2.1 (release_8.2.1-113-ga24775 @ /usr/share/emacs/site-lisp/org/) Emacs version: GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.2) of 2013-10-22 on smoon3 (actually it is emacs compiled from bzr trunk revno 114741) Emacs is started in following way emacs -Q --eval (add-to-list 'load-path \/usr/share/emacs/site-lisp/org\) --eval (require 'org) --eval (require 'ox-html) ex-call3.org (ex-call3.org is the name of example document). --- WBR, Vladimir Lomov. -- A lost ounce of gold may be found, a lost moment of time never.
Re: [O] [BUG] Exporting to HTML a document with a #+CALL
This issue only manifests with the Emacs compiled from source, and as such I can not reproduce it. If this bug makes it into a released version of Emacs I can address it then. Until then perhaps this should be reported to the emacs-dev list. Best, Vladimir Lomov lomov...@gmail.com writes: Hello, I have to ask again about this issue: the following example document 8 * Function definition #+NAME: simp-func #+BEGIN_SRC emacs-lisp :var name=My name is... (format [You passed data] %S name) #+END_SRC * This is title of first section Call me: #+CALL: simp-func() 8 is not exported to HTML with message in minibuffer #+BEGIN_EXAMPLE Marker points into wrong buffer: #marker in no buffer #+END_EXAMPLE Org version: Org-mode version 8.2.1 (release_8.2.1-113-ga24775 @ /usr/share/emacs/site-lisp/org/) Emacs version: GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.2) of 2013-10-22 on smoon3 (actually it is emacs compiled from bzr trunk revno 114741) Emacs is started in following way emacs -Q --eval (add-to-list 'load-path \/usr/share/emacs/site-lisp/org\) --eval (require 'org) --eval (require 'ox-html) ex-call3.org (ex-call3.org is the name of example document). --- WBR, Vladimir Lomov. -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Portable formatting of export?
There are several problems with this approach: 1. In order to force default behaviour, I'd have to set ALL customization variables of org explicitly (can be avoided by using an emacs -q session for compiling). 2. Even setting just a single setting can be very verbose (e.g. when defining a new document class). 3. The variables are not flagged as safe for use as file-local variables, requiring extra user-interaction whenever the file is visited. Sure, those are all mere convenience issues, but they add up to enough potential inconvenience for cooperative authoring (i.e. the file being edited in different emacs configurations by different people) to make direct latex editing rather attractive. Is that scenario simply outside the scope of org-mode? - Klaus-Dieter Bauer 2013/10/21 Eric Schulte schulte.e...@gmail.com This can be done with file local variables. See the following page of the Emacs manual. (info (emacs)Specifying File Variables) Klaus-Dieter Bauer bauer.klaus.die...@gmail.com writes: Hello! I have customized org export to both html and latex extensively since I disliked many of the defaults (e.g. the use of article vs scrartcl, red borders around pdf hyperlinks). This left me wondering however, if it is possible to create org files that will produce the same output on every machine, regardless of the local emacs customizations (of course assuming that no hacks of the export engine are part of the configuration). In order to make the files more portable I have been trying to make changes affecting export with things like #+LATEX_HEADER: but e.g. changing the documentclass to scrartcl seems to be possible only by changing a customization variable (org-latex-classes). Is it possible to make the export engine assume defaults for all customization variables for a file (preferably through an in-file setting) and to specify those customization inside the file? - Klaus -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Org-mode and continuing BBDB compatibility
Nick Dokos ndo...@gmail.com writes: Christopher Culver crcul...@christopherculver.com writes: I am using org-mode version 20131021 and the latest checkout of the bbdb3 git repository. Although I have the following lines in my main .org file: * Anniversaries :PROPERTIES: :CATEGORY: Anniv :END: %%(org-bbdb-anniversaries) I do not see anniversaries from my .bbdb file in the agenda. I know that some work was done in the past with making org-mode compatible with bbdb3, but are the two projects no longer compatible, or do I probably have some other problem on my end? I believe the %% construct is recognized only at the beginning of a line: try deleting the white space in front. Thanks, that did the trick. I can now see BBDB anniversaries in my agenda. Christopher Culver
[O] Setting default browser for export b on Win7
I am trying to set Firefox as the default browser on my Windows 7 machine. Here is the elisp code that modifies org-file-apps (defun mv-org-set-export-browser (browser) (setq org-file-apps (mapcar (lambda (entry) (if (string= (car entry) \\.x?html?\\') (cons (car entry) (if (equal browser 'default) browser (format %s %s browser %s))) entry)) org-file-apps))) I call it like this: (mv-org-set-export-browser 'default ;;firefox ;;c:/Program Files (x86)/Mozilla Firefox/firefox.exe ) The two commented lines are when I try to set firefox as the browser. But with either of them, I get no visible output. I don't see anything in *Messages*. (Thus the 'default is uncommented). I know the full path to work, as it is the same string that is used to specify the default browser for opening URL's. Any ideas on what is going wrong? Thanks, Mirko
Re: [O] Ox-HTML hover for certain languages
On 2013-10-21 19:28, R. Michael Weylandt michael.weyla...@gmail.com wrote: Around line 270 of Ox-html.el, there's CSS which gives certain code blocks in the resulting HTML a hover-over window saying what language they encode. Not all Babel-supported languages appear however: is there any reason for this? (E.g. perl is hard-coded but no python) Never noticed that before. IMHO, it's ugly and broken in a number of browser which don't handle the content attribute very well (firefox on solaris and IE 8 are bad for different reasons, looks ok on Chrome) and should be removed entirely instead of trying to keep up w/ babel. I can't say why the list is limited to the specific set of languages, but since this is part of a defconst for the default inline styles, it pretty much needs to be hard-coded. Note that you can easily add other languages via `html-head-extra'. I've been thinking about how to cleanup the whole inine css/javascript thing since it makes for bloated (but standalone) html documents, and in the case of inline css, is broken in batch export due to the use of htmlize (see `org-html-html-htmlize-output-type'). rick
Re: [O] trying to write a guidebook for students using org , need help with formating
On 2013-10-22 03:55, Xebar Saram wrote: Hi all i decided to dive into the deep water and get rid of M$ word once and for all. I'm still an org novice but since i love org i choose org for the task. I'm trying to write a simple guidebook for my students in a GIS course. Everything works great apart for the life of me i cant get the hang of formatting and specifically how to insert (automatically?) line breaks so that its discrete lines and not a paragraph. i think one can use '\' to indicate a line break but since its a guidebook form there are almost no paragraphs and most line are 1 liners, so it seems to me crazy to go over hundred lines of text and attach a \ at the end. What am i missing here? I think you are thinking about this in the wrong (microsoft word :) way: format vs. semantic structure. A series of steps should either be a list, or an example block. For instance in your sample, try: #+BEGIN_EXAMPLE Right click on the table name in the TOC panel – Table of Contents and then chose Display XY data; Define the X,Y coordinate and data (Z) fields; Click Edit to define the coordinate system (use WGS84); Click OK; Right click on the event layer newly created, go to data-export data, specify a location and give the layer a name [remember: events are a temporary layer, unless you save it as a shape file, it will disappear and you will not be able to use it next time]; add it a s new layer to your project, when asked. #+END_EXAMPLE or (since the lines above are too long to fit w/o truncating or wrapping, - Right click on the table name in the TOC panel – Table of Contents and then chose Display XY data; - Define the X,Y coordinate and data (Z) fields; - Click Edit to define the coordinate system (use WGS84); - Click OK; - Right click on the event layer newly created, go to data-export data, specify a location and give the layer a name [remember: events are a temporary layer, unless you save it as a shape file, it will disappear and you will not be able to use it next time]; add it a s new layer to your project, when asked. Think about the contents semantically (e.g., something is descriptive text, or a series of steps, or a code example), instead of how you think it should look and let org and latex may it look right. rick
Re: [O] Portable formatting of export?
Aloha Klaus,
IIUC, you are describing a setup that can also be described as
reproducible research. The idea behind reproducible research is to have
a stand-alone Org file that exactly reproduces the analysis reported in
a scientific paper, then prepares a copy of the document submitted for
publication. The Org file is meant to be distributed and so must be
capable of carrying out these tasks on any Emacs, regardless of the
end-user's setup.
It was possible to do this with Org mode 8.0, but with version 8.0 and
the new exporter framework, the approach changed and became somewhat
easier to accomplish. The key change was asynchronous export, which
internalized a mechanism for launching a new emacs process (the famous
emacs -q) that is responsible for export. A reproducible research paper
finds a way to configure asynchronous export that can be saved in the
Org file and distributed as part of the reproducible research.
One way to do this is with a babel emacs-lisp source code block that
contains the necessary configuration and that the end-user can tangle to
an initialization file that is read by the asynchronous export process.
My own work is geared to producing pdf files and I haven't worked much
with html, though I imagine the process would be similar.
Below, I've included an init file in progress--one that works for me,
but isn't yet fully reproducible, at least because paths are hard-coded
and I haven't yet spent the time to make them fully portable. My goal
with this init file is to meet a specification established by the
journal PLOS-One, so I've had to abandon the default packages used by
Org and load the packages specified by the journal.
The noweb parts implement editing conventions that I use, but aren't
strictly necessary for the reproducible research.
In practice, the user tangles the initialization file in preparation for
asynchronous export. For convenience, in a no-export section at the top
of the file, I have:
#+call: tangle-init-file()
** Export setup :noexport:
#+name: tangle-init-file
#+header: :results silent
#+begin_src emacs-lisp
(org-babel-tangle)
#+end_src
#+name: export-setup-plos-one
#+header: :noweb yes
#+header: :results silent
#+header: :tangle init-plos.el
#+begin_src emacs-lisp
(setq load-path (cons ~/.emacs.d/src/org-mode/lisp load-path))
(require 'ox-latex)
(org-babel-lob-ingest ~/org/td-lob.org)
(setq org-confirm-babel-evaluate nil)
(org-babel-do-load-languages
'org-babel-load-languages
'((R . t)
(dot . t)
(emacs-lisp . t)
(latex . t)
(org . t)
(sh . t)))
user-entities
(setq org-latex-packages-alist nil)
(add-to-list 'org-latex-packages-alist '( setspace))
(add-to-list 'org-latex-packages-alist '( amsmath))
(add-to-list 'org-latex-packages-alist '( amssymb))
(add-to-list 'org-latex-packages-alist '( graphicx))
(add-to-list 'org-latex-packages-alist '( cite))
(add-to-list 'org-latex-packages-alist '( color))
(add-to-list 'org-latex-packages-alist '( setspace))
(add-to-list 'org-latex-packages-alist
'(labelfont=bf,labelsep=period,justification=raggedright caption))
(setq org-latex-pdf-process '(latexmk -pdf %f))
(setq org-latex-tables-booktabs nil)
(setq org-latex-title-command nil)
(setq org-latex-remove-logfiles nil)
(setq org-latex-toc-command \\tableofcontents\n\n)
(setq org-latex-classes nil)
(add-to-list 'org-latex-classes
'(plos-article
\\documentclass[10pt]{article}
[NO-DEFAULT-PACKAGES]
[PACKAGES]
[EXTRA]
\\doublespacing
% Text layout
\\topmargin 0.0cm
\\oddsidemargin 0.5cm
\\evensidemargin 0.5cm
\\textwidth 16cm
\\textheight 21cm
\\bibliographystyle{plos2009}
\\makeatletter
\\renewcommand{\\@biblabel}[1]{\\quad#1.}
\\makeatother
\\pagestyle{myheadings}
%% ** EDIT HERE **
%% ** EDIT HERE **
%% PLEASE INCLUDE ALL MACROS BELOW
\\newcommand{\\texttwosuperior}{$^{2}$}
\\newcommand{\\textpm}{$\\pm$}
\\newcommand{\\rc}{$^{14}C$}
%% END MACROS SECTION
(\\section{%s} . \\section*{%s})
(\\subsection{%s} . \\subsection*{%s})
(\\subsubsection{%s} . \\subsubsection*{%s})
(\\paragraph{%s} . \\paragraph*{%s})
(\\subparagraph{%s} . \\subparagraph*{%s})))
ngz-nbsp
tsd-textpm
define-cite-link
#+end_src
It is also necessary to set up the end-user's Emacs instance somewhat,
although this is intrusive and leaves the user with a different Emacs
instance, and one that might not be wanted. I want this part to be as
minimal as possible, so eventually will work to move as much of this as
possible to file-local variables along the lines suggested by Eric
Schulte earlier in this thread.
The one I'm working with at
[O] ebnf2ps for babel
I've had a play with adding babel support for ebnf2ps, to generate
railroad diagrams for a grammar.
I'd appreciate any comments on the attached code.
Would anyone else find this useful?
Kind Regards,
Mike Gauland
;;; ob-ebnf.el --- org-babel functions for ebnf evaluation
;; Copyright (C) your name here
;; Author: Michael Gauland
;; Keywords: literate programming, reproducible research
;; Homepage: http://orgmode.org
;; Version: 0.01
;;; License:
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 3, or (at your option)
;; any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING. If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.
;;; Commentary:
;;; Org-Babel support for using ebnf2ps to generate encapsulated postscript
;;; railroad diagrams. It recogises these arguments:
;;;
;;; :file is required; it must include the extension '.eps.' All the rules
;;; in the block will be drawn in the same file. This is done by
;;; inserting a '[file' comment at the start of the block (see the
;;; documentation for ebnf-eps-buffer for more information).
;;;
;;; :style specifies a value in ebnf-style-database. This provides the
;;;ability to customise the output. The style can also specify the
;;;gramnmar syntax (by setting ebnf-syntax); note that only ebnf,
;;;iso-ebnf, and yacc are supported by this file.
;;; Requirements:
;;; Code:
(require 'ob)
(require 'ob-ref)
(require 'ob-comint)
(require 'ob-eval)
(require 'ebnf2ps)
;; optionally declare default header arguments for this language
(defvar org-babel-default-header-args:ebnf '((:style . nil)))
;; Use ebnf-eps-buffer to produce an encapsulated postscript file.
;;
(defun org-babel-execute:ebnf (body params)
Execute a block of Ebnf code with org-babel. This function is
called by `org-babel-execute-src-block'
(save-excursion
(let* ((dest-file (cdr (assoc :file params)))
(dest-dir (file-name-directory dest-file))
(dest-root (file-name-sans-extension
(file-name-nondirectory dest-file)))
(dest-ext (file-name-extension dest-file))
(style (cdr (assoc :style params)))
(current-dir default-directory)
(result nil))
(with-temp-buffer
(when style (ebnf-push-style style))
(let
((comment-format
(cond ((string= ebnf-syntax 'yacc) /*%s*/)
((string= ebnf-syntax 'ebnf) ;%s)
((string= ebnf-syntax 'iso-ebnf) (*%s*))
(t (setq result
(format EBNF error: format %s not supported.
ebnf-syntax))
(setq ebnf-eps-prefix dest-dir)
(insert (format comment-format (format [%s dest-root)))
(newline)
(insert body)
(newline)
(insert (format comment-format (format ]%s dest-root)))
(ebnf-eps-buffer)
(when style (ebnf-pop-style
result
)))
(provide 'ob-ebnf)
;;; ob-ebnf.el ends here
#+TITLE: Org Babel EBNF Sample
#+AUTHOR:Michael Gauland
#+EMAIL: mikely...@amuri.net
#+DATE: {{{time(%Y-%m-%d %H:%M)}}}
#+LaTeX_CLASS: article
#+LaTeX_CLASS_OPTIONS: [a4paper]
#+LaTeX_HEADER: \usepackage{epstopdf}
#+LATEX_HEADER: \definecolor{mygray}{gray}{0.8}
#+LATEX_HEADER: \lstset{rulesepcolor=\color{mygray}}
#+LaTeX_HEADER:
\lstdefinelanguage{ebnf}{rulesepcolor=\color{cyan},frameround=,backgroundcolor=\color{mygray}}
#+PROPERTY: exports both
* EBNF
#+HEADER: :file (org-babel-temp-file ./temp .eps)
#+BEGIN_SRC ebnf
sequence = this that.
alternation = this | that.
#+END_SRC
#+RESULTS:
[[file:/tmp/babel-5910UgK/temp5910f9T.eps]]
* ISO-EBNF
#+HEADER: :file (org-babel-temp-file ./temp .eps)
#+HEADER: :style 'iso-ebnf
#+BEGIN_SRC ebnf
sequence = this, that;
alternation = this | that;
#+END_SRC
#+RESULTS:
[[file:/tmp/babel-5910UgK/temp5910S6B.eps]]
* YACC
#+HEADER: :file (org-babel-temp-file ./temp .eps)
#+HEADER: :style 'yacc
#+BEGIN_SRC ebnf
%%
sequence: 'this' 'that';
alternation: 'this' | 'that';
#+END_SRC
#+RESULTS:
[[file:/tmp/babel-5910UgK/temp5910Uun.eps]]
Re: [O] [RFC] Change some defcustoms into defcont
Hi, not being a dev and really not being a lisp programmer, I still can see Nicolas attempt to unify the syntax in a way all and everyone/everything can rely on it. The question would be what would be more troublesome? Dealing in future with people who by chance changed some of those variables and who suddenly face problems using third party (internal as well as external) tools. E.g., tools like org-ruby came to my mind. More and more projects start to include org-syntax too. For all those it would become difficult to rely on certain keywords. Or is it more problematic that those who changed variables already, might find there system broken / in need of manual adoption after an update? Anyhow, I just had this idea that org-mode could rely on a fixed (as written in stone) set of keywords and that an a new exporter backend will be introduced which simply creates a standard-conform org-mode file. Let's call it ox-legacy ;) Those created files could be send to others to work on it or could be used in conjunction with 3rd party programs. By time, one could think of a org-mode import, which again takes a standard conform org-mode file and translates it back into the individual settings of a specific user. Having an legacy org-mode exporter and importer, could even allow to customize org-mode for different languages, e.g. one could set (setq org-mode-language german) to get a set of keywords in German. Exporting it into legacy org-mode would translate it back into e.g. English, which then again could be read-in by a user who set (setq org-mode-language japanese) and who would be able to read the file with a set of Japanese keywords. Just an idea I had following this thread. All the best Torsten On 22 October 2013 12:34, Carsten Dominik drostekirs...@gmail.com wrote: On Oct 22, 2013, at 11:52 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, You also said things like That's exactly the point of the defconst: you can still modify the variable, but it sends a strong message to the user. Also, it's not about deprecation: code base should still rely on these variables. so maybe I picked one interpretation over the other. I don't see any contradiction. You can modify a defconst, but the strong message is you are not supposed to do that. I didn't suggest modifying these variables was expected. Anyway, I acknowledge I wasn't very clear. Yes, sorry. By nothing I mean nothing we cannot achieve with documentation and a :set method. This will not fix the bug. Hi Nicolas, can you remind me what the bug was? The taskjuggler issue? Since we will still rely on the variables, the advantage for maintenance is something I do not see. As a developer, you have to keep in mind that the string might be changed. Sometimes, it's easy to forget you cannot hardcode it, e.g. when writing a search regexp. I have done a similar mistake in ox-taskjuggler.el, where I expect the effort property to be named :EFFORT:. More things to remember, more potential bugs, more maintenance efforts. Cache friendliness I see, but I would think that if someone changes these variables, they will not keep changing them. Of course. I shouldn't have talked about cache since it makes me sound like a lazy person. I can work around the cache problem. Again my main concern was to move to a proper, Emacs-independent, /minimal/ core syntax, i.e., to define the Org format. For example, at the moment, external tools cannot rely on SCHEDULED: string to write even a basic Org file, because SCHEDULED: doesn't clearly belong to the syntax and, therefore, might be incompatible with some configurations. Yes, as I said, I do see all these problems, but I also feel the responsibility to break as few as possible existing configurations. If you want, I can take a shot at documenting this properly. - Carsten Regards, -- Nicolas Goaziou
Re: [O] [RFC] Change some defcustoms into defcont
Torsten Wagner torsten.wag...@gmail.com writes: Anyhow, I just had this idea that org-mode could rely on a fixed (as written in stone) set of keywords and that an a new exporter backend will be introduced which simply creates a standard-conform org-mode file. Well, I like the idea of an importer. Not so much because of keywords, but because org should work on text files and text files often work with different conventions (I still have muse files around and old org files where I used *this* for emphasis.) By time, one could think of a org-mode import, which again takes a standard conform org-mode file and translates it back into the individual settings of a specific user. This I would call export. Having an legacy org-mode exporter and importer, could even allow to customize org-mode for different languages, e.g. one could set (setq org-mode-language german) to get a set of keywords in German. Exporting it into legacy org-mode would translate it back into e.g. English, which then again could be read-in by a user who set (setq org-mode-language japanese) and who would be able to read the file with a set of Japanese keywords. The problem is, the exporter can only be used if org-element can parse the syntax, which is exactly what Nicolas wants to get rid of. Org-element clearly isn't intend to be a general parser. So an importer/preprocessor/old-new converter would have to be either a simple search and replace mechanism or do all the heavy lifting itself. Hm, if I'd have, say, an xml of lisp representation of the buffer (i.g. (ELEMENT (OPTIONS) ((ELEMENT (OPTIONS) ..., is there a way to hand that of to org-element or the exporter? -- Florian Beck
Re: [O] trying to write a guidebook for students using org , need help with formating
Xebar Saram zelt...@gmail.com writes: Thank you all I think `org-export-preserve-breaks' is the option you want. Try setting it in a single buffer with #+OPTIONS:\n:nil and see what happens... that sounds interesting, but i couldn't understand how to use it (again im still an org novice:) ) do i stick this line at the start: #+OPTIONS:\n:nil is that ^^ syntax correct? Nearly correct -- we're the victim of unfortunate line wrapping. It should look like: #+OPTIONS: \n:nil Ie, with an extra space. If you're a novice, as you say, you might like to see the default options template for exporting. In your org buffer, hit C-c C-e to get to the export dispatcher, then hit # for template insertion, then pick default. It will be a lot easier to see and edit existing options than type them all in by hand. Yours, Eric On Tue, Oct 22, 2013 at 12:39 PM, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Tue, Oct 22, 2013 at 09:55:12AM +0200, Xebar Saram wrote: I'm trying to write a simple guidebook for my students in a GIS course. Everything works great apart for the life of me i cant get the hang of formatting and specifically how to insert (automatically?) line breaks so that its discrete lines and not a paragraph. i think one can use '\\' to indicate a line break but since its a guidebook form there are almost no paragraphs and most line are 1 liners, so it seems to me crazy to go over hundred lines of text and attach a \\ at the end. What am i missing here? i hope i made sense :) any help or documentation links would be really appreciated! I'm attaching a short example of my org file, note that where i want single lines i add a empty space between lines but still in the exporter it creates a paragraph out of these lines I think you are better off trying to do this with a specialised LaTeX class. A quick search led me to this TeX.SX question: http://tex.stackexchange.com/q/3852. You could also try using lists, just disable the bullets with an option in an #+attr_latex line. GL, -- Suvayu Open source is the future. It sets us free.
[O] make new links show as figures?
Is it possible to define new links that would be rendered as inline images? I am imagining something like chemdraw:benzene.png which would show the benzene.png file inline, but when I click on it would open a chemdraw file for editing. John --- John Kitchin Associate Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu
