Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Tue, 13 Sep 2011 08:48:49 -0600,
Eric Schulte wrote:
> 
> So am I right in thinking that as of right this commit [1] we are
> passing all tests on Emacs 22 through Emacs24?
> 
> Thanks -- Eric
> 
> >
> > This is with
> >
> > GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of
> > 2010-12-11 on raven, modified by Debian
> >
> > Best,
> >   -- David
> > --
> > OpenPGP... 0x99ADB83B5A4478E6
> > Jabber dmj...@jabber.org
> > Email. dm...@ictsoc.de
> 
> 
> Footnotes: 
> [1]  dbf0e6d5bcbe94c8ee57d68889d3c25bf9cdef55
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/

For Emacs22 the only thing we need from simple.el is the definition of
special-mode; going to factor it out and trim it to Emacs22.

With HEAD at dbf0e6d5bcbe94c8ee57d68889d3c25bf9cdef55 and a fix for
the check for featurep 'org (37db5deea5ef75186bb7413b196fa0c96e5bdfb9)
I got:


Selector: "\\(org\\|ob\\)"
Passed: 99
Failed: 10 (10 unexpected)
Total:  109/109

Started at:   2011-09-16 06:56:59+0200
Finished.
Finished at:  2011-09-16 06:57:04+0200

..FF...FF..F.F...FF.F..F.

F ob-fortran/list-var
Test real array input
(void-function characterp)

F ob-fortran/list-var-from-table
Test real array from a table
(void-function characterp)

F test-ob-exp/org-babel-exp-src-blocks/w-no-file
Testing export from buffers which are not visiting any file.
(wrong-type-argument stringp nil)

F test-ob-exp/org-babel-exp-src-blocks/w-no-headers
Testing export without any headlines in the org-mode file.
(wrong-type-argument stringp nil)

F test-ob-lob/export-lob-lines
Test the export of a variety of library babel call lines.
(wrong-type-argument stringp nil)

F test-ob-sh/dont-error-on-empty-results
Was throwing an elisp error when shell blocks threw errors and
(void-function org-babel-execute:sh)

F test-org-babel/inline-src-blocks
(error "No org-babel-execute function for sh!")

F test-org-babel/inline-src_blk-default-results-replace-line-1
(error "No org-babel-execute function for sh!")

F test-org-exp/stripping-commas
Test the stripping of commas from within blocks during export.
(wrong-type-argument stringp nil)

F test-org/org-link-unescape-ascii-extended-char
Unescape old style percent escaped character.
(ert-test-failed
 ((should
   (string= "àâçèéêîôùû"
(org-link-unescape "%E0%E2%E7%E8%E9%EA%EE%F4%F9%FB")))
  :form
  (string= "àâçèéêîôùû" "\340\342\347\350\351\352\356\364\371\373")
  :value nil))


Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpaVINhKP9ar.pgp
Description: PGP signature

Re: [O] Four issues with org-babel-tangle

[Christopher Genovese]

> I'll write up this change as it may end up being longer than 10 lines,
> and if I write it we don't have to wait for your FSF assignment to clear
> (which can sometimes take months) before applying the patch.

That sounds good, thanks.

> In fact... if this attached patch looks good to you (i.e., allows the
> behavior you originally intended) then please let me know and I'll apply
> it immediately.

Ideally, I'd like to combine the customizable processing with the
simple fix code (which eliminates the two related bugs and the
extra *s).  Something like the following in place of the corresponding
section in the patch you sent.  The extra (match-end 0) and (point-min)'s
prevent those problems. Otherwise, it all looks great.

+   (funcall
+org-babel-process-comment-text
+(buffer-substring
+ (max (condition-case nil
+  (save-excursion
 +(org-back-to-heading t); sets match data
+(match-end 0))
+(error (point-min)))
+  (save-excursion
+(if (re-search-backward
+ org-babel-src-block-regexp nil t)
+(match-end 0)
+  (point-min
+ (point)

I'm happy to take a look at the patch again anytime.

> Hmm, but #+tangle is not an official Org-mode directive in the same way
> that #+source:, #+headers:, and #+call: are.  Unless I'm forgetting
> something #+tangle: lines would have no functional effect, in which case
> why not just use a normal org-mode comment (e.g., a line starting with
> "# ").

You're right, I agree. I'm just being particular about indentation.
I don't like to have a line starting with # when everything else is
indented.
And I don't like having to put a space after the #+ to prevent export, so I
just wanted #+tangle (or #+noop or #+comment or whatever) to count
as a non-exported comment too, just like #+ tangle would.  But I can see
that it's not worth the effort or the confusion with a functional directive
that
it would cause. I'll just suck it up and use the extra space.

Thanks again, Eric.

   Best,

 Christopher


On Thu, Sep 15, 2011 at 18:02, Eric Schulte  wrote:

> - Show quoted text -
>  Christopher Genovese  writes:
>
> > Hi Eric,
> >
> >Thanks for your note.
> >
> >> I would encourage you to begin the FSF assignment process if
> >> you anticipate potentially contributing more fixes in the
> >> future. Could you please send a git format-patch version of
> >> the simple fix to the list so that I might apply it?
> >
> >I will begin the FSF assignment process, and I will send a git-format
> > patch based on the simple fix. (I'll send that tonight.)
> >
>
> Fantastic.
>
> >
> >> I like the idea of introducing a customizable function for
> >> comment text transformation, however ... rather perhaps we
> >> should just leave the default value of this function as
> >> simple as possible and allow users to customize it 
> >
> >That makes sense, and I like the way you did it. In particular,
> > I absolutely agree that the org-babel-trim should be removed
> > from org-babel-spec-to-string (to allow flexibility in the
> customization).
> > Making it the default processor works well, I think.
> >
> >Would you like me to submit a separate patch based on this change
> > or should I include that as part of the patch with the simple fix?
> >
>
> I'll write up this change as it may end up being longer than 10 lines,
> and if I write it we don't have to wait for your FSF assignment to clear
> (which can sometimes take months) before applying the patch.
>
> In fact... if this attached patch looks good to you (i.e., allows the
> behavior you originally intended) then please let me know and I'll apply
> it immediately.
>
>
>
> >
> >> Finally I'm not sure I fully understand what you mean by ...
> >
> > Sorry, I wasn't clear. It's a small thing. If you put
> > '#+tangle' in column 0, the line is not exported because it
> > begins with #; if you put #+ tangle on a line (spaces
> > after + and possibly before #), the line is not exported
> > because it begins with #+; but if you put #+tangle (no
> > spaces after the + but spaces before the #), the line is
> > exported. I think it would be useful if something like
> >  #+tangle's (with no spaces between the # and +) were
> > *not* exported because such lines can support
> > useful customizations. Having to put the spaces after the +
> > is a bit bothersome and looks uglier to me.
> >
>
> Hmm, but #+tangle is not an official Org-mode directive in the same way
> that #+source:, #+headers:, and #+call: are.  Unless I'm forgetting
> something #+tange: lines would have no functional effect, in which case
> why not just use a normal org-mode comment (e.g., a line starting with
> "# ").
>
>
> >
> >> ..., it was a long email.
> >
> > Yeah, sorry. :) Thanks for slogging through.
> >
>
> no problem at all, didn't mean this as a complaint :)
>
> Cheers -- Eri

Re: [O] Feature request: Select links by description [7.4]

[Dave Abrahams]

on Thu Sep 15 2011, Dave Abrahams  wrote:

> on Tue Feb 15 2011, Dave Abrahams  wrote:
>
>> On Mon, Feb 14, 2011 at 11:14 PM, Bastien  
>> wrote:
>>> Dave Abrahams  writes:
>>
>>>
 How about just always showing the link as it will be presented to the
 user first, followed by the raw link?  Then everything will be
 consistent.
>>>
>>> I don't see how it would prevent the problem I've been mentionning: we
>>> will still have a mix of descriptions and raw links... or maybe I miss
>>> something?
>>
>> If it's really paramount to avoid a mixture, you must hide all
>> descriptions, which would be a step in the wrong direction for me.
>>
>>> I'm willing to improve the display of links, keep brainstorming!
>>
>> I'm out of ideas.  Leading off with the displayed form of the link is
>> the best I can do.
>
> 
>
> The best is the enemy of the good and all that... is there any reason
> this can't be made to work?

I actually have some fairly detailed new ideas for design changes in
this area if anyone is interested.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: [O] Automatically insert R source code block?

[Michael Hannon]

> From: suvayu ali 
> 
> Hey Mike,
> 
> On Fri, Sep 16, 2011 at 1:18 AM, Michael Hannon  wrote:
>> but Emacs complains about an "org-mode fontification error" and doesn't give
>> me an executable R source-code block.  I've tried numerous minor variations
>> on this theme, but I don't think it's worth wasting your time by listing all
>> of the thrashing I've done.  The solution is probably obvious to people with
>> a decent understanding of elisp.
>>
>
> Do you have org-src-fontify-natively set to t? If so I am taking a
> shot in the dark here, emacs probably doesn't know how to fontify R
> source. Do you have emacs-ess installed? I would expect an error like
> this if its not.
> 
> But I could be wrong here as I don't use either of emacs-ess or R.

Hi, Suvayu.  The variable org-src-fontify-natively was set to nil, but I get
the same result with it set to 't'.

I do have Emacs-ess installed.

I've been assuming that I was just messing up the syntax, but maybe there's
something deeper involved.

Thanks for your note.

-- Mike

Re: [O] Automatically insert R source code block?

[suvayu ali]

Hey Mike,

On Fri, Sep 16, 2011 at 1:18 AM, Michael Hannon  wrote:
> but Emacs complains about an "org-mode fontification error" and doesn't give
> me an executable R source-code block.  I've tried numerous minor variations
> on this theme, but I don't think it's worth wasting your time by listing all
> of the thrashing I've done.  The solution is probably obvious to people with
> a decent understanding of elisp.
>

Do you have org-src-fontify-natively set to t? If so I am taking a
shot in the dark here, emacs probably doesn't know how to fontify R
source. Do you have emacs-ess installed? I would expect an error like
this if its not.

But I could be wrong here as I don't use either of emacs-ess or R.

Hopefully this was of some help.

-- 
Suvayu

Open source is the future. It sets us free.

[O] Automatically insert R source code block?

[Michael Hannon]

Greetings.  Pardon my ignorance, but I'm having trouble understanding some 
elisp syntax.

Some time ago I asked on this list how to use the "<..." shortcut to 
insert a source-code block in upper case (as: BEGIN_SRC, etc.),

Suvayu Ali responded with:


(add-to-list 'org-structure-template-alist
    '("S" "#+BEGIN_SRC ?\n\n#+END_SRC" "\n\n"))


and this indeed worked just fine (thanks, Suvayu!).


Lately most of the source blocks I've been using have been R source blocks, so 
I thought I'd just modify the elisp above to stick the string " R" after the 
"begin_src" string.

Here's an example of something I tried:


(add-to-list 'org-structure-template-alist
    '("r" "#+begin_src R\n\n#+end_src" "\n\n"))

The first part of this works OK; i.e., I do get:

    #+begin_src R

    #+end_src

but Emacs complains about an "org-mode fontification error" and doesn't give me 
an executable R source-code block.  I've tried numerous minor variations on 
this theme, but I don't think it's worth wasting your time by listing all of 
the thrashing I've done.  The solution is probably obvious to people with a 
decent understanding of elisp.


If you have any suggestions, please send them to me.  Thanks.

-- Mike

[O] Is LaTeX pdf export that uses pgfSweave possible?

[Mikhail Titov]

Hello!

First of all I’m not good at lisp as of now. I’d like to have an extra export 
option when I press C-c C-e that would create Rnw file instead of 
tex, pass it through pgfSweave in running R session.

I have the following to use pgfSweave in R session:

---8<--->8---
 
(defun ess-swv-pgfweave ()
   "Run pgfSweave on the current .Rnw file."
   (interactive)
   (ess-execute "library(pgfSweave)")
   (ess-swv-run-in-R "pgfSweave"))

(define-key noweb-minor-mode-map "\M-ns" 'ess-swv-pgfweave)

(easy-menu-add-item noweb-minor-mode-menu '("Sweaving, Tangling, ...") 
["pgfSweave" ess-swv-pgfweave t])
---8<--->8---

So I thought I'd somehow hook up altogether as I like an idea of folding things 
while make Beamer slides, but same time I like neatness of pgfSweave...

I don't know if there might be problems passing through constructs like

<>=
stuff
@

untouched into Rnw file.

I'm aware of babel for R but I can't use LaTeX in plots with it :(

Mikhail

[O] Bug: [bug/patch] actually truncate lines in `*Org Link*' buffers [7.7 (release_7.7.292.g0d4e8.dirty)]

[Dave Abrahams]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


commit 0d4e8b073144681e3049c3dd1d64f99f38a5f9f1 (HEAD, refs/heads/org-x)
Author: Dave Abrahams 
Date:   Thu Sep 15 18:54:10 2011 -0400

BUGFIX: _actually_ truncate lines in the `*Org Link*' buffer

	Modified   lisp/org.el
diff --git a/lisp/org.el b/lisp/org.el
index 36d82cb..b59829c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9004,7 +9004,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
 		  (reverse org-stored-links) "\n"
   (let ((cw (selected-window)))
 	(select-window (get-buffer-window "*Org Links*" 'visible))
-	(with-current-buffer "*Org Links*" (setq truncate-lines) t)
+	(with-current-buffer "*Org Links*" (setq truncate-lines t))
 	(unless (pos-visible-in-window-p (point-max))
 	  (org-fit-window-to-buffer))
 	(and (window-live-p cw) (select-window cw)))

[back] 


Emacs  : GNU Emacs 23.3.1 (x86_64-apple-darwin10.8.0, Carbon Version 1.6.0 
AppKit 1038.36)
 of 2011-09-12 on pluto.luannocracy.com
Package: Org-mode version 7.7 (release_7.7.292.g0d4e8.dirty)
-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: [O] Four issues with org-babel-tangle

[Eric Schulte]

Christopher Genovese  writes:

> Hi Eric,
>
>Thanks for your note.
>
>> I would encourage you to begin the FSF assignment process if
>> you anticipate potentially contributing more fixes in the
>> future. Could you please send a git format-patch version of
>> the simple fix to the list so that I might apply it?
>
>I will begin the FSF assignment process, and I will send a git-format
> patch based on the simple fix. (I'll send that tonight.)
>

Fantastic.

>
>> I like the idea of introducing a customizable function for
>> comment text transformation, however ... rather perhaps we
>> should just leave the default value of this function as
>> simple as possible and allow users to customize it 
>
>That makes sense, and I like the way you did it. In particular,
> I absolutely agree that the org-babel-trim should be removed
> from org-babel-spec-to-string (to allow flexibility in the customization).
> Making it the default processor works well, I think.
>
>Would you like me to submit a separate patch based on this change
> or should I include that as part of the patch with the simple fix?
>

I'll write up this change as it may end up being longer than 10 lines,
and if I write it we don't have to wait for your FSF assignment to clear
(which can sometimes take months) before applying the patch.

In fact... if this attached patch looks good to you (i.e., allows the
behavior you originally intended) then please let me know and I'll apply
it immediately.

>From cebe0bec72df8c07dab367e2df500d2fd1a8aae3 Mon Sep 17 00:00:00 2001
From: Eric Schulte 
Date: Thu, 15 Sep 2011 16:00:10 -0600
Subject: [PATCH] customizable processing of Org-mode text used as comments in tangled source-code files

* lisp/ob-tangle.el (org-babel-process-comment-text): Customizable
  function to process comment text.
  (org-babel-tangle-collect-blocks): Make use of new customizable
  processing function.
  (org-babel-spec-to-string): Call customizable function rather than
  `org-babel-trim'.
---
 lisp/ob-tangle.el |   41 +
 1 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index d1e26c0..10fc120 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -95,6 +95,14 @@ controlled by the :comments header argument."
   :group 'org-babel
   :type 'string)
 
+(defcustom org-babel-process-comment-text #'org-babel-trim
+  "Function called to process raw Org-mode text collected to be
+inserted as comments in tangled source-code files.  The function
+should take a single string argument and return a string
+result.  The default value is `org-babel-trim'."
+  :group 'org-babel
+  :type 'function)
+
 (defun org-babel-find-file-noselect-refresh (file)
   "Find file ensuring that the latest changes on disk are
 represented in the file."
@@ -345,16 +353,18 @@ code blocks by language."
 		(when (or (string= "both" (cdr (assoc :comments params)))
 			  (string= "org" (cdr (assoc :comments params
 		  ;; from the previous heading or code-block end
-		  (buffer-substring
-		   (max (condition-case nil
-(save-excursion
-  (org-back-to-heading t) (point))
-			  (error 0))
-			(save-excursion
-			  (re-search-backward
-			   org-babel-src-block-regexp nil t)
-			  (match-end 0)))
-		   (point
+		  (funcall
+		   org-babel-process-comment-text
+		   (buffer-substring
+			(max (condition-case nil
+ (save-excursion
+   (org-back-to-heading t) (point))
+			   (error 0))
+			 (save-excursion
+			   (re-search-backward
+org-babel-src-block-regexp nil t)
+			   (match-end 0)))
+			(point)
 		   by-lang)
 	  ;; add the spec for this block to blocks under it's language
 	  (setq by-lang (cdr (assoc src-lang blocks)))
@@ -396,12 +406,11 @@ form
  (eval el
 			'(start-line file link source-name
 (flet ((insert-comment (text)
-(let ((text (org-babel-trim text)))
-	  (when (and comments (not (string= comments "no"))
-			 (> (length text) 0))
-		(when padline (insert "\n"))
-		(comment-region (point) (progn (insert text) (point)))
-		(end-of-line nil) (insert "\n")
+(when (and comments (not (string= comments "no"))
+		   (> (length text) 0))
+	  (when padline (insert "\n"))
+	  (comment-region (point) (progn (insert text) (point)))
+	  (end-of-line nil) (insert "\n"
   (when comment (insert-comment comment))
   (when link-p
 	(insert-comment
-- 
1.7.4.1


>
>> Finally I'm not sure I fully understand what you mean by ...
>
> Sorry, I wasn't clear. It's a small thing. If you put
> '#+tangle' in column 0, the line is not exported because it
> begins with #; if you put #+ tangle on a line (spaces
> after + and possibly before #), the line is not exported
> because it begins with #+; but if you put #+tangle (no
> spaces after the + but spaces before the #), the line is
> exported. I 

Re: [O] org-babel R, export, and :result value raw

[Eric Schulte]

Hi Christophe,

This issue of result wrappers (e.g., raw org html) not playing well with
result types (e.g., vector, scalar) came up a couple of months ago on
this mailing list and was not resolved.

I've just pushed up a change which should fix this problem, along with
an R-specific fix so that R respects the "scalar" and "verbatim"
:results header arguments so that the following now works.

#+begin_src R :results raw scalar
"[[file:bar.png]]"
#+end_src

Best -- Eric

Christophe Rhodes  writes:

> Hi,
>
> Consider the following org-mode file, assuming that org-babel support
> for emacs lisp and R is active:
>
> --- begin ---
> #+TITLE: Foo
>
> #+begin_src emacs-lisp :exports results :results value raw
> "[[file:foo.png]]"
> #+end_src
>
> #+results:
> [[foo.png]]
>
> #+begin_src R :exports results :results value raw
> "[[file:bar.png]]"
> #+end_src
> #+results: 
> [[file:bar\.png]]
> ---  end  ---
>
> The problem is probably obvious from the above, but to be explicit: the
> intent is to generate raw org-mode from the code blocks (this case is
> hugely simplified from my actual application), producing links to images
> which will then be part of the eventual exported document.  For emacs
> lisp, this works fine; for R, the path through files and specifically
> org-babel-import-elisp-from-file / org-babel-string-read causes the
> return value to be misinterpreted, introducing an extra backslash, and
> therefore generating bogus export files.
>
> (This used to work for my use case in org-mode 7.4, and does not work in
> org-mode 7.6; I looked at HEAD to see if I could identify a fix, but did
> not find one -- I'm sorry if I missed it)
>
> Thanks,
>
> Christophe
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] org-babel R, export, and :result value raw

[Nick Dokos]

Christophe Rhodes  wrote:

> Hi,
> 
> Consider the following org-mode file, assuming that org-babel support
> for emacs lisp and R is active:
> 
> --- begin ---
> #+TITLE: Foo
> 
> #+begin_src emacs-lisp :exports results :results value raw
> "[[file:foo.png]]"
> #+end_src
> 
> #+results:
> [[foo.png]]
> 
> #+begin_src R :exports results :results value raw
> "[[file:bar.png]]"
> #+end_src
> #+results: 
> [[file:bar\.png]]
> ---  end  ---
> 
> The problem is probably obvious from the above, but to be explicit: the
> intent is to generate raw org-mode from the code blocks (this case is
> hugely simplified from my actual application), producing links to images
> which will then be part of the eventual exported document.  For emacs
> lisp, this works fine; for R, the path through files and specifically
> org-babel-import-elisp-from-file / org-babel-string-read causes the
> return value to be misinterpreted, introducing an extra backslash, and
> therefore generating bogus export files.
> 
> (This used to work for my use case in org-mode 7.4, and does not work in
> org-mode 7.6; I looked at HEAD to see if I could identify a fix, but did
> not find one -- I'm sorry if I missed it)
> 

This bisects to the following commit:

--8<---cut here---start->8---
commit b6912331715c7da08927b3636b6721af5f5e0c41
Author: Eric Schulte 
Date:   Tue Mar 1 10:31:00 2011 -0700

ob: allow passing elisp vectors through to code blocks

* lisp/ob.el (org-babel-read): Pass elisp vectors through to code
  blocks.

diff --git a/lisp/ob.el b/lisp/ob.el
index ea1c968..b0b5fb6 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -1913,16 +1913,15 @@ (defun org-babel-script-escape (str)
 
 (defun org-babel-read (cell &optional inhibit-lisp-eval)
   "Convert the string value of CELL to a number if appropriate.
-Otherwise if cell looks like lisp (meaning it starts with a \"(\"
-or a \"'\") then read it as lisp, otherwise return it unmodified
-as a string.  Optional argument NO-LISP-EVAL inhibits lisp
-evaluation for situations in which is it not appropriate."
+Otherwise if cell looks like lisp (meaning it starts with a
+\"(\", \"'\", \"`\" or a \"[\") then read it as lisp, otherwise
+return it unmodified as a string.  Optional argument NO-LISP-EVAL
+inhibits lisp evaluation for situations in which is it not
+appropriate."
   (if (and (stringp cell) (not (equal cell "")))
   (or (org-babel-number-p cell)
   (if (and (not inhibit-lisp-eval)
-  (or (equal "(" (substring cell 0 1))
-  (equal "'" (substring cell 0 1))
-  (equal "`" (substring cell 0 1
+  (member (substring cell 0 1) '("(" "'" "`" "[")))
   (eval (read cell))
 (progn (set-text-properties 0 (length cell) nil cell) cell)))
 cell))
--8<---cut here---end--->8---

If I revert it, I get the 7.4 behavior.

The problem is that  "[..." looks like a lisp vector to this function.

Nick

[O] org-babel R, export, and :result value raw

[Christophe Rhodes]

Hi,

Consider the following org-mode file, assuming that org-babel support
for emacs lisp and R is active:

--- begin ---
#+TITLE: Foo

#+begin_src emacs-lisp :exports results :results value raw
"[[file:foo.png]]"
#+end_src

#+results:
[[foo.png]]

#+begin_src R :exports results :results value raw
"[[file:bar.png]]"
#+end_src

#+results: 
[[file:bar\.png]]
---  end  ---

The problem is probably obvious from the above, but to be explicit: the
intent is to generate raw org-mode from the code blocks (this case is
hugely simplified from my actual application), producing links to images
which will then be part of the eventual exported document.  For emacs
lisp, this works fine; for R, the path through files and specifically
org-babel-import-elisp-from-file / org-babel-string-read causes the
return value to be misinterpreted, introducing an extra backslash, and
therefore generating bogus export files.

(This used to work for my use case in org-mode 7.4, and does not work in
org-mode 7.6; I looked at HEAD to see if I could identify a fix, but did
not find one -- I'm sorry if I missed it)

Thanks,

Christophe

Re: [O] Feature request: Select links by description [7.4]

[Dave Abrahams]

on Tue Feb 15 2011, Dave Abrahams  wrote:

> On Mon, Feb 14, 2011 at 11:14 PM, Bastien  wrote:
>> Dave Abrahams  writes:
>
>>
>>> How about just always showing the link as it will be presented to the
>>> user first, followed by the raw link?  Then everything will be
>>> consistent.
>>
>> I don't see how it would prevent the problem I've been mentionning: we
>> will still have a mix of descriptions and raw links... or maybe I miss
>> something?
>
> If it's really paramount to avoid a mixture, you must hide all
> descriptions, which would be a step in the wrong direction for me.
>
>> I'm willing to improve the display of links, keep brainstorming!
>
> I'm out of ideas.  Leading off with the displayed form of the link is
> the best I can do.



The best is the enemy of the good and all that... is there any reason
this can't be made to work?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: [O] Time range between now and timestamp

[Alexander Wingård]

Wonderful, thanks alot!

I can already see this becoming of great use to me.

Best Regards /Alexander

On Thu, Sep 15, 2011 at 6:02 PM, Nick Dokos  wrote:
> Alexander Wingård  wrote:
>
>> Let's say I have this:
>>
>> <2011-09-15 Thu>--<2011-09-16 Fri>
>>
>> and I put my cursor over this and press C-c C-y my minibuffer will
>> spit out 1 day.
>>
>> I would like a command that does the same thing if i execute it over
>> just <2011-09-16 Fri>.
>>
>> Sometimes I'm interested in how much time there is left to a specific
>> appointment.
>>
>
> Here is one way to do it:
>
> --8<---cut here---start->8---
> (defun aw/org-evaluate-time-range (&optional to-buffer)
>  (interactive)
>  (if (org-at-date-range-p t)
>      (org-evaluate-time-range to-buffer)
>    ;; otherwise, make a time range in a temp buffer and run o-e-t-r there
>    (let ((headline (buffer-substring (point-at-bol) (point-at-eol
>      (with-temp-buffer
>        (insert headline)
>        (goto-char (point-at-bol))
>        (re-search-forward org-ts-regexp (point-at-eol) t)
>        (if (not (org-at-timestamp-p t))
>            (error "No timestamp here"))
>        (goto-char (match-beginning 0))
>        (org-insert-time-stamp (current-time) nil nil)
>        (insert "--")
>        (org-evaluate-time-range to-buffer)
> --8<---cut here---end--->8---
>
> There are probably better implementations; also, you might be able to advise
> o-e-t-r, instead of writing a new function, which would have the advantage
> of preserving the key binding.
>
> AFAICT, the above works with dates in the past as well, but it always gives
> the absolute value of the difference.
>
> Nick
>
>>
>> On Thu, Sep 15, 2011 at 4:37 PM, Nick Dokos  wrote:
>> > Alexander Wingård  wrote:
>> >
>> >> Hi!
>> >>
>> >> I really would want to have a command that given the cursor is over a
>> >> timestamp would output the time-range from the current time to that
>> >> timestamp.
>> >>
>> >
>> > Can you please provide an example? I can interpret this
>> > in a couple of different ways and I'm not sure what you
>> > want.
>> >
>> > Also, when you say "output", do you mean that the function
>> > should return e.g. a string representation of whatever it is
>> > you want? Or print the result in the minibuffer?
>> > Or insert it in the buffer you are editing? (and, if the last,
>> > where?)
>> >
>> > Nick
>> >
>>
>

Re: [O] Time range between now and timestamp

[Nick Dokos]

Alexander Wingård  wrote:

> Let's say I have this:
> 
> <2011-09-15 Thu>--<2011-09-16 Fri>
> 
> and I put my cursor over this and press C-c C-y my minibuffer will
> spit out 1 day.
> 
> I would like a command that does the same thing if i execute it over
> just <2011-09-16 Fri>.
> 
> Sometimes I'm interested in how much time there is left to a specific
> appointment.
> 

Here is one way to do it:

--8<---cut here---start->8---
(defun aw/org-evaluate-time-range (&optional to-buffer)
  (interactive)
  (if (org-at-date-range-p t)
  (org-evaluate-time-range to-buffer)
;; otherwise, make a time range in a temp buffer and run o-e-t-r there
(let ((headline (buffer-substring (point-at-bol) (point-at-eol
  (with-temp-buffer
(insert headline)
(goto-char (point-at-bol))
(re-search-forward org-ts-regexp (point-at-eol) t)
(if (not (org-at-timestamp-p t))
(error "No timestamp here"))
(goto-char (match-beginning 0))
(org-insert-time-stamp (current-time) nil nil)
(insert "--")
(org-evaluate-time-range to-buffer)
--8<---cut here---end--->8---

There are probably better implementations; also, you might be able to advise
o-e-t-r, instead of writing a new function, which would have the advantage
of preserving the key binding.

AFAICT, the above works with dates in the past as well, but it always gives
the absolute value of the difference.

Nick

> 
> On Thu, Sep 15, 2011 at 4:37 PM, Nick Dokos  wrote:
> > Alexander Wingård  wrote:
> >
> >> Hi!
> >>
> >> I really would want to have a command that given the cursor is over a
> >> timestamp would output the time-range from the current time to that
> >> timestamp.
> >>
> >
> > Can you please provide an example? I can interpret this
> > in a couple of different ways and I'm not sure what you
> > want.
> >
> > Also, when you say "output", do you mean that the function
> > should return e.g. a string representation of whatever it is
> > you want? Or print the result in the minibuffer?
> > Or insert it in the buffer you are editing? (and, if the last,
> > where?)
> >
> > Nick
> >
> 

Re: [O] Four issues with org-babel-tangle

[Eric Schulte]

Hi Christopher,

Thank you for the thorough examples and for suggesting fixes.  I would
like to apply your "simple fix" immediately, and the resulting patch
should be small enough (less than 10 lines of changes) that it can be
applied without FSF assignment -- although I would encourage you to
begin the FSF assignment process if you anticipate potentially
contributing more fixes in the future.  Could you please send a git
format-patch version of the simple fix to the list so that I might apply
it?

I like the idea of introducing a customizable function for comment text
transformation, however I'm not sure that the temporary-buffer mechanics
need to be included by default, rather perhaps we should just leave the
default value of this function as simple as possible and allow users to
customize it to be as simple or complex as they wish.  Perhaps a change
like the following, where the call to `org-babel-trim' in
`org-babel-spec-to-string' is removed.

#+begin_src emacs-lisp
  (buffer-substring
   (max (condition-case nil
(save-excursion
  (org-back-to-heading t) (point))
  (error 0))
(save-excursion
  (re-search-backward
   org-babel-src-block-regexp nil t)
  (match-end 0)))
   (point))
  
  ;; | becomes
  ;; v
  
  (org-babel-process-comment-text
   (buffer-substring
(max (condition-case nil
 (save-excursion
   (org-back-to-heading t) (point))
   (error 0))
 (save-excursion
   (re-search-backward
org-babel-src-block-regexp nil t)
   (match-end 0)))
(point)))
  
  ;; where
  
  (defcustom org-babel-process-comment-text #'org-babel-trim
"Customizable function for processing comment text."
:group 'org-babel
:type 'function)
#+end_src

This change may end up being more than 10 lines long, but a patch would
still be welcome, otherwise if the solution I sketched out above sounds
reasonable I could compose a patch and then share it with you for double
checking before it is applied.

Finally I'm not sure I fully understand what you mean by

>
> [fn:2] A feature request: I would propose that the =#+tangle:= construct
> be recognized as non-exported even with spaces preceding the =#= and no
> spaces after the =+=. This would enable a variety of interesting
> customization for tangled comments. Alternatively, a generic construct
> such as =#+noop:= or =#+generic:= could be a valuable for user-based
> tags in an org file that serves a similar purpose -- allow customized
> processing without directly being exported.
>

Please do let me know if I missed anything, it was a long email.

Thanks for contributing! -- Eric

Christopher Genovese  writes:

> /Semi-verbose Preamble/.
> Having recently begun intensive use of org-mode for tangling source
> files, I encountered four issues related to comment extraction (two
> bugs, one undesirable behavior, and one ... unfulfilled need), which I
> describe in detail below. I started by creating an org file that would
> reproduce the problems, and soon started /describing/ the problems in
> the org file as well as putting my fixes in the source blocks. At the
> risk of it being too meta or annoying, I've included that org file at
> the end of this message as the problem description. All the details are
> there as well as two fixes. Tangling that file in various ways described
> demonstrates the problems, and you can export to PDF for nicer reading.
> (I've attached the PDF to this mail for convenience. It looks good;
> kudos, org-mode!) I've also attached a tarball with files that make it
> easy to try my changes and to restore the original behavior, as well as
> tests and results from the org file for easy comparison. See the
> included README.
>
> I've been using the revised code now for a few days. It fixes the
> problems I describe, and I think it provides a flexible framework for
> comment extraction with minimal change to the base code. If the reaction
> to this is positive, I will happily submit a patch, sign paperwork, or
> whatever is needed, after fixing any problems that you all see. In any
> case, I very much look forward to any feedback you can offer. Thanks.
>
>   -- Christopher
>
> P.S. In case the attachments get dropped, I've put the PDF and the
>  tarball at
>
>  http://www.stat.cmu.edu/~genovese/depot/tangle-error.pdf
>  http://www.stat.cmu.edu/~genovese/depot/tangle-bundle.tgz
>
> /Problem Description/
>  Cut Here 
> # -*- org-return-follows-link: t; comment-empty-lines: t; -*-
> #+TITLE: Tangle this file: four issues with org-babel-tangle
> #+AUTHOR: Christopher Genovese
> #+DATE: 14 Sep 2011\vspace*{-0.5cm}
> #+EMAIL: genov...@cmu.edu
> #+OPTIONS: toc:1 H:1
> #+BABEL: :tangle yes :comments org :results silent :exports code
> #+BIND: org-export-latex-hyperref-format "\\hyperlink{%s}{%s}"
> #+STARTUP: showall
> #+LATEX_HEADER: \usepackage[labelsep=period,labelfont=bf]{

Re: [O] [babel] Some variables with no default value don't provoke an error

[Eric Schulte]

"Sebastien Vauban"  writes:

> Hi Eric,
>
> As said previously, I've been forced to add a default value to many code
> blocks I had in my local LOB, which I ingest in my `.emacs' file:
>
> #+begin_src emacs-lisp
>  (when (try-require 'ob-lob)
>(org-babel-lob-ingest "~/emacs/site-lisp/my-local-lob.org"))
> #+end_src
>
> Weirdly enough, in the following code block, I must add a default value for
> vars `table', `column' and `type' but not for the var `nullability'.
>
> I've even been able to add fake vars `something' and `else' with no error
> being reported (at ingestion time):
>
> #+srcname: add-column-in-table(table="", column="", something, type="", else, 
> nullability)
> #+begin_src sql
> -- add column `$column' (if column does not exist yet)
> IF NOT EXISTS (SELECT *
>FROM INFORMATION_SCHEMA.COLUMNS
>WHERE TABLE_NAME = '$table'
>AND COLUMN_NAME = '$column')
> BEGIN
> ALTER TABLE $table
> ADD $column $type $nullability
> END
> #+end_src
>
> Note that, in the above state, the code block is ingested with no error, but,
> if I remove the default value of var `table', it then generates back an
> error...
>

I've just pushed up a check for these functional-syntax variables which
will ensure that each is given a default value.  Since this check takes
place at the location of the code block it /does/ include the name of
the code block in the error message.

Cheers -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] [babel] Export problem (Wrong type argument: consp, nil)

[Eric Schulte]

>
> Question: Would it be possible to add the src-name in the error
> message?

Unfortunately the code block name is not known to the function (namely
`org-babel-merge-params') which throws errors when variables are not
assigned default values.  In fact this function may be called when there
are no code blocks present.  I think that this is why you ran into
problems trying to thread the code block info down into this error
message.

Another option may be to check when a code block is initially parsed to
ensure that all variables are assigned default parameters.  If the
checking is done initially then the code block name and position will be
known and could be included into the error message.  There exists a
function for checking code blocks (namely `org-babel-check-src-block'),
I've added a TODO to this function to add a check that all variables are
initialized.

>
> * Test
>
> #+begin_src emacs-lisp
> (ert-deftest test-org-babel/no-defaut-value-for-var ()
>   "Test that the absence of a default value for a variable does throw a proper
>   error."
>   (org-test-at-id "f2df5ba6-75fa-4e6b-8441-65ed84963627"
> (org-babel-next-src-block)
> (should-error (org-babel-execute-src-block))
> :type 'error))
> #+end_src
>
> Though, I have 2 questions:
>
> - How can I differentiate between the clean error (with a message) and the one
>   which wasn't correctly trapped?  Based on the first line of a backtrace
>   (string comparison) or on the type of the error?  In the latter case, how
>   can I know what's the type of the current error thrown, and the one of the
>   error before your fix?
>

I believe Martyn answered this question

>
> - I wonder why we need twice the =org-babel-next-src-block= call, and
>   not only once in the =should-error= form.
>

I only see a single call to org-babel-next-src-block in the above test.

Thanks for working on this test, I look forward to adding it once it is
completed.

Cheers -- Eric

>
> Thanks.
>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] Error in post-command-hook: (void-variable org-ans1)

[Diep Pham Van]

On Thu, 15 Sep 2011 10:42:07 -0400
brian powell  wrote:

> *Could do this work-around:
> 
> nl file_you_will_edit.org | cut -f 1 > line_numbers
> 
> *Open the file_you_will_edit.org and do:
> 
> Mx split-window-horizontally
> 
> *Put the line_numbers in the left-hand-side buffer!
> 
> ;-)
> 
> 
> P.S. I put the line number and column number on the modeline:
> http://www.gnu.org/s/libtool/manual/emacs/Mode-Line.html
> 
> 
> 
> On Thu, Sep 15, 2011 at 8:37 AM, Diep Pham Van 
> wrote:
> > On Thu, 15 Sep 2011 14:07:57 +0200
> > Olaf Dietsche  wrote:
> >
> >> Diep Pham Van  writes:
> >>
> >> > On Thu, 15 Sep 2011 12:04:30 +0200
> >> > Olaf Dietsche  wrote:
> >> >
> >> >> Have you tried disabling or reducing these modes? One of them
> >> >> or a combination is responsible for the error you get.
> >> >>
> >> >> Regards, Olaf
> >> >
> >> > Got it.
> >> > Disable linum-mode solve this problem.
> >> > Update to the latest version of linum-mode, the error is still
> >> > appear.
> >> >
> >> > How this can be? I think linum-mode is very popular.
> >>
> >> I don't know, since I don't use it myself. It could be a
> >> combination of linum-mode and some other.
> >>
> >> Regards, Olaf
> >
> > So install linum-off.el solve this problem.
> > Anyone else use linum-mode with org-mode?
> >
> > --
> >
> > PHẠM Văn Điệp
> >
> > h  : http://favadi.com
> > e  : i...@favadi.com
> > e2 : favadi.a...@gmail.com
> > m  : +84 339 841
> >
> > p  : Information system and communication technology
> > u  : Hanoi University of Science and Technology (PFIEV - Programme
> > de Formation d’Ingénieurs d’Excellence au Vietnam)
> >
> > k  : h = home, e = email, e2 = second_email, m = mobile, p =
> > professional, u = university, k = key
> >
> >

I don't really need line number while using org-mode. Turn them off for
org seem to be a better idea.
Tks.

-- 

PHẠM Văn Điệp

h  : http://favadi.com
e  : i...@favadi.com
e2 : favadi.a...@gmail.com
m  : +84 339 841

p  : Information system and communication technology
u  : Hanoi University of Science and Technology (PFIEV - Programme de
Formation d’Ingénieurs d’Excellence au Vietnam)

k  : h = home, e = email, e2 = second_email, m = mobile, p =
professional, u = university, k = key

Re: [O] Time range between now and timestamp

[Alexander Wingård]

Let's say I have this:

<2011-09-15 Thu>--<2011-09-16 Fri>

and I put my cursor over this and press C-c C-y my minibuffer will
spit out 1 day.

I would like a command that does the same thing if i execute it over
just <2011-09-16 Fri>.

Sometimes I'm interested in how much time there is left to a specific
appointment.

Best Regards /Alexander

On Thu, Sep 15, 2011 at 4:37 PM, Nick Dokos  wrote:
> Alexander Wingård  wrote:
>
>> Hi!
>>
>> I really would want to have a command that given the cursor is over a
>> timestamp would output the time-range from the current time to that
>> timestamp.
>>
>
> Can you please provide an example? I can interpret this
> in a couple of different ways and I'm not sure what you
> want.
>
> Also, when you say "output", do you mean that the function
> should return e.g. a string representation of whatever it is
> you want? Or print the result in the minibuffer?
> Or insert it in the buffer you are editing? (and, if the last,
> where?)
>
> Nick
>

Re: [O] Error in post-command-hook: (void-variable org-ans1)

[brian powell]

*Could do this work-around:

nl file_you_will_edit.org | cut -f 1 > line_numbers

*Open the file_you_will_edit.org and do:

Mx split-window-horizontally

*Put the line_numbers in the left-hand-side buffer!

;-)


P.S. I put the line number and column number on the modeline:
http://www.gnu.org/s/libtool/manual/emacs/Mode-Line.html



On Thu, Sep 15, 2011 at 8:37 AM, Diep Pham Van  wrote:
> On Thu, 15 Sep 2011 14:07:57 +0200
> Olaf Dietsche  wrote:
>
>> Diep Pham Van  writes:
>>
>> > On Thu, 15 Sep 2011 12:04:30 +0200
>> > Olaf Dietsche  wrote:
>> >
>> >> Have you tried disabling or reducing these modes? One of them or a
>> >> combination is responsible for the error you get.
>> >>
>> >> Regards, Olaf
>> >
>> > Got it.
>> > Disable linum-mode solve this problem.
>> > Update to the latest version of linum-mode, the error is still
>> > appear.
>> >
>> > How this can be? I think linum-mode is very popular.
>>
>> I don't know, since I don't use it myself. It could be a combination
>> of linum-mode and some other.
>>
>> Regards, Olaf
>
> So install linum-off.el solve this problem.
> Anyone else use linum-mode with org-mode?
>
> --
>
> PHẠM Văn Điệp
>
> h  : http://favadi.com
> e  : i...@favadi.com
> e2 : favadi.a...@gmail.com
> m  : +84 339 841
>
> p  : Information system and communication technology
> u  : Hanoi University of Science and Technology (PFIEV - Programme de
> Formation d’Ingénieurs d’Excellence au Vietnam)
>
> k  : h = home, e = email, e2 = second_email, m = mobile, p =
> professional, u = university, k = key
>
>

Re: [O] Time range between now and timestamp

[Nick Dokos]

Alexander Wingård  wrote:

> Hi!
> 
> I really would want to have a command that given the cursor is over a
> timestamp would output the time-range from the current time to that
> timestamp.
> 

Can you please provide an example? I can interpret this
in a couple of different ways and I'm not sure what you
want.

Also, when you say "output", do you mean that the function
should return e.g. a string representation of whatever it is
you want? Or print the result in the minibuffer?
Or insert it in the buffer you are editing? (and, if the last,
where?)

Nick

[O] Time range between now and timestamp

[Alexander Wingård]

Hi!

I really would want to have a command that given the cursor is over a timestamp 
would output the time-range from the current time to that timestamp.

I've been searching a lot for this but no luck and I even did an attempt to 
implement some hacked version of org-evaluate-time-range and org-days-to-time 
but since my experience with lisp is absolutely zero I failed miserably.

I imagine someone here could help me whip this up in a couple of lines or maybe 
such feature can already be achieved?

Best Regards /Alexander

Ps. I love org-mode

Re: [O] Lisp nesting exceeds `max-lisp-eval-depth'"

[brian powell]

*"Variable: max-lisp-eval-depth
This variable defines the maximum depth allowed in calls to eval,
apply, and funcall before an error is signaled (with error message
"Lisp nesting exceeds max-lisp-eval-depth"). This limit, with the
associated error when it is exceeded, is one way that Lisp avoids
infinite recursion on an ill-defined function.
The depth limit counts internal uses of eval, apply, and funcall, such
as for calling the functions mentioned in Lisp expressions, and
recursive evaluation of function call arguments and function body
forms, as well as explicit calls in Lisp code.

The default value of this variable is 300. If you set it to a value
less than 100, Lisp will reset it to 100 if the given value is
reached. Entry to the Lisp debugger increases the value, if there is
little room left, to make sure the debugger itself has room to
execute.

max-specpdl-size provides another limit on nesting. See section 11.3
Local Variables."

**I think this is one weakness of ELISP vs. CommonLISP--but this is
"by design"; EMACS has always been focused on editing, so some
trade-offs are used, objects such as "buffers, windows, etc." are a
paramount part of the language--and recursion is handled slightly
differently, I believe this is done on purpose.

**Maybe try to set the max-lisp-eval-depth variable higher?

***Maybe something like (setq max-lisp-eval-depth 3000)

**Maybe load the common lisp module; which is always a good idea--but
this probably won't help, just an idea.


On Thu, Sep 15, 2011 at 4:48 AM, Martin Butz  wrote:
> Hello all,
>
> I get the following error message while using org-mode during the last weeks
> quite frequently (unfortunately I am not able to link it to an update of the
> installation of some lisp file); I can reproduce the behaviour by opening
> the agenda buffer (C-c a a) and trying to quit with "q"; this will open a
> new frame with the backtrace buffer and leave the agenda buffer in the other
> frame open.
>
> There are loads of other events, which trigger the same behaviour; can
> anybody give a hint how I can solve this rather annoying problem?
>
> Thanks in advance
> Martin
>
>  Backtrace --8<
>
> Debugger entered--Lisp error: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")
>  (- (nth 2 edges) (nth 0 edges))
>  (let ((edges ...)) (- (nth 2 edges) (nth 0 edges)))
>  sr-speedbar-current-window-take-width()
>  (let ((win-width ...)) (if (and ... ... ...) (setq sr-speedbar-width
> win-width)))
>  sr-speedbar-remember-window-width()
>  old-delete-window(#)
>
>  following lines are repeated several times--8<
>
>  (if (one-window-p t) (delete-frame) (old-delete-window (selected-window)))
>  (save-current-buffer (setq window (or window ...)) (select-window window)
> (if (one-window-p t) (delete-frame) (old-delete-window ...)))
>  ad-Orig-delete-window(#)
>  old-delete-window(#)
>
>  /following lines are repeated several times--8<---
>
>  (if (one-window-p t) (delete-frame) (old-delete-window (selected-window)))
>  (save-current-buffer (setq window (or window ...)) (select-window window)
> (if (one-window-p t) (delete-frame) (old-delete-window ...)))
>  ad-Orig-delete-window(nil)
>  delete-window()
>  (and (not (eq org-agenda-window-setup ...)) (not (one-window-p))
> (delete-window))
>  (if (eq org-agenda-window-setup (quote other-frame)) (progn (kill-buffer
> buf) (org-agenda-reset-markers) (org-columns-remove-overlays) (setq
> org-agenda-archives-mode nil) (delete-frame)) (and (not ...) (not ...)
> (delete-window)) (kill-buffer buf) (org-agenda-reset-markers)
> (org-columns-remove-overlays) (setq org-agenda-archives-mode nil))
>  (let ((buf ...)) (if (eq org-agenda-window-setup ...) (progn ... ... ...
> ... ...) (and ... ... ...) (kill-buffer buf) (org-agenda-reset-markers)
> (org-columns-remove-overlays) (setq org-agenda-archives-mode nil)))
>  (if org-agenda-columns-active (org-columns-quit) (let (...) (if ... ... ...
> ... ... ... ...)) (and org-agenda-restore-windows-after-quit (not ...)
> org-pre-agenda-window-conf (set-window-configuration
> org-pre-agenda-window-conf)))
>  org-agenda-quit()
>  call-interactively(org-agenda-quit nil nil)
>
>  /Backtrace --8<---
>
> --
> ~
> sym.net  ||  butz & siefer gbr  ||  50670 koeln  ||  hansaring 78
> phone +49(0)221/3762591 -  twitter.com/symnet  - mail b...@sym.net
> ~~ www.sym.net | www.moodalis.de 
>
>

Re: [O] Error in post-command-hook: (void-variable org-ans1)

[Diep Pham Van]

On Thu, 15 Sep 2011 14:07:57 +0200
Olaf Dietsche  wrote:

> Diep Pham Van  writes:
> 
> > On Thu, 15 Sep 2011 12:04:30 +0200
> > Olaf Dietsche  wrote:
> >
> >> Have you tried disabling or reducing these modes? One of them or a
> >> combination is responsible for the error you get.
> >> 
> >> Regards, Olaf
> >
> > Got it.
> > Disable linum-mode solve this problem.
> > Update to the latest version of linum-mode, the error is still
> > appear.
> >
> > How this can be? I think linum-mode is very popular.
> 
> I don't know, since I don't use it myself. It could be a combination
> of linum-mode and some other.
> 
> Regards, Olaf

So install linum-off.el solve this problem.
Anyone else use linum-mode with org-mode?

-- 

PHẠM Văn Điệp

h  : http://favadi.com
e  : i...@favadi.com
e2 : favadi.a...@gmail.com
m  : +84 339 841

p  : Information system and communication technology
u  : Hanoi University of Science and Technology (PFIEV - Programme de
Formation d’Ingénieurs d’Excellence au Vietnam)

k  : h = home, e = email, e2 = second_email, m = mobile, p =
professional, u = university, k = key

Re: [O] Error in post-command-hook: (void-variable org-ans1)

[Olaf Dietsche]

Diep Pham Van  writes:

> On Thu, 15 Sep 2011 12:04:30 +0200
> Olaf Dietsche  wrote:
>
>> Have you tried disabling or reducing these modes? One of them or a
>> combination is responsible for the error you get.
>> 
>> Regards, Olaf
>
> Got it.
> Disable linum-mode solve this problem.
> Update to the latest version of linum-mode, the error is still appear.
>
> How this can be? I think linum-mode is very popular.

I don't know, since I don't use it myself. It could be a combination of
linum-mode and some other.

Regards, Olaf

Re: [O] Use id property as anchor in the Table of Contents

[Pere Quintana Seguí]

2011/9/15 Olaf Dietsche :
>> With this patch, what happens if there is no id in a heading, does it
>> create it automatically?
>
> It is supposed to use the CUSTOM_ID, if set. Next, it tries the ID
> property. At last, it falls back to "sec-...".

Ok, perfect. Thanks.

Re: [O] Error in post-command-hook: (void-variable org-ans1)

[Diep Pham Van]

On Thu, 15 Sep 2011 12:04:30 +0200
Olaf Dietsche  wrote:

> Diep Pham Van  writes:
> 
> > I get this error: "Error in post-command-hook: (void-variable
> > org-ans1)" every time I want to use schedule or deadline. After
> > that, the error message appear with any command. After some
> > minutes, this error message disappear and I can use anny command as
> > expected.
> >
> > This problem happens with both the version ship with emacs 23.3 or
> > latest version (7.7).
> >
> > This is my .emacs config.
> >
> > http://pastebin.com/sQaTYJCR
> >
> > C-h v post-command-hook before the problem appear:
> >
> > post-command-hook is a variable defined in `C source code'.
> > Its value is
> > (linum-update-current ac-handle-post-command
> > autopair-post-command-handler t)
> >
> > Local in buffer .emacs; global value is 
> > (global-font-lock-mode-check-buffers global-linum-mode-check-buffers
> > global-auto-complete-mode-check-buffers
> > autopair-global-mode-check-buffers yas/global-mode-check-buffers
> > global-hl-line-highlight)
> 
> Have you tried disabling or reducing these modes? One of them or a
> combination is responsible for the error you get.
> 
> Regards, Olaf

Got it.
Disable linum-mode solve this problem.
Update to the latest version of linum-mode, the error is still appear.

How this can be? I think linum-mode is very popular.


-- 

PHẠM Văn Điệp

Re: [O] Lisp nesting exceeds `max-lisp-eval-depth'"

[Olaf Dietsche]

Martin Butz  writes:

> Am 15.09.2011 11:36, schrieb Olaf Dietsche:
>> Hi Martin,
>
> [...]
>
>>>sr-speedbar-remember-window-width()
>>>old-delete-window(#)
>>
>> This one hints at speedbar. Are you using the speedbar module?
>
> Yes. Good advice. I have a (require 'sr-speedbar) in my .emacs, which
> I do not use anymore.
>
>>>  following lines are repeated several times--8<
>>>
>>>(if (one-window-p t) (delete-frame) (old-delete-window
>>> (selected-window)))
>>>(save-current-buffer (setq window (or window ...)) (select-window
>>> window) (if (one-window-p t) (delete-frame) (old-delete-window ...)))
>>>ad-Orig-delete-window(#)
>>>old-delete-window(#)
>>
>> And this one points to advice. Any advice usage here?
>
> "Advice". What's that in the org-mode context?

Advice is an emacs module for wrapping an already existing
function. Look at  for
example.

Orgmode uses defadvice, but not for delete-window, AFAICS.

Regards, Olaf

Re: [O] Error in post-command-hook: (void-variable org-ans1)

[Diep Pham Van]

On Thu, 15 Sep 2011 12:04:30 +0200
Olaf Dietsche  wrote:

> Diep Pham Van  writes:
> 
> > I get this error: "Error in post-command-hook: (void-variable
> > org-ans1)" every time I want to use schedule or deadline. After
> > that, the error message appear with any command. After some
> > minutes, this error message disappear and I can use anny command as
> > expected.
> >
> > This problem happens with both the version ship with emacs 23.3 or
> > latest version (7.7).
> >
> > This is my .emacs config.
> >
> > http://pastebin.com/sQaTYJCR
> >
> > C-h v post-command-hook before the problem appear:
> >
> > post-command-hook is a variable defined in `C source code'.
> > Its value is
> > (linum-update-current ac-handle-post-command
> > autopair-post-command-handler t)
> >
> > Local in buffer .emacs; global value is 
> > (global-font-lock-mode-check-buffers global-linum-mode-check-buffers
> > global-auto-complete-mode-check-buffers
> > autopair-global-mode-check-buffers yas/global-mode-check-buffers
> > global-hl-line-highlight)
> 
> Have you tried disabling or reducing these modes? One of them or a
> combination is responsible for the error you get.
> 
> Regards, Olaf

After disable all these mode. C-h v:

post-command-hook is a variable defined in `C source code'.
Its value is nil

  This variable is potentially risky when used as a file local variable.

Documentation:
Normal hook run after each command is executed.
If an unhandled error happens in running this hook,
the hook value is set to nil, since otherwise the error
might happen repeatedly and make Emacs nonfunctional.


And the problem is still appear.
-- 

PHẠM Văn Điệp

h  : http://favadi.com
e  : i...@favadi.com
e2 : favadi.a...@gmail.com
m  : +84 339 841

p  : Information system and communication technology
u  : Hanoi University of Science and Technology (PFIEV - Programme de
Formation d’Ingénieurs d’Excellence au Vietnam)

k  : h = home, e = email, e2 = second_email, m = mobile, p =
professional, u = university, k = key

Re: [O] Error in post-command-hook: (void-variable org-ans1)

[Olaf Dietsche]

Diep Pham Van  writes:

> I get this error: "Error in post-command-hook: (void-variable
> org-ans1)" every time I want to use schedule or deadline. After that,
> the error message appear with any command. After some minutes, this
> error message disappear and I can use anny command as expected.
>
> This problem happens with both the version ship with emacs 23.3 or
> latest version (7.7).
>
> This is my .emacs config.
>
> http://pastebin.com/sQaTYJCR
>
> C-h v post-command-hook before the problem appear:
>
> post-command-hook is a variable defined in `C source code'.
> Its value is
> (linum-update-current ac-handle-post-command
> autopair-post-command-handler t)
>
> Local in buffer .emacs; global value is 
> (global-font-lock-mode-check-buffers global-linum-mode-check-buffers
> global-auto-complete-mode-check-buffers
> autopair-global-mode-check-buffers yas/global-mode-check-buffers
> global-hl-line-highlight)

Have you tried disabling or reducing these modes? One of them or a
combination is responsible for the error you get.

Regards, Olaf

Re: [O] Lisp nesting exceeds `max-lisp-eval-depth'"

[Olaf Dietsche]

Hi Martin,

Martin Butz  writes:

> Hello all,
>
> I get the following error message while using org-mode during the last
> weeks quite frequently (unfortunately I am not able to link it to an
> update of the installation of some lisp file); I can reproduce the
> behaviour by opening the agenda buffer (C-c a a) and trying to quit
> with "q"; this will open a new frame with the backtrace buffer and
> leave the agenda buffer in the other frame open.
>
> There are loads of other events, which trigger the same behaviour; can
> anybody give a hint how I can solve this rather annoying problem?
>
> Thanks in advance
> Martin
>
>  Backtrace --8<
>
> Debugger entered--Lisp error: (error "Lisp nesting exceeds
> max-lisp-eval-depth'")
>   (- (nth 2 edges) (nth 0 edges))
>   (let ((edges ...)) (- (nth 2 edges) (nth 0 edges)))
>   sr-speedbar-current-window-take-width()
>   (let ((win-width ...)) (if (and ... ... ...) (setq sr-speedbar-width
> win-width)))
>   sr-speedbar-remember-window-width()
>   old-delete-window(#)

This one hints at speedbar. Are you using the speedbar module?

>  following lines are repeated several times--8<
>
>   (if (one-window-p t) (delete-frame) (old-delete-window
> (selected-window)))
>   (save-current-buffer (setq window (or window ...)) (select-window
> window) (if (one-window-p t) (delete-frame) (old-delete-window ...)))
>   ad-Orig-delete-window(#)
>   old-delete-window(#)

And this one points to advice. Any advice usage here?

Usually you can narrow the real culprit by eliminating/reducing your
emacs init files until the error disappears. Then search from there on.

Look also at  and
.

Regards, Olaf

Re: [O] Use id property as anchor in the Table of Contents

[Olaf Dietsche]

Pere Quintana Seguí  writes:

> 2011/9/13 Olaf Dietsche :
>> How did you create ID properties for all entries? Have you exported your
>> org-files to icalendar?
>
> Most of them have ID properties because I often link them internally.
> When I create the link with C-c l, org adds the id.
>
> For those that do not have ID, I'll create them manually with
> org-id-get-create. With a keyboard macro this will be fast.

Ok, thanks for this explanation.

> With this patch, what happens if there is no id in a heading, does it
> create it automatically?

It is supposed to use the CUSTOM_ID, if set. Next, it tries the ID
property. At last, it falls back to "sec-...".

> At work I'm using stable versions of Org-mode. This weekend I'll try
> the git version at home and test your patch.

Regards, Olaf

[O] Lisp nesting exceeds `max-lisp-eval-depth'"

[Martin Butz]

Hello all,

I get the following error message while using org-mode during the last 
weeks quite frequently (unfortunately I am not able to link it to an 
update of the installation of some lisp file); I can reproduce the 
behaviour by opening the agenda buffer (C-c a a) and trying to quit with 
"q"; this will open a new frame with the backtrace buffer and leave the 
agenda buffer in the other frame open.


There are loads of other events, which trigger the same behaviour; can 
anybody give a hint how I can solve this rather annoying problem?


Thanks in advance
Martin

 Backtrace --8<

Debugger entered--Lisp error: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")

  (- (nth 2 edges) (nth 0 edges))
  (let ((edges ...)) (- (nth 2 edges) (nth 0 edges)))
  sr-speedbar-current-window-take-width()
  (let ((win-width ...)) (if (and ... ... ...) (setq sr-speedbar-width 
win-width)))

  sr-speedbar-remember-window-width()
  old-delete-window(#)

 following lines are repeated several times--8<

  (if (one-window-p t) (delete-frame) (old-delete-window 
(selected-window)))
  (save-current-buffer (setq window (or window ...)) (select-window 
window) (if (one-window-p t) (delete-frame) (old-delete-window ...)))

  ad-Orig-delete-window(#)
  old-delete-window(#)

 /following lines are repeated several times--8<---

  (if (one-window-p t) (delete-frame) (old-delete-window 
(selected-window)))
  (save-current-buffer (setq window (or window ...)) (select-window 
window) (if (one-window-p t) (delete-frame) (old-delete-window ...)))

  ad-Orig-delete-window(nil)
  delete-window()
  (and (not (eq org-agenda-window-setup ...)) (not (one-window-p)) 
(delete-window))
  (if (eq org-agenda-window-setup (quote other-frame)) (progn 
(kill-buffer buf) (org-agenda-reset-markers) 
(org-columns-remove-overlays) (setq org-agenda-archives-mode nil) 
(delete-frame)) (and (not ...) (not ...) (delete-window)) (kill-buffer 
buf) (org-agenda-reset-markers) (org-columns-remove-overlays) (setq 
org-agenda-archives-mode nil))
  (let ((buf ...)) (if (eq org-agenda-window-setup ...) (progn ... ... 
... ... ...) (and ... ... ...) (kill-buffer buf) 
(org-agenda-reset-markers) (org-columns-remove-overlays) (setq 
org-agenda-archives-mode nil)))
  (if org-agenda-columns-active (org-columns-quit) (let (...) (if ... 
... ... ... ... ... ...)) (and org-agenda-restore-windows-after-quit 
(not ...) org-pre-agenda-window-conf (set-window-configuration 
org-pre-agenda-window-conf)))

  org-agenda-quit()
  call-interactively(org-agenda-quit nil nil)

 /Backtrace --8<---

--
~
sym.net  ||  butz & siefer gbr  ||  50670 koeln  ||  hansaring 78
phone +49(0)221/3762591 -  twitter.com/symnet  - mail b...@sym.net
~~ www.sym.net | www.moodalis.de 

Re: [O] plus in superscript.

[Christian Moe]

On 9/15/11 9:44 AM, Carsten Dominik wrote:


When Org exports to HTML for use with MathJax, it does convert $..$ to \(..\) 
to work around this.


Oops, I should have guessed. I just remembered having to fiddle with 
my MathJax configuration at one point, but that was probably before 
Org even switched from dvipng to MathJax as default.



Still, parsing $...$ is much harder than parsing \(..\), so most of the time, 
using \(//\) will give better and more stable results with Org-mode.


And a good deal more readable.

Christian

Re: [O] plus in superscript.

[Carsten Dominik]

On Sep 15, 2011, at 9:43 AM, Christian Moe wrote:

> Hi,
> 
> $...$ may sometimes get confused with currency signs, variable names and 
> whatnot.
> 
> Org-mode is sophisticated about it as long as you follow a few safeguards -- 
> from the Info section 11.7.3:
> 
> To avoid conflicts
> with currency specifications, single `$' characters are only
> recognized as math delimiters if the enclosed text contains at
> most two line breaks, is directly attached to the `$' characters
> with no whitespace in between, and if the closing `$' is followed
> by whitespace, punctuation or a dash.  For the other delimiters,
> there is no such restriction, so when in doubt, use `\(...\)' as
> inline math delimiters.
> 
> But note that MathJax, the preferred backend for math in Org's HTML exports, 
> does not support $...$ by default. To configure it, see:
> 
> http://www.mathjax.org/docs/1.1/tex.html#tex-and-latex-math-delimiters


When Org exports to HTML for use with MathJax, it does convert $..$ to \(..\) 
to work around this.

Still, parsing $...$ is much harder than parsing \(..\), so most of the time, 
using \(//\) will give better and more stable results with Org-mode.

- Carsten

Re: [O] plus in superscript.

[Christian Moe]

Hi,

$...$ may sometimes get confused with currency signs, variable names 
and whatnot.


Org-mode is sophisticated about it as long as you follow a few 
safeguards -- from the Info section 11.7.3:


 To avoid conflicts
 with currency specifications, single `$' characters are only
 recognized as math delimiters if the enclosed text contains at
 most two line breaks, is directly attached to the `$' characters
 with no whitespace in between, and if the closing `$' is followed
 by whitespace, punctuation or a dash.  For the other delimiters,
 there is no such restriction, so when in doubt, use `\(...\)' as
 inline math delimiters.

But note that MathJax, the preferred backend for math in Org's HTML 
exports, does not support $...$ by default. To configure it, see:


http://www.mathjax.org/docs/1.1/tex.html#tex-and-latex-math-delimiters

Yours,

Christian

On 9/15/11 9:19 AM, Nick Dokos wrote:

suvayu ali  wrote:


Hi Nick,

On Wed, Sep 14, 2011 at 6:55 PM, Nick Dokos  wrote:

* This is a test: \(T^{+}\)


Apart from what Christian said, do you have any comments about $..$
and \(..\) ? I hear conflicting arguments about which is preferred
(e.g. $..$ is a TeX construct where as \(..\) is a LaTeX macro arguing
in favour of $..$). Specially an opinion in the context of org ->
latex export would be interesting to hear.



As far as LaTeX is concerned, I believe that $...$ and \(...\) are
entirely equivalent (but you have to use \[...\], and not $$...$$ for
displayed material). That's from reading Lamport's book: sec 3.3 and
Appendix E (the "Miscellaneous" section); I have not checked the code.

I prefer \(...\) and (iirc) sometimes that has worked when $...$ has
not, but I don't remember the context; afaik those (rare) situations
were deemed to be bugs in the exporter and have all been fixed.

Nick

Re: [O] plus in superscript.

[Nick Dokos]

suvayu ali  wrote:

> Hi Nick,
> 
> On Wed, Sep 14, 2011 at 6:55 PM, Nick Dokos  wrote:
> > * This is a test: \(T^{+}\)
> 
> Apart from what Christian said, do you have any comments about $..$
> and \(..\) ? I hear conflicting arguments about which is preferred
> (e.g. $..$ is a TeX construct where as \(..\) is a LaTeX macro arguing
> in favour of $..$). Specially an opinion in the context of org ->
> latex export would be interesting to hear.
> 

As far as LaTeX is concerned, I believe that $...$ and \(...\) are
entirely equivalent (but you have to use \[...\], and not $$...$$ for
displayed material). That's from reading Lamport's book: sec 3.3 and
Appendix E (the "Miscellaneous" section); I have not checked the code.

I prefer \(...\) and (iirc) sometimes that has worked when $...$ has
not, but I don't remember the context; afaik those (rare) situations
were deemed to be bugs in the exporter and have all been fixed.

Nick