Problem with org-babel and shell scripts

Problem with org-babel and shell scripts

[John Wiegley]

I have a shell block in my todo.txt which I've been using for generating some
reports for about a year.  I just tried C-c C-c in that shell block today, and
got the following:

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (void-variable org-current-export-file)
  org-babel-confirm-evaluate(("sh" "..." ((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . "no") (:tangle . "no") (:exports . "code") (:results . "replace") (:session . "none") (:hlines . "no") (:padnewline . "yes") (:result-type . value) (:result-params "replace") (:rowname-names) (:colname-names)) "" nil 0))
  org-babel-execute-src-block(nil ("sh" "..." ((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . "no") (:tangle . "no") (:exports . "code") (:results . "replace") (:session . "none") (:hlines . "no") (:padnewline . "yes") (:result-type . value) (:result-params "replace") (:rowname-names) (:colname-names)) "" nil 0))
  org-babel-execute-src-block-maybe()
  org-babel-execute-maybe()
  org-babel-execute-safely-maybe()
  run-hook-with-args-until-success(org-babel-execute-safely-maybe)
  org-ctrl-c-ctrl-c(nil)
  call-interactively(org-ctrl-c-ctrl-c nil nil)
--8<---------------cut here---------------end--------------->8---

I guess something changed recently?

John

Re: Problem with org-babel and shell scripts

[Nick Dokos]

John Wiegley <johnw@newartisans.com> wrote:

> I have a shell block in my todo.txt which I've been using for generating some
> reports for about a year.  I just tried C-c C-c in that shell block today, and
> got the following:
> 
> Debugger entered--Lisp error: (void-variable org-current-export-file)
>   org-babel-confirm-evaluate(("sh" "..." ((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . "no") (:tangle . "no") (:exports . "code") (:results . "replace") (:session . "none") (:hlines . "no") (:padnewline . "yes") (:result-type . value) (:result-params "replace") (:rowname-names) (:colname-names)) "" nil 0))
>   org-babel-execute-src-block(nil ("sh" "..." ((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . "no") (:tangle . "no") (:exports . "code") (:results . "replace") (:session . "none") (:hlines . "no") (:padnewline . "yes") (:result-type . value) (:result-params "replace") (:rowname-names) (:colname-names)) "" nil 0))
>   org-babel-execute-src-block-maybe()
>   org-babel-execute-maybe()
>   org-babel-execute-safely-maybe()
>   run-hook-with-args-until-success(org-babel-execute-safely-maybe)
>   org-ctrl-c-ctrl-c(nil)
>   call-interactively(org-ctrl-c-ctrl-c nil nil)
> 
> I guess something changed recently?
> 

The most recent change I can find in that area is

e56e2c87 lisp/ob.el       (Bastien Guerry 2011-12-12 18:04:15 +0100 275) (defvar org-current-export-file) ; dynamically bound

Not sure if that's enough to explain the error you get. Does

(require 'org-exp)

fix it? or (long shot and rather doubtful) "make autoloads"? 

Nick

Re: Problem with org-babel and shell scripts

[Bastien]

Hi John,

"John Wiegley" <johnw@newartisans.com> writes:

> I have a shell block in my todo.txt which I've been using for generating some
> reports for about a year.  I just tried C-c C-c in that shell block today, and
> got the following:

I've pushed a fix for this.

Thanks,

-- 
 Bastien

Bug in behavior of M-RET with latest Org-mode

[John Wiegley]

In Org I've liked that fact that hitting M-RET in a list of headlines which
have no intervening whitespace, will add a new headline without whitespace.
Example:

    * One
    * Two<cursor>
    * Three

If hit M-RET at the <cursor>, I'll would get:

    * One
    * Two
    * <cursor>
    * Three

With the latest Org, I get:

    * One
    * Two
    * <cursor>

    * Three

Is this just a regression, or has the core behavior been changed to do this?
Is there a new variable I need to tweak to get the old behavior?

Thanks! John

Re: Bug in behavior of M-RET with latest Org-mode

[Nick Dokos]

John Wiegley <johnw@newartisans.com> wrote:

> In Org I've liked that fact that hitting M-RET in a list of headlines which
> have no intervening whitespace, will add a new headline without whitespace.
> Example:
> 
>     * One
>     * Two<cursor>
>     * Three
> 
> If hit M-RET at the <cursor>, I'll would get:
> 
>     * One
>     * Two
>     * <cursor>
>     * Three
> 
> With the latest Org, I get:
> 
>     * One
>     * Two
>     * <cursor>
> 
>     * Three
> 
> Is this just a regression, or has the core behavior been changed to do this?
> Is there a new variable I need to tweak to get the old behavior?
> 

This I think:

,----
| org-blank-before-new-entry is a variable defined in `org.el'.
| Its value is ((heading) (plain-list-item))
| Original value was 
| ((heading . auto)
|  (plain-list-item . auto))
| 
| 
| Documentation:
| Should `org-insert-heading' leave a blank line before new heading/item?
| The value is an alist, with `heading' and `plain-list-item' as CAR,
| and a boolean flag as CDR.  The cdr may also be the symbol `auto', in
| which case Org will look at the surrounding headings/items and try to
| make an intelligent decision whether to insert a blank line or not.
| 
| For plain lists, if the variable `org-empty-line-terminates-plain-lists' is
| set, the setting here is ignored and no empty line is inserted, to avoid
| breaking the list structure.
`----

Given that this was introduced a long time ago however, I'm not sure what
caused the recent change in behavior:

,----
| $ git show 15ad97ac
| commit 15ad97ac3ce0857b92d94cc02d15025fcce05b7d
| Author: Carsten Dominik <carsten.dominik@gmail.com>
| Date:   Thu Jan 8 09:30:55 2009 +0100
| 
|     Editing: Automatic empty lines before new entries.
|     
|     The variable `org-blank-before-new-entry' regulates if Org should
|     insert a blank line before a new entry, when making a new headline or
|     plain list item.  Up to now, the possible values in each case where t
|     or nil, i.e. unconditionally do or don't insert a blank line.
|     
|     Now each setting can also be `auto'.  If this is the case,  Org will
|     look if the current entry, of which the command creates a sibling,
|     does have a blank line before it.  If yes, it will also make a blank
|     line.  If not, it will not.  This seems so useful that I have made
|     this behavior the default.
`----

Nick

Re: Bug in behavior of M-RET with latest Org-mode

[Nick Dokos]

John Wiegley <johnw@newartisans.com> wrote:

> In Org I've liked that fact that hitting M-RET in a list of headlines which
> have no intervening whitespace, will add a new headline without whitespace.
> Example:
> 
>     * One
>     * Two<cursor>
>     * Three
> 
> If hit M-RET at the <cursor>, I'll would get:
> 
>     * One
>     * Two
>     * <cursor>
>     * Three
> 
> With the latest Org, I get:
> 
>     * One
>     * Two
>     * <cursor>
> 
>     * Three
> 
> Is this just a regression, or has the core behavior been changed to do this?
> Is there a new variable I need to tweak to get the old behavior?
> 

Actually, with the default (`auto') setting of the variable I indicated
in my previous email (`org-blank-before-new-entry'), I get the first
behavior, not the second.

The only problem is that when I insert the first headline, it gets
inserted after an empty first line, so adding a second headline fools
the auto setting into thinking I want empty lines between headings. But
if I delete the empty first line, M-RET never puts any empty lines between
headings. So the heuristic might not be perfect, but it seems to work for
all but the first headline.

Nick

Re: Bug in behavior of M-RET with latest Org-mode

[Bastien]

Hi Nick and John,

Nick Dokos <nicholas.dokos@hp.com> writes:

> So the heuristic might not be perfect, but it seems to work for
> all but the first headline.

I fixed this and the heuristic should not insert undue blank lines
anymore.  Thanks for confirming,

-- 
 Bastien