Re: [O] [BUG] New latex exporter: Not respecting author:nil and timestamp:nil
Hello Nicolas,
sorry for the late reply.
On 10月 20 2012, Nicolas Goaziou n.goaz...@gmail.com wrote:
IIUC, there's a mismatch between current behaviour (author:nil =
\author{}) and what you want (author:nil = no author command at all).
I don't mind switching to the second option if there's no unwanted side
effect.
It would be good if no author command is export. please implement it.
Thanks.,
--
ఎందరో మహానుభావులు అందరికి వందనములు
YYR
Re: [O] [BUG] New latex exporter: Not respecting author:nil and timestamp:nil
Hello, Yagnesh Raghava Yakkala h...@yagnesh.org writes: It would be good if no author command is export. please implement it. Done. Note: author:nil _and_ email:t will still use the email as the argument of the author command. Regards, -- Nicolas Goaziou
[O] htmlize and #+INCLUDE:
Hi all, Is there something special to do for htmlize to process an #+INCLUDE'd source file ? Up to now, it seems to ignore it. I'm using the new exporter. Besides this, as far as I Can see, I have to use : #+BEGIN_SRC java but #+INCLUDE: file java Why to use a colon in one case and not in the other one? Or am I wrong here? Best regards and thanks in advance for explanations Fabrice
[O] Capturing column view and LOGBOOK state change entries?
Morning, I have been reading and playing around with column view and capturing column view, but am unable to work-out how to view LOGBOOK entries. I record a note on certain state changes and would like to output these to a org table. Capturing column view / dynamic block looks like the way to go. Could you help? Many thanks, 'Mash
[O] [Bug] Strange behavior of property-search and org-tags-view
Hi all Whenever I do a property-search (C-a / p) or an org-tags-view, some org-buffers are touched and need to be saved again, i.e. they display the ** flag in the status line and in Ibuffer. It is always the same three files, that seemingly have changed (in fact, they didn't change at all). They all belong to my org-agenda-files but this contains many other files too, which remain unchanged. So, there are two wired miracles involved: 1. What makes these three files so specially vulnerable? 2. Why does any file (apparently) change at all by a search operation? I'm using Emacs 23.3.1 under Ubuntu 11.10 and org-mode 7.8.03 of the sticky branch. Thanks for help Sven
Re: [O] [feature] Cut paste of subtree
Hello Yagnesh, Yagnesh Raghava Yakkala wrote: On 10月 31 2012, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org wrote: Since more or less one month or so, I've seen a change in the behavior of C-c C-x C-w, when cutting and pasting a subtree. I did know about this key binding, thanks for letting me know.. generally I go to the beginning of the heading I fold it and cut it., may be work around for you.. coming the problem, I can confirm the behavior. A shot in the dark. I tested your patch. It does what it should -- thanks! However, testing it with C-c C-x C-y (for pasting the subtree), I've discovered there was a need to remove the same type of line in org-paste-subtree. The following patch does it all. Thanks for your help. From b644b0bd2aaf9c19c62d60b69702733e4999a11d Mon Sep 17 00:00:00 2001 From: Sebastien Vauban wxhgmqzgw...@spammotel.com Date: Thu, 1 Nov 2012 13:04:19 +0100 Subject: [PATCH] When pasting a copied subtree, respect the whitelines before and after * org.el (org-copy-subtree, org-paste-subtree): Remove badly inserted whitelines, when pasting a copied subtree. --- lisp/org.el |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 67e41e5..39e741b 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7721,7 +7721,6 @@ useful if the caller implements cut-and-paste as copy-then-paste-then-cut. (if (org-called-interactively-p 'any) (org-back-to-heading nil) ; take what looks like a subtree (org-back-to-heading t)) ; take what is really there -(org-back-over-empty-lines) (setq beg (point)) (skip-chars-forward \t\r\n) (save-match-data @@ -7731,7 +7730,6 @@ useful if the caller implements cut-and-paste as copy-then-paste-then-cut. (org-forward-heading-same-level (1- n) t) (error nil)) (org-end-of-subtree t t)) -(org-back-over-empty-lines) (setq end (point)) (goto-char beg0) (when ( end beg) @@ -7822,7 +7820,6 @@ the inserted text when done. (delete-region (point-at-bol) (point))) ;; Paste (beginning-of-line (if (bolp) 1 2)) - (unless for-yank (org-back-over-empty-lines)) (setq beg (point)) (and (fboundp 'org-id-paste-tracker) (org-id-paste-tracker txt)) (insert-before-markers txt) -- 1.7.9 Best regards, Seb -- Sebastien Vauban
Re: [O] [feature] Cut paste of subtree
However, testing it with C-c C-x C-y (for pasting the subtree) or simply C-y ?? Thanks., -- ఎందరో మహానుభావులు అందరికి వందనములు YYR
Re: [O] [feature] Cut paste of subtree
Hi Yagnesh, Yagnesh Raghava Yakkala wrote: However, testing it with C-c C-x C-y (for pasting the subtree) or simply C-y ?? With the above patch, _both_ C-y and C-c C-x C-y now work as expected. Best regards, Seb -- Sebastien Vauban
Re: [O] TeX-master: TeX-master is let-bound
Nick Dokos nicholas.do...@hp.com writes: Hi Nick, were you able to reproduce my problem? Christopher Schmidt christop...@ch.ristopher.com wrote: Nick Dokos nicholas.do...@hp.com writes: In any case, if you can get rid of the let-bind (or the need to muck with TeX-master at all within org), without introducing a regression, we are all ears. I think adding (require 'tex nil t) before the let form is a nice fix. Not really: you end up pulling in auctex even if you are not going to use it. What do you think about (when to-buffer (let ((sym 'latex-mode)) (while (symbolp sym) (setq sym (symbol-function sym))) (when (eq (car-safe sym) 'autoload) (load (cadr sym) sym t t ? Christopher
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
On Wed, Oct 31, 2012 at 5:53 PM, Nick Dokos nicholas.do...@hp.com wrote: John Hendy jw.he...@gmail.com wrote: On Wed, Oct 31, 2012 at 3:12 PM, cbe...@tajo.ucsd.edu wrote: John Hendy jw.he...@gmail.com writes: On Wed, Oct 31, 2012 at 11:41 AM, span dir=ltrmailto: cbe...@tajo.ucsd.edu/span wrote: John Hendy mailto:jw.he...@gmail.com writes: I edited the subject to be more concise/clear.I let orgmode chug away on reading in some ~10-30mb csv files for nearly 30min. [rest deleted] You need an ECM.I did my best to provide one, other than the file, which I offered to provide if others requested that I upload it somewhere. Since you have done so, so have I: - https://docs.google.com/open?id=0BzQupOSnvw08WHdabHh5VVczRGM Let me know if that doesn#39;t work. I put it on Google docs and sometimes have issues with the sharing settings... Not an ECM in my book, but ... What else would you like? I provided: - the config - the data - how to [attempt to] reproduce - the org-mode text Smaller set of data I'd guess :-) But it does not seem to be the size of the data that matters. On my 4 year old MacBook: , | | #+PROPERTY: session *R* | | #+name: bigcsv | #+begin_src R | bigcsv - Sys.glob(~/Downloads/*.csv) | #+end_src | | #+RESULTS: bigcsv | : /Users/cberry/Downloads/test-file.csv | | #+name: readbig | #+begin_src R :results output | system.time( | tmp - read.csv(bigcsv) | ) | | #+end_src | | #+RESULTS: readbig | :user system elapsed | : 5.679 0.306 6.002 | ` About the same as running from ESS. Not sure what to say. Looking for ways to troubleshoot or confirm. Since you can't confirm, any suggestions on where I should look for my issue? I can't explain it! All I know is that org chugs and chugs and the direct execution in ESS session is lightning fast. A few things to try in no particular order: This was extremely helpful. Thanks for the suggestions. Here's my attempt at an ECM, though I'm going to keep using the big file since that's what's actually doing it an I've already uploaded it :) - Using emacs config here: http://pastebin.com/raw.php?i=iTbRtCE9 - Using this org-mode file: #+begin_src org * headline #+begin_src R :session r :results silent # file here: https://docs.google.com/uc?export=downloadconfirm=no_antivirusid=0BzQupOSnvw08WHdabHh5VVczRGM data - read.csv(path/to/file.csv) #+end_src #+end_src org - Execute block with C-c C-c after downloading and changing path o run top (or whatever equivalent is available on your OS) and see whether the CPU (or one of the CPUs) gets pegged at 100% utilization and stays there. If yes, that's an indication of an infinite loop somewhere. - quit any other instances of emacs/R - start `top` in terminal - execute block - Use '' '' to sort back and forth between cpu and ram Observations - R is at 80-100% cpu for about 5sec - Then emacs shifts to fairly constant ~100% cpu usage - After about a minute, the minibuffer expands to ~1/3 of the window height and fills with the csv data - Finished after ~5min total time - So, R took about 5sec, emacs took another 5min to finish o run vmstat (or equivalent) and see if any of the counters are out of whack. That requires some experience though. I'll skip for now; no experience with that. o use elp-instrument-package to instrument org and run the test, getting a profile. I'm not sure whether the results will be useful, since you are going to interrupt the test when you run out of patience, but it cannot hurt and it might tell you something useful. o run your ECM on a different computer/OS/emacs installation. Being able to compare things side by side is often very useful. o Halve your file and run the test on each half (but that's probably not the problem given Chuck's results). o Reinstall org from scratch - you might have some corruption in one of the compiled files that's causing it to go into an infinite loop. - `cd ~/.elisp` - `sudo rm -r org.git` - `git clone http://git://orgmode.org/org-mode.git org.git` - cd org.git make clean make make doc - Quit previous emacs instance; reopen - Remove (require 'org-install) per prompt; restart again - Repeat `top` experiment Results: - Didn't even see R flash on the screen this time; emacs just jumped to 100% - After 1min 10sec, the minibuffer filled with data - At that point I quit, as I think it will be a repeat of the above o Turn on debug-on-quit, start your test, wait a bit and then interrupt it. Check the backtrace. Do it again and check whether the backtrace looks the same. That's often an indication of an infinite loop (inferring an infinite loop from a two element sample
Re: [O] TeX-master: TeX-master is let-bound
Christopher Schmidt christop...@ch.ristopher.com wrote: Nick Dokos nicholas.do...@hp.com writes: Hi Nick, were you able to reproduce my problem? No - I didn't try to duplicate what ELPA does (or install through it): I just don't have the time for that. Christopher Schmidt christop...@ch.ristopher.com wrote: Nick Dokos nicholas.do...@hp.com writes: In any case, if you can get rid of the let-bind (or the need to muck with TeX-master at all within org), without introducing a regression, we are all ears. I think adding (require 'tex nil t) before the let form is a nice fix. Not really: you end up pulling in auctex even if you are not going to use it. What do you think about (when to-buffer (let ((sym 'latex-mode)) (while (symbolp sym) (setq sym (symbol-function sym))) (when (eq (car-safe sym) 'autoload) (load (cadr sym) sym t t Haven't even tried to decypher this yet, but I assume it makes your problem go away? I can try it with my setup and see if it causes any problems. Nick
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
John Hendy jw.he...@gmail.com wrote: o run top (or whatever equivalent is available on your OS) and see whether the CPU (or one of the CPUs) gets pegged at 100% utilization and stays there. If yes, that's an indication of an infinite loop somewhere. - quit any other instances of emacs/R - start `top` in terminal - execute block - Use '' '' to sort back and forth between cpu and ram Observations - R is at 80-100% cpu for about 5sec - Then emacs shifts to fairly constant ~100% cpu usage - After about a minute, the minibuffer expands to ~1/3 of the window height and fills with the csv data - Finished after ~5min total time - So, R took about 5sec, emacs took another 5min to finish So not an infinite loop. That's progress ;-) Perhaps emacs is thrashing? If you are on linux, use swapon -s or (perhaps better) iostat, or (perhaps even better, at least if you are on the Gnome 2.x desktop[fn:1]), run the system monitor applet, click Properties, enable all the monitored resources (cpu, mem, net, swap, load, disk) and watch it while you are running the test: in particular, check memory and swap. If you are swapping even a little bit, that's enough to cause severe performacne problems[fn:2], which can be cured by using less memory (so stop any memory hogs from running) or by adding memory. Top can also show you memory and swap so maybe that's the quickest way to check. Nick Footnotes: [fn:1] You can pobably do this in other desktops but I have no experience with them, so no guidance to give. [fn:2] My old laptop with 1GB of memory would swap whenever I ran mairix to index my mail: it would take 30 minutes or so to finish. My new(er) laptop has 4GB and finishes in 30 seconds: memory usage peaks at about 2.5 GB.
Re: [O] htmlize and #+INCLUDE:
Hello, Fabrice Popineau fabrice.popin...@gmail.com writes: Is there something special to do for htmlize to process an #+INCLUDE'd source file ? No. Besides this, as far as I Can see, I have to use : #+BEGIN_SRC java but #+INCLUDE: file java It's #+INCLUDE: file src java Why to use a colon in one case and not in the other one? Or am I wrong here? #+INCLUDE: is a keyword, like #+TITLE: whereas #+BEGIN_SRC is a block, like #+BEGIN_CENTER. Not the same object, not the same syntax. Regards, -- Nicolas Goaziou
Re: [O] htmlize and #+INCLUDE:
Is there something special to do for htmlize to process an #+INCLUDE'd source file ? No. Do you mean that it should work out of the box or that it is not working at all? Because for me: - I can htmlize src blocks (with BEGIN_SRC) - I can highlight src blocks with syntaxhighlighter (by new-exporting to html) - I can highlight included src blocks with syntaxhighlighter Given the fact that '#+INCLUDE: file src java' is expanded into an src block, I assume that htmlize should apply there too. Am I wrong? Greetings, Fabrice
Re: [O] htmlize and #+INCLUDE:
Fabrice Popineau fabrice.popin...@gmail.com writes: Given the fact that '#+INCLUDE: file src java' is expanded into an src block, I assume that htmlize should apply there too. Am I wrong? I think you're correct. A quick test shows me fontification is fine. Do you have an ECM to show the problem? Regards,
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
On Thu, Nov 1, 2012 at 10:38 AM, Nick Dokos nicholas.do...@hp.com wrote: John Hendy jw.he...@gmail.com wrote: o run top (or whatever equivalent is available on your OS) and see whether the CPU (or one of the CPUs) gets pegged at 100% utilization and stays there. If yes, that's an indication of an infinite loop somewhere. - quit any other instances of emacs/R - start `top` in terminal - execute block - Use '' '' to sort back and forth between cpu and ram Observations - R is at 80-100% cpu for about 5sec - Then emacs shifts to fairly constant ~100% cpu usage - After about a minute, the minibuffer expands to ~1/3 of the window height and fills with the csv data - Finished after ~5min total time - So, R took about 5sec, emacs took another 5min to finish So not an infinite loop. That's progress ;-) Perhaps emacs is thrashing? If you are on linux, use swapon -s or (perhaps better) iostat, or (perhaps even better, at least if you are on the Gnome 2.x desktop[fn:1]), run the system monitor applet, click Properties, enable all the monitored resources (cpu, mem, net, swap, load, disk) and watch it while you are running the test: in particular, check memory and swap. If you are swapping even a little bit, that's enough to cause severe performacne problems[fn:2], which can be cured by using less memory (so stop any memory hogs from running) or by adding memory. Top can also show you memory and swap so maybe that's the quickest way to check. It's not swap... :) $ free total used free sharedbuffers cached Mem: 397886424271321551732 0 122072 509140 -/+ buffers/cache:17959202182944 Swap:0 0 0 Best regards, John Nick Footnotes: [fn:1] You can pobably do this in other desktops but I have no experience with them, so no guidance to give. [fn:2] My old laptop with 1GB of memory would swap whenever I ran mairix to index my mail: it would take 30 minutes or so to finish. My new(er) laptop has 4GB and finishes in 30 seconds: memory usage peaks at about 2.5 GB.
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
On Thu, Nov 1, 2012 at 10:38 AM, Nick Dokos nicholas.do...@hp.com wrote: John Hendy jw.he...@gmail.com wrote: o run top (or whatever equivalent is available on your OS) and see whether the CPU (or one of the CPUs) gets pegged at 100% utilization and stays there. If yes, that's an indication of an infinite loop somewhere. - quit any other instances of emacs/R - start `top` in terminal - execute block - Use '' '' to sort back and forth between cpu and ram Observations - R is at 80-100% cpu for about 5sec - Then emacs shifts to fairly constant ~100% cpu usage - After about a minute, the minibuffer expands to ~1/3 of the window height and fills with the csv data - Finished after ~5min total time - So, R took about 5sec, emacs took another 5min to finish So not an infinite loop. That's progress ;-) Perhaps emacs is thrashing? If you are on linux, use swapon -s or (perhaps better) iostat, or (perhaps even better, at least if you are on the Gnome 2.x desktop[fn:1]), run the system monitor applet, click Properties, enable all the monitored resources (cpu, mem, net, swap, load, disk) and watch it while you are running the test: in particular, check memory and swap. If you are swapping even a little bit, that's enough to cause severe performacne problems[fn:2], which can be cured by using less memory (so stop any memory hogs from running) or by adding memory. Oh, and I'm conscious of R using RAM, so I tried to run this stuff without browsers open, no other R sessions, etc. Prior to running R and without a browser, I'm typically around 10-15% RAM utilized... I have 4gb, so that should be enough to read this, especially per Chuck's results! This is also an i7 work computer. It should fly (and in the ESS session itself, it does). John Top can also show you memory and swap so maybe that's the quickest way to check. Nick Footnotes: [fn:1] You can pobably do this in other desktops but I have no experience with them, so no guidance to give. [fn:2] My old laptop with 1GB of memory would swap whenever I ran mairix to index my mail: it would take 30 minutes or so to finish. My new(er) laptop has 4GB and finishes in 30 seconds: memory usage peaks at about 2.5 GB.
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
John Hendy jw.he...@gmail.com wrote: On Thu, Nov 1, 2012 at 10:38 AM, Nick Dokos nicholas.do...@hp.com wrote: John Hendy jw.he...@gmail.com wrote: o run top (or whatever equivalent is available on your OS) and see whether the CPU (or one of the CPUs) gets pegged at 100% utilization and stays there. If yes, that's an indication of an infinite loop somewhere. - quit any other instances of emacs/R - start `top` in terminal - execute block - Use '' '' to sort back and forth between cpu and ram Observations - R is at 80-100% cpu for about 5sec - Then emacs shifts to fairly constant ~100% cpu usage - After about a minute, the minibuffer expands to ~1/3 of the window height and fills with the csv data - Finished after ~5min total time - So, R took about 5sec, emacs took another 5min to finish So not an infinite loop. That's progress ;-) Perhaps emacs is thrashing? If you are on linux, use swapon -s or (perhaps better) iostat, or (perhaps even better, at least if you are on the Gnome 2.x desktop[fn:1]), run the system monitor applet, click Properties, enable all the monitored resources (cpu, mem, net, swap, load, disk) and watch it while you are running the test: in particular, check memory and swap. If you are swapping even a little bit, that's enough to cause severe performacne problems[fn:2], which can be cured by using less memory (so stop any memory hogs from running) or by adding memory. Oh, and I'm conscious of R using RAM, so I tried to run this stuff without browsers open, no other R sessions, etc. Prior to running R and without a browser, I'm typically around 10-15% RAM utilized... I have 4gb, so that should be enough to read this, especially per Chuck's results! This is also an i7 work computer. It should fly (and in the ESS session itself, it does). Check /var/log/syslog (or thereabouts) to see if the kernel is seeing errors with some blocks on the disk and keeps retrying. Assuming SMART is enabled, run smartctl -a as well and look for problems. Nick
Re: [O] Displaying agenda for today instead of diary with the calendar
On 2012-11-01 12:41, Nick Dokos wrote: (add-hook 'calendar-initial-window-hook 'org-agenda-list) That's it, it works wonderfully! Thank's a lot, Christian -- Christian Wittern, Kyoto
Re: [O] htmlize and #+INCLUDE:
Thanks for the confirmation. There is no problem. It was me doing it wrong. It works ok now. I just have to chose between syntaxhighlighter, google code prettify or htmlize. I tend to prefer htmlize (probably more flexible as I can hack elisp code) but there is thing about using my current theme with which I'm not very comfortable. Anyway, the more I'm using org-mode and the new exporter, the more I like it. Thanks for providing us with this tool. Fabrice 2012/11/1 Nicolas Goaziou n.goaz...@gmail.com Fabrice Popineau fabrice.popin...@gmail.com writes: Given the fact that '#+INCLUDE: file src java' is expanded into an src block, I assume that htmlize should apply there too. Am I wrong? I think you're correct. A quick test shows me fontification is fine. Do you have an ECM to show the problem? Regards,
[O] Generating captions--is there a better way?
I use R to plot data, and like to include information about the plot in the caption. I do this by combining two named SRC blocks--one for the image, and one for the caption--and then put their #+RESULTS: together. The caption is the tricky bit; I use R to print a string that starts with #+CAPTION:, shown in the exmaple below. While this works, I've wondered if there is a more elegant way to do this. How do others do this? Kind Regards, Mike Gauland - example - #+NAME: image #+HEADER: :session #+HEADER: :results graphics #+HEADER: :exports results #+HEADER: :file (org-babel-temp-file ./figure- .pdf) #+BEGIN_SRC R x - rnorm(100) hist(x) #+END_SRC #+NAME: caption #+HEADER: :session #+HEADER: :results raw #+HEADER: :exports results #+BEGIN_SRC R print(paste(#+CAPTION: The mean value is , format(mean(x), digits=3), ., sep=)); #+END_SRC #+RESULTS: caption #+RESULTS: image
Re: [O] Generating captions--is there a better way?
Michael Gauland mikely...@no8wireless.co.nz writes:
I use R to plot data, and like to include information about the plot in the
caption. I do this by combining two named SRC blocks--one for the image, and
one
for the caption--and then put their #+RESULTS: together. The caption is the
tricky bit; I use R to print a string that starts with #+CAPTION:, shown in
the
exmaple below. While this works, I've wondered if there is a more elegant way
to
do this. How do others do this?
[snip]
For something simple like this, I'd use:
,
| #+PROPERTY: session *R*
| #+PROPERTY: results output
|
| #+NAME: image
| #+HEADER: :results graphics
| #+HEADER: :exports results
| #+HEADER: :file (org-babel-temp-file ./figure- .pdf)
| #+BEGIN_SRC R
| x - rnorm(100)
| caption.string -
| sprintf(The mean value is %.3f.\n,mean(x))
| hist(x)
| #+END_SRC
|
|
| #+CAPTION: src_R[:results raw]{ cat(caption.string) }
| #+RESULTS: image
`
For more complicated stuff I use ravel[1] to export as *.Rnw and then use
knitr on the result.
HTH,
Chuck
[1] see
https://github.com/chasberry/orgmode-accessories/blob/master/ravel-org.md
