Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

2019-02-04 Thread Emmanuel Charpentier
as of today's (20190118) org-plus-contrib, this seems fixed. Quick
check :

===
# Noweb syntax check

#+property: header-args:python :session
#+property: header-args:sage :session

#+name: A
#+begin_src sage
L.append(i)
#+end_src

#+name: B
#+begin_src sage :noweb yes :exports both
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src

#+name: C
#+begin_src python
L.append(i)
#+end_src

#+name: D
#+begin_src python :noweb yes :exports both
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src
===

Thanks a lot !

--
Emmanuel Charpentier

Le lundi 04 février 2019 à 18:03 +0100, Nicolas Goaziou a écrit :
> Hello,
> 
> Robert Pluim  writes:
> 
> > John Kitchin  writes:
> > 
> > > #+RESULTS:
> > > : <<\([^
> > > : ].+?[^ ]\|[^
> > > : ]\)>>
> > 
> > That regex looks malformed, and will only match strings with 1 or 3
> > or
> > more characters between << and >>. If someone knows what itʼs
> > supposed
> > to be matching we can fix it. eg it looks like it wants to allow
> > 
> > < > 
> > Is that something that should be accepted?
> 
> I fixed the regexp. Thank you.
> 
> Regards,
> 




Re: [O] org-today broken

2019-02-04 Thread Samuel Wales
On 1/31/19, Kyle Meyer  wrote:
> Thanks for the report.  I introduced this and a handful of other related
> incompatibilities with my port of Emacs's c75f505de.  I've reverted the
> problematic spots.

thank you.



[O] bug#34323: reproducibility: absolute file names in ox-odt.elc

2019-02-04 Thread Glenn Morris
Package: emacs,org-mode
Version: 26.1.91
Severity: minor

The compiled file ox-odt.elc contains strings that refer to the
absolute location of the build directory, through
org-odt-schema-dir-list and org-odt-styles-dir-list.
For example, in the Emacs 26.1.91 pretest tarfile, it contains
"/home/nico/work/emacs-26/etc/schema/" and
"/home/nico/work/emacs-26/etc/styles/".
This means the generated elc file is non-reproducible (ie, the contents
change depending on the build directory).

(Like https://debbugs.gnu.org/34321, issued spotted in
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/emacs.html
)





[O] Possible bug fontifying the terms in numbered description list

2019-02-04 Thread Nick Dokos
Terms in description lists

  - Term :: definition

are given an `org-list-dt' face, but the regex (org.el: l.6307 or
thereabouts) does not seem to apply to numbered description lists - in:

  1. Term :: definition

the Term is given no face at all: is that intentional?

Version: Org mode version 9.2 (release_9.2-209-gdeb5c4 @ 
/home/nick/elisp/org-mode/lisp/)

Ref: 
https://emacs.stackexchange.com/questions/47560/customize-the-colour-of-term-in-description-list

Thanks!
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler




Re: [O] [RFC] Org Num library

2019-02-04 Thread Nicolas Goaziou
Hello,

Marco Wahl  writes:

> If there is interest in that patch, the code could be refined to only
> hook into the `post-command-hook' when local numbering of narrowed parts
> has been chosen.

This is mostly already the case. If local numbering of narrowed parts is
inactive, the code executed in `post-command-hook' is (when #f), which
adds no overhead.

Regards,

-- 
Nicolas Goaziou



Re: [O] Commenting in org-mode 9.2.1

2019-02-04 Thread Abdo Haji-Ali
> I cannot reproduce your issue, neither or maint nor on master.
Thanks. I was using Emacs 25.2.2. Updating to Emacs 27.0.50 solves this issue.

-- 
Abdo Haji-Ali



Re: [O] Manual available?

2019-02-04 Thread Kaushal Modi
On Mon, Feb 4, 2019 at 11:33 AM Lawrence Bottorff  wrote:

> Is the latest org-mode manual available as an org file? Is there a github
> for it somewhere?
>
> LB
>

It's here:
https://code.orgmode.org/bzg/org-mode/raw/master/doc/org-manual.org


Re: [O] Commenting in org-mode 9.2.1

2019-02-04 Thread Nicolas Goaziou
Hello,

Abdo Haji-Ali  writes:

> I just updated to the latest org-mode (9.2.1) and noticed that when I press
> M-; (or call `org-comment-dwim`) inside a `#+BEGIN_SRC emacs-lisp` section,
> I get the following error message
> `org-comment-dwim: Wrong number of arguments: (0 . 2), 3`
>
> Calling the function outside a source section works fine though.

I cannot reproduce your issue, neither or maint nor on master.

Regards,

-- 
Nicolas Goaziou



Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

2019-02-04 Thread Nicolas Goaziou
Hello,

Robert Pluim  writes:

> John Kitchin  writes:
>
>> #+RESULTS:
>> : <<\([^
>> : ].+?[^ ]\|[^
>> : ]\)>>
>
> That regex looks malformed, and will only match strings with 1 or 3 or
> more characters between << and >>. If someone knows what itʼs supposed
> to be matching we can fix it. eg it looks like it wants to allow
>
> <>>
>
> Is that something that should be accepted?

I fixed the regexp. Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [O] Error in Literal Examples manual?

2019-02-04 Thread Nicolas Goaziou
Hello,

Lawrence Bottorff  writes:

> At the bottom of this  is
> a description of adding a `org-store-link` inside of a babel code block
> edit called with C-c ' , however, it doesn't seem to work with C-c l ,
> although M-x org-store-line does work. Or am I seeing, doing this
> wrong?

Recent manual doesn't talk about `C-c l', which is a user-reserved
binding. However, if it is bound to `org-store-link', it should work as
expected.

Regards,

-- 
Nicolas Goaziou



[O] Manual available?

2019-02-04 Thread Lawrence Bottorff
Is the latest org-mode manual available as an org file? Is there a github
for it somewhere?

LB


[O] Error in Literal Examples manual?

2019-02-04 Thread Lawrence Bottorff
At the bottom of this  is
a description of adding a `org-store-link` inside of a babel code block
edit called with C-c ' , however, it doesn't seem to work with C-c l ,
although M-x org-store-line does work. Or am I seeing, doing this wrong?

Sorry about previous  version. . . .

LB


Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

2019-02-04 Thread Robert Pluim
John Kitchin  writes:

> #+RESULTS:
> : <<\([^
> : ].+?[^ ]\|[^
> : ]\)>>

That regex looks malformed, and will only match strings with 1 or 3 or
more characters between << and >>. If someone knows what itʼs supposed
to be matching we can fix it. eg it looks like it wants to allow

<>

Is that something that should be accepted?

Robert



Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

2019-02-04 Thread John Kitchin
I doubt it is Python specific, and I don't know why it would work in some
places and not others. For me, the two character name does not work in
elisp, but 1 or 3 does. I agree that seems buggy.

The origin of the problem is here:

#+BEGIN_SRC emacs-lisp
(list
 (string-match (org-babel-noweb-wrap) "<>")
 (string-match (org-babel-noweb-wrap) "<>")
 (string-match (org-babel-noweb-wrap) "<>"))
#+END_SRC

#+RESULTS:
| 0 | nil | 0 |

my regex fu is not adequate to identify the problem:

#+BEGIN_SRC emacs-lisp
(org-babel-noweb-wrap)
#+END_SRC

#+RESULTS:
: <<\([^
: ].+?[^ ]\|[^
: ]\)>>

That function is used in org-babel-expand-noweb-references.


It is somewhat luck that I found that, I was tracing
org-babel-expand-noweb-references to see where it was failing, and walked
through that line to see it failed on "Ah", and worked on longer names.

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 Mon, Feb 4, 2019 at 8:40 AM Emmanuel Charpentier 
wrote:

> Le lundi 04 février 2019 à 08:11 -0500, John Kitchin a écrit :
>
> The problem may be the name is only two characters long. Try Ahh instead.
> That works for me.
>
>
> Indeed. Nice catch ; how did you find this ?
>
> Since this doesn't happen with emacs-lisp or Sage, and since nothing in
> the docs I've read so far suggests anything about the length of a block
> identifier, I consider this a bug in the Python language support code. What
> do you think ? Any hint ?
>
> Thanks a lot !
>
> --
> Emmanuel Charpentier
>
> 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 Mon, Feb 4, 2019 at 7:00 AM Emmanuel Charpentier <
> emm.charpent...@free.fr> wrote:
>
> Seen in `org-mode' version `9.2'.
>
> Using `noweb' syntax works OK with `emacs-lisp':
>
> ┌
> │ #+name: a
> │ #+begin_src emacs-lisp
> │   (setq L (append L (list i)))
> │ #+end_src
> │
> │ #+name: b
> │ #+begin_src emacs-lisp :noweb yes :exports both
> │   ;; Lisp version
> │   (setq L nil)
> │   (dotimes (i 5) <>)
> │   L
> │ #+end_src
> └
>
> This gives :
>
> ┌
> │ (setq L (append L (list i)))
> └
>
> ┌
> │ ;; Lisp version
> │ (setq L nil)
> │ (dotimes (i 5) )
> │ L
> └
>
> The `noweb' syntax also works with `Sage' (a symbolic maths oriented
> Python derivative):
>
> ┌
> │ #+name: Aaarghhh
> │ #+begin_src sage
> │   L.append(i)
> │ #+end_src
> │
> │ #+name: Berde
> │ #+begin_src sage :noweb yes :exports both
> │   ## Python version
> │   L=[]
> │   for i in range(1,6):
> │   <>
> │   L
> │ #+end_src
> └
>
> wich gives :
>
> ┌
> │ L.append(i)
> └
>
> ┌
> │ ## Sage version
> │ L=[]
> │ for i in range(1,6):
> │
> │ L
> └
>
> But using the same syntax in Python fails miserably:
>
> ┌
> │ #+name: Ah
> │ #+begin_src python
> │   L.append(i)
> │ #+end_src
> │
> │ #+name: Beee
> │ #+begin_src python :noweb yes :exports both
> │   ## Python version
> │   L=[]
> │   for i in range(1,6):
> │   <>
> │   L
> │ #+end_src
> └
>
> ┌
> │ L.append(i)
> └
>
> ┌
> │ ## Python version
> │ L=[]
> │ for i in range(1,6):
> │ <>
> │ L
> └
>
> ┌
> │ []
> └
>
>
> It *seems* that the "Ah" block is not expanded.
>
> The code itself should be sound *if* it expanded:
>
> ┌
> │ #+name: B0
> │ #+begin_src python :exports both
> │   L=[]
> │   for i in range(1,6):
> │   L.append(i)
> │   L
> │ #+end_src
> └
>
> ┌
> │ L=[]
> │ for i in range(1,6):
> │ L.append(i)
> │ L
> └
>
> ━━━
>  1  2  3  4  5
> ━━━
>
> During the compilation of the source of this mail, the following is
> printed in the `*Python*' buffer:
>
> ┌
> │ >>> L.append(i)
> │ >>>
> │ >>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
> │ >>>
> │ >>>
> │ >>> 'org_babel_python_eoe'
> │ 'org_babel_python_eoe'
> │ >>> ## Python version
> │ ... L=[]
> │ >>> for i in range(1,6):
> │ ... <>
> │   File "", line 2
> │ <>
> │  ^
> │ SyntaxError: invalid syntax
> │ >>>
> │ >>> L
> │ []
> │ >>>
> │ >>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
> │ >>>
> │ >>>
> │ >>> 'org_babel_python_eoe'
> │ 'org_babel_python_eoe'
> │ >>> L=[]
> │ >>> for i in range(1,6):
> │ ... L.append(i)
> │ ...
> │ >>> L
> │ [1, 2, 3, 4, 5]
> │ >>>
> │ >>> open('/tmp/babel-OJSsxf/python-fW5gK0', 'w').write(str(_))
> │ >>>
> │ >>>
> │ >>> 'org_babel_python_eoe'
> │ 'org_babel_python_eoe'
> │ >>>
> └
>
> The source code of this mail is attached.
>
> --
> Emmanuel Charpentier
>
>


Re: [O] (9.2) Noweb blocks not expanded in Python blocks : it should be a bug...

2019-02-04 Thread Emmanuel Charpentier
Le lundi 04 février 2019 à 08:11 -0500, John Kitchin a écrit :
> The problem may be the name is only two characters long. Try Ahh
> instead. That works for me. 

Indeed. Nice catch ; how did you find this ?
Since this doesn't happen with emacs-lisp or Sage, and since nothing in
the docs I've read so far suggests anything about the length of a block
identifier, I consider this a bug in the Python language support code.
What do you think  ? Any hint ?
Thanks a lot !
--Emmanuel Charpentier
> 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 Mon, Feb 4, 2019 at 7:00 AM Emmanuel Charpentier <
> emm.charpent...@free.fr> wrote:
> > Seen in `org-mode' version `9.2'.
> > 
> > 
> > 
> > Using `noweb' syntax works OK with `emacs-lisp':
> > 
> > 
> > 
> > ┌
> > 
> > │ #+name: a
> > 
> > │ #+begin_src emacs-lisp
> > 
> > │   (setq L (append L (list i)))
> > 
> > │ #+end_src
> > 
> > │ 
> > 
> > │ #+name: b
> > 
> > │ #+begin_src emacs-lisp :noweb yes :exports both
> > 
> > │   ;; Lisp version
> > 
> > │   (setq L nil)
> > 
> > │   (dotimes (i 5) <>)
> > 
> > │   L
> > 
> > │ #+end_src
> > 
> > └
> > 
> > 
> > 
> > This gives :
> > 
> > 
> > 
> > ┌
> > 
> > │ (setq L (append L (list i)))
> > 
> > └
> > 
> > 
> > 
> > ┌
> > 
> > │ ;; Lisp version
> > 
> > │ (setq L nil)
> > 
> > │ (dotimes (i 5) )
> > 
> > │ L
> > 
> > └
> > 
> > 
> > 
> > The `noweb' syntax also works with `Sage' (a symbolic maths
> > oriented
> > 
> > Python derivative):
> > 
> > 
> > 
> > ┌
> > 
> > │ #+name: Aaarghhh
> > 
> > │ #+begin_src sage
> > 
> > │   L.append(i)
> > 
> > │ #+end_src
> > 
> > │ 
> > 
> > │ #+name: Berde
> > 
> > │ #+begin_src sage :noweb yes :exports both
> > 
> > │   ## Python version
> > 
> > │   L=[]
> > 
> > │   for i in range(1,6):
> > 
> > │   <>
> > 
> > │   L
> > 
> > │ #+end_src
> > 
> > └
> > 
> > 
> > 
> > wich gives :
> > 
> > 
> > 
> > ┌
> > 
> > │ L.append(i)
> > 
> > └
> > 
> > 
> > 
> > ┌
> > 
> > │ ## Sage version
> > 
> > │ L=[]
> > 
> > │ for i in range(1,6):
> > 
> > │ 
> > 
> > │ L
> > 
> > └
> > 
> > 
> > 
> > But using the same syntax in Python fails miserably:
> > 
> > 
> > 
> > ┌
> > 
> > │ #+name: Ah
> > 
> > │ #+begin_src python
> > 
> > │   L.append(i)
> > 
> > │ #+end_src
> > 
> > │ 
> > 
> > │ #+name: Beee
> > 
> > │ #+begin_src python :noweb yes :exports both
> > 
> > │   ## Python version
> > 
> > │   L=[]
> > 
> > │   for i in range(1,6):
> > 
> > │   <>
> > 
> > │   L
> > 
> > │ #+end_src
> > 
> > └
> > 
> > 
> > 
> > ┌
> > 
> > │ L.append(i)
> > 
> > └
> > 
> > 
> > 
> > ┌
> > 
> > │ ## Python version
> > 
> > │ L=[]
> > 
> > │ for i in range(1,6):
> > 
> > │ <>
> > 
> > │ L
> > 
> > └
> > 
> > 
> > 
> > ┌
> > 
> > │ []
> > 
> > └
> > 
> > 
> > 
> > 
> > 
> > It *seems* that the "Ah" block is not expanded.
> > 
> > 
> > 
> > The code itself should be sound *if* it expanded:
> > 
> > 
> > 
> > ┌
> > 
> > │ #+name: B0
> > 
> > │ #+begin_src python :exports both
> > 
> > │   L=[]
> > 
> > │   for i in range(1,6):
> > 
> > │   L.append(i)
> > 
> > │   L
> > 
> > │ #+end_src
> > 
> > └
> > 
> > 
> > 
> > ┌
> > 
> > │ L=[]
> > 
> > │ for i in range(1,6):
> > 
> > │ L.append(i)
> > 
> > │ L
> > 
> > └
> > 
> > 
> > 
> > ━━━
> > 
> >  1  2  3  4  5 
> > 
> > ━━━
> > 
> > 
> > 
> > During the compilation of the source of this mail, the following is
> > 
> > printed in the `*Python*' buffer:
> > 
> > 
> > 
> > ┌
> > 
> > │ >>> L.append(i)
> > 
> > │ >>> 
> > 
> > │ >>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
> > 
> > │ >>> 
> > 
> > │ >>> 
> > 
> > │ >>> 'org_babel_python_eoe'
> > 
> > │ 'org_babel_python_eoe'
> > 
> > │ >>> ## Python version
> > 
> > │ ... L=[]
> > 
> > │ >>> for i in range(1,6):
> > 
> > │ ... <>
> > 
> > │   File "", line 2
> > 
> > │ <>
> > 
> > │  ^
> > 
> > │ SyntaxError: invalid syntax
> > 
> > │ >>> 
> > 
> > │ >>> L
> > 
> > │ []
> > 
> > │ >>> 
> > 
> > │ >>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
> > 
> > │ >>> 
> > 
> > │ >>> 
> > 
> > │ >>> 'org_babel_python_eoe'
> > 
> > │ 'org_babel_python_eoe'
> > 
> > │ >>> L=[]
> > 
> > │ >>> for i in range(1,6):
> > 
> > │ ... L.append(i)
> > 
> > │ ... 
> > 
> > │ >>> L
> > 
> > │ [1, 2, 3, 4, 5]
> > 
> > │ >>> 
> > 
> > │ >>> open('/tmp/babel-OJSsxf/python-fW5gK0', 'w').write(str(_))
> > 
> > │ >>> 
> > 
> > │ >>> 
> > 
> > │ >>> 'org_babel_python_eoe'
> > 
> > │ 'org_babel_python_eoe'
> > 
> > │ >>> 
> > 
> > └
> > 
> > 
> > 
> > The source code of this mail is attached.
> > 
> > 
> > 
> > --
> > 
> > Emmanuel Charpentier
> > 


Re: [O] (9.2) Noweb blocks not expanded in Python blocks.

2019-02-04 Thread John Kitchin
The problem may be the name is only two characters long. Try Ahh instead.
That works for me.
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 Mon, Feb 4, 2019 at 7:00 AM Emmanuel Charpentier 
wrote:

> Seen in `org-mode' version `9.2'.
>
> Using `noweb' syntax works OK with `emacs-lisp':
>
> ┌
> │ #+name: a
> │ #+begin_src emacs-lisp
> │   (setq L (append L (list i)))
> │ #+end_src
> │
> │ #+name: b
> │ #+begin_src emacs-lisp :noweb yes :exports both
> │   ;; Lisp version
> │   (setq L nil)
> │   (dotimes (i 5) <>)
> │   L
> │ #+end_src
> └
>
> This gives :
>
> ┌
> │ (setq L (append L (list i)))
> └
>
> ┌
> │ ;; Lisp version
> │ (setq L nil)
> │ (dotimes (i 5) )
> │ L
> └
>
> The `noweb' syntax also works with `Sage' (a symbolic maths oriented
> Python derivative):
>
> ┌
> │ #+name: Aaarghhh
> │ #+begin_src sage
> │   L.append(i)
> │ #+end_src
> │
> │ #+name: Berde
> │ #+begin_src sage :noweb yes :exports both
> │   ## Python version
> │   L=[]
> │   for i in range(1,6):
> │   <>
> │   L
> │ #+end_src
> └
>
> wich gives :
>
> ┌
> │ L.append(i)
> └
>
> ┌
> │ ## Sage version
> │ L=[]
> │ for i in range(1,6):
> │
> │ L
> └
>
> But using the same syntax in Python fails miserably:
>
> ┌
> │ #+name: Ah
> │ #+begin_src python
> │   L.append(i)
> │ #+end_src
> │
> │ #+name: Beee
> │ #+begin_src python :noweb yes :exports both
> │   ## Python version
> │   L=[]
> │   for i in range(1,6):
> │   <>
> │   L
> │ #+end_src
> └
>
> ┌
> │ L.append(i)
> └
>
> ┌
> │ ## Python version
> │ L=[]
> │ for i in range(1,6):
> │ <>
> │ L
> └
>
> ┌
> │ []
> └
>
>
> It *seems* that the "Ah" block is not expanded.
>
> The code itself should be sound *if* it expanded:
>
> ┌
> │ #+name: B0
> │ #+begin_src python :exports both
> │   L=[]
> │   for i in range(1,6):
> │   L.append(i)
> │   L
> │ #+end_src
> └
>
> ┌
> │ L=[]
> │ for i in range(1,6):
> │ L.append(i)
> │ L
> └
>
> ━━━
>  1  2  3  4  5
> ━━━
>
> During the compilation of the source of this mail, the following is
> printed in the `*Python*' buffer:
>
> ┌
> │ >>> L.append(i)
> │ >>>
> │ >>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
> │ >>>
> │ >>>
> │ >>> 'org_babel_python_eoe'
> │ 'org_babel_python_eoe'
> │ >>> ## Python version
> │ ... L=[]
> │ >>> for i in range(1,6):
> │ ... <>
> │   File "", line 2
> │ <>
> │  ^
> │ SyntaxError: invalid syntax
> │ >>>
> │ >>> L
> │ []
> │ >>>
> │ >>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
> │ >>>
> │ >>>
> │ >>> 'org_babel_python_eoe'
> │ 'org_babel_python_eoe'
> │ >>> L=[]
> │ >>> for i in range(1,6):
> │ ... L.append(i)
> │ ...
> │ >>> L
> │ [1, 2, 3, 4, 5]
> │ >>>
> │ >>> open('/tmp/babel-OJSsxf/python-fW5gK0', 'w').write(str(_))
> │ >>>
> │ >>>
> │ >>> 'org_babel_python_eoe'
> │ 'org_babel_python_eoe'
> │ >>>
> └
>
> The source code of this mail is attached.
>
> --
> Emmanuel Charpentier
>


[O] (9.2) Noweb blocks not expanded in Python blocks.

2019-02-04 Thread Emmanuel Charpentier
Seen in `org-mode' version `9.2'.

Using `noweb' syntax works OK with `emacs-lisp':

┌
│ #+name: a
│ #+begin_src emacs-lisp
│   (setq L (append L (list i)))
│ #+end_src
│ 
│ #+name: b
│ #+begin_src emacs-lisp :noweb yes :exports both
│   ;; Lisp version
│   (setq L nil)
│   (dotimes (i 5) <>)
│   L
│ #+end_src
└

This gives :

┌
│ (setq L (append L (list i)))
└

┌
│ ;; Lisp version
│ (setq L nil)
│ (dotimes (i 5) )
│ L
└

The `noweb' syntax also works with `Sage' (a symbolic maths oriented
Python derivative):

┌
│ #+name: Aaarghhh
│ #+begin_src sage
│   L.append(i)
│ #+end_src
│ 
│ #+name: Berde
│ #+begin_src sage :noweb yes :exports both
│   ## Python version
│   L=[]
│   for i in range(1,6):
│   <>
│   L
│ #+end_src
└

wich gives :

┌
│ L.append(i)
└

┌
│ ## Sage version
│ L=[]
│ for i in range(1,6):
│ 
│ L
└

But using the same syntax in Python fails miserably:

┌
│ #+name: Ah
│ #+begin_src python
│   L.append(i)
│ #+end_src
│ 
│ #+name: Beee
│ #+begin_src python :noweb yes :exports both
│   ## Python version
│   L=[]
│   for i in range(1,6):
│   <>
│   L
│ #+end_src
└

┌
│ L.append(i)
└

┌
│ ## Python version
│ L=[]
│ for i in range(1,6):
│ <>
│ L
└

┌
│ []
└


It *seems* that the "Ah" block is not expanded.

The code itself should be sound *if* it expanded:

┌
│ #+name: B0
│ #+begin_src python :exports both
│   L=[]
│   for i in range(1,6):
│   L.append(i)
│   L
│ #+end_src
└

┌
│ L=[]
│ for i in range(1,6):
│ L.append(i)
│ L
└

━━━
 1  2  3  4  5 
━━━

During the compilation of the source of this mail, the following is
printed in the `*Python*' buffer:

┌
│ >>> L.append(i)
│ >>> 
│ >>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
│ >>> 
│ >>> 
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> ## Python version
│ ... L=[]
│ >>> for i in range(1,6):
│ ... <>
│   File "", line 2
│ <>
│  ^
│ SyntaxError: invalid syntax
│ >>> 
│ >>> L
│ []
│ >>> 
│ >>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
│ >>> 
│ >>> 
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> L=[]
│ >>> for i in range(1,6):
│ ... L.append(i)
│ ... 
│ >>> L
│ [1, 2, 3, 4, 5]
│ >>> 
│ >>> open('/tmp/babel-OJSsxf/python-fW5gK0', 'w').write(str(_))
│ >>> 
│ >>> 
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> 
└

The source code of this mail is attached.

--
Emmanuel Charpentier
# Syntaxe noweb ?

#+title:
#+date:
#+author:
#+options: toc:nil

#+property: header-args:python :session
#+property: header-args:sage :session

Seen in ~org-mode~ version src_emacs-lisp{org-version}.

Using ~noweb~ syntax works OK with ~emacs-lisp~:

#+begin_example
#+name: a
#+begin_src emacs-lisp
  (setq L (append L (list i)))
#+end_src

#+name: b
#+begin_src emacs-lisp :noweb yes :exports both
  ;; Lisp version
  (setq L nil)
  (dotimes (i 5) <>)
  L
#+end_src
#+end_example

This gives :

#+name: a
#+begin_src emacs-lisp
  (setq L (append L (list i)))
#+end_src

#+name: b
#+begin_src emacs-lisp :noweb yes :exports both
  ;; Lisp version
  (setq L nil)
  (dotimes (i 5) <>)
  L
#+end_src

The ~noweb~ syntax also works with ~Sage~ (a symbolic maths oriented
Python derivative):

#+begin_example
#+name: Aaarghhh
#+begin_src sage
  L.append(i)
#+end_src

#+name: Berde
#+begin_src sage :noweb yes :exports both
  ## Python version
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src
#+end_example

wich gives :

#+name: Aaarghhh
#+begin_src sage
  L.append(i)
#+end_src

#+name: Berde
#+begin_src sage :noweb yes :exports both
  ## Sage version
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src

But using the same syntax in Python fails miserably:

#+begin_example
#+name: Ah
#+begin_src python
  L.append(i)
#+end_src

#+name: Beee
#+begin_src python :noweb yes :exports both
  ## Python version
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src
#+end_example

#+name: Ah
#+begin_src python
  L.append(i)
#+end_src

#+name: Beee
#+begin_src python :noweb yes :exports both
  ## Python version
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src

It *seems* that the "Ah" block is not expanded.

The code itself should be sound *if* it expanded:

#+begin_example
#+name: B0
#+begin_src python :exports both
  L=[]
  for i in range(1,6):
  L.append(i)
  L
#+end_src
#+end_example

#+name: B0
#+begin_src python :exports both
  L=[]
  for i in range(1,6):
  L.append(i)
  L
#+end_src

During the compilation of the source of this mail, the following is
printed in the ~*Python*~ buffer:

#+begin_example
>>> L.append(i)
>>> 
>>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
>>> 
>>> 
>>> 'org_babel_python_eoe'
'org_babel_python_eoe'
>>> ## Python version
... L=[]
>>> for i in range(1,6):
... <>
  File "", line 2
<>
 ^
SyntaxError: invalid syntax
>>> 
>>> L
[]
>>> 
>>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
>>> 
>>> 

[O] (9.2) Noweb syntax not understood in Python blocks

2019-02-04 Thread Emmanuel Charpentier
Seen in `org-mode' version `9.2'.

Using `noweb' syntax works OK with `emacs-lisp':

┌
│ #+name: a
│ #+begin_src emacs-lisp
│   (setq L (append L (list i)))
│ #+end_src
│ 
│ #+name: b
│ #+begin_src emacs-lisp :noweb yes :exports both
│   ;; Lisp version
│   (setq L nil)
│   (dotimes (i 5) <>)
│   L
│ #+end_src
└

This gives :

┌
│ (setq L (append L (list i)))
└

┌
│ ;; Lisp version
│ (setq L nil)
│ (dotimes (i 5) )
│ L
└

The `noweb' syntax also works with `Sage' (a symbolic maths oriented
Python derivative):

┌
│ #+name: Aaarghhh
│ #+begin_src sage
│   L.append(i)
│ #+end_src
│ 
│ #+name: Berde
│ #+begin_src sage :noweb yes :exports both
│   ## Python version
│   L=[]
│   for i in range(1,6):
│   <>
│   L
│ #+end_src
└

wich gives :

┌
│ L.append(i)
└

┌
│ ## Sage version
│ L=[]
│ for i in range(1,6):
│ 
│ L
└

But using the same syntax in Python fails miserably:

┌
│ #+name: Ah
│ #+begin_src python
│   L.append(i)
│ #+end_src
│ 
│ #+name: Beee
│ #+begin_src python :noweb yes :exports both
│   ## Python version
│   L=[]
│   for i in range(1,6):
│   <>
│   L
│ #+end_src
└

┌
│ L.append(i)
└

┌
│ ## Python version
│ L=[]
│ for i in range(1,6):
│ <>
│ L
└

┌
│ []
└


It *seems* that the "Ah" block is not expanded.

The code itself should be sound *if* it expanded:

┌
│ #+name: B0
│ #+begin_src python :exports both
│   L=[]
│   for i in range(1,6):
│   L.append(i)
│   L
│ #+end_src
└

┌
│ L=[]
│ for i in range(1,6):
│ L.append(i)
│ L
└

━━━
 1  2  3  4  5 
━━━

During the compilation of the source of this mail, the following is
printed in the `*Python*' buffer:

┌
│ >>> L.append(i)
│ >>> 
│ >>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
│ >>> 
│ >>> 
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> ## Python version
│ ... L=[]
│ >>> for i in range(1,6):
│ ... <>
│   File "", line 2
│ <>
│  ^
│ SyntaxError: invalid syntax
│ >>> 
│ >>> L
│ []
│ >>> 
│ >>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
│ >>> 
│ >>> 
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> L=[]
│ >>> for i in range(1,6):
│ ... L.append(i)
│ ... 
│ >>> L
│ [1, 2, 3, 4, 5]
│ >>> 
│ >>> open('/tmp/babel-OJSsxf/python-fW5gK0', 'w').write(str(_))
│ >>> 
│ >>> 
│ >>> 'org_babel_python_eoe'
│ 'org_babel_python_eoe'
│ >>> 
└

The source code of this mail is attached.

--
Emmanuel Charpentier

# Syntaxe noweb ?

#+title:
#+date:
#+author:
#+options: toc:nil

#+property: header-args:python :session
#+property: header-args:sage :session

Seen in ~org-mode~ version src_emacs-lisp{org-version}.

Using ~noweb~ syntax works OK with ~emacs-lisp~:

#+begin_example
#+name: a
#+begin_src emacs-lisp
  (setq L (append L (list i)))
#+end_src

#+name: b
#+begin_src emacs-lisp :noweb yes :exports both
  ;; Lisp version
  (setq L nil)
  (dotimes (i 5) <>)
  L
#+end_src
#+end_example

This gives :

#+name: a
#+begin_src emacs-lisp
  (setq L (append L (list i)))
#+end_src

#+name: b
#+begin_src emacs-lisp :noweb yes :exports both
  ;; Lisp version
  (setq L nil)
  (dotimes (i 5) <>)
  L
#+end_src

The ~noweb~ syntax also works with ~Sage~ (a symbolic maths oriented
Python derivative):

#+begin_example
#+name: Aaarghhh
#+begin_src sage
  L.append(i)
#+end_src

#+name: Berde
#+begin_src sage :noweb yes :exports both
  ## Python version
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src
#+end_example

wich gives :

#+name: Aaarghhh
#+begin_src sage
  L.append(i)
#+end_src

#+name: Berde
#+begin_src sage :noweb yes :exports both
  ## Sage version
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src

But using the same syntax in Python fails miserably:

#+begin_example
#+name: Ah
#+begin_src python
  L.append(i)
#+end_src

#+name: Beee
#+begin_src python :noweb yes :exports both
  ## Python version
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src
#+end_example

#+name: Ah
#+begin_src python
  L.append(i)
#+end_src

#+name: Beee
#+begin_src python :noweb yes :exports both
  ## Python version
  L=[]
  for i in range(1,6):
  <>
  L
#+end_src

It *seems* that the "Ah" block is not expanded.

The code itself should be sound *if* it expanded:

#+begin_example
#+name: B0
#+begin_src python :exports both
  L=[]
  for i in range(1,6):
  L.append(i)
  L
#+end_src
#+end_example

#+name: B0
#+begin_src python :exports both
  L=[]
  for i in range(1,6):
  L.append(i)
  L
#+end_src

During the compilation of the source of this mail, the following is
printed in the ~*Python*~ buffer:

#+begin_example
>>> L.append(i)
>>> 
>>> open('/tmp/babel-OJSsxf/python-dVESY4', 'w').write(str(_))
>>> 
>>> 
>>> 'org_babel_python_eoe'
'org_babel_python_eoe'
>>> ## Python version
... L=[]
>>> for i in range(1,6):
... <>
  File "", line 2
<>
 ^
SyntaxError: invalid syntax
>>> 
>>> L
[]
>>> 
>>> open('/tmp/babel-OJSsxf/python-9NR46u', 'w').write(str(_))
>>> 
>>> 

Re: [O] [RFC] Org Num library

2019-02-04 Thread Marco Wahl
Hello stardiviner,

>>> Just one idea came to my mind.  What about adding an option to restart
>>> the numbering at 1 for the first heading in the case when narrowing is
>>> in effect?
>>
>> AFAICT, detecting narrowing changes requires using
>> `post-command-hook'.
>
> Add more things into `post-command-hook' is not a good idea. Org will
> really getting slow! I saw many Org Mode newbie complain about Org Mode
> slow on big Org file. Myself has this experience often. I have to
> disable some features so speedup Org rendering.
>
> Well, I think this is just my personal opinion. I respect author's
> decision.

I also think it's a good idea to save resources.

I tried out the patch from Nicolas (which works great BTW, thanks!) but
I'm undecided if it adds much value to Org.  So if there is no interest
we could just not commit the patch.

If there is interest in that patch, the code could be refined to only
hook into the `post-command-hook' when local numbering of narrowed parts
has been chosen.


Best regards,  Marco




Re: [O] org-today broken

2019-02-04 Thread Marco Wahl
Hi Kyle,

>> Occasionally I like to bend time to see what the agenda would look like
>> if another day was current.  This can be achieved conveniently when
>> solely function "current-time" is the source for the current time.
>>
>> So I'm all for using the explicit calls to current-time instead of using
>> alternatve sources for the current time.
>
> Sorry for making your time travel harder :]

:[

> Emacs's c75f505dea6 argues for replacing current-time calls with nil
> where possible because "nil is a bit more efficient and should have less
> timing error".  But if there are any particular spots where you'd like
> to use current-time for the reasons you give above, please feel free to
> make those changes.  (There are already quite a few places where I've
> done this because we depend on overriding current-time in tests.)

Thanks for the clarification.

I think it's a not so great idea to build on an assumption about some
internal stuff, here concretely the expectation that the current time is
retrieved per call to `current-time' everywhere in Org.

If there shall be a time travel feature in Org this feature should be
made explicit, I think, which BTW could be ensured with suitable tests.

Possibly one could use external tools to get even more powerful
timetravel, as Marcin proposed IIRC.

So go ahead with every optimization you can find!


Best regards,  Marco




Re: [O] Bug: org-copy-subtree: Invalid function: org-preserve-local-variables

2019-02-04 Thread Abdo Haji-Ali
Updating to the latest org-mode (9.2.1) seems to solve this issue.

On Sun, Feb 3, 2019 at 4:40 PM Abdo Haji-Ali 
wrote:

> I just updated emacs to 27.0.50 and I am seeing the exact same error.
> I think org-preserve-local-variables is in org-macs which is part of
> org-mode source code.
>
> On Sun, Feb 3, 2019 at 4:14 PM Kyle Meyer  wrote:
> >
> > Hello,
> >
> > Abdo Haji-Ali  writes:
> >
> > > On the latest org-mode version, 9.2, I keep receiving the error
> > > 'org-copy-subtree: Invalid function: org-preserve-local-variables'
> > > whenever I try to move a subtree or when I access my agenda.
> > >
> > > This happens even if I run emacs with '-Q'.
> > >
> > > Emacs  : GNU Emacs 25.3.1 (x86_64-redhat-linux-gnu, GTK+ Version
> 3.22.10)
> >
> > This is very likely a problem in your Org installation due to an
> > interaction with the Org version that comes with Emacs 25.  (It lacks
> > the macro org-preserve-local-variables.)
> >
> > See .
>
>
>
> --
> Abdo Haji-Ali
>


-- 
Abdo Haji-Ali


[O] Commenting in org-mode 9.2.1

2019-02-04 Thread Abdo Haji-Ali
I just updated to the latest org-mode (9.2.1) and noticed that when I press
M-; (or call `org-comment-dwim`) inside a `#+BEGIN_SRC emacs-lisp` section,
I get the following error message
`org-comment-dwim: Wrong number of arguments: (0 . 2), 3`

Calling the function outside a source section works fine though.


Re: [O] meaning for _ (and perhaps ^) temporalily changed

2019-02-04 Thread Rudolf Sykora


Julius Dittmar  writes:

> Hi Ruda,
>
> Am 10.12.18 um 11:32 schrieb Rudolf Sykora:
>> is there a way to *temporalily* disable the default interpretation
>> of _ as a subscript?
>> 
>> I use filenames which include _ ,
>
> how about enclosing those filenames in a pair of = signs to mark the
> filename itself as text to be passed through verbatim?
>
> HTH,
> Julius

As I said, this works, however, using = has a font-size effect upon (at
least) html export. There it adds   tags, which, in my
case, makes the text smaller than other text.

Ruda