date:20160406

Hello,

Jonas Bernoulli  writes:

> The related `org-texinfo--build-menu' has a similar issue.  Unlike
> `org-texinfo-make-menu' which may end up not inserting a newline
> when it should, it may end up removing a newline when it should not.
>
> Given this Org file:
>
>   #+TITLE: Demo2 Manual
>   #+TEXINFO_DIR_CATEGORY: Emacs
>   #+TEXINFO_DIR_TITLE: Demo2: (demo2).
>   #+TEXINFO_DIR_DESC: Demo2.
>   
>   * chapter ends with subsection
>   
>   ** section
>   
>   *** subsection
>   
>   * chapter ends with section
>   
>   ** just a section
>   
>   * another chapter
>
> we end up with an info file containing
>
>   * subsection::
>   chapter ends with section
>
> but there should be an empty line between these two lines.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] ox-texinfo: empty line before "* Menu:" is missing

Hello,

Jonas Bernoulli  writes:

> Given this Org file
>
>   #+TITLE: Demo Manual
>   #+TEXINFO_DIR_CATEGORY: Emacs
>   #+TEXINFO_DIR_TITLE: Demo: (demo).
>   #+TEXINFO_DIR_DESC: Demo.
>   
>   * Missing empty line
>   
>   There is text between the heading and the menu
>   
>   ** There is text before this menu
>   ** the empty line before Menu IS missing
>   
>   * Has empty line
>   
>   ** There is no text between heading and this menu
>   ** the empty line before Menu is NOT missing
>
> using C-c C-e i i produces a texi file containing
>
>   There is text between the heading and the menu
>   @menu
>
> and an info file containing
>
>   There is text between the heading and the menu
>   * Menu:
>
> and that is then also displayed like that in Info.  But there should be
> an empty line before "* Menu:".

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] table.el orgmode export html or latex use table-generate-source

Hello,

Uwe Brauer  writes:

> However when I try to export a org file with a table controlled by
> table.el I run into a problem. I have to convert it to a org-table and
> in this process things like splitting cells are lost.

Why do you have to do that? Could you show an ECM?

> So could org-export not call table-generate-source for either latex or
> html export?

I am confused. Isn't `table-generate-source' the export function
provided by "table.el" to handle its tables specifically?

Regards,

-- 
Nicolas Goaziou

Re: [O] babel result chain outdated/inconsistent using var

Daniele Pizzolli  writes:

> Thanks Nicolas for the reply.  Ok, but `org-babel-execute-buffer'
> produces an inconsistent document right now.

This is because you ask it to. See below.

> Mmm, the same reasoning can be used for arguing about the current
> behaviour: If I C-c C-c on a block, I expect only the code of the
> block to be executed, not some other part of the document I am
> editing.  This behaviour will fix my issue.

You are explicitly asking for a re-execution of a remote source block:

  :var DATA=pid

If you are only interested in the results, you should name them, and use
that instead, e.g.

  #+NAME: pid
  #+BEGIN_SRC shell :results value :cache no
  printf '%s' "${$}"
  #+END_SRC

  The following result is usually outdated/inconsistent!

  #+NAME: pid-result
  #+RESULTS: pid
  : 21867

  #+NAME: echo-pid
  #+BEGIN_SRC shell :var DATA=pid-result :results value
  printf '%s' "${DATA}"
  #+END_SRC

  #+RESULTS: echo-pid
  : 21867


Regards,

Re: [O] ox-texinfo: empty line before "* Menu:" is missing

2016-04-06 Thread Jonas Bernoulli

The related `org-texinfo--build-menu' has a similar issue.  Unlike
`org-texinfo-make-menu' which may end up not inserting a newline
when it should, it may end up removing a newline when it should not.

Given this Org file:

  #+TITLE: Demo2 Manual
  #+TEXINFO_DIR_CATEGORY: Emacs
  #+TEXINFO_DIR_TITLE: Demo2: (demo2).
  #+TEXINFO_DIR_DESC: Demo2.
  
  * chapter ends with subsection
  
  ** section
  
  *** subsection
  
  * chapter ends with section
  
  ** just a section
  
  * another chapter

we end up with an info file containing

  * subsection::
  chapter ends with section

but there should be an empty line between these two lines.

This only happens if the preceeding chapter ends with a subsection.
If that ends with section then everything is good.  There might be
other instances where `org-texinfo--build-menu' removes to much
whitespace.

My suggestion is to remove `org-element-normalize-string' from
`org-texinfo--build-menu'.  Again this change might result in some
insignificant whitespace not being removed and again that is better
than removing significant whitespace.

Without doing this the detailed note listing would look like this:

  — The Detailed Node Listing —
  
  chapter ends with subsection# bold
  
  * section:: # empty line follows
  
  section # bold
  
  * subsection::  # no empty line follows
  chapter ends with section   # not bold
  
  * just a section:

Ps: In both cases you might find better solutions which not only never
omit necessary whitespace but also never keep/add unnecessary
whitespace.  But for me just not removing/not adding necessary
whitespace would be good enough and I believe that the changes I
have suggested accomplish that.

[O] ox-texinfo: empty line before "* Menu:" is missing

2016-04-06 Thread Jonas Bernoulli

Hello

Given this Org file

  #+TITLE: Demo Manual
  #+TEXINFO_DIR_CATEGORY: Emacs
  #+TEXINFO_DIR_TITLE: Demo: (demo).
  #+TEXINFO_DIR_DESC: Demo.
  
  * Missing empty line
  
  There is text between the heading and the menu
  
  ** There is text before this menu
  ** the empty line before Menu IS missing
  
  * Has empty line
  
  ** There is no text between heading and this menu
  ** the empty line before Menu is NOT missing

using C-c C-e i i produces a texi file containing

  There is text between the heading and the menu
  @menu

and an info file containing

  There is text between the heading and the menu
  * Menu:

and that is then also displayed like that in Info.  But there should be
an empty line before "* Menu:".

This can be fixed in `org-texinfo-make-menu' by replacing
"@menu\n%s@end menu" with "\n@menu\n%s@end menu".  In rare cases (which
I have not further investigated) this change leads to two empty lines in
the texi file where there should only be one, but these two empty lines
won't make it into the info file, which after all is what really matters
here, after all that's what the end-user will be looking at.

The behavior is currently the same in "maint" and "master".

  Best regards,
  Jonas

Re: [O] [PATCH] org-attach: Use relative path for git annex

2016-04-06 Thread Erik Hetzner

Hi Nicolas,

I don’t believe it was ever applied, nor was it superseded by another. This was
to fix a problem with testing older versions of git-annex. I believe David
remove git-annex on the buildbot, which stopped it from failing, because it was
not being tested.

If you need me to make any changes to this patch, let me know. Thank you!

best, Erik

On Wed, 06 Apr 2016 06:12:42 -0700,
Nicolas Goaziou  wrote:
> 
> Hello,
> 
> Erik Hetzner  writes:
> 
> > * lisp/org-attach.el (org-attach-annex-get-maybe): Use relative path as
> >   argument for git annex. Fixes error in test with version 3 of git
> >   annex.
> 
> It seems like I lost track on this one. Could you tell me about the
> status of this patch? I doesn't seem to be applied. Was it superseded by
> another one?
> 
> Thank you.
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

[O] [PATCH] new :async feature for org-babel-clojure


Hi,

Here is my proposal to create a new :async feature for 
Org-babel-clojure. This is discussed at length in this blog post:


http://fgiasson.com/blog/index.php/2016/04/05/using-clojure-in-org-mode-and-implementing-asynchronous-processing/

I added the commit of the changes, the commit for the ORG-NEWS file and 
the commit for the Worg documentation.


IMPORTANT NOTE: this includes the patches for the new :async feature 
*AND* the new org-babel-clojure-sync-nrepl-timeout setting (for 
consistency's sake)


Thanks,

Fred
>From 2fe515d1fb89ba1ea160711d10f2f68fe0287246 Mon Sep 17 00:00:00 2001
From: Frederick Giasson 
Date: Wed, 6 Apr 2016 12:18:21 -0400
Subject: [PATCH 3/4] Adding information about the new org-babel-clojure :async
 feature.

---
 etc/ORG-NEWS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index e684587..fad0679 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -110,6 +110,15 @@ becomes
 This new option tells the =org-babel-clojure= module the length of the timeout 
 of a synchronous call to the nREPL. This value is in seconds. If =nil= then
 no timeout will occur.
+*** New code block option =:async= for =org-babel-clojure=
+This new option gives the possibility to =org-babel-clojure= user to run
+a block code asynchronously using a new code block parameter =:async=.
+If =:async= is specified in the code block, then it will be processed
+asynchronously by Org-mode. This means that everything that will be 
+output to the REPL by the code will appear in a new window when it will
+be output. Once the processing is finalized, then the window will be closed
+and the output will be added to the results section (if =:results output= is 
+specified).
 *** New org-protocol key=value syntax
 
 Org-protocol can now handle query-style parameters such as:
-- 
1.9.5.msysgit.0

>From e218aaef38f6dc0f9affa516aafa18b77c2a3a1e Mon Sep 17 00:00:00 2001
From: Frederick Giasson 
Date: Wed, 6 Apr 2016 12:19:11 -0400
Subject: [PATCH 4/4] Adding a new feature :async feature to org-babel-clojure.
 With this new feature, someone can evaluate Clojure code in Org-mode code
 blocks asynchronously.

---
 lisp/ob-clojure.el | 78 ++
 1 file changed, 61 insertions(+), 17 deletions(-)

diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 86f1cff..6059d7d 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -91,35 +91,79 @@
   body)))
 
 (defun org-babel-execute:clojure (body params)
-  "Execute a block of Clojure code with Babel."
+  "Execute a block of Clojure code with Babel. The block can be executed
+   synchenously by default or asynchronously with the :async parameter"
   (let ((expanded (org-babel-expand-body:clojure body params))
+   (sbuffer "*Clojure Sub Buffer*")
+   (async (if (assoc :async params) t nil))
+   (response (cons 'dict nil))
+   status
result)
 (case org-babel-clojure-backend
   (cider
(require 'cider)
(let ((result-params (cdr (assoc :result-params params
-(setq result
-  (nrepl-dict-get
-   (let ((nrepl-sync-request-timeout 
org-babel-clojure-sync-nrepl-timeout))
- (nrepl-sync-request:eval
-  expanded (cider-current-connection) (cider-current-session)))
-   (if (or (member "output" result-params)
-   (member "pp" result-params))
-   "out"
- "value")
+ ; Check if the user want to run code asynchronously
+ (when async
+   ; Create a new window with the async output buffer
+   (switch-to-buffer-other-window sbuffer)
+
+   ; Run the Clojure code asynchronously in nREPL
+   (nrepl-request:eval
+expanded 
+(lambda (resp) 
+  (when (member "out" resp)
+; Print the output of the nREPL in the asyn output buffer
+(princ (nrepl-dict-get resp "out") (get-buffer sbuffer)))
+  (nrepl--merge response resp)
+  ; Update the status of the nREPL output session
+  (setq status (nrepl-dict-get response "status")))
+(cider-current-connection) 
+(cider-current-session))
+   
+   ; Wait until the nREPL code finished to be processed
+   (while (not (member "done" status))
+ (nrepl-dict-put response "status" (remove "need-input" status))
+ (accept-process-output nil 0.01)
+ (redisplay))
+
+   ; Delete the async buffer & window when the processing is finalized
+   (let ((wins (get-buffer-window-list sbuffer nil t)))
+ (dolist (win wins)
+   (delete-window win))
+ (kill-buffer sbuffer))
+ 
+   ; Put the output or the value in the result section of the code 
block
+   (setq result

Re: [O] Bug: URL with spaces in is incorrectly rendered in LaTeX export [8.3.3 (8.3.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]

I'm sorry, I only just understood, from looking at git, that you added the
ability to use angular links inside link descriptions in response to my
query.

Thanks very much for this quick fix! I look forward to the next release.

On 6 April 2016 at 10:43, Reuben Thomas  wrote:

> On 6 April 2016 at 10:44, Nicolas Goaziou  wrote:
>
>> Reuben Thomas  writes:
>>
>> > So the feature is not in 8.3.4?
>>
>> No it isn't. New feature are added to development branch (master, which
>> will become Org 9.0 when ready), not stable branch.
>>
>
> Thanks again.
>
> --
> http://rrt.sc3d.org
>

-- 
http://rrt.sc3d.org

[O] org-mime-org-buffer-htmlize can't find back-end

2016-04-06 Thread Peter Davis


I used to be able to use org-buffer-org-mime-htmlize to send my org documents 
as multipart/alternative html & text email. For some
reason, this is stopped working, and now displays

Unknown "nil" back-end: Aborting export

In the *Messages* buffer, I see

org-export-barf-if-invalid-backend: Unknown "nil" back-end: Aborting export

So how is the back-end supposed to be defined? (And why might it have broken?) 
I haven't not made any related changes in a *long*
time.


Thank you.

-pd

Re: [O] a patch to ob-lisp.el

2016-04-06 Thread numbch...@gmail.com

Oh, right. I should attach it.

```diff
>From 30eec5a63e4f720fa3880b9aef06aedd84072078 Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Sat, 2 Apr 2016 00:46:36 +0800
Subject: [PATCH] add SLY support in ob-lisp

* ob-lisp.el (org-babel-execute:lisp): Support using SLY to evaluate
  lisp src block.

SLY has some advantages over SLIME, let user can evaluate Lisp src block
with SLY.

modified from a patch proposal by stardiviner.

TINYCHANGE
---
 etc/ORG-NEWS|  2 ++
 lisp/ob-lisp.el | 51 ---
 2 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3ddc3f9..bb8a00d 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -819,6 +819,8 @@ See the docstring of ~org-latex-classes~ and

 *** `org-insert-heading' can be forced to insert top-level headline

+*** let ob-lisp supporting use SLY to evaluate
+
 ** Removed functions

 *** Removed function ~org-translate-time~
diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el
index 64b032d..68ea5e2 100644
--- a/lisp/ob-lisp.el
+++ b/lisp/ob-lisp.el
@@ -25,16 +25,26 @@

 ;;; Commentary:

-;;; support for evaluating common lisp code, relies on slime for all eval
+;;; Support for evaluating Common Lisp code, relies on SLY or SLIME for
all eval.

 ;;; Requirements:

-;; Requires SLIME (Superior Lisp Interaction Mode for Emacs.)
-;; See http://common-lisp.net/project/slime/
+;; Requires SLY (Sylvester the Cat's Common Lisp IDE) or SLIME.
+;; See:
+;; - https://github.com/capitaomorte/sly
+;; - http://common-lisp.net/project/slime/

 ;;; Code:
 (require 'ob)

+(defcustom org-babel-lisp-eval-fn "sly-eval"
+  "The function to be called to evaluate code on the Lisp side."
+  :group 'org-babel
+  :version "24.1"
+  :options '("sly-eval" "slime-eval")
+  :type 'stringp)
+
+(declare-function sly-eval "ext:sly" (sexp  package))
 (declare-function slime-eval "ext:slime" (sexp  package))

 (defvar org-babel-tangle-lang-exts)
@@ -72,24 +82,27 @@ current directory string."
   body)))

 (defun org-babel-execute:lisp (body params)
-  "Execute a block of Common Lisp code with Babel."
-  (require 'slime)
+  "Execute a block `BODY' with `PARAMS' of Common Lisp code with Babel."
+  (pcase org-babel-lisp-eval-fn
+("slime-eval" (require 'slime))
+("sly-eval" (require 'sly)))
   (org-babel-reassemble-table
(let ((result
-  (funcall (if (member "output" (cdr (assoc :result-params params)))
-   #'car #'cadr)
-   (with-temp-buffer
- (insert (org-babel-expand-body:lisp body params))
- (slime-eval `(swank:eval-and-grab-output
-   ,(let ((dir (if (assoc :dir params)
-   (cdr (assoc :dir params))
- default-directory)))
-  (format
-   (if dir (format org-babel-lisp-dir-fmt dir)
- "(progn %s\n)")
-   (buffer-substring-no-properties
- (point-min) (point-max)
- (cdr (assoc :package params)))
+  (funcall (if (member "output" (cdr (assoc :result-params
params)))
+   #'car #'cadr)
+   (with-temp-buffer
+ (insert (org-babel-expand-body:lisp body params))
+ (funcall org-babel-lisp-eval-fn
+  `(swank:eval-and-grab-output
+,(let ((dir (if (assoc :dir params)
+(cdr (assoc :dir params))
+  default-directory)))
+   (format
+(if dir (format org-babel-lisp-dir-fmt
dir)
+  "(progn %s\n)")
+(buffer-substring-no-properties
+ (point-min) (point-max)
+  (cdr (assoc :package params)))
  (org-babel-result-cond (cdr (assoc :result-params params))
result
(condition-case nil
-- 
2.8.0
```

[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 Wed, Apr 6, 2016 at 8:49 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> "numbch...@gmail.com"  writes:
>
> > Hi, Nicolas, the another email which you commented many places is
> outdated.
> > That patch is modified from the version of MELPA package
> `org-plus-conrtib`.
> >
> > I cloned org-mode git repo, and created public repo branch at here:
> > https://github.com/stardiviner/org-mode/tree/sly-support-for-ob-lisp
> >
> > I checked this branch's diff with your mentioned places. All checked.
> > I followed org-mode contrib guide to create this commit.
> > Please let me know if there is any place need to modify.
>
> From your local branch, use
>
>   git format-patch master
>
> This will generate a patch file, which you can send to this ML.
>
> Regards,
>
> --
> Nicolas

Re: [O] [PATCH] expose nrepl's timeout setting in ob-clojure.el


Hi Nicolas!


-;;; ob-clojure.el --- Babel Functions for Clojure-*- lexical-binding: t; 
-*-
+;;; ob-clojure.el --- org-babel functions for clojure evaluation

Your patch reverts a change introduced in development version. Could you
rebase it on top of latest Org first?


Yeah sorry, I did this from the latest published version, not master. 
Fixed now.





  ;; Copyright (C) 2009-2016 Free Software Foundation, Inc.
  
@@ -55,6 +55,7 @@
  
  (defvar org-babel-default-header-args:clojure '())

  (defvar org-babel-header-args:clojure '((package . :any)))
+(defvar org-babel-clojure-nrepl-timeout 10)

Would it make sense to turn it into a defcustom instead? If so, this
should be added in etc/ORG-NEWS file.


Patch attached.


Bonus points if Worg documentation
about this back-end


Patch attached.




  (defcustom org-babel-clojure-backend
(cond ((featurep 'cider) 'cider)
@@ -67,7 +68,7 @@
  
  (defun org-babel-expand-body:clojure (body params)

"Expand BODY according to PARAMS, return the expanded body."
-  (let* ((vars (org-babel--get-vars params))
+  (let* ((vars (mapcar #'cdr (org-babel-get-header params :var)))

You are also reverting a previous change here.


Fixed.




 (result-params (cdr (assoc :result-params params)))
 (print-level nil) (print-length nil)
 (body (org-babel-trim
@@ -94,8 +95,9 @@
 (let ((result-params (cdr (assoc :result-params params
 (setq result
   (nrepl-dict-get
-   (nrepl-sync-request:eval
-expanded (cider-current-connection) (cider-current-session))
+   (let ((nrepl-sync-request-timeout 
org-babel-clojure-nrepl-timeout))
+ (nrepl-sync-request:eval
+  expanded (cider-current-connection) (cider-current-session)))

It seems you need to define `nrepl-sync-request-timeout' as
a dynamically scoped variable:

   (defvar nrepl-sync-request-timeout)

Indeed "ob-clojure.el" uses lexical binding, even though you disabled it
in the first line of your patch ;)


Fixed :)


Eventually, could you add an appropriate commit message for this patch?
Something like

   ob-clojure: Make REPL timeout configurable

   * lisp/ob-clojure.el (org-babel-clojure-nrepl-timeout):  New variable.
   (org-babel-expand-body:clojure): Use new variable.

   ... explanations about the motivation of the change...


Patch attached.


Hope everything is good now!

Thanks,

Fred

>From c8e89d774590e9b39604252b3a344f95b56e3924 Mon Sep 17 00:00:00 2001
From: Frederick Giasson 
Date: Wed, 6 Apr 2016 10:00:18 -0400
Subject: [PATCH] Document the new option ob-clojure option
 "org-babel-clojure-sync-nrepl-timeout".

---
 org-contrib/babel/languages/ob-doc-clojure.org | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/org-contrib/babel/languages/ob-doc-clojure.org 
b/org-contrib/babel/languages/ob-doc-clojure.org
index 72942df..17c0f20 100644
--- a/org-contrib/babel/languages/ob-doc-clojure.org
+++ b/org-contrib/babel/languages/ob-doc-clojure.org
@@ -90,6 +90,17 @@ Add these lines to your .emacs file to configure CIDER:
   (require 'cider)
 #+END_SRC
 
+Optionally you can specify the Cider timeout by setting the 
=org-babel-clojure-sync-nrepl-timeout=
+setting option. The value is in seconds and if set to =nil= then no timeout 
will occur.
+
+#+BEGIN_SRC emacs-lisp
+  ; Disable Cider's timeout
+  (setq org-babel-clojure-sync-nrepl-timeout nil)
+
+  ; Set the timeout to 20 seconds
+  (setq org-babel-clojure-sync-nrepl-timeout 20)
+#+END_SRC
+
 ** Create a Clojure Project with Leiningen
 
 Create a Leiningen project directory tree:
-- 
1.9.5.msysgit.0

>From 9a81363719f3078d13de9b971440ee6fd456b4b2 Mon Sep 17 00:00:00 2001
From: Frederick Giasson 
Date: Wed, 6 Apr 2016 10:24:54 -0400
Subject: [PATCH 1/2] Update of ORG-NEWS to mention the addition of the new
 setting "org-babel-clojure-sync-nrepl-timeout"

---
 etc/ORG-NEWS | 4 
 1 file changed, 4 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 82d5ad0..e684587 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -106,6 +106,10 @@ becomes
 : ("pdf" . (lambda (file link) (foo)))
 
 ** New features
+*** New option =org-babel-clojure-sync-nrepl-timeout= for =org-babel-clojure=
+This new option tells the =org-babel-clojure= module the length of the timeout 
+of a synchronous call to the nREPL. This value is in seconds. If =nil= then
+no timeout will occur.
 *** New org-protocol key=value syntax
 
 Org-protocol can now handle query-style parameters such as:
-- 
1.9.5.msysgit.0

>From dab6472228d1a0a41831dcae969335d0a7fb7531 Mon Sep 17 00:00:00 2001
From: Frederick Giasson 
Date: Wed, 6 Apr 2016 10:46:35 -0400
Subject: [PATCH 2/2] Addition of a new customization variable called
 "org-babel-clojure-sync-nrepl-timeout" which expose the Cider timeout setting
 as a custom variable.

The timeout is in second, and if nil is specified and timeout is disabled.

With

Re: [O] Space after an inline emacs call affects output on export

On Wednesday,  6 Apr 2016 at 15:21, Nicolas Goaziou wrote:
> In the second case, something is preventing =xxx= from being parsed as
> a verbatim object.

Ah, I see.  Makes perfect sense.  Thanks.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-705-g716e33

Re: [O] font-lock fails with \to in a macro

On Wednesday,  6 Apr 2016 at 14:46, Nicolas Goaziou wrote:
> FWIW, I cannot reproduce it.

Ignore.  Probably due to the same issue discussed elsewhere: my
modification of org-emphasis-alist... 

thanks!
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-705-g716e33

Re: [O] babel result chain outdated/inconsistent using var

2016-04-06 Thread Daniele Pizzolli

On Wed, Apr 06 2016, Nicolas Goaziou wrote:

> Hello,
>
> Daniele Pizzolli  writes:
>
>> is possible to update the “#+RESULTS: pid” when the block “#+NAME:
>> echo-pid” is evaluated in the following snippet?
>
> Without `org-babel-execute-buffer', I don't think so.

Hello,

Thanks Nicolas for the reply.  Ok, but `org-babel-execute-buffer'
produces an inconsistent document right now.

>> This will lead to a consistent document generation with “M-x
>> org-babel-execute-buffer” or by hitting “C-c C-c” on “#+NAME:
>> echo-pid”.
>
> I'm not convinced that this behaviour should be enforced. If I C-c C-c
> on a block, I expect only the results of the block to be updated, not
> some other part of the document I am editing.

Mmm, the same reasoning can be used for arguing about the current
behaviour: If I C-c C-c on a block, I expect only the code of the
block to be executed, not some other part of the document I am
editing.  This behaviour will fix my issue.

I agree that neither case should be enforced, but the user should be
in charge to choose.  A reasonable default behaviour will be to not
re-execute the other code block if the previous result is already
present.

> Also, what if the other block is in another document? I don't think it
> should be updated either.

But should it be either executed?

> What is the harm in using `org-babel-execute-buffer' for your use case?

Right now it does not produce a consistent document, that should be
desirable.

I do not have a strong preference about the solution (reuse without
re-execute, or update the other result) but for sure, right now there
is no way to produce a consistent document.

I tried for a workaround, adding `:eval query'

#+NAME: pid
#+BEGIN_SRC shell :results value :cache no :eval query
printf '%s' "${$}"
#+END_SRC

and then discarding the execution, but instead of reusing the actual
result it pass `nil'... no luck.

Thanks again,
Daniele

[O] table.el orgmode export html or latex use table-generate-source

2016-04-06 Thread Uwe Brauer

hi

It is great that in orgmode I can edit tables, which are controlled by
table.el, since table.el for example allows to split and joins cells,
which org-table does not.


However when I try to export a org file with a table controlled by
table.el I run into a problem. I have to convert it to a org-table and
in this process things like splitting cells are lost.

So could org-export not call table-generate-source for either latex or
html export?

regards

Uwe Brauer

Re: [O] Space after an inline emacs call affects output on export

Eric S Fraga  writes:

> However, I am curious as to why the output from the inline source
> evaluation is different?  I.e. why =xxx= versus xxx?  What is the
> rationale for one versus the other?

The result of the inline source evaluation is =xxx= (I'll ignore the
no-op results macro around it). If =xxx= can be parsed as a verbatim
object, it becomes \textt{xxx} in the output. If it cannot, = signs
appear as-is in the output.

In the second case, something is preventing =xxx= from being parsed as
a verbatim object.

Regards,

Re: [O] Space after an inline emacs call affects output on export

On Wednesday,  6 Apr 2016 at 14:37, Nicolas Goaziou wrote:
> Wild guess. You forbade ":" after emphasis markers in
> `org-emphasis-regexp-components'.

Ummm, I've never touched org-emphasis-regexp-components...

But I have played around with org-emphasis-alist, introducing @ as an
emphasis marker (as I did a long time ago to introduce \alert{} for
beamer per v8).So although @@latex:@@ etc. still works fine,
it has implications elsewhere.  I will remove my change to
org-emphasis-alist.

However, I am curious as to why the output from the inline source
evaluation is different?  I.e. why =xxx= versus xxx?  What is the
rationale for one versus the other?

Thanks,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-705-g716e33

Re: [O] [PATCH] org-attach: Use relative path for git annex

Hello,

Erik Hetzner  writes:

> * lisp/org-attach.el (org-attach-annex-get-maybe): Use relative path as
>   argument for git annex. Fixes error in test with version 3 of git
>   annex.

It seems like I lost track on this one. Could you tell me about the
status of this patch? I doesn't seem to be applied. Was it superseded by
another one?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] ob-clojure: possible to display results as soon as something is written to STDOUT?


Hi,


Yes, you are. There is a "go to the topic" action on the left panel.
Anyway, there is not much to see, just some pointers to start
a discussion.


Haa great thanks, see it now :)

Let me revise a few things, suggest another patch, and then will start 
to think about these things.


Thanks,

Fred

Re: [O] ob-clojure: possible to display results as soon as something is written to STDOUT?

Frederick Giasson  writes:

> Humm, from the page you provided, I don't see any threads, but just
> the initial message, am I looking at the right thing?

Yes, you are. There is a "go to the topic" action on the left panel.
Anyway, there is not much to see, just some pointers to start
a discussion.

Regards,

Re: [O] How to do proper folding and semantic markup

2016-04-06 Thread Eduardo Mercovich

Hi Nick.

[...]
>> Excuse me if this sounds almost philosophical, but in which situation an
>> indirect buffer may be better that just focusing on the same (original)
>> buffer? For example, when you are toying with potentially big
>> modifications and don't want to replace the original? Is it like opening
>> a parallel path to try things without worries?

> No - if you change the indirect buffer, you change the base buffer as
> well.

As always, razor sharp precise.

Thanks. :)

Best...


-- 
eduardo mercovich 

 Donde se cruzan tus talentos 
 con las necesidades del mundo, 
 ahí está tu vocación.

Re: [O] How to do proper folding and semantic markup

2016-04-06 Thread Eduardo Mercovich

Hi Adam.  Porter  writes:

>> Excuse me if this sounds almost philosophical, but in which situation an
>> indirect buffer may be better that just focusing on the same (original)
>> buffer?  [...]

> [...]
> So by jumping to an entry in an indirect buffer, I see only that entry, and
> I can't modify any other nodes.  It means I can treat each entry
> independently, view and edit them separately, etc.

> In this way it resembles the way Evernote presents notes independently, but
> with all the power and flexibility of Org and Emacs. [...]
> (I also confess that it gives me some peace of mind, because a few times I
> have accidentally hit the wrong keys and deleted parts of an Org file that I
> didn't mean to.  Most of the time I immediately undo it and no harm is done,
> but one time I didn't realize it until days or weeks later, and I had to
> pull it out of an earlier commit in my org directory's git repo.)

Crystal clear, thanks. :)
Best...


-- 
eduardo mercovich 

 Donde se cruzan tus talentos 
 con las necesidades del mundo, 
 ahí está tu vocación.

Re: [O] ob-clojure: possible to display results as soon as something is written to STDOUT?


Hi Nicolas,


However, I am not sure neither how generic such a solution could be,
and what would still be required to implement in each OB plugin. My
(very little) experience so far is the Python prototype that John
wrote, and then my analysis of the Clojure OB plugin. As I was
explaining in this blog post, things are quite different between the
two. In Python, it appears that one has to run a sub-process, in
Clojure this is not necessary since we benefit the nREPL that handle
that.

The link I gave is a first approximation of the generic behaviour.
Basically, we could spawn a new Emacs process which could then
evaluation the block synchronously.


Ok good.


One difficulty is to grab the "closure" of the block. Another one is to
collect and insert the results back into the buffer without being
disruptive. The thread above gave hints about that second point.


Humm, from the page you provided, I don't see any threads, but just the 
initial message, am I looking at the right thing?


Thanks,

Fred

Re: [O] babel result chain outdated/inconsistent using var

Hello,

Daniele Pizzolli  writes:

> is possible to update the “#+RESULTS: pid” when the block “#+NAME:
> echo-pid” is evaluated in the following snippet?

Without `org-babel-execute-buffer', I don't think so.

> This will lead to a consistent document generation with “M-x
> org-babel-execute-buffer” or by hitting “C-c C-c” on “#+NAME:
> echo-pid”.

I'm not convinced that this behaviour should be enforced. If I C-c C-c
on a block, I expect only the results of the block to be updated, not
some other part of the document I am editing. 

Also, what if the other block is in another document? I don't think it
should be updated either.

What is the harm in using `org-babel-execute-buffer' for your use case?

Regards,

-- 
Nicolas Goaziou

Re: [O] a patch to ob-lisp.el

Hello,

"numbch...@gmail.com"  writes:

> Hi, Nicolas, the another email which you commented many places is outdated.
> That patch is modified from the version of MELPA package `org-plus-conrtib`.
>
> I cloned org-mode git repo, and created public repo branch at here:
> https://github.com/stardiviner/org-mode/tree/sly-support-for-ob-lisp
>
> I checked this branch's diff with your mentioned places. All checked.
> I followed org-mode contrib guide to create this commit.
> Please let me know if there is any place need to modify.

>From your local branch, use

  git format-patch master

This will generate a patch file, which you can send to this ML.

Regards,

-- 
Nicolas Goaziou

Re: [O] font-lock fails with \to in a macro

Hello,

Eric S Fraga  writes:

> I have the following macro to aid in presenting calculations in
> solutions to coursework questions etc. for my teaching:
>
> #+macro: calculate src_calc[:exports code]{$1} = @@latex:\fbox{@@ 
> src_emacs-lisp{(setq var-$2 (string-to-number (calc-eval "evalv($1)")))} \to 
> $2 @@latex:}\\@@
>
> The "\to" which org catches and converts to → on export causes a problem
> with font-locking:
>
> Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument 
> vectorp →)
>
> Using math mode directly, i.e. \(\to\) works just fine, at least for
> LaTeX export, but I thought I'd mention this anomaly in case it bites
> anybody else!

FWIW, I cannot reproduce it.

Regards,

-- 
Nicolas Goaziou

Re: [O] ob-clojure: possible to display results as soon as something is written to STDOUT?

Hello,

Frederick Giasson  writes:

> However, I am not sure neither how generic such a solution could be,
> and what would still be required to implement in each OB plugin. My
> (very little) experience so far is the Python prototype that John
> wrote, and then my analysis of the Clojure OB plugin. As I was
> explaining in this blog post, things are quite different between the
> two. In Python, it appears that one has to run a sub-process, in
> Clojure this is not necessary since we benefit the nREPL that handle
> that.

The link I gave is a first approximation of the generic behaviour.
Basically, we could spawn a new Emacs process which could then
evaluation the block synchronously.

One difficulty is to grab the "closure" of the block. Another one is to
collect and insert the results back into the buffer without being
disruptive. The thread above gave hints about that second point.

Regards,

-- 
Nicolas Goaziou

Re: [O] Space after an inline emacs call affects output on export

Hello,

Eric S Fraga  writes:

> Could anybody explain why these two lines give different outputs for the
> inline elisp calculation?
>
> First line:
>
> @@latex:\fbox{@@ src_emacs-lisp{(setq var-Q1 (string-to-number (calc-eval 
> "evalv(15.357*(184.2-80))")))} @@latex:}@@
>
> Second line:
>
> @@latex:\fbox{@@ src_emacs-lisp{(setq var-Q1 (string-to-number (calc-eval 
> "evalv(15.357*(184.2-80))")))}@@latex:}@@
>
> The only difference in these two lines is a space before the last LaTeX
> directive.

Wild guess. You forbade ":" after emphasis markers in
`org-emphasis-regexp-components'.

Regards,

-- 
Nicolas Goaziou

[O] Space after an inline emacs call affects output on export

Could anybody explain why these two lines give different outputs for the
inline elisp calculation?

First line:

@@latex:\fbox{@@ src_emacs-lisp{(setq var-Q1 (string-to-number (calc-eval 
"evalv(15.357*(184.2-80))")))} @@latex:}@@

Second line:

@@latex:\fbox{@@ src_emacs-lisp{(setq var-Q1 (string-to-number (calc-eval 
"evalv(15.357*(184.2-80))")))}@@latex:}@@

The only difference in these two lines is a space before the last LaTeX
directive.

Screen shot attached.


The first is what I want, by the way.

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-705-g716e33

Re: [O] ob-clojure: possible to display results as soon as something is written to STDOUT?

Hi Nicolas,

Here is a blog post that explains the changes I did. I still have one
improvement to do (but don't how it could be done or even if it can be
done) which is explained at the end of the post:

http://fgiasson.com/blog/index.php/2016/04/05/using-clojure-in-org-mode-and-implementing-asynchronous-processing/

Thanks for your help, it is now working the way I need it to.

This looks interesting. Thank you for sharing your result.

Org Babel would benefit from a generic asynchronous execution mechanism.
See for example .

Indeed, it would be interesting to generalize such a generic mechanism
directly in Babel, and not in each OB plugins.

However, I am not sure neither how generic such a solution could be, and
what would still be required to implement in each OB plugin. My (very
little) experience so far is the Python prototype that John wrote, and
then my analysis of the Clojure OB plugin. As I was explaining in this
blog post, things are quite different between the two. In Python, it
appears that one has to run a sub-process, in Clojure this is not
necessary since we benefit the nREPL that handle that.

So far, the best idea about how to present async process I think is what
John was proposing with the new window. Otherwise I still wonder about
having a real background process for this thing to run such that one can
continue to write things in the Org buffer while a code block is running
in background. But as I explained, I will have to seriously look into
Elisp in order to assess the full scope of such a task.

So, if anyone feels like discussing the details of an implementation of
such a thing, please chime in.

So far this is the only thing I have to say about that. In mean time I
will fix my other patch, and then I will submit another one for this
async feature (which will probably require much more review from your part).

Thanks,

Fred

[O] babel result chain outdated/inconsistent using var

2016-04-06 Thread Daniele Pizzolli

Hello,

is possible to update the “#+RESULTS: pid” when the block “#+NAME:
echo-pid” is evaluated in the following snippet?

This will lead to a consistent document generation with “M-x
org-babel-execute-buffer” or by hitting “C-c C-c” on “#+NAME:
echo-pid”.  Using the cache does not make sense: the process is
generating different output every time.

The info at “M-: (info "(org) Specific header arguments")” does not
mention something useful.

* Intro

** pid

#+NAME: pid
#+BEGIN_SRC shell :results value :cache no
printf '%s' "${$}"
#+END_SRC

The following result is usually outdated/inconsistent!

#+RESULTS: pid
: 25272

** echo pid

#+NAME: echo-pid
#+BEGIN_SRC shell :var DATA=pid :results value
printf '%s' "${DATA}"
#+END_SRC

#+RESULTS: echo-pid
: 25273

The code block in pid is evaluated every time, but the results are
used only to populate the pid variable and non for updating the
results in the buffer:

#+BEGIN_EXAMPLE
executing Shell code block (pid)...
Wrote /tmp/babel-4889iZN/ob-input-4889CyZ
"25273"
executing Shell code block (echo-pid)...
Wrote /tmp/babel-4889iZN/ob-input-48892ay
Code block evaluation complete.
#+END_EXAMPLE

This was tested with Org-mode version 8.3.4 release_8.3.4-705-g716e33.

Thanks in advance for your suggestions,
Daniele

[O] font-lock fails with \to in a macro

Hello,

I have the following macro to aid in presenting calculations in
solutions to coursework questions etc. for my teaching:

#+macro: calculate src_calc[:exports code]{$1} = @@latex:\fbox{@@ 
src_emacs-lisp{(setq var-$2 (string-to-number (calc-eval "evalv($1)")))} \to $2 
@@latex:}\\@@

The "\to" which org catches and converts to → on export causes a problem
with font-locking:

Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument 
vectorp →)

Using math mode directly, i.e. \(\to\) works just fine, at least for
LaTeX export, but I thought I'd mention this anomaly in case it bites
anybody else!

thanks,
eric


-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-705-g716e33

[O] Test failures on update

2016-04-06 Thread Christian Moe


Hi,

I just updated to the current 8.3.4 after a system upgrade (Mac OS X
10.11, fresh Emacs 24.5.1 installed via Homebrew).

When trying to =make up2=, I got 79 "unexpected" failures. About the
same as I recall from some months back, but far more than I used to. Are
other people getting this many test failures? Are other Mac users?

Some of these involve ob-fortran. They've never ever worked on my sysem,
and I've wondered how to turn them off, anyway, so that's OK. Some of
them may be about unix tools that were lost in the OS upgrade (though I
had similar results before the upgrade), or Mac idiosyncracies to do
with shells and paths. Others look more worrisome.

I attach the list of failures, in case maintainers find it useful. Let
me know if you need other information (that I can provide by following
simple instructions).

Yours,
Christian


#+begin_example
Ran 619 tests, 540 results as expected, 79 unexpected (2016-04-06 12:44:45+0200)
8 expected failures

79 unexpected results:
   FAILED  ob-C/inhomogeneous_table
   FAILED  ob-C/integer-var
   FAILED  ob-C/list-list-var
   FAILED  ob-C/list-var
   FAILED  ob-C/preprocessor
   FAILED  ob-C/simple-program
   FAILED  ob-C/string-var
   FAILED  ob-C/table
   FAILED  ob-C/two-integer-var
   FAILED  ob-C/vector-var
   FAILED  ob-awk/input-none
   FAILED  ob-awk/input-src-block-1
   FAILED  ob-awk/input-src-block-2
   FAILED  ob-awk/tabular-input
   FAILED  ob-emacs-lisp/commented-last-block-line
   FAILED  ob-emacs-lisp/commented-last-block-line-no-var
   FAILED  ob-emacs-lisp/commented-last-block-line-with-var
   FAILED  ob-exp/exports-inline
   FAILED  ob-exp/exports-inline-code
   FAILED  ob-exp/noweb-no-export-and-exports-both
   FAILED  ob-exp/noweb-strip-export-ensure-strips
   FAILED  ob-exp/use-case-of-reading-entry-properties
   FAILED  ob-fortran/character-var
   FAILED  ob-fortran/command-arguments
   FAILED  ob-fortran/fortran-var-program
   FAILED  ob-fortran/input-var
   FAILED  ob-fortran/list-matrix-from-table1
   FAILED  ob-fortran/list-matrix-from-table2
   FAILED  ob-fortran/list-var
   FAILED  ob-fortran/list-var-from-table
   FAILED  ob-fortran/preprocessor-var
   FAILED  ob-fortran/simple-program
   FAILED  ob-shell/bash-uses-arrays
   FAILED  ob-shell/bash-uses-assoc-arrays
   FAILED  ob-shell/generic-uses-no-arrays
   FAILED  ob-shell/generic-uses-no-assoc-arrays
   FAILED  ob-tangle/comment-links-at-left-margin
   FAILED  ob-tangle/comment-links-numbering
   FAILED  ob-tangle/continued-code-blocks-w-noweb-ref
   FAILED  ob-tangle/jump-to-org
   FAILED  test-ob-lob/do-not-eval-lob-lines-in-example-blocks-on-export
   FAILED  test-ob-python/colnames-nil-header-argument
   FAILED  test-ob-python/colnames-no-header-argument
   FAILED  test-ob-python/colnames-no-header-argument-again
   FAILED  test-ob-python/colnames-yes-header-argument
   FAILED  test-ob-python/colnames-yes-header-argument-again
   FAILED  test-ob-shell/dont-error-on-empty-results
   FAILED  test-ob-shell/session
   FAILED  test-ob/combining-scalar-and-raw-result-types
   FAILED  test-ob/commented-last-block-line-no-var
   FAILED  test-ob/commented-last-block-line-with-var
   FAILED  test-ob/elisp-in-header-arguments
   FAILED  test-ob/indented-cached-org-bracket-link
   FAILED  test-ob/inline-src_blk-default-results-replace-line-1
   FAILED  test-ob/just-one-results-block
   FAILED  test-ob/multi-line-header-arguments
   FAILED  test-ob/org-babel-remove-result--results-default
   FAILED  test-ob/org-babel-results-indented-wrap
   FAILED  test-ob/parse-header-args
   FAILED  test-ob/parse-header-args2
   FAILED  test-ob/simple-named-code-block
   FAILED  test-ob/simple-variable-resolution
   FAILED  test-ob/specific-colnames
   FAILED  test-org-element/link-parser
   FAILED  test-org-export/expand-include
   FAILED  test-org-export/output-file-name
   FAILED  test-org-src/blank-line-block
   FAILED  test-org-table/org-at-TBLFM-p
   FAILED  test-org-table/org-table-TBLFM-begin
   FAILED  test-org-table/org-table-TBLFM-begin-for-multiple-TBLFM-lines
   FAILED  test-org-table/org-table-TBLFM-begin-for-pultiple-TBLFM-lines-blocks
   FAILED  test-org-table/org-table-calc-current-TBLFM
   FAILED  
test-org-table/org-table-calc-current-TBLFM-when-stop-because-of-error
   FAILED  test-org/entry-properties
   FAILED  test-org/open-at-point-in-comment
   FAILED  test-org/open-at-point-in-keyword
   FAILED  test-org/open-at-point-in-property
   FAILED  test-org/open-at-point/info
   FAILED  test-org/open-at-point/inline-image
#+end_example

Re: [O] a patch to ob-lisp.el

2016-04-06 Thread numbch...@gmail.com

Hi, Nicolas, the another email which you commented many places is outdated.
That patch is modified from the version of MELPA package `org-plus-conrtib`.

I cloned org-mode git repo, and created public repo branch at here:
https://github.com/stardiviner/org-mode/tree/sly-support-for-ob-lisp

I checked this branch's diff with your mentioned places. All checked.
I followed org-mode contrib guide to create this commit.
Please let me know if there is any place need to modify.

[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 Wed, Apr 6, 2016 at 5:26 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> "numbch...@gmail.com"  writes:
>
> > Ask a beside question. I cloned org-mode git repo, should I contribute my
> > patch with git way? (I mean create a git branch on my own public clone,
> > then paste it here to let maintainer merge it?)
>
> Please look at the document suggested by Thomas. In particular, please
> read section "For Org contributors: preferred way of submitting
> patches".
>
> Following advices there tremendeously helps maintainers.
>
> Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Bug: URL with spaces in is incorrectly rendered in LaTeX export [8.3.3 (8.3.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]

On 6 April 2016 at 10:44, Nicolas Goaziou  wrote:

> Reuben Thomas  writes:
>
> > So the feature is not in 8.3.4?
>
> No it isn't. New feature are added to development branch (master, which
> will become Org 9.0 when ready), not stable branch.
>

Thanks again.

-- 
http://rrt.sc3d.org

Re: [O] Bug: URL with spaces in is incorrectly rendered in LaTeX export [8.3.3 (8.3.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]

Reuben Thomas  writes:

> So the feature is not in 8.3.4?

No it isn't. New feature are added to development branch (master, which
will become Org 9.0 when ready), not stable branch.

Regards,

Re: [O] [PATCH] expose nrepl's timeout setting in ob-clojure.el

Hello,

Thank you for the patch.

Frederick Giasson  writes:

> -;;; ob-clojure.el --- Babel Functions for Clojure-*- lexical-binding: t; 
> -*-
> +;;; ob-clojure.el --- org-babel functions for clojure evaluation

Your patch reverts a change introduced in development version. Could you
rebase it on top of latest Org first?

>  
>  ;; Copyright (C) 2009-2016 Free Software Foundation, Inc.
>  
> @@ -55,6 +55,7 @@
>  
>  (defvar org-babel-default-header-args:clojure '())
>  (defvar org-babel-header-args:clojure '((package . :any)))
> +(defvar org-babel-clojure-nrepl-timeout 10)

Would it make sense to turn it into a defcustom instead? If so, this
should be added in etc/ORG-NEWS file. Bonus points if Worg documentation
about this back-end 
>  
>  (defcustom org-babel-clojure-backend
>(cond ((featurep 'cider) 'cider)
> @@ -67,7 +68,7 @@
>  
>  (defun org-babel-expand-body:clojure (body params)
>"Expand BODY according to PARAMS, return the expanded body."
> -  (let* ((vars (org-babel--get-vars params))
> +  (let* ((vars (mapcar #'cdr (org-babel-get-header params :var)))

You are also reverting a previous change here.

>(result-params (cdr (assoc :result-params params)))
>(print-level nil) (print-length nil)
>(body (org-babel-trim
> @@ -94,8 +95,9 @@
> (let ((result-params (cdr (assoc :result-params params
>(setq result
>  (nrepl-dict-get
> - (nrepl-sync-request:eval
> -  expanded (cider-current-connection) (cider-current-session))
> + (let ((nrepl-sync-request-timeout 
> org-babel-clojure-nrepl-timeout))
> +   (nrepl-sync-request:eval
> +expanded (cider-current-connection) (cider-current-session)))

It seems you need to define `nrepl-sync-request-timeout' as
a dynamically scoped variable:

  (defvar nrepl-sync-request-timeout)

Indeed "ob-clojure.el" uses lexical binding, even though you disabled it
in the first line of your patch ;)

Eventually, could you add an appropriate commit message for this patch?
Something like

  ob-clojure: Make REPL timeout configurable

  * lisp/ob-clojure.el (org-babel-clojure-nrepl-timeout):  New variable.
  (org-babel-expand-body:clojure): Use new variable.

  ... explanations about the motivation of the change...


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: URL with spaces in is incorrectly rendered in LaTeX export [8.3.3 (8.3.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]

On 6 April 2016 at 10:35, Nicolas Goaziou  wrote:

> Reuben Thomas  writes:
>
> > When you say "latest Org", which version is that?
>
> The tip of master branch, a.k.a. development version. At the moment, is
> it "release_8.3.4-705-g716e33".
>

So the feature is not in 8.3.4?

thanks again,

Reuben

-- 
http://rrt.sc3d.org

Re: [O] Bug: URL with spaces in is incorrectly rendered in LaTeX export [8.3.3 (8.3.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]

Reuben Thomas  writes:

> When you say "latest Org", which version is that?

The tip of master branch, a.k.a. development version. At the moment, is
it "release_8.3.4-705-g716e33".

Regards,

Re: [O] ob-lisp.el patch to choose to use SLIME or SLY

Hello,

"numbch...@gmail.com"  writes:

> I original created an package ob-lisp on here:
> https://github.com/stardiviner/ob-lisp
> and add it to MELPA recipe.
> https://github.com/melpa/melpa/pull/3682
>
> The author suggest me to merge this change to Org-mode.
>
> I attached patch in attachment file.
> Hope someone can merge this patch.

Thank you. I have some comments about it.

> [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/
>
> diff --git a/ob-lisp.el b/ob-lisp.el
> index d2cac3d..04df7fb 100644
> --- a/ob-lisp.el
> +++ b/ob-lisp.el
> @@ -1,14 +1,12 @@
> -;;; ob-lisp.el --- org-babel functions for common lisp evaluation with SLY 
> or SLIME.
> +;;; ob-lisp.el --- org-babel functions for common lisp evaluation

You are not using an up-to-date version of the file, since this header
changed in development version. Could you rebase your patch on top of
latest development release?
>  
> -;; Copyright (C) 2016-2020 Free Software Foundation, Inc.
> +;; Copyright (C) 2009-2016 Free Software Foundation, Inc.

Ditto.

> -;; Authors: stardiviner 
> -;; Maintainer: stardiviner 
> -;; Keywords: org babel lisp sly slime
> -;; URL: https://github.com/stardiviner/ob-lisp
> -;; Created: 1th March 2016
> -;; Version: 0.0.1
> -;; Package-Requires: ((org "8"))
> +;; Authors: Joel Boehland
> +;;Eric Schulte
> +;;David T. O'Toole 
> +;; Keywords: literate programming, reproducible research
> +;; Homepage: http://orgmode.org

Ditto. These changes should not appear in the final patch.
>  
>  ;; This file is part of GNU Emacs.
>  
> @@ -27,27 +25,17 @@
>  
>  ;;; Commentary:
>  
> -;;; Support for evaluating Common Lisp code, relies on SLY or SLIME for all 
> eval.
> +;;; support for evaluating common lisp code, relies on slime for all eval

s/slime/SLIME/

>  
>  ;;; Requirements:
>  
> -;; Requires SLY (Sylvester the Cat's Common Lisp IDE) and SLIME
> -;; See:
> -;; - https://github.com/capitaomorte/sly
> -;; - http://common-lisp.net/project/slime/
> +;; Requires SLIME (Superior Lisp Interaction Mode for Emacs.)
> +;; See http://common-lisp.net/project/slime/
>  
>  ;;; Code:
>  (require 'ob)
>  
> -(defcustom org-babel-lisp-eval-fn "sly-eval"
> -  "The function to be called to evaluate code on the Lisp side."
> -  :group 'org-babel
> -  :version "24.1"
> -  :options '("sly-eval" "slime-eval")
> -  :type 'stringp)

Could you mention this removal in etc/ORG-NEWS? This is a user-visible
change.

Also, could you provide an appropriate commit message, e.g.:

--8<---cut here---start->8---
  ob-lisp: Drop SLY in favor of SLIME

  * lisp/ob-lisp.el (org-babel-expand-body:lisp,
org-babel-execute:lisp): Use SLIME instead of SLY.
  (org-babel-lisp-eval-fn): Remove variable.
--8<---cut here---end--->8---

Feel free to add justifications about this change at the end of the
commit message.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: URL with spaces in is incorrectly rendered in LaTeX export [8.3.3 (8.3.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]

On 6 April 2016 at 10:13, Nicolas Goaziou  wrote:

> Hello,
>
> Reuben Thomas  writes:
>
> > \href{Starting\%20Workshop\%20Notes.org}{\url{Starting Workshop
> Notes.org}}
> >
> > But maybe the space ends the URL?
>
> Indeed. For obvious reasons, "plain links" do not accept spaces since
> those are used as a delimiter. However, angular links could be used in
> this case, since they are morally equivalent to plain links.
>
> Hence, it is possible to write the following in latest Org
>
>  [[file:Starting%20Workshop%20Notes.org][ Notes.org>]]
>

Thanks, apologies for misreporting.

When you say "latest Org", which version is that?

-- 
http://rrt.sc3d.org

Re: [O] a patch to ob-lisp.el

Hello,

"numbch...@gmail.com"  writes:

> Ask a beside question. I cloned org-mode git repo, should I contribute my
> patch with git way? (I mean create a git branch on my own public clone,
> then paste it here to let maintainer merge it?)

Please look at the document suggested by Thomas. In particular, please
read section "For Org contributors: preferred way of submitting
patches".

Following advices there tremendeously helps maintainers.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] a patch to ob-lisp.el

Hello,

"numbch...@gmail.com"  writes:

> My think my patch modifies less than 15 lines. Do I have to assign the
> copyright of FSF?

No you don't. That will be helpful for your next patches.

> I have sent one. But no response for some days. I hope Org-mode maintainer
> can merge this patch.

The copyright is not an issue.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: URL with spaces in is incorrectly rendered in LaTeX export [8.3.3 (8.3.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]

Hello,

Reuben Thomas  writes:

> \href{Starting\%20Workshop\%20Notes.org}{\url{Starting Workshop Notes.org}}
>
> But maybe the space ends the URL?

Indeed. For obvious reasons, "plain links" do not accept spaces since
those are used as a delimiter. However, angular links could be used in
this case, since they are morally equivalent to plain links. 

Hence, it is possible to write the following in latest Org

 [[file:Starting%20Workshop%20Notes.org][]]

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: URL with spaces in is incorrectly rendered in LaTeX export [8.3.3 (8.3.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]

On 5 April 2016 at 23:01, Nicolas Goaziou  wrote:

> Hello,
>
> Reuben Thomas  writes:
>
> > The output for
> >
> >   [[file:Starting%20Workshop%20Notes.org][file:Starting Workshop
> Notes.org]]
> >
> > is:
> >
> >
> 
> \href{Starting\%20Workshop\%20Notes.org}{\url{Starting} Workshop Notes.org}
> >
> > despite the fact that in the org-mode buffer the URL is correctly
> > displayed as a whole, and mousing over it shows the whole thing is
> > active.
>
> What output did you expect?
>



\href{Starting\%20Workshop\%20Notes.org}{\url{Starting Workshop Notes.org}}

But maybe the space ends the URL?

-- 
http://rrt.sc3d.org

Re: [O] agenda column view and CLOCKSUM

Hello,

Makmiller Pedroso  writes:

> I am using Org-mode version 8.3beta (release_8.3beta-422-gb54ad3).
>
> I tried to create a minimal example in which the CLOCKSUMs do not get
> updated. It seems that the CLOCKSUM_T is the one that is not getting
> updated (unless if I run the column view in the agenda file before I run
> the agenda dispatcher). I'm not sure if this is expected behavior.
>
> Here is the example I used. I ran
>
> emacs -q -l /tmp/example.el
>
> where "example.el" contains
>
> --
> (setq org-columns-default-format "%1PRIORITY %5TODO %20ITEM(Task)
> %10SCHEDULED %10Effort(Effort){:} %10CLOCKSUM_T %10CLOCKSUM %TAGS")
>
> (setq org-agenda-custom-commands
>   '(("h" "Things to do today"
> ((tags "@Today")
>  (agenda "" ((org-agenda-ndays 1)
>  (org-agenda-show-all-dates nil)))
>
> (setq org-agenda-files (list "/tmp/agenda.org"))
> -
>
> and the agenda.org contains
>
> ---
> ** TODO Eat cookies :@Today:
>:LOGBOOK:
>CLOCK: [2016-04-02 Sat 07:26]--[2016-04-02 Sat 09:26] =>  2:00
>:END:
>
> ** TODO Eat more cookies :@Today:
>:LOGBOOK:
>CLOCK: [2016-04-02 Sat 07:26]--[2016-04-02 Sat 11:26] =>  4:00
>:END:
> 

Thank you for the ECM.

However, I don't think this issue exists in recent releases. Could you update
Org to latest development version and try again?


Regards,

-- 
Nicolas Goaziou

Re: [O] logging the timings of task A + task B both at once?

Hello,

Sharon Kimble  writes:

> Being that we can have multiple cursors, is it possible to have 2
> separate, distinct, tasks being clocked both at the same time?

[...]

> So, can it be done please?

There can only be one active clock at any given time. Although
I understand the need for some special features, I don't think it is
worth re-implementing "org-clock.el" to allow multiple ones.

You may probably redefine "Task A" and "Task B" so they do not overlap
and require being clocked at the same time.

Regards,

-- 
Nicolas Goaziou

[O] logging the timings of task A + task B both at once?

2016-04-06 Thread Sharon Kimble

Being that we can have multiple cursors, is it possible to have 2
separate, distinct, tasks being clocked both at the same time?

I've googled but didn't come up with anything, but trying it I find that
'Task B' when it starts timing it auto-logs-out of 'Task A'. But I'm now
in the situation where I have to write down the times of 'Task A' to
fudge the timings in the logbook of 'Task A' when 'Task B' finishes,
which isn't ideal.

So, can it be done please?

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.4, fluxbox 1.3.7, emacs 25.0.92


signature.asc
Description: PGP signature

Re: [O] ob-clojure: possible to display results as soon as something is written to STDOUT?

Hello,

Frederick Giasson  writes:

> Here is a blog post that explains the changes I did. I still have one
> improvement to do (but don't how it could be done or even if it can be
> done) which is explained at the end of the post:
>
> http://fgiasson.com/blog/index.php/2016/04/05/using-clojure-in-org-mode-and-implementing-asynchronous-processing/
>
> Thanks for your help, it is now working the way I need it to.

This looks interesting. Thank you for sharing your result.

Org Babel would benefit from a generic asynchronous execution mechanism.
See for example .

So, if anyone feels like discussing the details of an implementation of
such a thing, please chime in.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: CALL misbehavior with :results verbatim [8.3.4 (8.3.4-5-gdc68d2-elpaplus @ /Users/rossdonaldson/.emacs.d/elpa/org-plus-contrib-20160229/)]