Re: [O] commit 4e864643 breaks org-return

[Simon Thum]

Yes, absolutely, it's annnoying. This probably is the bug I reported a 
day ago.


But in the past I observed this a bit differently:

Your description is correct, but there is/was a workaround: If you go to 
x from the line below (i.e. press cursor left from the beginning of the 
next line) it does/did not trigger. Any fix should probably be tested 
against that trick too.


Cheers,

Simon



On 10/24/15 06:48, Stefan-W. Hahn wrote:

Mail von Nicolas Goaziou, Sat, 24 Oct 2015 at 00:34:54 +0200:

Hello,


commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
Author: Nicolas Goaziou 
Date:   Sun Oct 18 09:36:15 2015 +0200

changes the behaviour of org-return when positioned right after a link with
org-return-follows-link set to t.


the following patch seems to repair the behaviour:


But is the current behaviour broken in the first place? At least it is
consistent with `org-open-at-point' (C-c C-o).


Yes. Yes.

Before commit 4e86464 the behaviour was:

[[link][description]]x

with cursor at x hitting  I got a line opened with cursor positioned
at the beginning of the new line (or indented).

But you are right, org-open-at-point with cursor at position x jumps
to the link. This behaviour is not changed with the commit but I think
this is also not the right behaviour. If you go with the mouse over the x
then you don't get any popup from the link. For this you have to
go at least over the last character "]" of the link resp. the visual "n"
of the description. Even if you describe-text-properties with cursor at x
you don't get any hint of the link. You have to go over the "]" (resp. "n")
to see the link hint.

 From my point of view the commit 4e86464 changes the behaviour of org-return
in a manner of which I think is not natural. org-open-at-point is, in my
opinion, wrong in the same way because description says:
"... When point is on a link, follow it."
And being with cursor at x is obviously not "on a link".

Any opinions from you or other org'ers?

With kind regards,
Stefan

Re: [O] Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return)

[Nicolas Goaziou]

Hello

"Stefan-W. Hahn"  writes:

> as I observed there is a change in behaviour of org-return from on
>
> commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
> Author: Nicolas Goaziou 
> Date:   Sun Oct 18 09:36:15 2015 +0200
>
> for timestamps, date ranges and any link.
>
> The same change of behaviour was done for org-open-at-point from on
>
> commit d75fa9febc676af4893fba9e4d53d5babbb801aa
> Author: Nicolas Goaziou 
> Date:   Sun Mar 2 10:32:51 2014 +0100
>
> for timestamp, any link and footnote-reference (perhaps other I'm not sure).
>
> For example of a link:
>
>[[link][description]]x
>
> If cursor was at position x the old behaviour of org-return (hitting )
> was to open a new line, and position the cursor at the beginning of the new
> line. The old behaviour of org-open-at-point was to say "no link".
>
> For me this seems consistent because if you go with the cursor over
> position x you see no hint and mouse-click do nothing. You have to go
> over the link to see face changing and be able to mouse-click top follow
> the link.
>
> Additonally description of org-open-at-point say "... When point is on a
> link, follow it", not "on or after".
>
> Also if you insert a link by yanking or org-insert-link cursor is positioned
> directly after inserted link, cursor pos x s.o. With old behaviour you can
> behaviour you can straight hit  to get a newline. With new behaviour
> you have to add space before  or call open-line and position the
> cursor.
>
> For me the new behaviour seems inconsistend itself because everytime
> I want to get a new line I noew have to check if cursor is positioned
> right after a timestamp, or link. Or I have to shutoff
> org-return-follows-link.

Fixed in both `org-return' and `org-open-at-point'. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: commit 72c3f5e8e breaks diary-style sexp entries

[Nicolas Goaziou]

Hello,

"Stefan-W. Hahn"  writes:

> commit 72c3f5e8e55ccab8a9793f729bfbaa89f4fab732
> Author: Nicolas Goaziou 
> Date:   Wed Oct 28 14:41:31 2015 +0100
>
> org-agenda: Fix `org-agenda-get-scheduled'
> 
> * lisp/org-agenda.el (org-agenda-get-scheduled): Rewrite function.
>   Comment code.  Fix fontification and sorting issues introduced in
>
>
> breaks org-agenda when using diary-style sexp entries like <%%(diary-float t
> 4 2)> in as schedule date in org-agenda-get-scheduled when calling
> org-time-string-to-absolute with the sexp.
>
> Errormessage is:
>
> error: #("Bad timestamp ‘%%(diary-float t 4 2)’
> Error was: (Not a standard Org-mode time string: %%(diary-float
> t 4 2))" 15 36 (org-category "test-date" fontified nil))

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Regression in Org triggered from helm

[Kyle Meyer]

Kyle Meyer  writes:

> Simon Thum  writes:
>
>> I was a bit early; I am getting this error now:
>>
>> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>>   replace-regexp-in-string("[]+\\'" "" nil)
>>   (lambda (s) (replace-regexp-in-string "[   ]+\\'" "" s))(nil)
>>   mapconcat((lambda (s) (replace-regexp-in-string "[ ]+\\'" "" s))
>> (#("Aktionen" 0 8 (face org-level-1)) #("Stellensuche" 0 12 (face
>> org-level-2)) #("Kandidaten" 0 10 (face org-level-3)) nil) "/")
>>
>>
>> I bet it's my habit of putting slashes into headlines which breaks the
>> logic. However it worked before.
>
> I can reproduce this with a buffer containing an empty heading.
> (Slashes should work fine.)
>
> org-format-outline-path takes a list of strings for path elements.  It
> handles an empty list fine, but helm-get-org-candidates-in-file is
> passing it (nil).  I'll update org-format-outline-path to discard nil
> path elements, but I should also probably submit a patch to helm to make
> it ignore empty headers rather than passing a non-string list.

This error should be fixed as of 59d7062.

--
Kyle

Re: [O] Babel: How to call code in one org file into another org file

[Lawrence Bottorff]

I guess I'm saying that the whole `org-babel-lob-ingest` into
`org-babel-library-of-babel` exercise should make code ready and available.
Otherwise (especially with the extra `org-babel-lob-ingest` in Local
Variable step I mentioned), what John Kitchin suggested with
`org-babel-load-file` is just as good, i.e., LOB seems hardly worth it. My
whole motivation is to avoid having to scroll through endless code blocks
all on the same level, rather, to have things more modular and distributed,
a bit like DDLs in MS-land.

On Sat, Oct 31, 2015 at 4:34 PM, Nick Dokos  wrote:

> Lawrence Bottorff  writes:
>
> > Yes, I experimented with this too -- and got it to work. But strangely,
> if you leave out the
> >
> > # eval: (org-babel-lob-ingest "./a.org")
> > # eval: (org-babel-lob-ingest "./b.org")
> >
> > lines and do a regular `org-babel-lob-ingest` (or  C-c C-v i) on those
> > two files -- it doesn't work. Rather bizarre behavior, IMHO.
> >
>
> I think you have some misconceptions about what org-babel-lob-ingest
> does. All it does is go through the file and add the named source
> blocks in that file to org-babel-library-of-babel: it does *not*
> evaluate the code blocks. So if the code block is e.g. a lisp code
> block with a defun in it, the function is *not* defined, until the
> code block is evaluated by org-babel: that's what org-sbe does.
>
> > Anyway, the dream behavior for LOB would be to simply add your files to
> your `org-babel-lob-files` in your Emacs init, start up an org file -- and
> be able to simply use all the LOB
> > files in your "live" `org-babel-library-of-babel` list library.
> >
>
> You can do that but again all that does is populate a list that
> only org-babel knows about. You'd still need to evaluate the code
> blocks in order to tell the inferior lisp process about what the
> code block define.
>
> --
> Nick
>
>
>

Re: [O] Babel: How to call code in one org file into another org file

[Nick Dokos]

Lawrence Bottorff  writes:

> Yes, I experimented with this too -- and got it to work. But strangely, if 
> you leave out the 
>
> # eval: (org-babel-lob-ingest "./a.org")
> # eval: (org-babel-lob-ingest "./b.org")
>
> lines and do a regular `org-babel-lob-ingest` (or  C-c C-v i) on those
> two files -- it doesn't work. Rather bizarre behavior, IMHO.
>

I think you have some misconceptions about what org-babel-lob-ingest
does. All it does is go through the file and add the named source
blocks in that file to org-babel-library-of-babel: it does *not*
evaluate the code blocks. So if the code block is e.g. a lisp code
block with a defun in it, the function is *not* defined, until the
code block is evaluated by org-babel: that's what org-sbe does.

> Anyway, the dream behavior for LOB would be to simply add your files to your 
> `org-babel-lob-files` in your Emacs init, start up an org file -- and be able 
> to simply use all the LOB
> files in your "live" `org-babel-library-of-babel` list library.
>

You can do that but again all that does is populate a list that
only org-babel knows about. You'd still need to evaluate the code
blocks in order to tell the inferior lisp process about what the
code block define.

-- 
Nick

Re: [O] How does Library of Babel actually work?

[Lawrence Bottorff]

Yes, and see my response. Having to explicitly re-do the
`org-babel-lob-ingest` in the Local Variables with an eval tells me org
babel doesn't really know about LOB until my file explicitly tells it.
Doing `org-babel-lob-ingest` outside of the org file (at Emacs startup)
should set something to t and org babel should be happy.

On Sat, Oct 31, 2015 at 3:53 PM, Nick Dokos  wrote:

> Lawrence Bottorff  writes:
>
> > New thread. Anyway, putting lisp/SLIME aside, I experimented with emacs
> lisp -- and got
> > the same results, i.e., no real LOB functionality, despite proper
> loading. I must be doing
> > something wrong? I'll describe my process again:
> >
> > Load a.org and b.org into `org-babel-library-of-babel` with
> `org-babel-lob-ingest`. Good.
> > Check -- and yes, both functions are in `org-babel-library-of-babel` and
> seem to be ready
> > and "live." But when I try to call them in c.org, org-mode has no
> knowledge of them. Then
> > I try #+call and #+lob on a b.org function. Still no knowledge of it.
> At this point I'm
> > not sure LOB works -- or I have a mistaken idea of what it is and what
> it does.
> >
>
> org-babel-lob-ingest adds files to the LOB (i.e. it's as if you had the
> code blocks in your file explicitly). But you still need to define the
> function, i.e. evaluate the code block. IOW, you need to call (org-sbe
> "func") in the buffer where you are going to use "func" I think. See my
> other post re. your lisp/slime attempts.
>
> --
> Nick
>
>
>

Re: [O] Babel: How to call code in one org file into another org file

[Lawrence Bottorff]

Yes, I experimented with this too -- and got it to work. But strangely, if
you leave out the

# eval: (org-babel-lob-ingest "./a.org")
# eval: (org-babel-lob-ingest "./b.org")

lines and do a regular `org-babel-lob-ingest` (or  C-c C-v i) on those two
files -- *it doesn't work. *Rather bizarre behavior, IMHO.

Anyway, the dream behavior for LOB would be to simply add your files to
your `org-babel-lob-files` in your Emacs init, start up an org file -- and
be able to simply use all the LOB files in your "live"
`org-babel-library-of-babel` list library.

Re: [O] small caps

[Matt Price]

On Oct 30, 2015 09:09, "Christian Moe"  wrote:
>
>
> Thomas S. Dye writes:
>
> > Sorry, I forgot to give an example.  I use it like this [[sc:ad][AD]].
> >
> > The advantage of a link over a macro is that the link should export
> > correctly to both LaTeX and HTML.
> >
> > If you intend to export to a single backend, then Nicolas' suggestion to
> > use a macro is simpler.
>
> Though you could support multiple backends with a macro, too, you just
> need to use lots of @'s. E.g.:
>
>
> #+MACRO: sc @@latex:\textsc{$1}html:$1@@
>
> Already in 400 {{{sc(bc)}}}, the Greeks...
>
>
> That's for a quick example; better to use  or
> something and put the CSS in a separate stylesheet, of couse

thanks everyone for all the suggestions, I will try out a few of them and
decide which seems most natural for me. But in any event I've learned a bit
about macros and custom links, which has been great.

Matt
>
> Yours,
> Christian

Re: [O] How does Library of Babel actually work?

[Nick Dokos]

Lawrence Bottorff  writes:

> New thread. Anyway, putting lisp/SLIME aside, I experimented with emacs lisp 
> -- and got
> the same results, i.e., no real LOB functionality, despite proper loading. I 
> must be doing
> something wrong? I'll describe my process again:
>
> Load a.org and b.org into `org-babel-library-of-babel` with 
> `org-babel-lob-ingest`. Good.
> Check -- and yes, both functions are in `org-babel-library-of-babel` and seem 
> to be ready
> and "live." But when I try to call them in c.org, org-mode has no knowledge 
> of them. Then
> I try #+call and #+lob on a b.org function. Still no knowledge of it. At this 
> point I'm
> not sure LOB works -- or I have a mistaken idea of what it is and what it 
> does.
>

org-babel-lob-ingest adds files to the LOB (i.e. it's as if you had the
code blocks in your file explicitly). But you still need to define the
function, i.e. evaluate the code block. IOW, you need to call (org-sbe
"func") in the buffer where you are going to use "func" I think. See my
other post re. your lisp/slime attempts.

-- 
Nick

Re: [O] Org markup bug ?

[Nick Dokos]

Mehul Sanghvi  writes:

> Nicolas,
>
>       Thanks for pointing out that the latest version works. I updated 
> org-mode and it seems to be working now.
> I wonder what changed to cause it to work.
>

My guess would be

commit b4af3f0852e9705ddbac66d78cd8a508c547be85
Author: Nicolas Goaziou 
Date:   Sun Oct 25 19:20:25 2015 +0100

Allow more characters in emphasis

* lisp/org.el (org-emphasis-regexp-components): Allow singe quote,
  double quote and comma as the last character in an emphasis string.

Reported-by: Marcin Borkowski 



> On Sat, Oct 31, 2015 at 10:57 AM, Mehul Sanghvi  
> wrote:
>
> I am currently using:
>
>    Org-mode version 8.3.2 (release_8.3.2-195-gbf9146
>
> I will try updating and seeing what happens.
>
> On Sat, Oct 31, 2015 at 5:23 AM, Nicolas Goaziou  
> wrote:
>
> Hello,
>
> Mehul Sanghvi  writes:
>
> > I have the following written in an org file:
> >
> >       The =\,= allows you to put a Lisp expression there and the 
> =#= is
> >        the /replace-count/.  Read /*replace-regexp*/ for more 
> information.
> >
> > When I render this in HTML I get the following:
> >
> >        The \,= allows you to put a Lisp expression there and the =# 
> is the
> > *replace-count*. Read *replace-regexp* for more information.
> >
> > Is this a bug with the parser or am I doing something wrong ?
>
> FWIW, I cannot reproduce it in development version. You may want to
> update Org.
>

-- 
Nick

Re: [O] Babel: How to call code in one org file into another org file

[Nick Dokos]

Lawrence Bottorff  writes:

> I would use local variables for this--something like (untested):
>
> # eval: (org-babel-lob-ingest path/to/your/file)
> # eval: (sbe "my-add")
> # eval: (sbe "multi_x2")
>
> Computer savvy Org moders don't like eval because anything can happen,
> but if you're willing to trust yourself, then it shouldn't cause any
> problems.
>
> With this near the bottom of your file, whenever you open the file your
> other org files will be loaded into the Library of Babel where you can
> load up function definitions as needed.
>
> Of course, you'll need to have slime running when you open the file.
>
> hth,
> Tom
>
> Thanks Tom. Still, I'm wondering if the whole LOB is worth it in
> Lisp/SLIME-land. I can load code with org-babel-lob-ingest into
> `org-babel-library-of-babel`, but SLIME doesn't seem to know about it
> -- which sort of defeats the whole purpose, if you follow what I
> mean. . . . 
>

You got me all curious to see where things break: I had to install slime
and clisp to find out. Everything is working I think: nothing is broken.

As long as you are willing to add Tom's initialization (slightly
modified - the function I have is org-sbe rather than sbe - I guess Tom
has defined sbe in his own setup for backward-compatibility purposes),
the following process works for me.

Here's what I added to my .emacs:

--8<---cut here---start->8---
(setq inferior-lisp-program "/usr/bin/clisp")

;;; start it  - it's important to start slime *before*
;;; you load the c.org file below.
(slime)

(require 'ob-lisp)
--8<---cut here---end--->8---

a.org and b.org are just as you defined them:

--8<---cut here---start->8---
#+name: myadd
#+begin_src lisp :session foo
(defun myadd (x y)
 (+ x y))
#+end_src
--8<---cut here---end--->8---

--8<---cut here---start->8---
#+name: multi_x2
#+begin_src lisp :session
(defun multi_x2 (x)
  (* 2 x))
#+end_src
--8<---cut here---end--->8---

and c.org with Tom's modifications looks like this:

--8<---cut here---start->8---
#+name: add&multi_x2
#+begin_src lisp :session
(defun add&multi_x2 (x y)
 (multi_x2 (myadd x y)))
#+end_src

#+BEGIN_SRC lisp :session
  (add&multi_x2 2 3)
#+END_SRC

# Local Variables:
# eval: (org-babel-lob-ingest "./a.org")
# eval: (org-babel-lob-ingest "./b.org")
# eval: (org-sbe "myadd")
# eval: (org-sbe "multi_x2")
# End:
--8<---cut here---end--->8---

Evaluation of the two code block in c.org proceeds correctly and without
problems.

-- 
Nick

Re: [O] How does Library of Babel actually work?

[John Kitchin]

I think you are mistaken in what you think it does. I am pretty sure what
it does is allow you to call named src-blocks with this syntax:

#+call: some-func-in-lob(args)

It doesn't make the functions in the code blocks necessarily available in
another code block (although through side effects for  emacs-lisp, that
might happen).

I think what you want (this works for emacs-lisp)

is a file, say f1.org containing

#+BEGIN_SRC emacs-lisp :tangle f1.el
(defun mfe () 8)
#+END_SRC


Then, in another file you can do:
#+BEGIN_SRC emacs-lisp
(org-babel-load-file "f1.org")
(mfe)
#+END_SRC

and you will get 8. org-babel-load

This isn't possible in other languages. You can of course have an elisp
block to tangle f1.org, and then if it was python, for example, you could
import the functions in a python block.


John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Sat, Oct 31, 2015 at 11:10 AM, Lawrence Bottorff 
wrote:

> New thread. Anyway, putting lisp/SLIME aside, I experimented with emacs
> lisp -- and got the same results, i.e., no real LOB functionality, despite
> proper loading. I must be doing something wrong? I'll describe my process
> again:
>
> Load a.org and b.org into `org-babel-library-of-babel` with
> `org-babel-lob-ingest`. Good. Check -- and yes, both functions are
> in `org-babel-library-of-babel` and seem to be ready and "live." But when I
> try to call them in c.org, org-mode has no knowledge of them. Then I try
> #+call and #+lob on a b.org function. Still no knowledge of it. At this
> point I'm not sure LOB works -- or I have a mistaken idea of what it is and
> what it does.
>
> LB
>
>
>

Re: [O] Org markup bug ?

[Mehul Sanghvi]

Nicolas,

  Thanks for pointing out that the latest version works. I updated
org-mode and it seems to be working now.
I wonder what changed to cause it to work.


cheers,

  mehul


On Sat, Oct 31, 2015 at 10:57 AM, Mehul Sanghvi 
wrote:

> I am currently using:
>
>Org-mode version 8.3.2 (release_8.3.2-195-gbf9146
>
>
> I will try updating and seeing what happens.
>
>
>
>
> On Sat, Oct 31, 2015 at 5:23 AM, Nicolas Goaziou 
> wrote:
>
>> Hello,
>>
>> Mehul Sanghvi  writes:
>>
>> > I have the following written in an org file:
>> >
>> >   The =\,= allows you to put a Lisp expression there and the =#= is
>> >the /replace-count/.  Read /*replace-regexp*/ for more
>> information.
>> >
>> > When I render this in HTML I get the following:
>> >
>> >The \,= allows you to put a Lisp expression there and the =# is
>> the
>> > *replace-count*. Read *replace-regexp* for more information.
>> >
>> > Is this a bug with the parser or am I doing something wrong ?
>>
>> FWIW, I cannot reproduce it in development version. You may want to
>> update Org.
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
>
>
> --
> Mehul N. Sanghvi
> email: mehul.sang...@gmail.com
>



-- 
Mehul N. Sanghvi
email: mehul.sang...@gmail.com

[O] How does Library of Babel actually work?

[Lawrence Bottorff]

New thread. Anyway, putting lisp/SLIME aside, I experimented with emacs
lisp -- and got the same results, i.e., no real LOB functionality, despite
proper loading. I must be doing something wrong? I'll describe my process
again:

Load a.org and b.org into `org-babel-library-of-babel` with
`org-babel-lob-ingest`. Good. Check -- and yes, both functions are
in `org-babel-library-of-babel` and seem to be ready and "live." But when I
try to call them in c.org, org-mode has no knowledge of them. Then I try
#+call and #+lob on a b.org function. Still no knowledge of it. At this
point I'm not sure LOB works -- or I have a mistaken idea of what it is and
what it does.

LB

Re: [O] Org markup bug ?

[Mehul Sanghvi]

I am currently using:

   Org-mode version 8.3.2 (release_8.3.2-195-gbf9146


I will try updating and seeing what happens.




On Sat, Oct 31, 2015 at 5:23 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Mehul Sanghvi  writes:
>
> > I have the following written in an org file:
> >
> >   The =\,= allows you to put a Lisp expression there and the =#= is
> >the /replace-count/.  Read /*replace-regexp*/ for more
> information.
> >
> > When I render this in HTML I get the following:
> >
> >The \,= allows you to put a Lisp expression there and the =# is
> the
> > *replace-count*. Read *replace-regexp* for more information.
> >
> > Is this a bug with the parser or am I doing something wrong ?
>
> FWIW, I cannot reproduce it in development version. You may want to
> update Org.
>
> Regards,
>
> --
> Nicolas Goaziou
>



-- 
Mehul N. Sanghvi
email: mehul.sang...@gmail.com

Re: [O] 'bare' time stamps

[Eric S Fraga]

On Friday, 30 Oct 2015 at 16:25, Subhan Michael Tindall wrote:
> I'm a fairly well versed org user for managing projects, on a personal
> level.
> I'm trying to set up some projects that need to have fixed numbers of hours
> from other departments distributed among projects and/or users. In order to
> do this cleanly, I'd like to be able to use 'bare' time stamps and time
> ranges IE No dates

Not quite what you want but could you use efforts?

[[info:org#Effort%20estimates][info:org#Effort estimates]]

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-209-gba4d33

Re: [O] Babel: How to call code in one org file into another org file

[Rasmus]

Hi Lawrence,

Lawrence Bottorff  writes:

> There are many, many Babel examples, but I can't seem to find this
> functionality: A function in a Lisp code block in one org file is to be
> called from a Lisp code block in another org file. Is this possible? I know
> you can stick stuff into your personal "Library of Babel," but I just want
> to write a Lisp block that calls a function from another org file. I'll
> have SLIME running, of course.
>
>
> file1.org:
> ...
>
>  #+begin_src lisp
> (defun foo ()
>(...))
> #+end_src
>
> file2.org:
> ...
>
> #+begin_src lisp
> (defun baa ()
>   (foo))
> #+end_src

At export time you could include a named block, but I’m not really sure
that gets you closer to what you want.

E.g. in file 1,

#+name: fun_foo 
#+begin_src lisp
(defun foo ()
   (...))
#+end_src

In file 2,

#+include: "file1.org::fun_foo"

#+begin_src lisp
(defun baa ()
  (foo))
#+end_src

Rasmus

-- 
Spil noget med Slayer!

Re: [O] Org markup bug ?

[Nicolas Goaziou]

Hello,

Mehul Sanghvi  writes:

> I have the following written in an org file:
>
>   The =\,= allows you to put a Lisp expression there and the =#= is
>the /replace-count/.  Read /*replace-regexp*/ for more information.
>
> When I render this in HTML I get the following:
>
>The \,= allows you to put a Lisp expression there and the =# is the
> *replace-count*. Read *replace-regexp* for more information.
>
> Is this a bug with the parser or am I doing something wrong ?

FWIW, I cannot reproduce it in development version. You may want to
update Org.

Regards,

-- 
Nicolas Goaziou