[O] babel header argument :var is not expanded when tangling
Here is a quick test: * Test tangle will auto expand and substitute :var #+begin_src js :tangle kk.js console.log("hello, world!"); #+end_src #+begin_src js :var name="chris" :tangle require-kk.js // require("kk.js"); console.log("Hi, ", name); #+end_src #+RESULTS: : Hi, chris #+NAME: check whether tangle expand and substitute :var #+begin_src shell cat require-kk.js #+end_src #+RESULTS: check whether tangle expand and substitute :var : var name="chris"; : console.log("Hi, ", name); The upper result should be: ~console.log("Hi, ", "chris");~. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/
Re: [O] Hope ob-js can support :session feature
I come up with an idea, use babel header argument :var to pass in the absolute path of tangled file. And ob-js will expand and replace that :var variable inside of JavaScript src block. So that you don't need to repeatly manually typing the absolute path of the tangled file. Maybe it only one for "require". One question is that I don't know whether tangle to auto expand and substitute the :var. After a quick test, seems it should be expanded but not indeed. Check out the info node of `:no-expand`. Here is my quick test: * Test tangle will auto expand and substitute :var #+begin_src js :tangle kk.js console.log("hello, world!"); #+end_src #+begin_src js :var name="chris" :tangle require-kk.js // require("kk.js"); console.log("Hi, ", name); #+end_src #+RESULTS: : Hi, chris #+NAME: check whether tangle expand and substitute :var #+begin_src shell cat require-kk.js #+end_src #+RESULTS: check whether tangle expand and substitute :var : var name="chris"; : console.log("Hi, ", name); [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Sat, Dec 23, 2017 at 11:06 AM, Martin Alsinetwrote: > Hello, > > I don't have a blog yet, it is in my list of new year's resolutions. I > will try to explain it here anyway, maybe it can serve as a draft for a > blog post. > > When you hit *C-c* inside of a javascript source block, *ob-js* takes the > js code from the js block and saves it into a temp file (in linux the temp > file will be in saved /tmp/random-name, while in Mac OS X it will be saved > in /var/folders/random-name). Then, it uses *org-babel-eval* to execute > the js code, which in turn creates a temp buffer, inserts the contents of > the temp file into the temp buffer and uses *shell-command-on-region* to > run the js code with *node* as the executed command. > > That is the reason why you must use absolute paths in the require, because > when the code runs it is no longer in the same directory of the org file, > but in a temporary folder. If you use require("./src/my-component.js"), > require won't find the js file because it is in another directory. > > Let's try an example (if you want you can send me one of your examples and > I can modify it to use my approach) > > First, I will define two functions to show an array of javascript objects > as an org-mode table: > > #+BEGIN_SRC js :tangle src/table.js > function table_row(cells){ > console.log("|" + cells.join("|") + "|"); > } > function table(rows){ > console.log("|---|"); > table_row(Object.keys(rows[0])); > console.log("|---|"); > rows.map(row => table_row(Object.keys(row).map(k => row[k]))); > console.log("|---|"); > } > module.exports = table; > #+END_SRC > > Notice the :tangle src/table.js property, which I will use to require it > in a later block: > > #+BEGIN_SRC js :results output raw drawer > var data = [ { day: 'SUNDAY', accidents: 3986 }, > { day: 'MONDAY', accidents: 6109 }, > { day: 'SATURDAY', accidents: 6274 }, > { day: 'WEDNESDAY', accidents: 6453 }, > { day: 'THURSDAY', accidents: 6546 }, > { day: 'TUESDAY', accidents: 6557 }, > { day: 'FRIDAY', accidents: 6916 } ]; > > // here you have to use the full path to the table.js file > var view_as_table = require("/app/src/table.js"); > > view_as_table(data); > #+END_SRC > > Then I run *org-babel-tangle* to write the table.js file, and when I hit > *C-c* inside of this last block, it requires the tangled table.js file, > runs the function and we get the following results: > > #+RESULTS: > :RESULTS: > |---+---| > | day | accidents | > |---+---| > | SUNDAY| 3986 | > | MONDAY| 6109 | > | SATURDAY | 6274 | > | WEDNESDAY | 6453 | > | THURSDAY | 6546 | > | TUESDAY | 6557 | > | FRIDAY| 6916 | > |---+---| > :END: > > About the order of execution, if you used sessions in my example, you have > to run the first block (which defines the function) before running the > second (which uses it), or it would fail because the table function has not > been loaded. > > Now imagine a very long document with dozens of source blocks. In order to > run the block number 23, you will have to run all the preceding blocks on > which that block depends. I don't like that, even if the document is meant > to be read sequentially, from start to finish, I want to be able to open > the org file, go to any section and running any source code block without > having to remember the sequence of dependencies between them. Worst case, > all I have to do is run org-babel-tangle to update the tangled files. This > has also the added benefit that it forces me to structure my blocks > correctly, from a code architecture point of view. > > I hope this makes it clearer for you. > > > Martin > >
[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables
Hello, Eli Zaretskiiwrites: >> From: Nicolas Goaziou >> Date: Fri, 08 Dec 2017 18:08:57 +0100 >> Cc: dov.grobg...@gmail.com, 11...@debbugs.gnu.org >> >> For tests, we use `org-test-with-temp-text' macro, e.g., >> >> (org-test-with-temp-text "| a | b |\n| c | d |" >> ... do something in that buffer ...) > > You didn't say that this macro is only available in the Org's Git > repository... I believed our test suite had been merged with Emacs. Sorry about that. > Method 2: give the spaces around the cell text the display property > which makes the spaces serve as segment separators for the purposes of > the bidirectional reordering. Sounds good. I implemented it in Org. Hopefully, Org is now friendlier to BiDi. Please let me know if something is missing. Thank you. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] [RFC] Dog food, anyone?
On Sat, Dec 23, 2017, 1:57 AM Yasushi SHOJIwrote: > I just tried rst exporter, which I just happen to be using, and it works > great, > with the following tiny patch. And the results is this. > > http://org-manual.readthedocs.io/en/latest/ > > Info and orgmode.org/org.html is already super useful so this doesn't > gain much for me. but someone might like the way it renders. > Thanks for sharing that! I do like the colors and syntax highlighting on readthedocs.io. The only minor issue is that it loads the whole manual as a single HTML page, so it takes a while to load. Do you know if there's a way to set it up so that it shows a single page per node as orgmode.org does? Even if not, this is wonderful :) > -- Kaushal Modi
[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables
> Date: Sat, 23 Dec 2017 15:38:11 +0200 > From: Eli Zaretskii> Cc: dov.grobg...@gmail.com, 11...@debbugs.gnu.org > > I found both methods doing well, so I'm going to show both, and let > you decide which one is better. On second thought, I think Method 2 is better, because it does exactly what segment separators were invented for: to separate cells in tables. By contrast, the bidi formatting control characters are for controlling the display order in general text, not necessarily in tables.
[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables
> From: Nicolas Goaziou> Date: Fri, 08 Dec 2017 18:08:57 +0100 > Cc: dov.grobg...@gmail.com, 11...@debbugs.gnu.org > > For tests, we use `org-test-with-temp-text' macro, e.g., > > (org-test-with-temp-text "| a | b |\n| c | d |" > ... do something in that buffer ...) You didn't say that this macro is only available in the Org's Git repository... Anyway, since it's a very simple macro, I just used its guts below. I found both methods doing well, so I'm going to show both, and let you decide which one is better. The below provides a demonstration of each method by displaying a buffer with a table whose columns include both L2R and R2L text, such that the table columns are still laid out left to right, unlike when one just types the characters in the cells. Method 1: wrap each string with (invisible) bidi formatting control characters which isolate each string from the surrounding text. (defun bidi-isolate-string (str) (concat (propertize (string ?\x2068) 'invisible t) str (propertize (string ?\x2069) 'invisible t))) (with-current-buffer (get-buffer-create "bidi-org-table1") (org-mode) (insert (concat "| " (bidi-isolate-string "abcd") " | " (bidi-isolate-string "efgh") " |\n| " (bidi-isolate-string "אבגד") " | " (bidi-isolate-string "הוזח") " |")) (pop-to-buffer "bidi-org-table")) This has a minor issue: it fails to conceal the bidi control characters on display, although I used the 'invisible' property for that purpose. I'm guessing that Org takes control of the 'invisible' properties, in which case perhaps this method should use some other property, if possible. If it is not practical to conceal the bidi controls on display, the following method is preferable. Method 2: give the spaces around the cell text the display property which makes the spaces serve as segment separators for the purposes of the bidirectional reordering. (defun bidi-separator-space () (propertize " " 'display '(space :width 1))) (with-current-buffer (get-buffer-create "bidi-org-table2") (org-mode) (insert (concat "|" (bidi-separator-space) "abcd" (bidi-separator-space) "|" (bidi-separator-space) "efgh" (bidi-separator-space) "|\n|" (bidi-separator-space) "אבגד" (bidi-separator-space) "|" (bidi-separator-space) "הוזח" (bidi-separator-space) "|")) (pop-to-buffer "bidi-org-table2")) Let me know if I can help you further, or if you have additional questions.
Re: [O] Error when using :show-process header argument in clojure
Hello, Paul Dumaiswrites: > Hi I was trying to use the new :show-process header argument for clojure in > Org mode version 9.1.4 (9.1.4-13-g84cb63-elpaplus @ > (org-plus-contrib-20171218/) > > I get the following error: > org-babel-insert-result: Wrong type argument: markerp, nil IMO, this is a bit terse to get useful answers. Could you provide an ECM, and a full backtrace? Thank you. Regards, -- Nicolas Goaziou
[O] bug#17523: 24.1; code block ":noweb no" ignored in org-mode
Hello, "Stephen P. Schaefer"writes: > I'm trying to use org-mode noweb syntax to deal with erlang code that > involves bit strings. This is an example t.org file: > > #+STARTUP: indent > * top level > > #+begin_src erlang :noweb yes :tangle hello.erl > -module(hello). > -export(hello). > <> > <> > #+end_src > > ** defines :PROPERTIES: :noweb-ref: defines :END: > > #+begin_src erlang :noweb no > -define(HELLO, <<"hello world">>). > #+end_src > > ** functions :PROPERTIES: :noweb-ref: functions :END: > > #+begin_src erlang > hello() -> ?HELLO. > #+end_src > > I want it to tangle to > > -module(hello). > -export(hello). > -define(HELLO, <<"hello world">>). > hello() -> ?HELLO. > > Instead it tangles to > > -module(hello). > -export(hello). > -define(HELLO, ). > hello() -> ?HELLO. This is now fixed. Thank you. Note however, that Babel properties syntax changed since this report. Properties drawers should be, e.g., :PROPERTIES: :header-args: :noweb-ref functions :END: Regards, -- Nicolas Goaziou0x80A93738