Browse Source

added functional test for deeply nested argument lists

Eric Schulte 16 năm trước cách đây
mục cha
commit
1c0e5f0ade
1 tập tin đã thay đổi với 190 bổ sung190 xóa
  1. 190 190
      org-babel.org

+ 190 - 190
org-babel.org

@@ -2284,6 +2284,194 @@ plot data using 1:2 with lines
 
 
 * Bugs [25/36]
+** TODO allow srcname to omit function call parentheses
+   Someone needs to revisit those regexps. Is there an argument for
+   moving some of the regexps used to match function calls into
+   defvars? (i.e. in o-b.el and o-b-ref.el)
+
+** TODO creeping blank lines
+   There's still inappropriate addition of blank lines in some circumstances. 
+
+   Hmm, it's a bit confusing. It's to do with o-b-remove-result. LoB
+   removes the entire (#+resname and result) and starts from scratch,
+   whereas #+begin_src only removes the result. I haven't worked out
+   what the correct fix is yet. Maybe the right thing to do is to make
+   sure that those functions (o-b-remove-result et al.) are neutral
+   with respect to newlines. Sounds easy, but...
+
+   E.g.
+
+#+begin_src sh
+b=5
+#+end_src
+
+
+
+   Compare the results of
+#+lob: python-add(a=5, b=17)
+
+#+resname: python-add(a=5, b=17)
+: 22
+--------------------------------
+
+#+begin_src python
+23
+#+end_src
+
+#+resname:
+: 23
+---------------------
+** TODO problem with newlines in output when :results value
+#+begin_src python :results value
+'\n'.join(map(str, range(4)))
+#+end_src
+
+#+resname:
+: 0
+
+Whereas I was hoping for
+
+| 0 |
+| 1 |
+| 2 |
+| 3 |
+
+This is some sort of non-printing char / quoting issue I think. Note
+that
+
+#+begin_src python :results value
+'\\n'.join(map(str, range(4)))
+#+end_src
+
+#+resname:
+: 0\n1\n2\n3
+
+Also, note that
+#+begin_src python :results output
+print('\n'.join(map(str, range(4))))
+#+end_src
+
+#+resname:
+: 0
+: 1
+: 2
+: 3
+
+*** collapsing consecutive newlines in string output
+    
+    This is an example of the same bug
+
+#+srcname: multi-line-string-output
+#+begin_src ruby :results output
+"the first line ends here
+
+
+     and this is the second one
+
+even a third"
+#+end_src
+
+This doesn't produce anything at all now. I believe that's because
+I've changed things so that :results output really does *not* get the
+value of the block, only the STDOUT. So if we add a print statement
+this works OK.
+
+#+srcname: multi-line-string-output
+#+begin_src ruby :results output
+print "the first line ends here
+
+
+     and this is the second one
+
+even a third"
+#+end_src
+
+#+resname:
+: the first line ends here
+: 
+: 
+:      and this is the second one
+: 
+: even a third
+
+However, the behaviour with :results value is wrong
+
+#+srcname: multi-line-string-value
+#+begin_src ruby
+"the first line ends here
+
+
+     and this is the second one
+
+even a third"
+#+end_src
+
+#+resname:
+: 0
+
+** TODO prompt characters appearing in output with R
+#+begin_src R :session *R* :results output
+  x <- 6
+  y <- 8
+  3
+#+end_src      
+
+#+resname:
+: > [1] 3
+
+** TODO o-b-execute-subtree overwrites heading when subtree is folded
+*** Example
+    Try M-x org-babel-execute-subtree with the subtree folded and
+    point at the beginning of the heading line.
+#+begin_src sh
+size=5
+#+end_src
+
+** TODO Allow source blocks to be recognised when #+ are not first characters on the line
+   I think Carsten has recently altered the core so that #+ can have
+   preceding whitespace, at least for literal/code examples. org-babel
+   should support this.
+
+** TODO non-orgtbl formatted lists
+for example
+
+#+srcname: this-doesn't-match-orgtbl
+#+begin_src emacs-lisp :results replace
+'((:results . "replace"))
+#+end_src
+
+#+resname: this-doesn't-match-orgtbl
+   
+** PROPOSED external shell execution can't isolate return values
+I have no idea how to do this as of yet.  The result is that when
+shell functions are run w/o a session there is no difference between
+the =output= and =value= result arguments.
+
+Yea, I don't know how to do this either.  I searched extensively on
+how to isolate the *last* output of a series of shell commands (see
+[[* last command for
+ shells][last command for shells]]).  The results of the search were basically
+that it was not possible (or at least not accomplish-able with a
+reasonable amount of effort).
+
+That fact combined with the tenancy to all ways use standard out in
+shell scripts led me to treat these two options (=output= and =value=)
+as identical in shell evaluation.  Not ideal but maybe good enough for
+the moment.
+
+In the `results' branch I've changed this so that they're not quite
+identical: output results in raw stdout contents, whereas value
+converts it to elisp, perhaps to a table if it looks tabular. This is
+the same for the other languages. [Dan]
+
+** TODO are the org-babel-trim s necessary?
+   at the end of e.g. org-babel-R-evaluate, org-babel-python-evaluate, but
+   not org-babel-ruby-evaluate
+** TODO use new merge function [[file:lisp/org-babel-ref.el::t%20nil%20org%20combine%20plists%20args%20nil][here]]?
+   And at other occurrences of org-combine-plists?
+** TODO LoB is not populated on startup
+   org-babel-library-of-babel is nil for me on startup. I have to
+   evaluate the [[file:lisp/org-babel-lob.el::][org-babel-lob-ingest]] line manually.
 ** DONE Fix nested evaluation
    The current parser / evaluator fails with greater levels of nested
    function block calls (example below).
@@ -2560,7 +2748,7 @@ arg
 
 *** DONE deeply nested arguments still fails
 
-#+srcname: level-one-nesting
+#+srcname: deeply-nested-args-bug
 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=one(),b=one()))
 arg
 #+end_src
@@ -2584,195 +2772,6 @@ Need to change the regexp in [[file:lisp/org-babel-ref.el::assign%20any%20argume
 it only matches when the parenthesis are balanced.  Maybe look at
 [[http://www.gnu.org/software/emacs/elisp/html_node/List-Motion.html][this]].
 
-** TODO allow srcname to omit function call parentheses
-   Someone needs to revisit those regexps. Is there an argument for
-   moving some of the regexps used to match function calls into
-   defvars? (i.e. in o-b.el and o-b-ref.el)
-
-** TODO creeping blank lines
-   There's still inappropriate addition of blank lines in some circumstances. 
-
-   Hmm, it's a bit confusing. It's to do with o-b-remove-result. LoB
-   removes the entire (#+resname and result) and starts from scratch,
-   whereas #+begin_src only removes the result. I haven't worked out
-   what the correct fix is yet. Maybe the right thing to do is to make
-   sure that those functions (o-b-remove-result et al.) are neutral
-   with respect to newlines. Sounds easy, but...
-
-   E.g.
-
-#+begin_src sh
-b=5
-#+end_src
-
-
-
-   Compare the results of
-#+lob: python-add(a=5, b=17)
-
-#+resname: python-add(a=5, b=17)
-: 22
---------------------------------
-
-#+begin_src python
-23
-#+end_src
-
-#+resname:
-: 23
----------------------
-** TODO problem with newlines in output when :results value
-#+begin_src python :results value
-'\n'.join(map(str, range(4)))
-#+end_src
-
-#+resname:
-: 0
-
-Whereas I was hoping for
-
-| 0 |
-| 1 |
-| 2 |
-| 3 |
-
-This is some sort of non-printing char / quoting issue I think. Note
-that
-
-#+begin_src python :results value
-'\\n'.join(map(str, range(4)))
-#+end_src
-
-#+resname:
-: 0\n1\n2\n3
-
-Also, note that
-#+begin_src python :results output
-print('\n'.join(map(str, range(4))))
-#+end_src
-
-#+resname:
-: 0
-: 1
-: 2
-: 3
-
-*** collapsing consecutive newlines in string output
-    
-    This is an example of the same bug
-
-#+srcname: multi-line-string-output
-#+begin_src ruby :results output
-"the first line ends here
-
-
-     and this is the second one
-
-even a third"
-#+end_src
-
-This doesn't produce anything at all now. I believe that's because
-I've changed things so that :results output really does *not* get the
-value of the block, only the STDOUT. So if we add a print statement
-this works OK.
-
-#+srcname: multi-line-string-output
-#+begin_src ruby :results output
-print "the first line ends here
-
-
-     and this is the second one
-
-even a third"
-#+end_src
-
-#+resname:
-: the first line ends here
-: 
-: 
-:      and this is the second one
-: 
-: even a third
-
-However, the behaviour with :results value is wrong
-
-#+srcname: multi-line-string-value
-#+begin_src ruby
-"the first line ends here
-
-
-     and this is the second one
-
-even a third"
-#+end_src
-
-#+resname:
-: 0
-
-** TODO prompt characters appearing in output with R
-#+begin_src R :session *R* :results output
-  x <- 6
-  y <- 8
-  3
-#+end_src      
-
-#+resname:
-: > [1] 3
-
-** TODO o-b-execute-subtree overwrites heading when subtree is folded
-*** Example
-    Try M-x org-babel-execute-subtree with the subtree folded and
-    point at the beginning of the heading line.
-#+begin_src sh
-size=5
-#+end_src
-
-** TODO Allow source blocks to be recognised when #+ are not first characters on the line
-   I think Carsten has recently altered the core so that #+ can have
-   preceding whitespace, at least for literal/code examples. org-babel
-   should support this.
-
-** TODO non-orgtbl formatted lists
-for example
-
-#+srcname: this-doesn't-match-orgtbl
-#+begin_src emacs-lisp :results replace
-'((:results . "replace"))
-#+end_src
-
-#+resname: this-doesn't-match-orgtbl
-   
-** PROPOSED external shell execution can't isolate return values
-I have no idea how to do this as of yet.  The result is that when
-shell functions are run w/o a session there is no difference between
-the =output= and =value= result arguments.
-
-Yea, I don't know how to do this either.  I searched extensively on
-how to isolate the *last* output of a series of shell commands (see
-[[* last command for
- shells][last command for shells]]).  The results of the search were basically
-that it was not possible (or at least not accomplish-able with a
-reasonable amount of effort).
-
-That fact combined with the tenancy to all ways use standard out in
-shell scripts led me to treat these two options (=output= and =value=)
-as identical in shell evaluation.  Not ideal but maybe good enough for
-the moment.
-
-In the `results' branch I've changed this so that they're not quite
-identical: output results in raw stdout contents, whereas value
-converts it to elisp, perhaps to a table if it looks tabular. This is
-the same for the other languages. [Dan]
-
-** TODO are the org-babel-trim s necessary?
-   at the end of e.g. org-babel-R-evaluate, org-babel-python-evaluate, but
-   not org-babel-ruby-evaluate
-** TODO use new merge function [[file:lisp/org-babel-ref.el::t%20nil%20org%20combine%20plists%20args%20nil][here]]?
-   And at other occurrences of org-combine-plists?
-** TODO LoB is not populated on startup
-   org-babel-library-of-babel is nil for me on startup. I have to
-   evaluate the [[file:lisp/org-babel-lob.el::][org-babel-lob-ingest]] line manually.
-
 ** DONE avoid stripping whitespace from output when :results output
    This may be partly solved by using o-b-chomp rather than o-b-trim
    in the o-b-LANG-evaluate functions.
@@ -3286,6 +3285,7 @@ of these tests may fail.
 | R number evaluation     | bug-R-number-evaluation    |     |           2 |           2 | pass |
 | multi-line ruby blocks  | multi-line-ruby-test       |     |           2 |           2 | pass |
 | forcing vector results  | test-forced-vector-results |     |       Array |       Array | pass |
+| deeply nested arguments | deeply-nested-args-bug     |     |           8 |           8 | pass |
 |-------------------------+----------------------------+-----+-------------+-------------+------|
 | sessions                |                            |     |             |             | pass |
 |-------------------------+----------------------------+-----+-------------+-------------+------|