[O] babel header argument :var is not expanded when tangling

2017-12-23 Thread numbch...@gmail.com
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

2017-12-23 Thread numbch...@gmail.com
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 Alsinet 
wrote:

> 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

2017-12-23 Thread Nicolas Goaziou
Hello,

Eli Zaretskii  writes:

>> 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?

2017-12-23 Thread Kaushal Modi
On Sat, Dec 23, 2017, 1:57 AM Yasushi SHOJI  wrote:

> 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

2017-12-23 Thread Eli Zaretskii
> 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

2017-12-23 Thread Eli Zaretskii
> 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

2017-12-23 Thread Nicolas Goaziou
Hello,

Paul Dumais  writes:

> 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

2017-12-23 Thread Nicolas Goaziou
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