Re: [O] Tracking Current Org Version
On Fri, Aug 8, 2014 at 5:39 PM, Kenneth Jacker k...@be.cs.appstate.edu wrote: What is the best way to do this? ;-) This should help you http://orgmode.org/worg/org-faq.html#Keeping-current -- Suvayu Open source is the future. It sets us free.
Re: [O] [patch, ox] Unnumbered headlines
Am Fri, 08 Aug 2014 15:39:15 +0200 schrieb Rasmus ras...@gmx.us: Needless to say such a feature needs to be discussed and I not sure whether the greater Org community finds it useful or needless clutter. Definitly a candidate for inclusion in org-mode. Thx for the patch! Detlef
Re: [O] proposal for improved integration of cdlatex
Hello, Federico Beffa be...@ieee.org writes: Do you think it is now a reasonable implementation? Would it be a suitable tiny change to `org-mode'? Yes, applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] org.el: make org-paragraph-fill ignore \[...\] regions starting and ending a line
Hello,
Federico Beffa be...@ieee.org writes:
OK, I understand that the Cons above is a serious issue and nobody wants it.
For this reason I went back to my original idea and modified the
`org-fill-paragraph' function. This provides the two Pros above
without having to introduce the undesired Cons. The behavior is a
follows:
- if \[...\] is inline, behave as before.
- if \[ is the first non space character of a line and the closing \]
is the last non space character of a line (possibly spanning several
lines), then do not fill this region of the paragraph.
But then, you introduce a discrepancy between M-q results and Org
syntax. This is not optimal either.
Also, this will not be consistent anyway with \begin{...} ... \end{...}
markup, which is handled differently, unlike to LaTeX.
Attached you find a patch with the proposed modification. I would
greatly appreciate if you could consider it for inclusion in org-mode
and provide feedback.
Note that you should use master to provide patches. `org-fill-paragraph'
was modified recently.
Regards,
--
Nicolas Goaziou
Re: [O] Some thoughts on MobileOrg and its development ....
Alexis flexibe...@gmail.com writes: i can't help but wonder if the 'MobileOrg' endeavour needs a reboot. It seems clear that it does. More specifically, it seems to me that rebuilding MobileOrg as a single project [...] might be a way forward, This is vital! on top of Apache Cordova: https://cordova.apache.org/ I'd just like to float Kivy as another possibility: http://kivy.org What makes Kivy interesting to me in this context (apart from its cross-platform nature) is its excellent support of gestures, which gives me (the perhaps naive) hope that a little more than an utterly trivial feature set might be provided on the mobile form factor. Unfortunately, due to other existing commitments, i wouldn't be able to take point on such a reboot. The dreamer in me thinks this might be the itch-to-scratch that finally motivates me to getting to grips with Kivy; the realist in me is pretty certain that I fall into the same category as you.
Re: [O] R code block produces only partial output
Charles C. Berry ccbe...@ucsd.edu writes: On Wed, 6 Aug 2014, Aaron Ecay wrote: Hi Eric, 2014ko abuztuak 6an, Eric Schulte-ek idatzi zuen: [...] Perhaps you could begin with a patch for the regexp issue in this thread? I have pushed a patch which allows us to avoid the regex issue entirely by using a native R method to capture the session output to a file. This introduces the change that the output no longer appears in the session buffer, but I think that’s actually an improvement: we were not previously echoing the commands to the buffer, such that the output would show up “out of the blue” without any indication of how it got there. Hi Aaron, I like what you are trying to do, but ... 1) The change has at least one bug: Remote sessions are broken by this change. 2) The behavior of :results output is modified in ways that might not be desired. i.e. warnings and errors will not show up in the output. Can you revert this change until the bugs are sorted out and consensus about the proper handling of cases like '2' is reached? Can I also suggest that in the future before a change is pushed, that the patch is announced so we can try it out or at least eyeball it and discuss issues/bugs? I think that would be a good idea, or create a separate branch for testing these features. Details: Issue 1) === If I open a *.org file on a remote machine and C-c C-c on a src block that has `:session :results output', after the usual session startup the src block fails. The session buffer shows this Error in file(file, if (append) a else w) : cannot open the connection In addition: Warning message: In file(file, if (append) a else w) : cannot open file '/scpc:berry@DELETED.URL:/tmp/R-1155xWV': No such file or directory === The file '/tmp/R-1155xWV' was created. I think if the tramp file localname is used. it might work. I do not know tramp, but maybe something like (let output-file-localname (if (tramp-tramp-file-p output-file) (tramp-file-name-localname (tramp-dissect-file-name output-file)) output-file)) is good enough. Issue 2) === ECM: #+NAME: aa #+BEGIN_SRC R :session R2 :results output warning(this is a warning) 1+1 #+END_SRC #+RESULTS: aa : [1] 2 For some purposes having the warnings in the #+RESULTS: block is helpful. And when revising code, having the errors in the #+RESULTS helps - especially if I have to put aside work in progress. Instead of capture.output, one could possibly use sink() as it can also capture error messages and warnings, as shown in the help: #+begin_src R ## capture all the output to a file. zz - file(all.Rout, open = wt) sink(zz) sink(zz, type = message) try(log(a)) ## back to the console sink(type = message) sink() file.show(all.Rout) #+end_src This combined with a try() bloxk could work? Cheers, Rainer HTH, Chuck -- 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 PGP: 0x0F52F982 pgpPoOAIsQV6v.pgp Description: PGP signature
Re: [O] R code block produces only partial output
Charles C. Berry ccbe...@ucsd.edu writes: On Thu, 7 Aug 2014, Aaron Ecay wrote: Hi Chuck, Thanks for your feedback. 2014ko abuztuak 7an, Charles C. Berry-ek idatzi zuen: Hi Aaron, I like what you are trying to do, but ... 1) The change has at least one bug: Remote sessions are broken by this change. 2) The behavior of :results output is modified in ways that might not be desired. i.e. warnings and errors will not show up in the output. [snip issue 1 discussion] Issue 2) === ECM: #+NAME: aa #+BEGIN_SRC R :session R2 :results output warning(this is a warning) 1+1 #+END_SRC #+RESULTS: aa : [1] 2 For some purposes having the warnings in the #+RESULTS: block is helpful. And when revising code, having the errors in the #+RESULTS helps - especially if I have to put aside work in progress. Hmm. Certainly, the previous behavior should be retained for now. In the longer term, I’d like to see a system whereby R errors trigger elisp errors. This is so that the execution of a whole document (subtree, etc.) will be halted by the first error, rather than continuing what may be a long series of commands that will not give valid output. What do you think? I need a while to sort through this. stop(), warning(), and message() will print to the session but not show up in what capture.output retains. sink() has the ability to capture those things, but there is added baggage. I fear some study of ?conditions is needed. My knowledge of condition handling in R is scant. As for stopping on error, I think that anything that changes current behavior at this late date ought to be configurable. FWIW, when I export documents, I sometimes get innocuous errors that I am happy did not stop the run in its tracks - like formatting one table fails with an error but all else went through. And sometimes I wish it had stopped. I agree here with Charles. An example where R errors do *not* trigger do not abort export are graphs: the graph generation, when using R, is wrapped in a tryCatch() block and shows the error in the exported document as well as in the R session but does not abort. A case where it is very useful to continue export is when creating lecture notes or slides to demonstrate errors. If there is the wish for R errors to trigger elisp errors, a header argument would be needed to specify if errors and warnings in R should trigger errors in elisp or if they should be ignored and the error message displayed and the export should be continued. Cheers, Rainer Best, Chuck -- 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 PGP: 0x0F52F982 pgpb1x4uxmJH8.pgp Description: PGP signature
Re: [O] [PATCH] Add support for :dbhost, :dbuser and :database parameters for poastgresql in ob-sql.el
Le 09/08/2014 02:38, Thomas S. Dye a écrit : Aloha Steven, Steven Rémot steven.re...@gmail.com writes: Hi, I did some changes to support :dbname, :dbhost and :database in SQL code blocks when using postgresql engine. Even if it was possible to specify this information using :cmdline parameter, I thought it was a bit cleaner to be able to provide this information in a way independent from the command line. I will gladly accept any remark / comment on this patch. Regards, Steven Rémot I'm not certain who is maintaining ob-sql.el, so I'm not replying in any directly useful way. However, this patch looks straightforward and good to me. Have you signed FSF papers? If so, the maintainer can accept (or reject) your patch. If not, then you'll need to identify it as a tiny change (see http://orgmode.org/worg/org-contribute.html). Thanks for this contribution to Org mode. All the best, Tom This is my only contribution to Emacs code, and it changes only 12 lines that impact a very tiny fragment of org, so I though I could send it without signing papers. If I was wrong, I don't mind signing papers at all. Regards, Steven Rémot
Re: [O] [PATCH] org.el: make org-paragraph-fill ignore \[...\] regions starting and ending a line
without having to introduce the undesired Cons. The behavior is a
follows:
- if \[...\] is inline, behave as before.
- if \[ is the first non space character of a line and the closing \]
is the last non space character of a line (possibly spanning several
lines), then do not fill this region of the paragraph.
But then, you introduce a discrepancy between M-q results and Org
syntax. This is not optimal either.
Would you mind elaborating on the discrepancy. I do not quite
understand what do you mean. Doesn't the Org syntax just defines the
result of parsing a buffer (like in most programming languages where
indentation and line breaks are just to help people reading code)?
Also, this will not be consistent anyway with \begin{...} ... \end{...}
markup, which is handled differently, unlike to LaTeX.
Yes, I agree. But, given that we do not want to make \[...\] an
`org-mode' environment for backward compatibility reasons, this
appears to be the only alternative. Note that (as noted earlier)
`latex-mode' behaves similarly: it does not fill parts of a paragraph
where a line begins with \[ and ends with \]. The reason and goal is
to achieve that a carefully typed long equation does not get scrambled
by M-q because if it does it becomes difficult to read for humans.
Attached you find a patch with the proposed modification. I would
greatly appreciate if you could consider it for inclusion in org-mode
and provide feedback.
Note that you should use master to provide patches. `org-fill-paragraph'
was modified recently.
OK, will pull again.
Regards,
Federico
Re: [O] Unicode (double-byte?) goofs up text table layout
Am 01.08.2014 um 18:32 schrieb Eric Abrahamsen e...@ericabrahamsen.net: John Lusk johnlu...@gmail.com writes: Hey, org-mode crew. Awesome app; I love it. It's pretty much the only thing that keeps me in emacs these days (apart from writing Python code :) ). A bit of work has gone into keeping double-byte characters from messing up Org tables, but my guess is what you've got there is just an odd-out glyph. It looks like the, erm, carrots (I'm not a mathematician) are getting borrowed from a different font and substituted into your fixed-width font where they don't quite belong. [five minutes later] I just went and did my homework and LOGICAL OR and LOGICAL AND are in fact single-byte characters. If they look funny, it's just because few fixed-width fonts come with all the necessaries. I don't think there's much way around that... Both characters are in DejaVu Sans Mono Free Monospaced Menlo Try one of these fonts. Axel
Re: [O] Tracking Current Org Version
Thanks, Suvayu, for your quick response! sa This should help you sa sa http://orgmode.org/worg/org-faq.html#Keeping-current Yes, I've seen that ... in fact, have it bookmarked already ... the procedure therein explained is what I've been doing. But I'm still unclear about versions ... How do I find the commit that corresponds to the org-version variable value? And what about the ELPA 'tar' files? How do they relate to the 'git' repo? Just wanting to understand what I'm doing, ;-) Thanks again, -Kenneth
Re: [O] Tracking Current Org Version
Kenneth Jacker writes:
For me, there is a little confusion on just which version I'm using ...
I changed to the org-mode git managed directory, and entered:
$ make update
{ Do I need to do more? I followed the above with
make and make install ... necessary? }
Well, if you do that, then make up2 is what you really want. It does
the above plus it doesn't install if the tests fail, so you aren't hosed
if you happen to build at a time where Org is broken.
After performing the above yesterday and then checking with M-x org-version
shows:
Org-mode version 8.3beta (release_8.3beta-175-g59cd25
Is that the latest? No date is included ...
Nor is there any need for that. The version string tells you that the
most recently tagged release version is 8.3beta, there have been 175
commits since then and the commit you're on has an SHA1 starting with
59cd25 (i.e. 'git show 59cd25' will let you look at that commit and 'git
log 59cd25' shows the changes from that point backward).
In addition, I receive announcements from elpa.gnu.org that shows things
like:
Latest: org-20140804.tar, 2014-Aug-04, 5.21MB
How does *that* differ/compare to what 'git' is downloading?
ELPA is fed by the maint branch, not master. In a nutshell, between
releases maint only gets bugfixes, while master can remove, change or
add features at any time. If you are using master, you should be
following the mailing list at least (and know how to install a different
version than the last one for the few times where one of those changes
on master may impact you).
What is the best way to do this? ;-)
Whatever you prefer.
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] [PATCH] Add support for :dbhost, :dbuser and :database parameters for poastgresql in ob-sql.el
Steven Rémot steven.re...@gmail.com writes: This is my only contribution to Emacs code, and it changes only 12 lines that impact a very tiny fragment of org, so I though I could send it without signing papers. If I was wrong, I don't mind signing papers at all. Either way should work. If you'd like to contribute other patches, then you'll want to sign the FSF papers following the instructions here: http://orgmode.org/worg/org-contribute.html#sec-2 This process will probably take some weeks to complete. This patch is less than 15 lines, so I think it can be considered a tiny change. If you want to contribute it as a tiny change then you'll need to indicate this in the patch. I'm not finding exact instructions for this at the moment, so someone else on the list will have to help. All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Re: [O] Tracking Current Org Version
On Sat, Aug 09, 2014 at 10:25:05AM -0400, Kenneth Jacker wrote: Thanks, Suvayu, for your quick response! sa This should help you sa sa http://orgmode.org/worg/org-faq.html#Keeping-current Yes, I've seen that ... in fact, have it bookmarked already ... the procedure therein explained is what I've been doing. But I'm still unclear about versions ... How do I find the commit that corresponds to the org-version variable value? The version string is derived from whatever `git describe' returns (the release_* part). To understand the string look at the man page for git-describe. Look at Achim's reponse about your ELPA tarball question. Hope this helps, -- Suvayu Open source is the future. It sets us free.
[O] Problem with org-plot: (void-variable data-file)
Hello, I'm working through this: https://www.gnu.org/software/emacs/manual/html_node/org/Org_002dPlot.html Using ob-plot.el that comes with the org extras. I created the demo table there, and I run org-plot/gnuplot, and I get: Error running timer: (void-variable data-file) Any clue? Thanks, Noah
Re: [O] [PATCH] Add support for :dbhost, :dbuser and :database parameters for poastgresql in ob-sql.el
Le 09/08/2014 17:31, Thomas S. Dye a écrit : If you'd like to contribute other patches, then you'll want to sign the FSF papers following the instructions here: I think it won't be the only patch I send to Org mode or Emacs, so I will sign copyright assignment and come back when it is done. Thank you for the clarification! Regards, Steven Rémot
[O] autorun M-x linum-mode when file is opened
How can I have a command auto-run when a file is opened from 'desktop recovery' please? I want to auto-run M-x linum-mode when I open my daily journal, which stays open all the time. Running that command will switch off linum-mode for that file, which may stop file-rot that I have observed in the past. This can, at present, only be resolved by shutting down emacs for half an hour or so, and then restarting it, and normal functionality will have been restored. Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots TGmeds = http://www.tgmeds.org.uk Debian testing, fluxbox 1.3.5, emacs 24.3.92.1 signature.asc Description: PGP signature
Re: [O] [PATCH] org.el: make org-paragraph-fill ignore \[...\] regions starting and ending a line
Federico Beffa be...@ieee.org writes:
But then, you introduce a discrepancy between M-q results and Org
syntax. This is not optimal either.
Would you mind elaborating on the discrepancy.
Ignoring \[...\] when filling the paragraph is misleading. You may
believe the object doesn't belong to the paragraph at all. I think M-q
should, on the contrary, give clues about the structure of the document.
Also, it doesn't make a difference when exporting to LaTeX, but it might
in back-ends with a different definition for paragraphs (e.g. HTML).
I do not quite understand what do you mean. Doesn't the Org syntax
just defines the result of parsing a buffer (like in most
programming languages where indentation and line breaks are just to
help people reading code)?
Indentation and line breaks are meaningful in Org. They are not just
syntactic sugar.
Yes, I agree. But, given that we do not want to make \[...\] an
`org-mode' environment for backward compatibility reasons, this
appears to be the only alternative.
There is another alternative: use \begin{equation*}
or \begin{displaymath}. M-q does not fill those.
You're trying to solve an already solved problem, although the actual
solution doesn't suit you.
Regards,
--
Nicolas Goaziou0x80A93738
[O] [PATCH] docstring improvement of org-agenda-refile
Hi, Here is a small patch to improve the docstring of `org-agenda-refile'. Can I apply it? From acd2830755849a055ce46a34b65af89b9547fcb2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com Date: Sun, 10 Aug 2014 01:41:16 +0200 Subject: [PATCH] lisp/org-agenda.el (org-agenda-refile): Documentation improvement * lisp/org-agenda.el (org-agenda-refile): State explicitly that '(16) = C-u C-u and that '(64) = C-u C-u C-u. --- lisp/org-agenda.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 3919328..8244eeb 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8475,8 +8475,8 @@ If this information is not given, the function uses the tree at point. (defun org-agenda-refile (optional goto rfloc no-update) Refile the item at point. -When GOTO is 0 or '(64), clear the refile cache. -When GOTO is '(16), go to the location of the last refiled item. +When GOTO is 0 or '(64) or \\[universal-argument] \\[universal-argument] \\[universal-argument], clear the refile cache. +When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to the location of the last refiled item. RFLOC can be a refile location obtained in a different way. When NO-UPDATE is non-nil, don't redo the agenda buffer. (interactive P) -- 1.8.0.2722.gc0242e5 -- Daimrod/Greg
[O] [PATCH] docstring improvement of org-agenda-refile
Hi, Here is a small patch to improve the docstring of `org-agenda-refile'. Can I apply it? From acd2830755849a055ce46a34b65af89b9547fcb2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com Date: Sun, 10 Aug 2014 01:41:16 +0200 Subject: [PATCH] lisp/org-agenda.el (org-agenda-refile): Documentation improvement * lisp/org-agenda.el (org-agenda-refile): State explicitly that '(16) = C-u C-u and that '(64) = C-u C-u C-u. --- lisp/org-agenda.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 3919328..8244eeb 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8475,8 +8475,8 @@ If this information is not given, the function uses the tree at point. (defun org-agenda-refile (optional goto rfloc no-update) Refile the item at point. -When GOTO is 0 or '(64), clear the refile cache. -When GOTO is '(16), go to the location of the last refiled item. +When GOTO is 0 or '(64) or \\[universal-argument] \\[universal-argument] \\[universal-argument], clear the refile cache. +When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to the location of the last refiled item. RFLOC can be a refile location obtained in a different way. When NO-UPDATE is non-nil, don't redo the agenda buffer. (interactive P) -- 1.8.0.2722.gc0242e5 -- Daimrod/Greg
[O] orgmode capture template how to add entry under org header
Hello: I added a custom template for the capture-mode: The problem is that the default Tasks template is not there anymore. So I tried to add this: (t Tasks entry (file ~/Documents/org/notes.org)) Now, when I press `M-x org-capture`, the Tasks option appears in the template options list. The default behaviour for the default Tasks template is to add the new entries under the * Tasks headline. How do I achieve that same feature? How to add all new entries under a specific header in the .org file? Thanks in advance for your kind help and time. Jenia P.S. This is how I add the custom template to the org-capture templates list: (setq org-capture-templates '( (c Class entry (file ~/Documents/org/class.txt) #'org-capture-class) (n Exercise session entry (file ~/Documents/org/notes.org)) (t Tasks entry (file ~/Documents/org/notes.org)) ))
[O] Programming with org-element-cache - short introduction?
Hi List (or rather Hi Nicolas), when programming with Org elements sometimes things seem to work and then something strange happens - what smells like a cache problem. I don't mean a cache bug, but a programmer (me) not taking the cache into account the right way. Is there a short introduction somewhere about the 'todos' and 'nogos' in programming with elements wrt to the org-element-cache? -- cheers, Thorsten
Re: [O] org-table: missing vertical boundary when exported
Hi, I learned a bit a about html/css and took another look the issue. It turns out that org-mode uses the border attribute which is not respected by my browser(Google Chrome version 36.0.1985.125 on Mac 10.9.4) . Org mode generated this line in the html for table but the border is not displayed, table border=2 cellspacing=0 cellpadding=6 rules=groups frame=hsides If we use css style to specify the border, the table border would show up: table style=border:2px cellspacing=0 cellpadding=6 rules=groups frame=hsides Don't know why it is that. But is there any org keywords/properties I can specify so that Org would not use the border attribute but use the style attribute instead when exporting to html? Thanks. Shiyuan On Tue, Jun 10, 2014 at 10:34 PM, Shiyuan gshy2...@gmail.com wrote: Yes, it seems to be related to the browser or css style stuff. In fact, for the attached html in Thorsten's previous email, the two boundaries vertical lines are also missing in my Google Chrome or Firefox. Thanks. This is the example directed from copy-paste. | | N | N^2 | N^3 | N^4 | sqrt(n) | sqrt[4](N) | |---++-+-+-+-+| | / | || ||| | | # | 1 | 1 | 1 | 1 | 1 | 1 | | # | 2 | 4 | 8 | 16 | 1.4142 | 1.1892 | | # | 3 | 9 | 27 | 81 | 1.7321 | 1.3161 | |---++-+-+-+-+| This is my minimal config, Emacs start with '-Q -l ~/myorg.el which is (package-initialize) (org-babel-do-load-languages 'org-babel-load-languages '((python . t) (emacs-lisp . t) (latex . t))) On Tue, Jun 10, 2014 at 6:23 AM, Rick Frankel r...@rickster.com wrote: On 2014-06-07 17:15, Shiyuan wrote: I am following the manual example http://orgmode.org/worg/org-tutorials/tables.html [1]. But the two vertical boundary line on the very left and right is not showing up when exported to html. Anything I am missing? Thanks. My guess is that it is related to the css being used to style the table in your setup. Could you post a minimal example with the html output? rick
[O] #+begin_src R :results output drawer doesn't work.
#+begin_src R :results output drawer 1 2 #+end_src #+RESULTS: : 2 --
