Re: [O] [BUG] [ODT] Subtree export gives wrong footnote style
Thanks! Yours, Christian Nicolas Goaziou writes: Christian Moe christian@hf.uio.no writes: For now, I think the patch is correct to apply. What do you think? Absolutely, it fixes a bug in footnote styling, and adds useful styling of quotes within footnotes. Patch applied. Thank you. Regards,
Re: [O] Sync Org with Google Calendar using google API (rather than caldav)
Adam Spiers orgmode at adamspiers.org writes: Sounds interesting. It would be very helpful if you could explain how it is different from the other synchronization possibilities out there, e.g. http://orgmode.org/worg/org-tutorials/org-google-sync.html https://code.google.com/p/emacs-google/ https://github.com/travisbhartwell/Emacs-Google-Calendar-Sync http://www.emacswiki.org/emacs/GoogleClient two main things make my sync different (also this does not make it more interesting ;) - it does not rely on external command - it does not rely on ics I always found that relying on external commands makes thing more complex : you have to configure that command, in its configuration file or through scripted call by passing right arguments, and then you have to integrate it in your Emacs workflow. Using command in Emacs, configured through convenient customization group is so natural … Then, my sync. uses Google json API (and authentification using oauth, stored in crypted file, for no secret in your config file or anywhere else). This make it by far less portable. But, with Google dropping standards, or juts maintaining it at there minimal level, it makes it more close to what you can get from Google calendar and events. Also using elisp Json library is so easy and robust in regard to parsing ics files that it sounds very natural to use it. I don't mean it is better than caldav sync tools, but that I could not find myself satisfied with those tools, worried about Google call to drop caldav compatibility, that I feel I need something more close to Google API possibilities. Then I started it, and just offer to share (that how it works, right ? ;) Thanks for the work of the community, Bat.
[O] I have terminated my assignment
I have terminated my copyright assignment to Emacs (or atleast notified the copyright desk). For the sake of record, I haven't authorized Bastien to move the ox-html.el and ox-odt.el out of the ./contrib/lisp directory in to the main ./lisp/ directory. He didn't seek my permissions to move the file away from contrib/lisp in to lisp/. I cannot agree with Orgmode project's contention that I have given consent for above work to be included in Emacs proper. If FSF ever consults me on rights to my contributions to the above files, my position will ambiguously be Changes made by me to files ox-html.el, ox-odt.el and ox-freemind.el are my own and I assert my rights over the changes. Specifically, I will not acknowledge FSF as having the rights to the said changes. Bastien has lost my trust very long back. More so when he resorted to erasing attribution to my work. My changes to ox-html.el and ox-odt.el is not worth the keyboard it is typed on. My changes are useful. Handing over of rights, liberal license grant backs from FSF and enforcement of copyright etc. are too big a thing to even think about for my humble contributions. The size of my contributions are simply not worth so much bureaucratic trouble. Meanwhile, interesting observers can observe how FSF responds. Either they can act consistent with project policy (and reject my work) or appropriate my work (through changing the rules of the game and interpreting the terms of contract) to suit their agenda. Advice for potential contributors: -- Think before signing a Future Assignment. Why write a blank cheque and have RMS run behind you with this is a diff to Emacs and all your code is mine. Assign work on a case-by-case basis. Insist that you cannot apriori sign off rights to future works (Future work and circumstances cannot be predicted. Be circumspect). If more people refuse to assign future rights, FSF will be forced to review their stance. Ask for information on how you can withhold assignments for some selected work. Ask them for cancellation form or a withholding form. Ask them at what point in time your work is *actually part* of Emacs. Carefully consider the arguments that FSF advances and also the arguments advanced by detractors. Don't be swayed by propaganda. If you are not sure, just don't sign the copyright and wait till you have ascertained the nature of your work in it's near final form. Jambunathan K.
[O] Visibility cycling applied on several windows
Hi, If you have 2 windows opened with the same Org buffer, when you use a visibility cycling command (TAB, S-TAB, etc.), it changes the visibility in both windows, while you would expect the visibility being changed only in the active windows (not in both windows). Is there a way to restrict the visibility cycling only to the active window? Thanks a lot for your help. Regards, Francesco
Re: [O] Visibility cycling applied on several windows
Francesco Pizzolante f...@missioncriticalit.com writes: If you have 2 windows opened with the same Org buffer, when you use a visibility cycling command (TAB, S-TAB, etc.), it changes the visibility in both windows, while you would expect the visibility being changed only in the active windows (not in both windows). Is there a way to restrict the visibility cycling only to the active window? maybe this is what you need (untested): http://www.gnu.org/software/emacs/manual/html_node/emacs/Indirect-Buffers.html -- cheers, Thorsten
Re: [O] Visibility cycling applied on several windows
Thorsten Jolitz tjol...@gmail.com writes: maybe this is what you need (untested): http://www.gnu.org/software/emacs/manual/html_node/emacs/Indirect-Buffers.html No, an indirect buffer shares its parent's text properties. Christopher
Re: [O] Visibility cycling applied on several windows
Hi Christopher and Thorsten, Thanks for your replies. Christopher Schmidt wrote: Thorsten Jolitz tjol...@gmail.com writes: maybe this is what you need (untested): http://www.gnu.org/software/emacs/manual/html_node/emacs/Indirect-Buffers.html No, an indirect buffer shares its parent's text properties. It's true: the indirect buffer shares its parent's text properties. But, the visibility cycling is applied only in the active window: either in the main buffer or in the indirect buffer but not in both windows at the same time. So, it works as expected to me. Thanks for the trick! But this trick seems like a workaround to me : using visibility cycling in one window should not affect another window, isn't it? Thanks for your help. Francesco
[O] MACRO and HTML escapes and migration to org-mode 8
I've finally bitten the bullet and tried to get my org-mode export
working with the new export mechanisms, so far so good.
My current sticking point is with my use of #+MACRO and @ escapes in
them -- they used to work in the old version of org-mode, in the current
one I get them quoted verbatim into the HTML output with text like
@ltspan blah blah text@lt/span
I must be missing the key part of TFM, since section 12.5.3 seems to say
that @ still escapes simple HTML tags. I've got a header file that
includes the line:
#+MACRO: datetime @span class=datetime title=$1$2@/span
This is then included in the org-mode files with
#+SETUPFILE: ~/path/macros.inc
Then in the text I have entries such as
{{{datetime(2013-04-01,yesterday)}}} -- and it all used to work.
--
Adrian Tritschler mailto:a...@ajft.org
Latitude 38°S, Longitude 145°E, Altitude 50m, Shoe size 44
---
Re: [O] MACRO and HTML escapes and migration to org-mode 8
Hi, Adrian,
The fine manual is not yet up to date with the new exporter, so when you're
bitten, check http://orgmode.org/worg/org-8.0.html.
The @ html-tag quoting has been replaced with a generalized export
snippets syntax (currently described at
http://orgmode.org/worg/org-8.0.html#sec-8-1).
This works:
#+MACRO: datetime @@html:span class=datetime title=$1$2/span@@
Yours,
Christian
Adrian writes:
I've finally bitten the bullet and tried to get my org-mode export
working with the new export mechanisms, so far so good.
My current sticking point is with my use of #+MACRO and @ escapes in
them -- they used to work in the old version of org-mode, in the current
one I get them quoted verbatim into the HTML output with text like
@ltspan blah blah text@lt/span
I must be missing the key part of TFM, since section 12.5.3 seems to say
that @ still escapes simple HTML tags. I've got a header file that
includes the line:
#+MACRO: datetime @span class=datetime title=$1$2@/span
This is then included in the org-mode files with
#+SETUPFILE: ~/path/macros.inc
Then in the text I have entries such as
{{{datetime(2013-04-01,yesterday)}}} -- and it all used to work.
[O] [PATCH] Was: How to apply multiple TBLFM rules?
Hi, This patch enables user to applies a temporal TBLFM line where you are in. It is useful when you switch a formula to another. I hope you liked this. When you have the following table, #+TBLNAME: test2 | 1 | 2 | | | 4 | 5 | | | 7 | 8 | 9 | #+TBLFM: @1$3='(+ 10 7) #+TBLFM: @2$3='(+ 11 9) hitting =C-c C-c= in the 2nd TBLFM line containg #+TBLFM: @2$3='(+ 11 9) gives you this result: #+TBLNAME: test2 | 1 | 2 || | 4 | 5 | 19 | | 7 | 8 | 9 | #+TBLFM: @1$3='(+ 10 7) #+TBLFM: @2$3='(+ 11 9) This patch consists of 4 parts as shown below: From e905aea041a2d306a37921797364a9056eadfa48 Mon Sep 17 00:00:00 2001 From: Ippei FURUHASHI top.tuna+orgm...@gmail.com Date: Tue, 2 Apr 2013 18:05:46 +0900 Subject: [PATCH 1/4] org.el (org-at-TBLFM-p): Add functon * org.el (org-at-TBLFM-p): Add function. * testing/lisp/test-org-table.el: Add test. --- lisp/org.el| 12 testing/lisp/test-org-table.el | 19 +++ 2 files changed, 31 insertions(+), 0 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 04ce386..ef27944 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4197,6 +4197,9 @@ (defconst org-table-any-border-regexp ^[ \t]*[^|+ \t] (org-autoload org-table '(org-table-begin org-table-blank-field org-table-end))) +(defconst org-TBLFM-regexp ^[ \t]*#\\+TBLFM: + Detect a #+TBLFM line.) + ;;;###autoload (defun turn-on-orgtbl () Unconditionally turn on `orgtbl-mode'. @@ -4291,6 +4294,15 @@ (defun org-table-map-tables (function optional quietly) (declare-function org-clock-update-mode-line org-clock ()) (declare-function org-resolve-clocks org-clock (optional also-non-dangling-p prompt last-valid)) + +(defun org-at-TBLFM-p (optional pos) + Return t when point (or POS) is in #+TBLFM line. If not, return nil. + (save-excursion +(let ((pos pos))) +(goto-char (or pos (point))) +(beginning-of-line 1) +(looking-at org-TBLFM-regexp))) + (defvar org-clock-start-time) (defvar org-clock-marker (make-marker) Marker recording the last clock-in.) diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el index 4c09239..ea8c4d8 100644 --- a/testing/lisp/test-org-table.el +++ b/testing/lisp/test-org-table.el @@ -749,6 +749,25 @@ (defconst references/target-special ;; Remote reference. ;; (should ;;(string= $3 = remote(FOO, @@#$2) (org-table-convert-refs-to-rc C = remote(FOO, @@#B) +(ert-deftest test-org-table/org-at-TBLFM-p () + (org-test-with-temp-text-in-file + +| 1 | +| 2 | +#+TBLFM: $2=$1*2 + + +(goto-char (point-min)) +(forward-line 2) +(should (equal (org-at-TBLFM-p) nil)) + +(goto-char (point-min)) +(forward-line 3) +(should (equal (org-at-TBLFM-p) t)) + +(goto-char (point-min)) +(forward-line 4) +(should (equal (org-at-TBLFM-p) nil (provide 'test-org-table) -- 1.7.9.msysgit.0 From 37369815b555ba1f2df168ac45c83237c628d609 Mon Sep 17 00:00:00 2001 From: Ippei FURUHASHI top.tuna+orgm...@gmail.com Date: Tue, 2 Apr 2013 18:09:26 +0900 Subject: [PATCH 2/4] org-table.el (org-TBLFM-begin): Add function * org-table.el (org-TBLFM-begin): Add function. * testing/lisp/test-org-table.el: Add test. --- lisp/org-table.el | 14 + testing/lisp/test-org-table.el | 123 2 files changed, 137 insertions(+), 0 deletions(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index f087cf7..78fbb2e 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -52,6 +52,8 @@ (defvar orgtbl-after-send-table-hook nil to the receiver position, otherwise, if table is not sent, the functions are not run.) +(defvar org-TBLFM-begin-regexp |\n[ \t]*#\\+TBLFM: ) + (defcustom orgtbl-optimized (eq org-enable-table-editor 'optimized) Non-nil means use the optimized table editor version for `orgtbl-mode'. In the optimized version, the table editor takes over all simple keys that @@ -3169,6 +3171,18 @@ (defun org-table-iterate-buffer-tables () (setq checksum c1))) (user-error No convergence after %d iterations imax)) +(defun org-TBLFM-begin () + Find the beginning of the TBLFM lines and return its position. +Return nil when the beginning of TBLFM line was not found. + (save-excursion +(if (progn (forward-line 1) + (re-search-backward + org-TBLFM-begin-regexp + nil t)) + (progn (beginning-of-line 2) + (point)) + nil))) + (defun org-table-expand-lhs-ranges (equations) Expand list of formulas. If some of the RHS in the formulas are ranges or a row reference, expand diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el index ea8c4d8..805f57a 100644 --- a/testing/lisp/test-org-table.el +++ b/testing/lisp/test-org-table.el @@ -769,6 +769,129 @@ (defconst references/target-special (forward-line 4) (should (equal (org-at-TBLFM-p) nil +(ert-deftest
Re: [O] Creating Gantt charts by Exporting to TaskJuggler 3.3.0
Buddy Butterfly buddy.butter...@web.de writes: I still feel the lack of the support for all tj properties a major drawback. @Christian: Did you work on something like the prefix proposal below? This would be real cool as we could then just use any property we would like. As far as I know Yann's patches improved this situation, but as far as I know most of the tj properties are supported anyway. Can you specify which properties are missing? It should be easy to add them in many cases. Thanks Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] Creating Gantt charts by Exporting to TaskJuggler 3.3.0
On Tue, Apr 2, 2013 at 10:46 AM, Christian Egli christian.e...@sbs.ch wrote:
Buddy Butterfly buddy.butter...@web.de writes:
I still feel the lack of the support for all tj properties a
major drawback.
@Christian: Did you work on something like the prefix proposal below?
This would be real cool as we could then just use any property we would
like.
As far as I know Yann's patches improved this situation, but as far as I
know most of the tj properties are supported anyway. Can you specify
which properties are missing? It should be easy to add them in many
cases.
I meant to follow up on this general idea per your comment in another
thread. I would have responded over there, but this is fresher and
seems like a better fit for a response. Nevertheless, I'll link to it
for a bread crumb trail.
- http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68957.html
This was the bit I specifically wanted to comment on:
#+begin_quote Buddy Butterfly
Also, you will likely only implement subsets of tj
properties.
For example, there are properties missing like
:workinghours:
#+end_quote
Have you looked at ox-taskjuggler.el? Here are the properties
available (check in org-taskjuggler-valid-resource-attributes):
#+begin_src ox-taskjuggler.el
(defcustom org-taskjuggler-valid-task-attributes
'(account start note duration endbuffer endcredit end
flags journalentry length limits maxend maxstart minend
minstart period reference responsible scheduling
startbuffer startcredit statusnote chargeset charge)
Valid attributes for Taskjuggler tasks.
If one of these appears as a property for a headline, it will be
exported with the corresponding task.
:group 'org-export-taskjuggler)
(defcustom org-taskjuggler-valid-resource-attributes
'(limits vacation shift booking efficiency journalentry rate
workinghours flags)
Valid attributes for Taskjuggler resources.
If one of these appears as a property for a headline, it will be
exported with the corresponding resource.
:group 'org-export-taskjuggler)
(defcustom org-taskjuggler-valid-report-attributes
'(headline columns definitions timeformat hideresource hidetask
loadunit sorttasks formats period)
Valid attributes for Taskjuggler reports.
If one of these appears as a property for a headline, it will be
exported with the corresponding report.
:group 'org-export-taskjuggler)
#+end_src
Also note that this is customizable. Anything matching those criteria
just gets passed through (:drawer: value - task_id name { drawer
value }).
Best regards,
John
Thanks
Christian
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] yanking a headline in folded state
42 147 aeus...@gmail.com writes: Hello mailing list, A source of slight irritation is killing a whole headline with C-k (usually to move it to another buffer), and seeing it unfold every single sub-headline after I yank it to its new position. This causes tremendous chaos sometimes, especially if there are a number of nested sub-headlines, and the killed headline itself needs to be adjusted to a deeper / shallower level (depending on where I inserted it). So in fewer words: how do I yank a headline in its folded state? In my Emacs I have the following. Would that work? C-c C-x C-w runs the command org-cut-special, which is an interactive compiled Lisp function in `org.el'. It is bound to C-c C-x C-w, menu-bar Org Edit Structure Cut Subtree, menu-bar Tbl Rectangle Cut Rectangle. (org-cut-special) Cut region in table or cut current subtree. Calls `org-table-copy' or `org-cut-subtree', depending on context. See the individual commands for more information. -- The Kids call him Billy the Saint
Re: [O] [PATCH 03/10] Clean up various org-babel-*-maybe commands
Aaron Ecay writes: * lisp/ob-core.el (org-babel-if-in-src-block): New macro […] +(defmacro org-babel-when-in-src-block (rest body) + `(if (or (org-babel-where-is-src-block-head) + (org-babel-get-inline-src-block-matches)) + (progn + ,@body + t) + nil)) Commit message and patch disagree about the name. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [PATCH 07/10] Simplify org-babel-execute-src-block
Aaron Ecay writes: * lisp/ob-core.el (org-babel-execute-src-block): Simplify control flow Avoid potential duplication of org-babel-process-params call. Also makes the code simpler. You may be changing semantics here. I'm not entirely certain if the current way of dealing with the the unmerged and merged parameters and the info block is necessary, but I'd be wary of such a change. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] [PATCH 09/10] Remove org-babel-check-confirm-evaluate macro
Aaron Ecay writes: * lisp/ob-core.el (org-babel-check-confirm-evaluate): remove (org-babel-check-evaluate), (org-babel-confirm-evaluate): move logic here This macro is used in only two places, and has two almost-independent complex logics coded into it. So, suppress the macro and move the logic into the respective functions. I have recently introduced that macro because no amount of documentation can guarantee that the two functions using these values compute them the same way when somebody makes further changes down the road. That is, however, mandatory for these functions to work properly and safely. I haven't checked if the logic hasn't changed with that patch, but I don't think it's any easier to understand than before. Regards, 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] yanking a headline in folded state
In my Emacs I have the following. Would that work? C-c C-x C-w runs the command org-cut-special, which is an interactive compiled Lisp function in `org.el'. I incidentally figured out the problem: I had rebound yank to C-., and did not realize that org-yank was bound to the original yank shortcut (C-y). Therefore, I was yanking the org text rather than org-yanking it. org-cut-special turns out not to be necessary, although I appreciate the suggestion; and in fiddling around with it, I found the solution to my problem. Lesson learned: I should always take a second look at potential org-mode parallels to the standard Emacs commands. Until now, I had assumed that yank in org-mode was identical to yank generally.
Re: [O] I have terminated my assignment
Jambunathan, If you're leaving the Org-mode community, I'd prefer to remember you with gratitude for leaving us the excellent ODT exporter. Please stop diminishing your legacy with this quasi-legal wrangling. As a user, I have greatly appreciated both your code contributions and your patient help on the mailing list in the past. I think your recent way of registering your displeasure with the Org maintainer is beneath you. Also unhelpful, pointless, damaging to the community, and, in the worst-case scenario, a damn waste of good work. Yours, Christian Jambunathan K writes: I have terminated my copyright assignment to Emacs (or atleast notified the copyright desk). For the sake of record, I haven't authorized Bastien to move the ox-html.el and ox-odt.el out of the ./contrib/lisp directory in to the main ./lisp/ directory. He didn't seek my permissions to move the file away from contrib/lisp in to lisp/. I cannot agree with Orgmode project's contention that I have given consent for above work to be included in Emacs proper. If FSF ever consults me on rights to my contributions to the above files, my position will ambiguously be Changes made by me to files ox-html.el, ox-odt.el and ox-freemind.el are my own and I assert my rights over the changes. Specifically, I will not acknowledge FSF as having the rights to the said changes. Bastien has lost my trust very long back. More so when he resorted to erasing attribution to my work. My changes to ox-html.el and ox-odt.el is not worth the keyboard it is typed on. My changes are useful. Handing over of rights, liberal license grant backs from FSF and enforcement of copyright etc. are too big a thing to even think about for my humble contributions. The size of my contributions are simply not worth so much bureaucratic trouble. Meanwhile, interesting observers can observe how FSF responds. Either they can act consistent with project policy (and reject my work) or appropriate my work (through changing the rules of the game and interpreting the terms of contract) to suit their agenda. Advice for potential contributors: -- Think before signing a Future Assignment. Why write a blank cheque and have RMS run behind you with this is a diff to Emacs and all your code is mine. Assign work on a case-by-case basis. Insist that you cannot apriori sign off rights to future works (Future work and circumstances cannot be predicted. Be circumspect). If more people refuse to assign future rights, FSF will be forced to review their stance. Ask for information on how you can withhold assignments for some selected work. Ask them for cancellation form or a withholding form. Ask them at what point in time your work is *actually part* of Emacs. Carefully consider the arguments that FSF advances and also the arguments advanced by detractors. Don't be swayed by propaganda. If you are not sure, just don't sign the copyright and wait till you have ascertained the nature of your work in it's near final form. Jambunathan K.
Re: [O] Org-mode as a metalanguage: calling SQL functions
Gary Oberbrunner ga...@oberbrunner.com writes: Aha -- you have to use the :var syntax on the begin_src line, not the params-in-parens syntax on the name line. Your version works: #+name: example-block #+begin_src sh :var input= echo input is $input #+end_src but this doesn't: #+name: example-block(input=) #+begin_src sh echo input is $input #+end_src The doc seems to say it should work the same, in http://orgmode.org/manual/var.html (see Alternate Argument Syntax). At this point I'm not sure if the documentation or the code should be amended. I've personally never liked the args-in-block-name syntax, but I don't recall if we formally decided to abandon it, or if it has simply been broken in a recent commit. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Aaron Ecay aarone...@gmail.com writes: Hi Eric, 2013ko martxoak 23an, Eric Schulte-ek idatzi zuen: Unless you actually try :var and find it lacking in some way, I'd prefer to stick with simply using :var to identify dependencies between code blocks. We've seen in other places how providing multiple alias for header arguments increases rather than reduces confusion. I’m uneasy with how magic :var is, in the sense that it does a lot of heavy lifting with interconversion to/from org syntax, table formats, etc. What if a special convention was introduced, whereby :var _=whatever would not result in any variable binding being introduced into the code block (but would behave the same wrt. dependencies)? This is similar to the syntax for discarding unused values in some programming languages (python comes to mind): I think the following is the simplest and clearest solution in these cases (certainly more straightforward than the syntax below). #+begin_src R x-make something big done #+end_src #+RESULTS: : done #+begin_src python _, foo, _ = iOnlyCareAboutTheSecondValue() #+end_src So, this would look like: #+begin_src R :var a=123 :var _=(R-pid) :var _=(something-else) # code which can access a, but has no access to (R-pid) or (something-else) #+end_src If this doesn’t resonate with you, I’ll just drop this suggestion. To me this sounds like a solution in search of a problem. If you actually run into a problem in real life then we can consider if an Org-mode solution is necessary. I will of course certainly report any problems I have using :var in practice as well, with patches to fix them insofar as it is within my ability to provide them. Great, thanks. Maybe the documentation of :var should be improved to enhance discoverability. I would be happy to apply a patch to this effect. Patch is on the way. Why not just return a dummy value at the end of the code block? #+begin_src R :cache yes # code to perform side effect done #+end_src This would require the user to add this dummy result redundantly to many code blocks, for no reason. That is cognitively burdensome (user must remember when to add it) and ugly, if the source code is to be exported in the document (or tangled). But this case is straightforward to detect on org’s end, and fairly straightforward to work around (this is in fact what my original patch was). So I am still not sure why this burden should to be imposed. Again, I think you're anticipating problems which don't crop up in actuality (e.g., in the many years of Org-mode code block usage by me and many others). Please just get to using Org-mode code blocks to do something, and then much more attention will be paid to *experienced* rather than *anticipated* problems. Well, I suppose one man's dirty kludge is another's beautiful hack. The question here is whether the complexity lies in the implementation (and thus the interface) or in the code block itself. While I generally prefer the later, in this case of :results none :cache yes I would be open to placing some custom logic in the backend, which stores the hash value with the code block, possibly changing #+begin_src R :cache yes # code to perform side effect #+end_src to #+begin_src R :cache 9f4e5b4b07e93c680ab37fc4ba1f75e1bfc0ee0a # code to perform side effect #+end_src keeping in mind that the actual hash value should be hidden after the first couple of characters. [...] If you want the cache in the header, I think I can try to work on a patch, but it does look tricky. So I am not sure I will have time to work on it until next week. (If anyone else wants to beat me to the punch, please feel free!) One question: should we have the cache in the header only for :results none blocks, or for all blocks? I'm just as happy raising an error or warning when the :cache and :results none options are found together, and doing no caching in that case. Users can always just return a dummy value and remove :results none. So should I not work on this modified version of my original patch? I am genuinely trying to be helpful, so that my own modest contribution can make even more useful what is already a very useful tool thanks to the efforts of many people, including you. Maybe I am barking up the wrong tree. Correct, lets not work on implementing this cache in the header idea. I am certainly sorry if you are upset by something I have said – such was never my intention. You misread my tone, I'm not upset. It sounds like such an (R-pid foo) function would be easy to implement. I'd vote for that solution (implementing this function in your .emacs, and then sharing it if necessary) for now. If this need to associate PIDs with results becomes more wide spread (in a couple of years of Org-mode code blocks this is the first time
Re: [O] [PATCH 00/10] babel cleanups
Aaron Ecay aarone...@gmail.com writes: Here are several patches to fix things in and around org-babel. They're each independent of the others (and hopefully all apply cleanly, without depending on other members of the series). Here's a little summary of each: Thanks for these patches, many look like obvious wins, some less so. I likely won't have time to review them (or do much of anything) in the near term, but at some point I will make time to review them and reply here. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [PATCH] Add 'inline-only option to org-export-babel-evaluate
I'm happy to apply this patch, however please also supply a patch which updates the corresponding documentation. Thanks! Aaron Ecay aarone...@gmail.com writes: * lisp/ob-exp.el (org-export-babel-evaluate): Update defcustom to provide 'inline-only option (org-babel-exp-results): Implement 'inline-only for org-export-babel-evaluate This is useful because there is no way for inline results to be stored. The imagined usecase is that all non-inline source blocks will be evaluated manually by the user. Inline blocks, however, must be evaluated during export, or they will be simply deleted by the exporter. --- lisp/ob-exp.el | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el index 0d98690..6783bd5 100644 --- a/lisp/ob-exp.el +++ b/lisp/ob-exp.el @@ -52,10 +52,13 @@ (defcustom org-export-babel-evaluate t Switch controlling code evaluation during export. When set to nil no code will be evaluated as part of the export -process. +process. When set to 'inline-only, only inline code blocks will +be executed. :group 'org-babel :version 24.1 - :type 'boolean) + :type '(choice (const :tag Never nil) + (const :tag Only inline code inline-only) + (const :tag Always t))) (put 'org-export-babel-evaluate 'safe-local-variable (lambda (x) (eq x nil))) (defun org-babel-exp-get-export-buffer () @@ -378,7 +381,9 @@ Results are prepared in a manner suitable for export by org-mode. This function is called by `org-babel-exp-do-export'. The code block will be evaluated. Optional argument SILENT can be used to inhibit insertion of results into the buffer. - (when (and org-export-babel-evaluate + (when (and (or (eq org-export-babel-evaluate t) + (and (eq type 'inline) + (eq org-export-babel-evaluate 'inline-only))) (not (and hash (equal hash (org-babel-current-result-hash) (let ((lang (nth 0 info)) (body (if (org-babel-noweb-p (nth 2 info) :eval) -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] I have terminated my assignment
On Tue, Apr 2, 2013 at 5:16 PM, Christian Moe m...@christianmoe.com wrote: Jambunathan, If you're leaving the Org-mode community, I'd prefer to remember you with gratitude for leaving us the excellent ODT exporter. Please stop diminishing your legacy with this quasi-legal wrangling. As a user, I have greatly appreciated both your code contributions and your patient help on the mailing list in the past. I think your recent way of registering your displeasure with the Org maintainer is beneath you. Also unhelpful, pointless, damaging to the community, and, in the worst-case scenario, a damn waste of good work. Yours, Christian Jambunathan K writes: I have terminated my copyright assignment to Emacs (or atleast notified the copyright desk). With respect to Org staying up to date on these developments, it probably *is* a good idea to know how Emacs/FSF responds. Should the rights be granted back to Jambunathan, Org should behave accordingly. As it currently reads however, it made me think of something along the lines of, I have terminated my marriage to my wife (or at least left a message with her secretary to let her know). The two are hardly the same. Until this is formalized, papers signed and rights granted (regardless of 20/20 hindsight and warnings to other potential signers) still stand as binding. John
Re: [O] I have terminated my assignment
Hi, For the record created by this mailing list thread, I would like to correct two mistakes: On 2.4.2013, at 10:42, Jambunathan K kjambunat...@gmail.com wrote: I have terminated my copyright assignment to Emacs (or atleast notified the copyright desk). For the sake of record, I haven't authorized Bastien to move the ox-html.el and ox-odt.el out of the ./contrib/lisp directory in to the main ./lisp/ directory. He didn't seek my permissions to move the file away from contrib/lisp in to lisp/. I cannot agree with Orgmode project's contention that I have given consent for above work to be included in Emacs proper. When this code first entered the Org-mode repository, it was not in contrib/. The code entered in EXPERIMENTAL/. Both files where marked Copyright (C) 2011-2012 FSF and Copyright (C) 2010-2012 FSF from the first moment they entered into the repository, in agreement with Jambunathan's standing assignment with the FSF at the time. http://orgmode.org/cgit.cgi/org-mode.git/commit/EXPERIMENTAL/org-e-html.el?id=93ec2c7a5034944f5f6c77be6f37c49b4a697b72 http://orgmode.org/cgit.cgi/org-mode.git/commit/EXPERIMENTAL/org-e-odt.el?id=c2ea76e71034a161d875647b27cfbd72264b5d64 The files moved to contrib/ only in April of 2012, in a period when the exporter structure was fleshed out and completed. This move was clearly a staging event for a later move into core, rather than a change of copyright assignment. While unassigned files are are only allowed in contrib/, the reverse is not true and never was. If FSF ever consults me on rights to my contributions to the above files, my position will ambiguously be Changes made by me to files ox-html.el, ox-odt.el and ox-freemind.el are my own and I assert my rights over the changes. Specifically, I will not acknowledge FSF as having the rights to the said changes. Bastien has lost my trust very long back. More so when he resorted to erasing attribution to my work. As far as I can see, the attribution is still in the manual and in all relevant files. What was removed seems to be a special acknowledgement of outstanding support for the maintainer. - Carsten
Re: [O] I have terminated my assignment
Am 03.04.2013 00:25, schrieb John Hendy: On Tue, Apr 2, 2013 at 5:16 PM, Christian Moe m...@christianmoe.com wrote: Jambunathan, If you're leaving the Org-mode community, I'd prefer to remember you with gratitude for leaving us the excellent ODT exporter. Please stop diminishing your legacy with this quasi-legal wrangling. As a user, I have greatly appreciated both your code contributions and your patient help on the mailing list in the past. I think your recent way of registering your displeasure with the Org maintainer is beneath you. Also unhelpful, pointless, damaging to the community, and, in the worst-case scenario, a damn waste of good work. Yours, Christian Jambunathan K writes: I have terminated my copyright assignment to Emacs (or atleast notified the copyright desk). With respect to Org staying up to date on these developments, it probably *is* a good idea to know how Emacs/FSF responds. Should the rights be granted back to Jambunathan, Org should behave accordingly. Hi John, as for the GPLed code, no one may revert it's GPLed status once published. That's great with GPL, made it a success story. Can't see anything to grant back so far from Org's side. Best, Andreas As it currently reads however, it made me think of something along the lines of, I have terminated my marriage to my wife (or at least left a message with her secretary to let her know). The two are hardly the same. Until this is formalized, papers signed and rights granted (regardless of 20/20 hindsight and warnings to other potential signers) still stand as binding. John
Re: [O] Org-mode as a metalanguage: calling SQL functions
Am 02.04.2013 23:54, schrieb Eric Schulte: Gary Oberbrunner ga...@oberbrunner.com writes: Aha -- you have to use the :var syntax on the begin_src line, not the params-in-parens syntax on the name line. Your version works: #+name: example-block #+begin_src sh :var input= echo input is $input #+end_src but this doesn't: #+name: example-block(input=) #+begin_src sh echo input is $input #+end_src The doc seems to say it should work the same, in http://orgmode.org/manual/var.html (see Alternate Argument Syntax). At this point I'm not sure if the documentation or the code should be amended. I've personally never liked the args-in-block-name syntax, but I don't recall if we formally decided to abandon it, or if it has simply been broken in a recent commit. Hi Eric, AFAIU exist considerable backsides when allowing this args-in-block-name. As languages differ, you must write some translations for every lang somehow, i.e, re-invent it's handling. Also can't see a meta-languags than, it would mean address other languages from an Org dialect. A major backside already visible it breaking the legibility of native languages code. Org constructs are not easier to read than native lang, it's more difficult with that lined-up args lists. Andreas
Re: [O] I have terminated my assignment
Carsten When this code first entered the Org-mode repository, it was not in contrib/. The code entered in EXPERIMENTAL/. Both files where marked Copyright (C) 2011-2012 FSF and Copyright (C) 2010-2012 FSF from the first moment they entered into the repository, in agreement with Jambunathan's standing assignment with the FSF at the time. http://orgmode.org/cgit.cgi/org-mode.git/commit/EXPERIMENTAL/org-e-html.el?id=93ec2c7a5034944f5f6c77be6f37c49b4a697b72 http://orgmode.org/cgit.cgi/org-mode.git/commit/EXPERIMENTAL/org-e-odt.el?id=c2ea76e71034a161d875647b27cfbd72264b5d64 The files moved to contrib/ only in April of 2012, in a period when the exporter structure was fleshed out and completed. This move was clearly a staging event for a later move into core, rather than a change of copyright assignment. While unassigned files are are only allowed in contrib/, the reverse is not true and never was. What does FSF record indicate? Last I checked, it indicates that Emacs contains no such files and these files are unknown to the Emacs product. FSF email records also say that I have out of my own initiative refused to assign *my* rights to them. I haven't authorized Bastien to move contrib/lisp changes to lisp/. I invite him to show a proof to that effect. What you indicate is daily routine. IMNSHO, they are good to know but not substantial to resolve the dispute. It is common knowledge that unreleased source is *known* to show wrong Copyright years prior to release. Corporations securely back up - as in put in a locker - only released tar balls. What matters is the product (product here is Emacs) and a public release of product together with source tarball. Org-8.0 is not released yet. It is a work-in-progress and not known to public at large. Org-8.0 is not in Emacs, it is merely a staging ground for Emacs and Emacs maintainers will do their own due diligence *independent* of the due diligence done by Org maintainer. Thought experiment: I steal my employer's code, slap my authorship and assign copyright to FSF. Does that mean the code is assigned to FSF? No. Bottomline: Intent to act is not the same as act itself. Jambunathan K.
Re: [O] Org-mode as a metalanguage: calling SQL functions
On 2.4.2013, at 23:54, Eric Schulte schulte.e...@gmail.com wrote: Gary Oberbrunner ga...@oberbrunner.com writes: Aha -- you have to use the :var syntax on the begin_src line, not the params-in-parens syntax on the name line. Your version works: #+name: example-block #+begin_src sh :var input= echo input is $input #+end_src but this doesn't: #+name: example-block(input=) #+begin_src sh echo input is $input #+end_src The doc seems to say it should work the same, in http://orgmode.org/manual/var.html (see Alternate Argument Syntax). At this point I'm not sure if the documentation or the code should be amended. I've personally never liked the args-in-block-name syntax, but I don't recall if we formally decided to abandon it, or if it has simply been broken in a recent commit. I am not sure if I have any say here, but I agree that the args in name notation looks not as good and might be considered for abolishment. - Carsten
