Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@gmail.com writes: The following patch should do that. It comes with tests, but it should be tested extensively, if only to know if this feature is as useful as it seems. Thanks a lot. I will not be online for the next 5 hours, but I'll think about this. -- Bastien
Re: [O] Bug: error enlighting file: [8.0-pre (release_8.0-pre-335-g4c426b-git @ org-loaddefs.el can not be found!)]
On Fri, Apr 12, 2013 at 02:24:21AM +0200, David Arroyo Menéndez wrote: current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) [...] org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) ) While submitting bug reports, could you please try with a minimal setup first? Otherwise the bug report becomes unnecessarily cluttered, and might be difficult to reproduce. For an example, please look in the manual, (info (org) Feedback). BTW, to others, is it by any chance possible to check how emacs was started (if -q or -Q was present among the command line options)? Then a message could be shown about minimal testing with a setup when users call `org-submit-bug-report'. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Org-mode as a replacement for Google Reader
Steinar Bang s...@dod.no writes: Karl Voit devn...@karl-voit.at: On the one hand, I do not have any Gnus experience It doesn't have to be Gnus. Any NNTP client will work with feeds on gwene. On the PC you could eg. use Thunderbird. and from the things I already read about Gnus configuration, I want to keep it that way. There is a big difference in what you _can_ do, and what you have to do. If you just want to read news with NNTP you basically only have to point it to at least one NNTP server (eg. gwene). On the other hand, Gnus does not offer something to sync with for the Android platform AFAIK. If you want a gwene reader for the android platform you will have to find an NNTP client for android. I don't know if there is one... well seems to be a couple: https://play.google.com/store/apps/details?id=ken.android.nntpreader.prohl=no There is, imho, one big difference between using google reader and gwene with any desktop news reader: as far as I know, you can not sync read items between ydifferent readers (desktops, mobile devices, tablets, ...). This is for me a problem, as I mainly read from my iPad, and sometimes friom my desktop. But I want to see only the news which I did not read on the other device. So something like an imap implementation for gwene would be needed to make it a *very* interesting solution for me. As it stands at the moment, I registered with feedly [1] which syncs with google reader (while it still exists) and provides very similar benefits. If I could sync my gnus (it is really not that difficult to get started, but much more difficult to not get carried away with configuring and tweaking - just because one can... But I love gnus: highly recommended) with my mobile device, I will stick with feedly. Cheers, Rainer #secure method=pgpmime mode=sign Footnotes: [1] http://www.feedly.com -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [PATCH 0/3] synctex support for pdf export
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Aaron Ecay aarone...@gmail.com writes:
This patch series is an attempt to add synctex support to org mode.
Thank you for your patch.
I have not tested this code extensively, but it does work for me. I
don't know if it works for async export or not, since I haven't set up
a working environment for that.
Async export works out of-the-box (though not optimized). There's no
special environment to set up.
There are currently limitations. The granularity of the jumping is
not great, because of the way the parser works. It will get you into
the paragraph corresponding to the PDF location, but no closer (with
pure latex, you will arrive at the exact line in the tex file). You
also have to run org-latex-patch-synctex manually, unless you use the
direct-to-pdf export option (C-c C-e l p). In regular latex, beamer
documents have somewhat degraded synctex granularity (in general, you
don't get to the exact source line, but only somewhere between
\begin{frame} and \end{frame}). This may be compounded by the bad
granularity of this patch -- I have not tested this combo very much.
[...]
As you notice, there are many limitations and I agree some of them will
be tedious to overcome. It also breaks asynchronous export.
Moreover, modifying both parser and core export framework for an
optional feature within a single back-end family is not right, IMO.
While I acknowledge the investment put into this patch, I won't accept
it in its current form. I might consider it if it only modifies
ox-latex.el, handles include keywords and buffer modifications through
Babel, and doesn't break asynchronous export. Not relying on text
properties is a real plus.
Though, don't push it too hard, I'm really not sure it's worth the
trouble.
Regards,
Hi Nicolas,
I understand all your points very well: Too heavy changes for an
optional and still feature-incomplete patch targeting a sub-group of users.
But the provided functionality would be really handy for everybody
who writes larger documents (like a thesis) with org-mode and has to
incorporate comments made to the pdf.
This feature has been asked for on this list
https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg01253.html
and on stackoverflow
http://stackoverflow.com/questions/9965049/how-to-use-synctex-with-org-mode
So I just want to contradict your last statement: IMO it's worth the
trouble to get this working in orgmode.
Best,
Andreas
Re: [O] Exploring org-element.el with navi-mode
Hello Thorsten, Thorsten Jolitz wrote: its now possible to use the new libraries for 'Org-mode outside Org-mode' (outshine, outorg, pop-org, navi-mode) on Emacs Lisp files that use the official header conventions (;;;+ ). Where are these official header conventions described? Best regards, Seb -- Sebastien Vauban
Re: [O] Exploring org-element.el with navi-mode
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hello Sebastien, Thorsten Jolitz wrote: its now possible to use the new libraries for 'Org-mode outside Org-mode' (outshine, outorg, pop-org, navi-mode) on Emacs Lisp files that use the official header conventions (;;;+ ). Where are these official header conventions described? There is a thread on emacs-devel with a discussion about the issue, describing the: - Lisp conventions for headlines (that appear surprisingly illogical and impractical) ,- | https://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00284.html `- - the Emacs Lisp conventions for headlines: ,- | https://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00266.html `- but the elisp manual seems to be out of date on this: ,- | https://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00305.html `- - and what I tend to use now and like best and thus proposed as alternative conventions (outcommented Org-mode headers): ,-- | ;; * level 1 | ;; ** level 2 `-- -- cheers, Thorsten
Re: [O] No definition for per-file basis in a source code block mode
On Mon, Apr 15, 2013 at 04:34:57PM +0800, Wolfkin Chiang wrote: Hi, All, While I try the per-file basis in a source code block mode, It tells me: No definition for class `per-file-class' in `org-export-latex-classes' Please help me to resolve it, thanks! (require 'org-latex) (require 'org-export-latex) The above is incorrect. It should be: (require 'ox-latex) Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] [PATCH 0/3] synctex support for pdf export
Hello, Andreas Leha writes: I understand all your points very well: Too heavy changes for an optional and still feature-incomplete patch targeting a sub-group of users. But the provided functionality would be really handy for everybody who writes larger documents (like a thesis) with org-mode and has to incorporate comments made to the pdf. This feature has been asked for on this list https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg01253.html and on stackoverflow http://stackoverflow.com/questions/9965049/how-to-use-synctex-with-org-mode So I just want to contradict your last statement: IMO it's worth the trouble to get this working in orgmode. I would happily use such a features. I write many presentations in org-mode, and I miss being able to simply click to go back to the right place in the buffer. Alan
Re: [O] org-outlook with Outlook 2010 on Windows 7
Am Donnerstag, 4. April 2013, 14:59:55 schrieb Per Per Kulseth Dahl: Hello, I have been trying to get org-outlook to work without any success. I am running Windows 7 and Outlook 2010. Yes, I wish didn't have to. I have put the VBA code generated by org-outlook-generate-vba into Outlook and then I changed the org-outlook-location to c:/Program Files (x86)/Microsoft Office/Office14/OUTLOOK.EXE in org-outlook.el. I didn't seem to work when I tried to change it through customize-group. I apparently get a link into an org document, but when click this link I get ShellExecute failed: w32 error 2147749890. Hi Per, did you get this solved? I'm interested, I get the same error after my PC at the office has been migrated to Outlook 2010 (Emacs 24.2, org-mode 7.9.4, Windows 7). Regards, Alexander I have set up org-protocol according to the Org Manual (http://orgmode.org/worg/org-contrib/org-protocol.html). I later came across this setup: http://denihow.com/can-i-create-a-link-to-a-specific-email-message-in-outloo k/ Which seems much simpler and looks to be sufficient for what I want, but this doesn't work either. It seems there is a problem with Dim doClipboard As New DataObject I have tried to search for help on VBA, that I have no prior experience with, for a clue as for what the problem is, but that has so far been a very frustrating experience. I am therefore hoping someone here has a working setup with Outlook 2010 and could point me in the right direction. I doesn't have to be with org-outlook, I just want have working links to Outlook messages in my org files. -- Cheers, Per
Re: [O] Exploring org-element.el with navi-mode
Thorsten Jolitz tjol...@gmail.com writes: - the Emacs Lisp conventions for headlines: ,- | https://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00266.html `- Also from within emacs : (info (elisp) Comment Tips) but the elisp manual seems to be out of date on this: ,- | https://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00305.html `- IMO the manual isn't out of date but simply more specific : headlines begin with regexp ;;;+ [^ ] i.e. exactly one space character. -- N.
Re: [O] org-outlook with Outlook 2010 on Windows 7
Am Montag, 15. April 2013, 13:57:37 schrieb AW AW: Am Donnerstag, 4. April 2013, 14:59:55 schrieb Per Per Kulseth Dahl: Hello, I have been trying to get org-outlook to work without any success. I am running Windows 7 and Outlook 2010. Yes, I wish didn't have to. I have put the VBA code generated by org-outlook-generate-vba into Outlook and then I changed the org-outlook-location to c:/Program Files (x86)/Microsoft Office/Office14/OUTLOOK.EXE in org-outlook.el. I didn't seem to work when I tried to change it through customize-group. I apparently get a link into an org document, but when click this link I get ShellExecute failed: w32 error 2147749890. Hi Per, did you get this solved? I'm interested, I get the same error after my PC at the office has been migrated to Outlook 2010 (Emacs 24.2, org-mode 7.9.4, Windows 7). Regards, Alexander OK, it was not that difficult. There seem to be many solutions. I'm satisfied with a simple one, discussed here: http://superuser.com/questions/71786/can-i-create-a-link-to-a-specific-email-message-in-outlook It was sufficient to change a line to meet the demands of the new outlook version: (w32-shell-execute open Path/to/OUTLOOK.EXE (concat /select outlook: id) -- stolen from a comment there.
Re: [O] minor bug in babel with silent output and remote R session
Hi all, Thomas Alexander Gerds t...@biostat.ku.dk writes: Hi Bastien I think that I can describe the problem a bit better now. It is not related to the silent option but occurs whenever :results value. Emacs freezes due to the following line in org-babel-comint-eval-invisibly-and-wait-for-file (while (not (file-exists-p file)) (sit-for (or period 0.25))) sorry for hijacking this thread. With a quite useless message... I experience freezes at that exact position also on local sessions sometimes. I have never reported, because I can't send the scripts where this happens and slight modifications to the causing source block usually 'fix' this. So I failed in creating a reproducible example that I can send so far. The main purpose of this message is the hope, that someone else has experienced and solved that problem before (maybe changing some ESS-setup?). I will try more to get a reproducible example and report if I get one. Best, Andreas
Re: [O] Agenda in MobileOrg for Android
Hi all, sorry for the OT post. [...] As it happens, one of the lead developers of mobileorg started a thread on the MobileOrg-Android mailing list asking for issues that need to be addressed, and features that are needed, before it's ready for 1.0. Well, I didn't know about the existence if that list;). I guess the list is https://groups.google.com/forum/?fromgroups#!forum/mobileorg-android Can someone tell me how to read that list in gnus? Is that possible? - Andreas
Re: [O] minor bug in babel with silent output and remote R session
hmm. I agree that this should be handled by ESS and I have not given up yet.
as indicated in my previous mail, I dont know how to test if an
R-session is remote because the command ess-remote deletes all local
variables. a hack would be to let the R-process evaluate
file.exists((file-name-directory org-babel-temp-file))
thanks
Eric Schulte schulte.e...@gmail.com writes:
It is a shame that this can't be handled gracefully either through ESS
or R code.
I agree it would be nice to raise a warning rather than hang waiting
for a file which won't ever exist. So, how can we tell from the Babel
source if the R session is remote?
Thanks,
Thomas Alexander Gerds t...@biostat.ku.dk writes:
yes, I am using ESS. ess-remote allows me to evaluate R-code from
the local emacs-session on a remote machine connected to via ssh.
there are two problems:
1) the remote machine cannot write to org-babel-temp-file because
the tmp-directory exists on the local machine. here we could add
if(!file.exists(dirname(transfer.file))){dir.create(dirname(transfer.file))}
in the middle of the variable org-babel-R-write-object-command this
would achieve that the file is at least generated on the remote
host.
2) however, still the transfer file does not exist on the local
machine. there are several possiblities:
a) tell org-babel-comint-eval-invisibly-and-wait-for-file that the
file is remote and then test if (concat / username @ host :
file) exists instead of file.
b) use tramp to transfer the file from the remote to the local
machine. the function ssh does define ssh-host and ssh-username,
however, calling ess-remote removes these variables again.
c) tell org-babel-comint-eval-invisibly-and-wait-for-file not to
wait for file if it is remote
my conclusion: it would be nice to have this functionality, but
perhaps it is not worth the efforts and it would be sufficient to
avoid the endless loop when waiting for a file which never will
generated.
cheers thomas
Eric Schulte schulte.e...@gmail.com writes:
Bastien b...@gnu.org writes:
Hi Thomas, thanks for the follow-up. Thomas Alexander Gerds
t...@biostat.ku.dk writes:
I think that I can describe the problem a bit better now. It is
not related to the silent option but occurs whenever :results
value. Emacs freezes due to the following line in
org-babel-comint-eval-invisibly-and-wait-for-file (while (not
(file-exists-p file)) (sit-for (or period 0.25))) it seems that R
cannot transfer the file and hence this is an endless loop.
I'm not knowledgeable enough in this area to provide a fix, maybe
someone else will.
Could this be a problem with whatever tool (I'm assuming ESS) you
are using to maintain the R session and generate the R file?
Perhaps babel needs to modify the R code used to create the file
(held in the `org-babel-R-write-object-command' variable). Could
you take a shot at providing another version of this variable? I
don't really use R myself.
Thanks,
-- Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics
University of Copenhagen, Øster Farimagsgade 5, 1014 Copenhagen,
Denmark Office: CSS-15.2.07 (Gamle Kommunehospital) tel: 35327914
(sec: 35327901)
--
Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics
University of Copenhagen, Øster Farimagsgade 5, 1014 Copenhagen, Denmark
Office: CSS-15.2.07 (Gamle Kommunehospital)
tel: 35327914 (sec: 35327901)
Re: [O] [PATCH] Process hlines in imported tables
Hi Eric, Sebastien Vauban wrote: Eric Schulte wrote: I would agree that this (meaning raw implies scalar) should either occur for all languages or for none. I think this is something interesting, but I wonder now if we wouldn't loose more than we would win. I mean: how would one be able to output a real raw result, then, that is one where pipes are not interpreted as table field separator which have to be aligned in some specific way. Do we need another argument for that? I mean: at the end, raw should really be raw (no interpretation). If we want some cycling for table alignment purpose (BTW, do you have lots of such code blocks?), maybe it'd be better to introduce a `cycle' argument or so? I think that this portion of my post has been ignored in your answers -- which I still have to carefully look at. Though, I don't think the above question should stay unanswered: if you now cycle on all raw results, how do we insert real raw results for which we don't want any interpretation (not even cycling tables, or what you be confounded as tables)? Best regards, Seb -- Sebastien Vauban
[O] Colour themes suggestions?
Hi I am looking for some subjective opinions on color themes for emacs 24. I am using (obviously) org-mode and mainly for literate programming in R and also use gnus. There might be more to come, but I don't know yet. I am looking for suggestions for color themes which are on a light background (reflections are less) and has nice and effective syntax highlighting. Any suggestions? I am using twilight-bright at the momen, but am somehow not that happy with it. Any (subjective) suggestions? Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug pgpG9BzTkU0X3.pgp Description: PGP signature
Re: [O] Colour themes suggestions?
Hi Rainer, I am a big fan of Zenburn. Unfortunately, it is exactly the opposite of what you are looking for. I find it very eye friendly. However, maybe once in a while you want a dark-color-theme and then zenburn might be worse to try ;) Greetings Torsten
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Eric, Eric Schulte wrote: Let me explain. AFAICT, there were 5 possibles values of the :colnames header argument: - no header argument :: (default for all languages but Emacs Lisp) - :colnames no :: (default for Emacs Lisp code blocks) - :colnames yes :: Tells Org Babel that your first row contains column names. - :colnames LIST :: Specifies to use LIST as column names. - :colnames nil :: Same as :colnames yes. Right? Almost, values 1 (none) and 5 (nil) are the same. I don't share your view about this last statement. As I believe I mentioned nil on a header argument is not interpreted as the lisp literal `nil'. To pass an empty argument to a code block you should do :colnames '(), an obscure syntax for an obscure thing. I do now share your view with your precision on using - :colnames '() or - :colnames () to pass an empty argument. Are both version above really equivalent (they _do_ behave the same in my tests, but I'm wondering for the future)? Best regards, Seb -- Sebastien Vauban
Re: [O] Colour themes suggestions?
On Mon, Apr 15, 2013 at 03:32:31PM +0200, Rainer M. Krug wrote: I am looking for suggestions for color themes which are on a light background (reflections are less) and has nice and effective syntax highlighting. Any suggestions? I am using twilight-bright at the momen, but am somehow not that happy with it. Completely opposite of what you asked, you could checkout dark-emacs[1]. It is a very dark theme, designed to emulate emacs -nw in a black background terminal. It has some org related customisations in (custom-theme-set-variables ...) and some of the org faces are built up on other basic faces; all in all it might give you some ideas to write your own theme. GL, Footnotes: [1] https://github.com/suvayu/.emacs.d/blob/master/themes/dark-emacs-theme.el -- Suvayu Open source is the future. It sets us free.
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Eric, Eric Schulte wrote: ** Using =:colnames no= header argument (case 2) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Here, I still don't understand why I do see the table header line: I did change the default =:colnames yes= specification to =:colnames no= on the code block. I did override the default value. Why is the =no= argument not respected? Because 'hlines is set to yes by default in `org-babel-default-header-args:emacs-lisp'. I missed the cumulative effect of hlines on the behavior of colnames. Yes, setting hlines to no does solve the problem for Emacs Lisp code blocks. Thanks a lot. Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Eric, Eric Schulte wrote: What is still unclear to me as well, is why =()= and =nil= aren't the same from Babel's point of view? However, I think I understood this one: it is because nil is interpreted as a string, not as the empty list; right? That's because strings aren't quoted, right? Yes. Apart from the automatic (and, maybe, sometimes unwished) coercion of a symbol into a string (case of `nil'), are you aware of other tricky stuff? For my own understanding, why didn't we force the user to quote all strings, and avoid the above problem? Best regards, Seb -- Sebastien Vauban
[O] org-babel-tangle
Hi, When editing https://github.com/bateast/google-calendar/blob/master/google-calendar.org I assume from the documentation that hitting C-c C-v C-t or M-x org-babel-tangle would produce the pure source (in casu elisp) file, but it says 'Tangled 0 code blocks from google-calendar.org' I am pretty sure that it should be possible to produce the source file without any modification of the input file, but appearently I am approaching it the wrong way. Any help and suggestions would be most welcome, Guido -- Nadia Comaneci, simple perfection. -- '76 Olympics http://vanhoecke.org ... and go2 places!
Re: [O] org-babel-tangle
Guido Van Hoecke wrote: When editing https://github.com/bateast/google-calendar/blob/master/google-calendar.org I assume from the documentation that hitting C-c C-v C-t or M-x org-babel-tangle would produce the pure source (in casu elisp) file, but it says 'Tangled 0 code blocks from google-calendar.org' I am pretty sure that it should be possible to produce the source file without any modification of the input file, but appearently I am approaching it the wrong way. Any help and suggestions would be most welcome, Put, at least, `#+PROPERTY: tangle yes' in the first lines of the Org file -- or put a target filename. Best regards, Seb -- Sebastien Vauban
[O] Bug: org-cycle-separator-lines ignored after S-TAB with numeric arg [8.0-pre (release_8.0-pre-443-g06294c @ /home/creidieki/elisp/org-mode/lisp/)]
When using a numeric prefix argument to S-TAB, empty lines aren't displayed between folded parts of the subtree, regardless of the setting of org-cycle-separator-lines. Reproduction instructions: 1) Create a file with: begin test file * Stuff ** Things * Other stuff end test file 2) C-2 S-TAB Expected outcome: Blank lines between items (as happens with S-TAB) Actual outcome: Blank lines not present between items The descriptions of org-shifttab, org-cycle, and org-cycle-separator-lines seem to imply that the blank lines should appear, as do the descriptions in the manual of org-cycle-separator-lines (sect 2.2) and of S-TAB (sect 2.3). Plus my document is harder to read without the lines it's supposed to have :-) This seems to happen because org-cycle-separator-lines is only used in org-cycle-show-empty-lines, which is called from org-cycle-hook; but when S-TAB is called with a numeric argument, it doesn't use org-cycle, it uses org-content directly. The following change seems to fix the problem, but I haven't done detailed testing, and I don't know enough about the code to know whether this was the best way: -begin patch-- diff --git a/lisp/org.el b/lisp/org.el index 5412028..4e57a2b 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -19550,6 +19550,7 @@ See the individual commands for more information. (let ((arg2 (if org-odd-levels-only (1- (* 2 arg)) arg))) (message Content view to level: %d arg) (org-content (prefix-numeric-value arg2)) + (org-cycle-show-empty-lines t) (setq org-cycle-global-status 'overview))) (t (call-interactively 'org-global-cycle -end patch--- Thanks, and please let me know if there's anything I can clarify or help out with. -- Michael Crouch Emacs : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of 2013-04-13 on trouble, modified by Debian Package: Org-mode version 8.0-pre (release_8.0-pre-443-g06294c @ /home/creidieki/elisp/org-mode/lisp/) current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-agenda-start-on-weekday 0 org-log-done 'time org-format-latex-options '(:foreground default :background default :scale 1.6 :html-foreground Black :html-background Transparent :html-scale 1.0 :matchers (begin $1 $ $$ \\( \\[)) org-confirm-shell-link-function 'yes-or-no-p org-export-date-timestamp-format %Y-%m-%d org-pretty-entities t org-agenda-todo-ignore-scheduled 'all org-agenda-prefix-format '((agenda . %-12:T%?-12t% s) (timeline . % s) (todo . %-12:c) (tags . %-12:c) (search . %-12:c)) org-agenda-skip-scheduled-if-done t org-agenda-custom-commands '((H TODO items tags-todo HOME|COMPUTER nil) (h TODO items tags-todo HOME nil) (D Daily Action List ((agenda ((org-agenda-ndays 1) (org-agenda-sorting-strategy (quote ((agenda time-up habit-up priority-down tag-down (org-deadline-warning-days 0)) ) ) nil) (c TODO items tags-todo COMPUTER nil) (T TODO items tags-todo TOWN nil)) org-latex-format-headline-function 'org-latex-format-headline-default-function org-default-notes-file ~/Dropbox/writeup/org//notes.org org-agenda-time-leading-zero t org-todo-keyword-faces '((LATER . #00)) org-agenda-remove-tags 'prefix org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-export-copy-to-kill-ring t org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-agenda-cmp-user-defined 'org-custom-cmp-tag org-refile-targets '((org-agenda-files :level . 1)) org-export-with-tags 'not-in-toc org-agenda-sorting-strategy '((agenda habit-down time-up user-defined-down priority-down category-keep) (todo priority-down
[O] Examples of orgmode+beamer presentations?
Hi, I'm trying to find examples of presentations made with orgmode and beamer. Ideally I would like to see sample presentations first (in PDF), so that I can get one that looks as close to what I would need, and then I would like to get the source code for it. Are there any good templates out there? (Something similar to http://draketo.de/light/english/politics-and-free-software/recipes-presentations-beamer-latex-using-emacs-org-mode, but hopefully with more options). Is there anything out there? Thanks, -- Ángel de Vicente http://angel-de-vicente.blogspot.com/
Re: [O] Agenda in MobileOrg for Android
Hi Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: I guess the list is https://groups.google.com/forum/?fromgroups#!forum/mobileorg-android Can someone tell me how to read that list in gnus? Is that possible? The list is also on Gmane: http://thread.gmane.org/gmane.comp.handhelds.android.mobileorg -- Bastien
Re: [O] Examples of orgmode+beamer presentations?
I'm not clear on whether you are looking for templates or examples, but if the later, maybe my slides at http://projects.iq.harvard.edu/rtc/event/introduction-r will be of some interest. Scroll down to the bottom and download the .zip file. The rintro.pdf is the beamer export of the rintro.org file. HTH, Ista On Mon, Apr 15, 2013 at 11:18 AM, Angel de Vicente ang...@iac.es wrote: Hi, I'm trying to find examples of presentations made with orgmode and beamer. Ideally I would like to see sample presentations first (in PDF), so that I can get one that looks as close to what I would need, and then I would like to get the source code for it. Are there any good templates out there? (Something similar to http://draketo.de/light/english/politics-and-free-software/recipes-presentations-beamer-latex-using-emacs-org-mode, but hopefully with more options). Is there anything out there? Thanks, -- Ángel de Vicente http://angel-de-vicente.blogspot.com/
Re: [O] Examples of orgmode+beamer presentations?
On Mon, Apr 15, 2013 at 10:18 AM, Angel de Vicente ang...@iac.es wrote:
Hi,
I'm trying to find examples of presentations made with orgmode and
beamer. Ideally I would like to see sample presentations first (in PDF),
so that I can get one that looks as close to what I would need, and then
I would like to get the source code for it. Are there any good templates
out there? (Something similar to
http://draketo.de/light/english/politics-and-free-software/recipes-presentations-beamer-latex-using-emacs-org-mode,
but hopefully with more options).
Is there anything out there?
Not sure you'll find much out there since Org-mode is just using what
you can do with the Beamer LaTeX package. You might have better luck
searching around for Beamer themes and sample PDFs and then accessing
that look/style with Org-mode. This is typically as simple as this at
the top of the document:
#+latex_header: \usetheme[options]{theme-name}
For some Beamer examples:
- Matrix of all the standard themes:
http://www.hartwork.org/beamer-theme-matrix/
- Nice compilation of custom themes: http://latex.simon04.net/
I'm partial to Torino and have been using that at work with the
freewilly color option (blue) for almost everything.
To use it, I just have this at the top of all presentation files:
#+latex_header: \usetheme[alternativetitlepage=true,titleline=true]{Torino}
#+latex_header: \usecolortheme{freewilly}
Sorry if that's not what you're looking for! The recipe page you
posted will show you how to do some various columns and layouts, but
again, this is just doing in Org what you can do manually in Beamer.
The appearance is all going to come from the theme.
John
Thanks,
--
Ángel de Vicente
http://angel-de-vicente.blogspot.com/
Re: [O] Colour themes suggestions?
yet. I am looking for suggestions for color themes which are on a light background (reflections are less) and has nice and effective syntax highlighting. http://orgmode.org/worg/org-color-themes.html You may like Leuven. Vikas
Re: [O] Examples of orgmode+beamer presentations?
Hi, Ista Zahn istaz...@gmail.com writes: I'm not clear on whether you are looking for templates or examples, anything will do but if the later, maybe my slides at http://projects.iq.harvard.edu/rtc/event/introduction-r will be of some interest. Scroll down to the bottom and download the .zip file. The rintro.pdf is the beamer export of the rintro.org file. this looks very nice, thanks a lot. I will look into it and try to modify the footnote, some colours, etc. and see if I can get to where I want to go. Thanks, -- Ángel de Vicente http://www.iac.es/galeria/angelv/ - ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protecci�n de Datos, acceda a http://www.iac.es/disclaimer.php WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en
Re: [O] [PATCH 0/3] synctex support for pdf export
Hi all, even if the feature were asked by many many people, I don't think it would be the right time to implement it. The current parser needs to settle down a bit, to be heavily debugged in its current form before we can move on and modify it for another feature. So maybe for Org 9.0 if someone tackles the challenge to amend Aaron's series of patches. 2 cents, -- Bastien
Re: [O] Specify file name on commandline in batch export
Hi, Wiskey 5 Alpha wiskey5al...@gmail.com writes: this works well for exporting, but it will only output the file to the directory where the original org file is, and it will be named orgfile basename.odt Is there anyway to specify the output directory and filename at the time that I call the function ? Not that I can think of. Best, -- Bastien
Re: [O] phone links...
Hi Feng, thanks for your reply. I'll let Grégoire decide on what to apply to org-contacts.el. Best, -- Bastien
Re: [O] Bug: error enlighting file: [8.0-pre (release_8.0-pre-335-g4c426b-git @ org-loaddefs.el can not be found!)]
Hi Suvayu, Suvayu Ali fatkasuvayu+li...@gmail.com writes: BTW, to others, is it by any chance possible to check how emacs was started (if -q or -Q was present among the command line options)? Then a message could be shown about minimal testing with a setup when users call `org-submit-bug-report'. Well, there is `command-line-args' but -Q is deleted from this list when the args are processed. -- Bastien
Re: [O] Colour themes suggestions?
On Mon, Apr 15, 2013 at 03:32:31PM +0200, Rainer M. Krug wrote: I am looking for suggestions for color themes which are on a light background (reflections are less) and has nice and effective syntax highlighting. Any suggestions? I'm a big fan of Solarized [1]. It comes in light and dark. I use it in combination with the font Source Code Pro [2]. Best regards, Manuel -- [1] http://ethanschoonover.com/solarized [2] http://sourceforge.net/projects/sourcecodepro.adobe/
Re: [O] org-babel-tangle
Hi Sebastien, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Guido Van Hoecke wrote: When editing https://github.com/bateast/google-calendar/blob/master/google-calendar.org I assume from the documentation that hitting C-c C-v C-t or M-x org-babel-tangle would produce the pure source (in casu elisp) file, but it says 'Tangled 0 code blocks from google-calendar.org' I am pretty sure that it should be possible to produce the source file without any modification of the input file, but appearently I am approaching it the wrong way. Any help and suggestions would be most welcome, Put, at least, `#+PROPERTY: tangle yes' in the first lines of the Org file -- or put a target filename. I put it as first line of the file, saved it, and org-babel-tangle still refuses to output any code. Also tried `#+PROPERTY: tangle google-calendar.el' but again, no success. Seems to me that I fail to perform some very basic operation?! Guido -- As goatherd learns his trade by goat, so writer learns his trade by wrote. http://vanhoecke.org ... and go2 places!
Re: [O] org-babel-tangle
Hi Guido, Guido Van Hoecke gui...@gmail.com writes: I put it as first line of the file, saved it, and org-babel-tangle still refuses to output any code. Also tried `#+PROPERTY: tangle google-calendar.el' but again, no success. You may need to refresh the configuration by hitting C-c C-c on the #+PROPERTY line (or on any #+... line). -- Bastien
Re: [O] Bug: error enlighting file: [8.0-pre (release_8.0-pre-335-g4c426b-git @ org-loaddefs.el can not be found!)]
Hi Bastien, On Mon, Apr 15, 2013 at 05:49:28PM +0200, Bastien wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: BTW, to others, is it by any chance possible to check how emacs was started (if -q or -Q was present among the command line options)? Then a message could be shown about minimal testing with a setup when users call `org-submit-bug-report'. Well, there is `command-line-args' but -Q is deleted from this list when the args are processed. As far as I recall, if you start with emacs -Q, then customize refuses to save anything. Not sure if this is true for -q too. That would imply customize source should have some hint on how to do that :). Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] org-babel-tangle
Hi Bastien You may need to refresh the configuration by hitting C-c C-c on the #+PROPERTY line (or on any #+... line). Of course, I should have realised this. After refreshing, the tangle process works as expected. Sorry for the noise, Guido -- Tempt not a desperate man. -- William Shakespeare, Romeo and Juliet http://vanhoecke.org ... and go2 places!
Re: [O] org-babel-tangle
Hi Bastien, Guido Van Hoecke gui...@gmail.com writes: Hi Bastien You may need to refresh the configuration by hitting C-c C-c on the #+PROPERTY line (or on any #+... line). Of course, I should have realised this. After refreshing, the tangle process works as expected. Sorry for the noise, I did read the org manual very carefully before my initial post, as well as after successfully applying the solution. I did not find any statement about the need of such a `#+PROPERTY: tangle yes' line, so maybe the manual should mention this? At least it would have avoided the current noise. Respectfully, Guido -- The key to building a superstar is to keep their mouth shut. To reveal an artist to the people can be to destroy him. It isn't to anyone's advantage to see the truth. -- Bob Ezrin, rock music producer http://vanhoecke.org ... and go2 places!
Re: [O] Bug: error enlighting file: [8.0-pre (release_8.0-pre-335-g4c426b-git @ org-loaddefs.el can not be found!)]
On Mon, Apr 15, 2013 at 06:05:56PM +0200, Suvayu Ali wrote: Hi Bastien, On Mon, Apr 15, 2013 at 05:49:28PM +0200, Bastien wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: BTW, to others, is it by any chance possible to check how emacs was started (if -q or -Q was present among the command line options)? Then a message could be shown about minimal testing with a setup when users call `org-submit-bug-report'. Well, there is `command-line-args' but -Q is deleted from this list when the args are processed. As far as I recall, if you start with emacs -Q, then customize refuses to save anything. Not sure if this is true for -q too. That would imply customize source should have some hint on how to do that :). I took a peek at the source; you can test for custom-file. Take a look at custom-save-variable. Here is the snippet I'm alluding to: ... (if (custom-file t) (custom-save-all) (message Setting `%s' temporarily since \emacs -q\ would overwrite customizations variable) (set variable value)) ... Hope this helps, :) -- Suvayu Open source is the future. It sets us free.
Re: [O] Colour themes suggestions?
Hi Rainer Torsten Wagner torsten.wag...@gmail.com writes: Hi Rainer, I am a big fan of Zenburn. Unfortunately, it is exactly the opposite of what you are looking for. I find it very eye friendly. However, maybe once in a while you want a dark-color-theme and then zenburn might be worse to try ;) The anti-zenburn theme is the light version. It is subdued and the faces make the distinctions well, as does zenburn. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bug: org-cycle-separator-lines ignored after S-TAB with numeric arg [8.0-pre (release_8.0-pre-443-g06294c @ /home/creidieki/elisp/org-mode/lisp/)]
Hi Michael, Michael Crouch creidi...@gmail.com writes: When using a numeric prefix argument to S-TAB, empty lines aren't displayed between folded parts of the subtree, regardless of the setting of org-cycle-separator-lines. thanks for the detailed report and the fix, was the good one. I just committed it. Best, -- Bastien
Re: [O] org-babel-tangle
Guido Van Hoecke gui...@gmail.com writes: Hi Bastien, Guido Van Hoecke gui...@gmail.com writes: Hi Bastien You may need to refresh the configuration by hitting C-c C-c on the #+PROPERTY line (or on any #+... line). Of course, I should have realised this. After refreshing, the tangle process works as expected. Sorry for the noise, I did read the org manual very carefully before my initial post, as well as after successfully applying the solution. I did not find any statement about the need of such a `#+PROPERTY: tangle yes' line, so maybe the manual should mention this? At least it would have avoided the current noise. The info page on tangling [1], does mention that the default behavior is for blocks to not be tangled. , | ':tangle no' | The default. The code block is not included in the tangled output. ` Could you suggest a note which we could add to that page to improve clarity and help others avoid the same trap you fell into? Thanks Respectfully, Guido -- The key to building a superstar is to keep their mouth shut. To reveal an artist to the people can be to destroy him. It isn't to anyone's advantage to see the truth. -- Bob Ezrin, rock music producer http://vanhoecke.org ... and go2 places! Footnotes: [1] (info (org)Extracting source code) -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Error with :wrap org in babel and 8.0-pre
On Fri, Apr 12, 2013 at 5:24 PM, Eric Schulte schulte.e...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
I thought this was the proper syntax for printing stuff directly to a
LaTeX document:
#+begin_src R :session :exports results :results output :wrap org
I think you want either :results latex or :wrap latex.
Trying my best to follow the evolution here I've tried to discern
from the manual and Worg the best way to do something, generally try
it and fail. Then I post to the list and get an answer. A short time
later, I try doing what I think is approximately the same thing to
find that it seems to have changed since the last time:
To print multiple file names and =#+attr_stuff= options, the answer
was =:results output org :exports results=
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01224.html
Trying to do the same exact thing a bit later was =:results output
wrap=, shortly followed up with the instruction to use =:wrap org=
- http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01599.html
Now, it's =:wrap latex=, but I'm not sure why.
Is =:wrap org= appropriate for anything? I understood it as telling
Org-mode, Hey, I want you to parse this results block as if it was
written directly in Org-mode. That seems like what I want to do.
Since I posted this question, I decided it would be easier to display
results in a small table. Something like this:
#+begin_src R :session r :exports results :results output :wrap org
library(ascii)
cat(Blah blah blah and this value is, var1, \n)
qty_table - ascii(qtys[, c(1, 3, 4)], header = T, include.colnames =
T, include.rownames = F)
print(qty_table, type = org)
#+end_src
That exports correctly (get my paragraphs and LaTeX table), but I
still get an error about \begin{org}. Using =:wrap latex= does not
work, as it's not interpreting the Org table properly.
Thanks for the assistance,
John
P.S. Sorry for the venty tone... I just hate 1) pestering the list
again and again for what I think are similar things and feeling
foolish and defeated by the documentation, and 2) having to wait to
have mysteries unveiled... especially when I'm using Org for
time-critical work things!
Cheers,
I've got a statement interspersing some prose with variable values like so:
cat(This and such value was, var1, , and this one was, var2, .\n)
The results block looks fine, but LaTeX is spitting out \begin{org}
and \end{org} around it, which results in a compilation error:
! LaTeX Error: Environment org undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.51 \begin{org}
! LaTeX Error: \begin{document} ended by \end{org}.
Suggestions?
Thanks,
John
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] Attributes on HTML tables?
Eric- Rick Frankel r...@rickster.com writes: I would argue that to set the element type fro the outer (outline-container) div or the inner (outline-text) div, a property setting would make more sense. I can see using a (headline level) :HTML_CONTAINER property to set the container on a given headline (which i think i will impliment as it is very low impact), and perhaps either an :HTML_CHILD_CONTAINER or :HTML_TEXT_CONTAINER to specify the wrapper on the inner section. I have pushed to master the abilty to set the :HTML_CONTAINER property on any headline and have that value override the default (:html-container for level 1 headines, div for the rest). Note that this is not an inherited property so only affect the headline it is specified on, not it's children. rick
Re: [O] Error with :wrap org in babel and 8.0-pre
John Hendy jw.he...@gmail.com writes:
On Fri, Apr 12, 2013 at 5:24 PM, Eric Schulte schulte.e...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
I thought this was the proper syntax for printing stuff directly to a
LaTeX document:
#+begin_src R :session :exports results :results output :wrap org
I think you want either :results latex or :wrap latex.
Trying my best to follow the evolution here I've tried to discern
from the manual and Worg the best way to do something, generally try
it and fail. Then I post to the list and get an answer. A short time
later, I try doing what I think is approximately the same thing to
find that it seems to have changed since the last time:
To print multiple file names and =#+attr_stuff= options, the answer
was =:results output org :exports results=
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01224.html
Trying to do the same exact thing a bit later was =:results output
wrap=, shortly followed up with the instruction to use =:wrap org=
- http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01599.html
Now, it's =:wrap latex=, but I'm not sure why.
I may have miss-understood your question.
Is =:wrap org= appropriate for anything?
Use :wrap latex if your code block produces raw latex. E.g.,
#+begin_src sh :results output :wrap latex
cat EOF
\begin{tabular}{rr}
a b\\
\hline
1 2\\
\end{tabular}
EOF
#+end_src
#+RESULTS:
#+BEGIN_latex
\begin{tabular}{rr}
a b\
\hline
1 2\
\end{tabular}
#+END_latex
Use :wrap org if your code block produces raw org. E.g.,
#+begin_src sh :results output :wrap org
cat EOF
| a | b |
|---+---|
| 1 | 2 |
EOF
#+end_src
#+RESULTS:
#+BEGIN_org
| a | b |
|---+---|
| 1 | 2 |
#+END_org
Let me know if that leave any mysteries or doesn't address part of your
question. I apologize for any contribution my often terse and hurried
responses have made to this confusion.
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] Nested list with percent-complete in multiple states?
Hi Brett, On Fri, Apr 12, 2013 at 07:39:24AM +0200, Bastien wrote: Hi Brett, thanks for sharing your recipe, nice. Yes indeed! I think this is a fine addition to Worg. Maybe the column view page would be appropriate? http://orgmode.org/worg/org-tutorials/org-column-view-tutorial.html Brett Viren b...@bnl.gov writes: I've been able to capture the columnview into another .org file and then export that to an HTML file. Is there a way to automate these three steps? Not that I can think about right now, but surely some hack could do. Time to break out keyboard macros! Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Agenda in MobileOrg for Android
Hi Bastien, Bastien b...@gnu.org writes: Hi Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: I guess the list is https://groups.google.com/forum/?fromgroups#!forum/mobileorg-android Can someone tell me how to read that list in gnus? Is that possible? The list is also on Gmane: http://thread.gmane.org/gmane.comp.handhelds.android.mobileorg thanks for that! Somehow, I had missed that. - Andreas
Re: [O] org-babel-tangle
Eric Schulte schulte.e...@gmail.com writes: Guido Van Hoecke gui...@gmail.com writes: Hi Bastien, Guido Van Hoecke gui...@gmail.com writes: Hi Bastien You may need to refresh the configuration by hitting C-c C-c on the #+PROPERTY line (or on any #+... line). Of course, I should have realised this. After refreshing, the tangle process works as expected. Sorry for the noise, I did read the org manual very carefully before my initial post, as well as after successfully applying the solution. I did not find any statement about the need of such a `#+PROPERTY: tangle yes' line, so maybe the manual should mention this? At least it would have avoided the current noise. The info page on tangling [1], does mention that the default behavior is for blocks to not be tangled. , | ':tangle no' | The default. The code block is not included in the tangled output. ` Could you suggest a note which we could add to that page to improve clarity and help others avoid the same trap you fell into? Further reading / study of the manual showed that the required info is present at the end of section `14.1 Structure of code blocks': , | header arguments | | Optional header arguments control many aspects of evaluation, | export and tangling of code blocks (see Header arguments). | Header arguments can also be set on a per-buffer or per-subtree | basis using properties. ` And section `14.8.1 Using header arguments' is very explicit and gives examples of all possible usages. So the manual is very complete and only needs to be read :P Again, sorry for the noise. Respectfully, Guido -- He who hesitates is a damned fool. -- Mae West
Re: [O] [PATCH] Process hlines in imported tables
Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Sebastien Vauban wrote: Eric Schulte wrote: I would agree that this (meaning raw implies scalar) should either occur for all languages or for none. I think this is something interesting, but I wonder now if we wouldn't loose more than we would win. I mean: how would one be able to output a real raw result, then, that is one where pipes are not interpreted as table field separator which have to be aligned in some specific way. Do we need another argument for that? I mean: at the end, raw should really be raw (no interpretation). If we want some cycling for table alignment purpose (BTW, do you have lots of such code blocks?), maybe it'd be better to introduce a `cycle' argument or so? I think that this portion of my post has been ignored in your answers -- which I still have to carefully look at. Though, I don't think the above question should stay unanswered: if you now cycle on all raw results, how do we insert real raw results for which we don't want any interpretation (not even cycling tables, or what you be confounded as tables)? Is this a hypothetical problem or do you have a use case which requires non-cycling? At this stage, completely hypothetical. It's just that we remove some possibility which existed: from now on, we can't insert some types of data anymore. And I feel that the name raw does not conform anymore to the reality. But, as said, I don't have a real problem at hand. Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
On Mon, Apr 15, 2013 at 1:12 PM, Eric Schulte schulte.e...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
On Fri, Apr 12, 2013 at 5:24 PM, Eric Schulte schulte.e...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
I thought this was the proper syntax for printing stuff directly to a
LaTeX document:
#+begin_src R :session :exports results :results output :wrap org
I think you want either :results latex or :wrap latex.
Trying my best to follow the evolution here I've tried to discern
from the manual and Worg the best way to do something, generally try
it and fail. Then I post to the list and get an answer. A short time
later, I try doing what I think is approximately the same thing to
find that it seems to have changed since the last time:
To print multiple file names and =#+attr_stuff= options, the answer
was =:results output org :exports results=
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01224.html
Trying to do the same exact thing a bit later was =:results output
wrap=, shortly followed up with the instruction to use =:wrap org=
- http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01599.html
Now, it's =:wrap latex=, but I'm not sure why.
I may have miss-understood your question.
Is =:wrap org= appropriate for anything?
Use :wrap latex if your code block produces raw latex. E.g.,
#+begin_src sh :results output :wrap latex
cat EOF
\begin{tabular}{rr}
a b\\
\hline
1 2\\
\end{tabular}
EOF
#+end_src
#+RESULTS:
#+BEGIN_latex
\begin{tabular}{rr}
a b\
\hline
1 2\
\end{tabular}
#+END_latex
That makes sense, but it's not what I'm doing or at least not in full.
I may insert LaTeX here or there, but am also using Org-specific
syntax in many places as well (#+attr_blah lines and such).
Use :wrap org if your code block produces raw org. E.g.,
#+begin_src sh :results output :wrap org
cat EOF
| a | b |
|---+---|
| 1 | 2 |
EOF
#+end_src
#+RESULTS:
#+BEGIN_org
| a | b |
|---+---|
| 1 | 2 |
#+END_org
Let me know if that leave any mysteries or doesn't address part of your
question. I apologize for any contribution my often terse and hurried
responses have made to this confusion.
This is also what I would have thought. In other words, =:wrap latex=
if you will have pure LaTeX in the blocks, and =:wrap org= if it's too
be interpreted just as if you'd typed the exact same thing in your
Org-mode file outside of the given results block.
But this was the reason for the original post. Here's my document:
#+begin_org_document
* Heading
#+begin_src R :session :exports results :results output :wrap org
library(ascii)
var1 - 100
var2 - 200
cat(With the assumption of, var1, lbs. of input material 1 and,
var2, lbs. of material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.\n)
qtys - data.frame(wall = c(5 mil, 6 mil, 8 mil), vals = c(.005,
.006, .008))
qtys$widgets - trunc(var2 / qtys$vals)
qty_table - ascii(qtys, header = T, include.colnames = T, include.rownames = F)
print(qty_table, type = org)
#+end_src
#+RESULTS:
#+BEGIN_org
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
| wall | vals | widgets |
|---+--+--|
| 5 mil | 0.01 | 4.00 |
| 6 mil | 0.01 | 3.00 |
| 8 mil | 0.01 | 25000.00 |
#+END_org
#+end_org_document
Everything looks to be correct. I get this LaTeX upon compilation for
the results section:
#+begin_latex_output
\begin{org}
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
\begin{center}
\begin{tabular}{lrr}
\toprule
wall vals widgets\\
\midrule
5 mil 0.01 4.00\\
6 mil 0.01 3.00\\
8 mil 0.01 25000.00\\
\bottomrule
\end{tabular}
\end{center}
\end{org}
% Generated by Org mode 8.0-pre in Emacs 24.3.1.
\end{document}
#+end_latex_output
This is in the *Org PDF LaTeX Output* buffer:
! LaTeX Error: Environment org undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.33 \begin{org}
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/wasysym/uwasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/base/ulasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsb.fd)
! LaTeX Error: \begin{document} ended by \end{org}.
So it seems like something is awry:
- Either the exporter is supposed to convert #+begin/end_org into
something else (I would assume there shouldn't be any \begin/end{org}
around it since it should just be including the LaTeX results as if it
wasn't in a #+RESULTS block at all, right?),
Re: [O] Error with :wrap org in babel and 8.0-pre
Dear Eric, Eric Schulte wrote: John Hendy jw.he...@gmail.com writes: On Fri, Apr 12, 2013 at 5:24 PM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: Use :wrap org if your code block produces raw org. E.g., #+begin_src sh :results output :wrap org cat EOF | a | b | |---+---| | 1 | 2 | EOF #+end_src #+RESULTS: #+BEGIN_org | a | b | |---+---| | 1 | 2 | #+END_org Playing a bit with the above code, removing `:results output' to see what would happen, I'm amazed by the results: #+begin_src sh :wrap org cat EOF | a | b | |---+---| | 1 | 2 | EOF #+end_src #+results: #+BEGIN_org | | | a | | | b | | | | ---+--- | | | | | | | | | 1 | | | 2 | | #+END_org Is it expected? Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
Hi John,
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 15, 2013 at 1:12 PM, Eric Schulte schulte.e...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
On Fri, Apr 12, 2013 at 5:24 PM, Eric Schulte schulte.e...@gmail.com
wrote:
John Hendy jw.he...@gmail.com writes:
I thought this was the proper syntax for printing stuff directly to a
LaTeX document:
#+begin_src R :session :exports results :results output :wrap org
I think you want either :results latex or :wrap latex.
Trying my best to follow the evolution here I've tried to discern
from the manual and Worg the best way to do something, generally try
it and fail. Then I post to the list and get an answer. A short time
later, I try doing what I think is approximately the same thing to
find that it seems to have changed since the last time:
To print multiple file names and =#+attr_stuff= options, the answer
was =:results output org :exports results=
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01224.html
Trying to do the same exact thing a bit later was =:results output
wrap=, shortly followed up with the instruction to use =:wrap org=
- http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01599.html
Now, it's =:wrap latex=, but I'm not sure why.
I may have miss-understood your question.
Is =:wrap org= appropriate for anything?
Use :wrap latex if your code block produces raw latex. E.g.,
#+begin_src sh :results output :wrap latex
cat EOF
\begin{tabular}{rr}
a b\\
\hline
1 2\\
\end{tabular}
EOF
#+end_src
#+RESULTS:
#+BEGIN_latex
\begin{tabular}{rr}
a b\
\hline
1 2\
\end{tabular}
#+END_latex
That makes sense, but it's not what I'm doing or at least not in full.
I may insert LaTeX here or there, but am also using Org-specific
syntax in many places as well (#+attr_blah lines and such).
Use :wrap org if your code block produces raw org. E.g.,
#+begin_src sh :results output :wrap org
cat EOF
| a | b |
|---+---|
| 1 | 2 |
EOF
#+end_src
#+RESULTS:
#+BEGIN_org
| a | b |
|---+---|
| 1 | 2 |
#+END_org
Let me know if that leave any mysteries or doesn't address part of your
question. I apologize for any contribution my often terse and hurried
responses have made to this confusion.
This is also what I would have thought. In other words, =:wrap latex=
if you will have pure LaTeX in the blocks, and =:wrap org= if it's too
be interpreted just as if you'd typed the exact same thing in your
Org-mode file outside of the given results block.
But this was the reason for the original post. Here's my document:
#+begin_org_document
* Heading
#+begin_src R :session :exports results :results output :wrap org
library(ascii)
var1 - 100
var2 - 200
cat(With the assumption of, var1, lbs. of input material 1 and,
var2, lbs. of material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.\n)
qtys - data.frame(wall = c(5 mil, 6 mil, 8 mil), vals = c(.005,
.006, .008))
qtys$widgets - trunc(var2 / qtys$vals)
qty_table - ascii(qtys, header = T, include.colnames = T, include.rownames =
F)
print(qty_table, type = org)
#+end_src
#+RESULTS:
#+BEGIN_org
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material
2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
| wall | vals | widgets |
|---+--+--|
| 5 mil | 0.01 | 4.00 |
| 6 mil | 0.01 | 3.00 |
| 8 mil | 0.01 | 25000.00 |
#+END_org
#+end_org_document
Everything looks to be correct. I get this LaTeX upon compilation for
the results section:
#+begin_latex_output
\begin{org}
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material
2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
\begin{center}
\begin{tabular}{lrr}
\toprule
wall vals widgets\\
\midrule
5 mil 0.01 4.00\\
6 mil 0.01 3.00\\
8 mil 0.01 25000.00\\
\bottomrule
\end{tabular}
\end{center}
\end{org}
% Generated by Org mode 8.0-pre in Emacs 24.3.1.
\end{document}
#+end_latex_output
This is in the *Org PDF LaTeX Output* buffer:
! LaTeX Error: Environment org undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.33 \begin{org}
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/wasysym/uwasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/base/ulasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsb.fd)
! LaTeX Error: \begin{document} ended by \end{org}.
So it seems like something is awry:
- Either the exporter is supposed to convert #+begin/end_org into
something else (I would assume there shouldn't be any
Re: [O] Error with :wrap org in babel and 8.0-pre
On Mon, Apr 15, 2013 at 2:48 PM, Andreas Leha
andreas.l...@med.uni-goettingen.de wrote:
Hi John,
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 15, 2013 at 1:12 PM, Eric Schulte schulte.e...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
On Fri, Apr 12, 2013 at 5:24 PM, Eric Schulte schulte.e...@gmail.com
wrote:
John Hendy jw.he...@gmail.com writes:
I thought this was the proper syntax for printing stuff directly to a
LaTeX document:
#+begin_src R :session :exports results :results output :wrap org
I think you want either :results latex or :wrap latex.
Trying my best to follow the evolution here I've tried to discern
from the manual and Worg the best way to do something, generally try
it and fail. Then I post to the list and get an answer. A short time
later, I try doing what I think is approximately the same thing to
find that it seems to have changed since the last time:
To print multiple file names and =#+attr_stuff= options, the answer
was =:results output org :exports results=
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01224.html
Trying to do the same exact thing a bit later was =:results output
wrap=, shortly followed up with the instruction to use =:wrap org=
- http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01599.html
Now, it's =:wrap latex=, but I'm not sure why.
I may have miss-understood your question.
Is =:wrap org= appropriate for anything?
Use :wrap latex if your code block produces raw latex. E.g.,
#+begin_src sh :results output :wrap latex
cat EOF
\begin{tabular}{rr}
a b\\
\hline
1 2\\
\end{tabular}
EOF
#+end_src
#+RESULTS:
#+BEGIN_latex
\begin{tabular}{rr}
a b\
\hline
1 2\
\end{tabular}
#+END_latex
That makes sense, but it's not what I'm doing or at least not in full.
I may insert LaTeX here or there, but am also using Org-specific
syntax in many places as well (#+attr_blah lines and such).
Use :wrap org if your code block produces raw org. E.g.,
#+begin_src sh :results output :wrap org
cat EOF
| a | b |
|---+---|
| 1 | 2 |
EOF
#+end_src
#+RESULTS:
#+BEGIN_org
| a | b |
|---+---|
| 1 | 2 |
#+END_org
Let me know if that leave any mysteries or doesn't address part of your
question. I apologize for any contribution my often terse and hurried
responses have made to this confusion.
This is also what I would have thought. In other words, =:wrap latex=
if you will have pure LaTeX in the blocks, and =:wrap org= if it's too
be interpreted just as if you'd typed the exact same thing in your
Org-mode file outside of the given results block.
But this was the reason for the original post. Here's my document:
#+begin_org_document
* Heading
#+begin_src R :session :exports results :results output :wrap org
library(ascii)
var1 - 100
var2 - 200
cat(With the assumption of, var1, lbs. of input material 1 and,
var2, lbs. of material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.\n)
qtys - data.frame(wall = c(5 mil, 6 mil, 8 mil), vals = c(.005,
.006, .008))
qtys$widgets - trunc(var2 / qtys$vals)
qty_table - ascii(qtys, header = T, include.colnames = T, include.rownames
= F)
print(qty_table, type = org)
#+end_src
#+RESULTS:
#+BEGIN_org
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material
2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
| wall | vals | widgets |
|---+--+--|
| 5 mil | 0.01 | 4.00 |
| 6 mil | 0.01 | 3.00 |
| 8 mil | 0.01 | 25000.00 |
#+END_org
#+end_org_document
Everything looks to be correct. I get this LaTeX upon compilation for
the results section:
#+begin_latex_output
\begin{org}
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material
2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
\begin{center}
\begin{tabular}{lrr}
\toprule
wall vals widgets\\
\midrule
5 mil 0.01 4.00\\
6 mil 0.01 3.00\\
8 mil 0.01 25000.00\\
\bottomrule
\end{tabular}
\end{center}
\end{org}
% Generated by Org mode 8.0-pre in Emacs 24.3.1.
\end{document}
#+end_latex_output
This is in the *Org PDF LaTeX Output* buffer:
! LaTeX Error: Environment org undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.33 \begin{org}
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/wasysym/uwasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/base/ulasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsb.fd)
! LaTeX Error: \begin{document} ended by \end{org}.
So it seems like something is awry:
- Either the exporter is supposed
Re: [O] css link colors for Worg are difficult to spot
On Sat, Apr 6, 2013 at 12:59 PM, Bastien b...@gnu.org wrote: John Hendy jw.he...@gmail.com writes: Agreed as well. +1 It drives me crazy to have posted to the list a couple times recently for someone to tell me where, exactly, something is only to find out there was, indeed, a link in the paragraph I was looking at but didn't see it! I hereby declare you Head of Worg Design Department! Please be bold. Didn't get to this, but looks like someone else did a bit of an overhaul! No more gray background, blue/purple links and simple underline appearance for hover. Works for me. John -- Bastien
Re: [O] Error with :wrap org in babel and 8.0-pre
Hello, John Hendy jw.he...@gmail.com writes: #+RESULTS: #+BEGIN_org With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2, we can produce the following number of widgets based on injection mold wall thicknesses. | wall | vals | widgets | |---+--+--| | 5 mil | 0.01 | 4.00 | | 6 mil | 0.01 | 3.00 | | 8 mil | 0.01 | 25000.00 | #+END_org This is wrong. We discussed it months ago on this ML and, IIRC, Babel should produce #+begin_src org blocks, not #+begin_org. Org documentation specifies it too. I didn't read the thread carefully, but you may want to use drawer output instead. Regards, -- Nicolas Goaziou
Re: [O] Error with :wrap org in babel and 8.0-pre
Use :wrap org if your code block produces raw org. E.g.,
#+begin_src sh :results output :wrap org
cat EOF
| a | b |
|---+---|
| 1 | 2 |
EOF
#+end_src
#+RESULTS:
#+BEGIN_org
| a | b |
|---+---|
| 1 | 2 |
#+END_org
Let me know if that leave any mysteries or doesn't address part of your
question. I apologize for any contribution my often terse and hurried
responses have made to this confusion.
Oh! I miss-spoke. There really are a staggering number of options. I
actually don't know what :wrap org would be used for. What *you* want
is a drawer. This has the benefit of delimiting your results, while
allowing them to be pure Org-mode with no special export behavior.
#+begin_src sh :results output drawer
cat EOF
| a | b |
|---+---|
| 1 | 2 |
EOF
#+end_src
#+RESULTS:
:RESULTS:
| a | b |
|---+---|
| 1 | 2 |
:END:
My sincere apologies.
This is also what I would have thought. In other words, =:wrap latex=
if you will have pure LaTeX in the blocks, and =:wrap org= if it's too
be interpreted just as if you'd typed the exact same thing in your
Org-mode file outside of the given results block.
But this was the reason for the original post. Here's my document:
#+begin_org_document
* Heading
#+begin_src R :session :exports results :results output :wrap org
library(ascii)
var1 - 100
var2 - 200
cat(With the assumption of, var1, lbs. of input material 1 and,
var2, lbs. of material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.\n)
qtys - data.frame(wall = c(5 mil, 6 mil, 8 mil), vals = c(.005,
.006, .008))
qtys$widgets - trunc(var2 / qtys$vals)
qty_table - ascii(qtys, header = T, include.colnames = T, include.rownames =
F)
print(qty_table, type = org)
#+end_src
#+RESULTS:
#+BEGIN_org
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material
2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
| wall | vals | widgets |
|---+--+--|
| 5 mil | 0.01 | 4.00 |
| 6 mil | 0.01 | 3.00 |
| 8 mil | 0.01 | 25000.00 |
#+END_org
#+end_org_document
Everything looks to be correct. I get this LaTeX upon compilation for
the results section:
#+begin_latex_output
\begin{org}
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material
2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
\begin{center}
\begin{tabular}{lrr}
\toprule
wall vals widgets\\
\midrule
5 mil 0.01 4.00\\
6 mil 0.01 3.00\\
8 mil 0.01 25000.00\\
\bottomrule
\end{tabular}
\end{center}
\end{org}
% Generated by Org mode 8.0-pre in Emacs 24.3.1.
\end{document}
#+end_latex_output
This is in the *Org PDF LaTeX Output* buffer:
! LaTeX Error: Environment org undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.33 \begin{org}
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/wasysym/uwasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/base/ulasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsb.fd)
! LaTeX Error: \begin{document} ended by \end{org}.
So it seems like something is awry:
- Either the exporter is supposed to convert #+begin/end_org into
something else (I would assume there shouldn't be any \begin/end{org}
around it since it should just be including the LaTeX results as if it
wasn't in a #+RESULTS block at all, right?), OR
- I'm missing some sort of definition for an =org= environment in
LaTeX setup so that it knows what to do with \begin/end{org}
Thanks,
John
--
Eric Schulte
http://cs.unm.edu/~eschulte
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] Error with :wrap org in babel and 8.0-pre
On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, John Hendy jw.he...@gmail.com writes: #+RESULTS: #+BEGIN_org With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2, we can produce the following number of widgets based on injection mold wall thicknesses. | wall | vals | widgets | |---+--+--| | 5 mil | 0.01 | 4.00 | | 6 mil | 0.01 | 3.00 | | 8 mil | 0.01 | 25000.00 | #+END_org This is wrong. We discussed it months ago on this ML and, IIRC, Babel should produce #+begin_src org blocks, not #+begin_org. Org documentation specifies it too. Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in that for my given use case, I shouldn't be using =:wrap org=? I didn't read the thread carefully, but you may want to use drawer output instead. In general and permanently moving forward, or as a workaround for the above (taking the first interpretation that =:wrap org= is misbehaving)? Thanks, John Regards, -- Nicolas Goaziou
Re: [O] Error with :wrap org in babel and 8.0-pre
Hello Nicolas, Nicolas Goaziou wrote: John Hendy jw.he...@gmail.com writes: #+RESULTS: #+BEGIN_org With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2, we can produce the following number of widgets based on injection mold wall thicknesses. | wall | vals | widgets | |---+--+--| | 5 mil | 0.01 | 4.00 | | 6 mil | 0.01 | 3.00 | | 8 mil | 0.01 | 25000.00 | #+END_org This is wrong. We discussed it months ago on this ML and, IIRC, Babel should produce #+begin_src org blocks, not #+begin_org. Org documentation specifies it too. Here, I think we confound two different syntaxes: - :results org, which produces #+BEGIN_SRC org..#+END_SRC - :wrap org, which produces #+BEGIN_org..END_org I didn't read the thread carefully, but you may want to use drawer output instead. My mind isn't clear yet about those use cases. Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
John Hendy jw.he...@gmail.com writes: On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, John Hendy jw.he...@gmail.com writes: #+RESULTS: #+BEGIN_org With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2, we can produce the following number of widgets based on injection mold wall thicknesses. | wall | vals | widgets | |---+--+--| | 5 mil | 0.01 | 4.00 | | 6 mil | 0.01 | 3.00 | | 8 mil | 0.01 | 25000.00 | #+END_org This is wrong. We discussed it months ago on this ML and, IIRC, Babel should produce #+begin_src org blocks, not #+begin_org. Org documentation specifies it too. Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in that for my given use case, I shouldn't be using =:wrap org=? Wrong as is the current behaviour is a bug. It is expected to produce #+begin_src org blocks. Its use case is to generate dead data: #+begin_src org ,#+AUTHOR: test #+end_src In that case, the #+AUTHOR keyword isn't applied to current set-up. On the other hand, if you want to generate live data, use drawer: #+results: :RESULTS: #+AUTHOR: test :END: In this example, the keyword is really installed in the buffer. Regards, -- Nicolas Goaziou
Re: [O] Error with :wrap org in babel and 8.0-pre
Nicolas Goaziou n.goaz...@gmail.com writes: John Hendy jw.he...@gmail.com writes: On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, John Hendy jw.he...@gmail.com writes: #+RESULTS: #+BEGIN_org With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2, we can produce the following number of widgets based on injection mold wall thicknesses. | wall | vals | widgets | |---+--+--| | 5 mil | 0.01 | 4.00 | | 6 mil | 0.01 | 3.00 | | 8 mil | 0.01 | 25000.00 | #+END_org This is wrong. We discussed it months ago on this ML and, IIRC, Babel should produce #+begin_src org blocks, not #+begin_org. Org documentation specifies it too. Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in that for my given use case, I shouldn't be using =:wrap org=? Wrong as is the current behaviour is a bug. It is expected to produce #+begin_src org blocks. Its use case is to generate dead data: I disagree, the current behavior is *not* a bug. From the manual. , | 14.8.2.23 ':wrap' | . | | The ':wrap' header argument is used to mark the results of source block | evaluation. The header argument can be passed a string that will be | appended to '#+BEGIN_' and '#+END_', which will then be used to wrap the | results. If not string is specified then the results will be wrapped in | a '#+BEGIN/END_RESULTS' block. ` I think you're confusing :results org with :wrap org. That said, I don't think there is ever a case when you would want to use :wrap org. The solution to the original question is to use :results drawer. Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Error with :wrap org in babel and 8.0-pre
Eric Schulte wrote: Nicolas Goaziou n.goaz...@gmail.com writes: John Hendy jw.he...@gmail.com writes: On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: #+RESULTS: #+BEGIN_org ... #+END_org This is wrong. We discussed it months ago on this ML and, IIRC, Babel should produce #+begin_src org blocks, not #+begin_org. Org documentation specifies it too. Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in that for my given use case, I shouldn't be using =:wrap org=? Wrong as is the current behaviour is a bug. It is expected to produce #+begin_src org blocks. Its use case is to generate dead data: I disagree, the current behavior is *not* a bug. From the manual. , | 14.8.2.23 ':wrap' | . | | The ':wrap' header argument is used to mark the results of source block | evaluation. The header argument can be passed a string that will be | appended to '#+BEGIN_' and '#+END_', which will then be used to wrap the | results. If not string is specified then the results will be wrapped in | a '#+BEGIN/END_RESULTS' block. ` I think you're confusing :results org with :wrap org. And it's even possible to use :wrap SRC org to get the same as :results org... That said, I don't think there is ever a case when you would want to use :wrap org. The solution to the original question is to use :results drawer. Best regards, Seb -- Sebastien Vauban
Re: [O] preview latex fragment with latex_header
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: I introduced LATEX_HEADER_EXTRA keyword, which will do the same as LATEX_HEADER but will not be used to preview latex snippets. We need to document this in the manual. Can you add a note? Also, the docstring of `org-latex-classes' uses [EXTRA] and [NO-EXTRA], but this does not refer to #+LATEX_HEADER_EXTRA so perhaps we should make it more explicit here. Thanks, -- Bastien
[O] Superscripts and subscripts
Aloha all,
With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
export. The space before the caret appears to be the problem.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Error with :wrap org in babel and 8.0-pre
On Mon, Apr 15, 2013 at 3:28 PM, Eric Schulte schulte.e...@gmail.com wrote:
Nicolas Goaziou n.goaz...@gmail.com writes:
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com
wrote:
Hello,
John Hendy jw.he...@gmail.com writes:
#+RESULTS:
#+BEGIN_org
With the assumption of 100 lbs. of input material 1 and 200 lbs. of
material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
| wall | vals | widgets |
|---+--+--|
| 5 mil | 0.01 | 4.00 |
| 6 mil | 0.01 | 3.00 |
| 8 mil | 0.01 | 25000.00 |
#+END_org
This is wrong. We discussed it months ago on this ML and, IIRC, Babel
should produce #+begin_src org blocks, not #+begin_org. Org
documentation specifies it too.
Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in
that for my given use case, I shouldn't be using =:wrap org=?
Wrong as is the current behaviour is a bug. It is expected to produce
#+begin_src org blocks. Its use case is to generate dead data:
I disagree, the current behavior is *not* a bug. From the manual.
,
| 14.8.2.23 ':wrap'
| .
|
| The ':wrap' header argument is used to mark the results of source block
| evaluation. The header argument can be passed a string that will be
| appended to '#+BEGIN_' and '#+END_', which will then be used to wrap the
| results. If not string is specified then the results will be wrapped in
| a '#+BEGIN/END_RESULTS' block.
`
I think you're confusing :results org with :wrap org.
That said, I don't think there is ever a case when you would want to use
:wrap org. The solution to the original question is to use :results
drawer.
Here's my summary of possible options from this thread and others in
which I've tried to do similar things (=:exports results= used in all
cases):
1) =:results output wrap=.
- Documentation: none seems to suggest that this combination is even possible.
- Behavior: Suggested in mailing list thread with Eric Schulte and
works properly for me.
2) =:results output org=.
- Documentation: The results are will be enclosed in a BEGIN_SRC org block.
- Behavior: Results look correct in Org buffer, but exports to LaTeX
in \begin/end{verbatim}.
3) =:results output :wrap org=.
- Documentation: Produces =#+begin/end_org= results block
- Behavior: Wraps results in \begin/end{org}, throws error on
compilation, but compiles into PDF correctly.
4) =:results output drawer=.
- Documentation: The result is wrapped in a RESULTS drawer. This can
be useful for inserting raw or org syntax results in such a way that
their extent is known and they can be automatically removed or
replaced.
- Behavior: Looks correct in both .tex and resultant PDF.
5) =:results output raw=
- Documentation: The results are interpreted as raw Org mode code and
are inserted directly into the buffer.
- Behavior: Seems like exactly what I want... but I get double results
This has helped me know which work and which don't, however I still
find the behavior counter-intuitive and difficult to remember. For
example, there's no reason I would expect =wrap= or =drawer= to have
anything to do with what I'm trying to accomplish. I'm trying to use R
to spit out syntax that's Org compatible... so my intuition would be
to use =:results output org= (or raw) for this.
Either way, I still find the documentation lacking. This thread has
motivated me to dive a bit deeper into a documentation with examples
of *all* results outputs, at least in R since that's what I'm used to.
Not sure if the behavior is tremendously different with other
languages. Eric, I was thinking of appending it to this page:
- http://orgmode.org/worg/org-contrib/babel/header-args.html
Something perhaps with Org results and then a screenshot of side by
side LaTeX output?
Best regards,
John
Best,
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] preview latex fragment with latex_header
Hello, Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: I introduced LATEX_HEADER_EXTRA keyword, which will do the same as LATEX_HEADER but will not be used to preview latex snippets. We need to document this in the manual. Can you add a note? Done. Also, the docstring of `org-latex-classes' uses [EXTRA] and [NO-EXTRA], but this does not refer to #+LATEX_HEADER_EXTRA so perhaps we should make it more explicit here. It does, a few lines above and a few lines below. Done anyway. Regards, -- Nicolas Goaziou
Re: [O] Error with :wrap org in babel and 8.0-pre
On Mon, Apr 15, 2013 at 3:51 PM, Sebastien Vauban
wxhgmqzgw...@spammotel.com wrote:
Eric Schulte wrote:
Nicolas Goaziou n.goaz...@gmail.com writes:
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com
wrote:
John Hendy jw.he...@gmail.com writes:
#+RESULTS:
#+BEGIN_org
...
#+END_org
This is wrong. We discussed it months ago on this ML and, IIRC, Babel
should produce #+begin_src org blocks, not #+begin_org. Org
documentation specifies it too.
Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in that
for my given use case, I shouldn't be using =:wrap org=?
Wrong as is the current behaviour is a bug. It is expected to produce
#+begin_src org blocks. Its use case is to generate dead data:
I disagree, the current behavior is *not* a bug. From the manual.
,
| 14.8.2.23 ':wrap'
| .
|
| The ':wrap' header argument is used to mark the results of source block
| evaluation. The header argument can be passed a string that will be
| appended to '#+BEGIN_' and '#+END_', which will then be used to wrap the
| results. If not string is specified then the results will be wrapped in
| a '#+BEGIN/END_RESULTS' block.
`
I think you're confusing :results org with :wrap org.
And it's even possible to use :wrap SRC org to get the same as :results
org...
True, however I don't get the same output as I used to with this and
think it's essentially useless now. =#+begin_src org/end_src= used to
give me the equivalent of essentially a block of Org-mode syntax that
would be interpreted and parsed just as if it had no #+begin/end
around it. Now, it's output to LaTeX in \begin{verbatim} /
\end{verbatim}. It's treated like source code, not Org-mode text to be
exported.
=#+begin_src org= seems to be no different than =#+begin_example= or
=#+begin_src lang :exports code :eval no=
John
That said, I don't think there is ever a case when you would want to use
:wrap org. The solution to the original question is to use :results
drawer.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
On Mon, Apr 15, 2013 at 2:47 PM, Sebastien Vauban
wxhgmqzgw...@spammotel.com wrote:
Dear Eric,
Eric Schulte wrote:
John Hendy jw.he...@gmail.com writes:
On Fri, Apr 12, 2013 at 5:24 PM, Eric Schulte schulte.e...@gmail.com
wrote:
John Hendy jw.he...@gmail.com writes:
Use :wrap org if your code block produces raw org. E.g.,
#+begin_src sh :results output :wrap org
cat EOF
| a | b |
|---+---|
| 1 | 2 |
EOF
#+end_src
#+RESULTS:
#+BEGIN_org
| a | b |
|---+---|
| 1 | 2 |
#+END_org
Playing a bit with the above code, removing `:results output' to see what
would happen, I'm amazed by the results:
#+begin_src sh :wrap org
cat EOF
| a | b |
|---+---|
| 1 | 2 |
EOF
#+end_src
#+results:
#+BEGIN_org
| | | a | | | b | |
| | ---+--- | | | | | |
| | | 1 | | | 2 | |
#+END_org
Is it expected?
Seems so: http://orgmode.org/worg/org-contrib/babel/header-args.html
That's the example from that page and without adding =verbatim= to the
list of =:results= args, it does that.
As a similar inquiry to behavior, what is the expected output of simply:
#+begin_results
stuff
#+end_results
If I use :wrap with no arguments, I get blocks like that, and the same
LaTeX error as I do for =:wrap org= (even though I know I shouldn't
use that). Just curious what the use-case would be for :wrap with no
args?
! LaTeX Error: Environment results undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.33 \begin{results}
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/wasysym/uwasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/base/ulasy.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/home/jwhendy/.texlive/2012/texmf-dist/tex/latex/amsfonts/umsb.fd)
! LaTeX Error: \begin{document} ended by \end{results}.
Best regards,
John
Best regards,
Seb
--
Sebastien Vauban
Re: [O] preview latex fragment with latex_header
Thanks! -- Bastien
Re: [O] Error with :wrap org in babel and 8.0-pre
John, John Hendy wrote: Here's my summary of possible options from this thread and others in which I've tried to do similar things (=:exports results= used in all cases): 1) =:results output wrap=. - Documentation: none seems to suggest that this combination is even possible. - Behavior: Suggested in mailing list thread with Eric Schulte and works properly for me. Just to be complete, :results wrap has been deprecated since Org 7.9.2, and replaced by :results drawer. Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
John,
John Hendy wrote:
I think you're confusing :results org with :wrap org.
And it's even possible to use :wrap SRC org to get the same as :results
org...
True, however I don't get the same output as I used to with this and
think it's essentially useless now. =#+begin_src org/end_src= used to
give me the equivalent of essentially a block of Org-mode syntax that
would be interpreted and parsed just as if it had no #+begin/end
around it. Now, it's output to LaTeX in \begin{verbatim} /
\end{verbatim}. It's treated like source code, not Org-mode text to be
exported.
=#+begin_src org= seems to be no different than =#+begin_example=
Yes, but for the syntax highlighting.
or =#+begin_src lang :exports code :eval no=
Yes, except that lang must be the same in the source and results block: so a
SQL code block producing SQL code, or R producing R, etc.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Best way to generate textile from orgmode ?
On Fri, Apr 12, 2013 at 07:36:26AM +0200, Bastien wrote: For this you need to define a new derived exporter from 'ascii. Get a fresh clone of Org and see how this is done in ox-md.el, which create a MarkDown exporter by deriving it from the ascii one. Actually ox-md derives from ox-html. It was not clear to me why that is the case though. I would have thought ox-ascii is the obvious choice. Only reason I could think of was referencing/linking is more natural with ox-html. -- Suvayu Open source is the future. It sets us free.
Re: [O] Error with :wrap org in babel and 8.0-pre
On Mon, Apr 15, 2013 at 4:44 PM, Sebastien Vauban
wxhgmqzgw...@spammotel.com wrote:
John,
John Hendy wrote:
I think you're confusing :results org with :wrap org.
And it's even possible to use :wrap SRC org to get the same as :results
org...
True, however I don't get the same output as I used to with this and
think it's essentially useless now. =#+begin_src org/end_src= used to
give me the equivalent of essentially a block of Org-mode syntax that
would be interpreted and parsed just as if it had no #+begin/end
around it. Now, it's output to LaTeX in \begin{verbatim} /
\end{verbatim}. It's treated like source code, not Org-mode text to be
exported.
=#+begin_src org= seems to be no different than =#+begin_example=
Yes, but for the syntax highlighting.
or =#+begin_src lang :exports code :eval no=
Yes, except that lang must be the same in the source and results block: so a
SQL code block producing SQL code, or R producing R, etc.
I don't think so. I took the results from my code example above, put
them in a new headline and then only exported that headline with =C-c
C-e C-s l p=:
* Heading
Block isolated from everything la la la.
#+BEGIN_src R :exports code :eval no
With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
| wall | vals | widgets |
|---+--+--|
| 5 mil | 0.01 | 4.00 |
| 6 mil | 0.01 | 3.00 |
| 8 mil | 0.01 | 25000.00 |
#+END_src
That exports verbatim and looks no different than =#+begin_src org=
and =#+begin_example=. There is only a code block, no results in this
case.
John
Best regards,
Seb
--
Sebastien Vauban
[O] Fix for bug in org-capture
I tried to make two submenus to my org-capture templates: a prefix key t (for TODO) and a prefix key T (for today's TODO). When I tried to use them, the T key did not appear and was not accepted. Looking more deeply, it appears that it was filtered out by a mistakenly case-folding (or at least potentially case-folding) search in org-capture. I am attaching a diff which has the two line fix for this bug. diff --git a/lisp/org-capture.el b/lisp/org-capture.el index d8e62a1..861d640 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -1431,7 +1431,8 @@ only the bare key is returned. (insert prefix [ dkey ] ...ddesc ... \n) ;; Skip keys which are below this prefix (setq re (concat \\` (regexp-quote dkey))) - (while (and tbl (string-match re (caar tbl))) (pop tbl))) + (let ((case-fold-search nil)) + (while (and tbl (string-match re (caar tbl))) (pop tbl ((= 2 (length (car tbl))) ;; Not yet a usable description, skip it )
Re: [O] evil-mode movement keys in the agenda?
Works like a charm! Thank you very much! On Thu, Apr 11, 2013 at 5:06 AM, Michael Strey mst...@strey.biz wrote: Marcelo, I'm using only the following two lines. #+BEGIN_SRC emacs-lisp ;;; org agenda -- leave in emacs mode but add j k (define-key org-agenda-mode-map j 'evil-next-line) (define-key org-agenda-mode-map k 'evil-previous-line) #+END_SRC It's a good compromise. Regards -- Michael Strey http://www.strey.biz
Re: [O] Error with :wrap org in babel and 8.0-pre
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 15, 2013 at 3:28 PM, Eric Schulte schulte.e...@gmail.com wrote:
Nicolas Goaziou n.goaz...@gmail.com writes:
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com
wrote:
Hello,
John Hendy jw.he...@gmail.com writes:
#+RESULTS:
#+BEGIN_org
With the assumption of 100 lbs. of input material 1 and 200 lbs. of
material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
| wall | vals | widgets |
|---+--+--|
| 5 mil | 0.01 | 4.00 |
| 6 mil | 0.01 | 3.00 |
| 8 mil | 0.01 | 25000.00 |
#+END_org
This is wrong. We discussed it months ago on this ML and, IIRC, Babel
should produce #+begin_src org blocks, not #+begin_org. Org
documentation specifies it too.
Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in
that for my given use case, I shouldn't be using =:wrap org=?
Wrong as is the current behaviour is a bug. It is expected to produce
#+begin_src org blocks. Its use case is to generate dead data:
I disagree, the current behavior is *not* a bug. From the manual.
,
| 14.8.2.23 ':wrap'
| .
|
| The ':wrap' header argument is used to mark the results of source block
| evaluation. The header argument can be passed a string that will be
| appended to '#+BEGIN_' and '#+END_', which will then be used to wrap the
| results. If not string is specified then the results will be wrapped in
| a '#+BEGIN/END_RESULTS' block.
`
I think you're confusing :results org with :wrap org.
That said, I don't think there is ever a case when you would want to use
:wrap org. The solution to the original question is to use :results
drawer.
Here's my summary of possible options from this thread and others in
which I've tried to do similar things (=:exports results= used in all
cases):
Please submit patches to the documentation where it is inaccurate or
insufficient.
1) =:results output wrap=.
- Documentation: none seems to suggest that this combination is even possible.
- Behavior: Suggested in mailing list thread with Eric Schulte and
works properly for me.
2) =:results output org=.
- Documentation: The results are will be enclosed in a BEGIN_SRC org block.
- Behavior: Results look correct in Org buffer, but exports to LaTeX
in \begin/end{verbatim}.
3) =:results output :wrap org=.
- Documentation: Produces =#+begin/end_org= results block
- Behavior: Wraps results in \begin/end{org}, throws error on
compilation, but compiles into PDF correctly.
4) =:results output drawer=.
- Documentation: The result is wrapped in a RESULTS drawer. This can
be useful for inserting raw or org syntax results in such a way that
their extent is known and they can be automatically removed or
replaced.
- Behavior: Looks correct in both .tex and resultant PDF.
5) =:results output raw=
- Documentation: The results are interpreted as raw Org mode code and
are inserted directly into the buffer.
- Behavior: Seems like exactly what I want... but I get double results
I bet that this is appearing twice in the export, because with raw it is
impossible to remove results, so if you have results existing in the
buffer, and you are re-evaluating on export, then you'll get duplicates.
Evaluate this code block again in the buffer and then re-export and I
bet you'll get triplicate results. :)
This has helped me know which work and which don't, however I still
find the behavior counter-intuitive and difficult to remember. For
example, there's no reason I would expect =wrap= or =drawer= to have
anything to do with what I'm trying to accomplish. I'm trying to use R
to spit out syntax that's Org compatible... so my intuition would be
to use =:results output org= (or raw) for this.
Either way, I still find the documentation lacking. This thread has
motivated me to dive a bit deeper into a documentation with examples
of *all* results outputs, at least in R since that's what I'm used to.
Not sure if the behavior is tremendously different with other
languages. Eric, I was thinking of appending it to this page:
- http://orgmode.org/worg/org-contrib/babel/header-args.html
Sounds great. Where your results generalize past R, please think about
a documentation patch as well.
Something perhaps with Org results and then a screenshot of side by
side LaTeX output?
Sounds great. Thanks for helping to improve the documentation!
Best regards,
John
Best,
--
Eric Schulte
http://cs.unm.edu/~eschulte
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] Error with :wrap org in babel and 8.0-pre
On Mon, Apr 15, 2013 at 5:38 PM, Eric Schulte schulte.e...@gmail.com wrote:
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 15, 2013 at 3:28 PM, Eric Schulte schulte.e...@gmail.com wrote:
Nicolas Goaziou n.goaz...@gmail.com writes:
John Hendy jw.he...@gmail.com writes:
On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com
wrote:
Hello,
John Hendy jw.he...@gmail.com writes:
#+RESULTS:
#+BEGIN_org
With the assumption of 100 lbs. of input material 1 and 200 lbs. of
material 2,
we can produce the following number of widgets based on injection mold
wall thicknesses.
| wall | vals | widgets |
|---+--+--|
| 5 mil | 0.01 | 4.00 |
| 6 mil | 0.01 | 3.00 |
| 8 mil | 0.01 | 25000.00 |
#+END_org
This is wrong. We discussed it months ago on this ML and, IIRC, Babel
should produce #+begin_src org blocks, not #+begin_org. Org
documentation specifies it too.
Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in
that for my given use case, I shouldn't be using =:wrap org=?
Wrong as is the current behaviour is a bug. It is expected to produce
#+begin_src org blocks. Its use case is to generate dead data:
I disagree, the current behavior is *not* a bug. From the manual.
,
| 14.8.2.23 ':wrap'
| .
|
| The ':wrap' header argument is used to mark the results of source block
| evaluation. The header argument can be passed a string that will be
| appended to '#+BEGIN_' and '#+END_', which will then be used to wrap the
| results. If not string is specified then the results will be wrapped in
| a '#+BEGIN/END_RESULTS' block.
`
I think you're confusing :results org with :wrap org.
That said, I don't think there is ever a case when you would want to use
:wrap org. The solution to the original question is to use :results
drawer.
Here's my summary of possible options from this thread and others in
which I've tried to do similar things (=:exports results= used in all
cases):
Please submit patches to the documentation where it is inaccurate or
insufficient.
1) =:results output wrap=.
- Documentation: none seems to suggest that this combination is even
possible.
- Behavior: Suggested in mailing list thread with Eric Schulte and
works properly for me.
2) =:results output org=.
- Documentation: The results are will be enclosed in a BEGIN_SRC org block.
- Behavior: Results look correct in Org buffer, but exports to LaTeX
in \begin/end{verbatim}.
3) =:results output :wrap org=.
- Documentation: Produces =#+begin/end_org= results block
- Behavior: Wraps results in \begin/end{org}, throws error on
compilation, but compiles into PDF correctly.
4) =:results output drawer=.
- Documentation: The result is wrapped in a RESULTS drawer. This can
be useful for inserting raw or org syntax results in such a way that
their extent is known and they can be automatically removed or
replaced.
- Behavior: Looks correct in both .tex and resultant PDF.
5) =:results output raw=
- Documentation: The results are interpreted as raw Org mode code and
are inserted directly into the buffer.
- Behavior: Seems like exactly what I want... but I get double results
I bet that this is appearing twice in the export, because with raw it is
impossible to remove results, so if you have results existing in the
buffer, and you are re-evaluating on export, then you'll get duplicates.
Evaluate this code block again in the buffer and then re-export and I
bet you'll get triplicate results. :)
Agreed, and this came up with you and I before on the list:
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01224.html
The solution was to do =:results output org= instead of =:results
output raw=. That's no longer the case.
This has helped me know which work and which don't, however I still
find the behavior counter-intuitive and difficult to remember. For
example, there's no reason I would expect =wrap= or =drawer= to have
anything to do with what I'm trying to accomplish. I'm trying to use R
to spit out syntax that's Org compatible... so my intuition would be
to use =:results output org= (or raw) for this.
Either way, I still find the documentation lacking. This thread has
motivated me to dive a bit deeper into a documentation with examples
of *all* results outputs, at least in R since that's what I'm used to.
Not sure if the behavior is tremendously different with other
languages. Eric, I was thinking of appending it to this page:
- http://orgmode.org/worg/org-contrib/babel/header-args.html
Sounds great. Where your results generalize past R, please think about
a documentation patch as well.
Something perhaps with Org results and then a screenshot of side by
side LaTeX output?
Sounds great. Thanks for helping to improve the documentation!
No problem. Prior to that, I have unanswered questions:
- Is the \begin/end{verbatim} wrapping the expected result for
Re: [O] Error with :wrap org in babel and 8.0-pre
Sounds great. Thanks for helping to improve the documentation!
No problem. Prior to that, I have unanswered questions:
- Is the \begin/end{verbatim} wrapping the expected result for
#+begin/end_src org?
Yes, this is the default export for any src block, see the following
page of the manual. There are other options as well.
(info (org)Literal Examples)
- Is =:results drawer= what we want as the syntax to get org syntax
parsed by the exporter?
Yes.
Just guessing from the name, it strikes me as a fix or enhancement for
some other behavior/option that's now being applied to code as an
after thought.
As I recall this solution came about because drawers are the best (maybe
only) way to demarcate a region without changing its semantics (which is
exactly what we want in this case).
- Can we prune some options/syntax that's no longer necessary? For
example, what does =:wrap= (no argument provided) do?
Wrap has been deprecated for some time. Perhaps it has been long enough
that we can go ahead and remove it entirely from the code and
documentation at this point.
Or =:wrap src org= / =:results output org=? It seems that these once
served a purpose but no longer accomplish anything useful.
I would be happy to remove support for =:results org=. It has been
supplanted by =:results drawer=, and I don't believe there is any other
use for it. Unless someone complains, I'd be happy to remove both.
Cheers,
Thanks,
John
Best regards,
John
Best,
--
Eric Schulte
http://cs.unm.edu/~eschulte
--
Eric Schulte
http://cs.unm.edu/~eschulte
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] phone links...
Bastien b...@gnu.org writes: Hi Feng, thanks for your reply. I'll let Grégoire decide on what to apply to org-contacts.el. Best, It's a good decision --
Re: [O] Error with :wrap org in babel and 8.0-pre
Hi all,
Eric Schulte schulte.e...@gmail.com writes:
- Can we prune some options/syntax that's no longer necessary? For
example, what does =:wrap= (no argument provided) do?
Wrap has been deprecated for some time. Perhaps it has been long enough
that we can go ahead and remove it entirely from the code and
documentation at this point.
I think :wrap is useful. It provides a very direct way to generate code
that can be exported to an arbitrary LaTeX environment. Say I find a new
LaTeX package that defines a =cutemarkup= environment, so I want
something like this the LaTeX file:
\begin{cutemarkup}
...
\end{cutemarkup}
Then, with babel:
#+begin_src lang :wrap cutemarkup
...
#+end_src
gets me what I want,
#+begin_cutemarkup
...
#+end_cutemarkup
IIRC, this is one reason why :wrap is there (thanks, Eric).
Perhaps this result is possible some other way? I don't know, but it
seems to me that :wrap is still potentially useful and we might want to
keep it around.
Tom
--
Thomas S. Dye
http://www.tsdye.com
[O] Looking for a way to scrape a webpage to a org-mode note (text+images)
Hya all im looking for a way/wondering if anyone has a homebrew script he uses, to scrape a webpage into org. That is mark the text+images you want (or just do it for the whole page), and then paste that into org-mode as a note, with the images as inline images (stored locally somewhere as attachments are perhaps?) any one know of a way to do that? best Z.
Re: [O] Error with :wrap org in babel and 8.0-pre
t...@tsdye.com (Thomas S. Dye) writes:
Hi all,
Eric Schulte schulte.e...@gmail.com writes:
- Can we prune some options/syntax that's no longer necessary? For
example, what does =:wrap= (no argument provided) do?
Wrap has been deprecated for some time. Perhaps it has been long enough
that we can go ahead and remove it entirely from the code and
documentation at this point.
I think :wrap is useful. It provides a very direct way to generate code
that can be exported to an arbitrary LaTeX environment. Say I find a new
LaTeX package that defines a =cutemarkup= environment, so I want
something like this the LaTeX file:
\begin{cutemarkup}
...
\end{cutemarkup}
Then, with babel:
#+begin_src lang :wrap cutemarkup
...
#+end_src
gets me what I want,
#+begin_cutemarkup
...
#+end_cutemarkup
IIRC, this is one reason why :wrap is there (thanks, Eric).
Perhaps this result is possible some other way? I don't know, but it
seems to me that :wrap is still potentially useful and we might want to
keep it around.
Tom
Hi Tom,
This is a reasonable use case, and I personally don't know of another
way to get these results. So I guess it is just the use of wrap to
delimit Org-mode results which is deprecated, and we *do* still have a
use for the :wrap header argument in general.
Thanks,
--
Eric Schulte
http://cs.unm.edu/~eschulte
[O] Typo in doc string of org-small-year-to-year
The doc string of org-small-year-to-year says: , | Convert 2-digit years into 4-digit years. | 38-99 are mapped into 1938-1999. 1-37 are mapped into 2001-2007. ` That 2007 should be 2037. -- Nick
Re: [O] Typo in doc string of org-small-year-to-year
Fixed, thanks. - Carsten On 16.4.2013, at 05:01, Nick Dokos ndo...@gmail.com wrote: The doc string of org-small-year-to-year says: , | Convert 2-digit years into 4-digit years. | 38-99 are mapped into 1938-1999. 1-37 are mapped into 2001-2007. ` That 2007 should be 2037. -- Nick
[O] [bug] list sorting wrong-type-argument error
To reproduce, place point at one of the entries and do: C-c ^ t === - State DONE from SOMESTATE [2012-12-28 Fri 02:16] - Note taken on [2012-12-29 Sat 02:15] \\ test === wrong-type-argument integer-or-marker-p nil in org-list-get-item-end-before-blank. I tried loading from source for bt but got a recursive load error. === Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] GNU Emacs 24.3.1 creates macro-expansion failure messages
Bastien bzg at gnu.org writes: I gather this is not with emacs -Q. Can you narrow down to what causes this in your configuration? I decided to start with a new .emacs file by commenting out every line then adding back the commands starting with orgmode. Everything worked fine so I can only assume that I had been loading an old package that caused a conflict. Now that I am happy with the latest version of org-mode and GNU Emacs I wont pursue the cause of my reported problem - obviously something of my own making. It is good to have a much cleaner .emacs file. I deleted a lot of code of things I have tried out in the past and dont use. Charles
