Re: [O] [ANN] Changes to link syntax
Nicolas Goaziou writes: > Hello, > > I finally pushed changed about escape syntax in bracket links. Here is > the excerpt from ORG-NEWS: > > Org used to percent-encode sensitive characters in the URI part of the > bracket links. > > Now, escaping mechanism uses the usual backslash character, according > to the following rules, applied in order: > > 1. All consecutive =\= characters at the end of the link must be >escaped; > 2. Any =]= character at the very end of the link must be escaped; > 3. Any =]= character followed by either =[= or =]= must be escaped; > 4. Other =]= and =\= characters need not be escaped. > > When in doubt, use the function ~org-link-escape~ in order to turn > a link string into its properly escaped form. > > The old ~org-link-escape~ and ~org-link-unescape~ functions have > been renamed into ~org-link-encode~ and ~org-link-decode~. > > I added a checker in "org-lint.el" to detect old percent-encoding escape > syntax in links. > > Internally, I also moved all link related code from "org.el" to "ol.el", > and renamed libraries defining a new link type with "ol-" prefix. (e.g. > "org-bbdb.el" to "ol-bbdb.el"), much like "ox-" prefix. > > Feedback is welcome. > > Regards, Hi, @Nicolas, will you release a method to update all existing Org file links? (Sorry for second time asking this, you have not mentioned it, so I asked again, it's important for me, or people who want to upgrade to new link syntax). I don't know which special escaped characters need to be converted. If someone already has command to do this. Can you share it? I'm still using a separate local branch which before this commit, so all my Org file links still can work temporarily. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] [PATCH 2/2] test-ob-emacs-lisp: Test :lexical src block header argument
Sebastian Miele writes: > After some initial tooth-grinding, My intent is not to be negative. I do understand that writing tests takes time. However, from experience, having to fix a regression when your only indication comes from a test you do not fully understand is a pain. To see what I mean, have a look at tests in "test-ob-header-arg-defaults.el" and imagine one of them fails… > I did rewrite them, and actually like > the result more than the previous version. Thank you for the suggestion! > > Here is the updated patch: Thank you. I applied it.
[O] Timestamps: overnight repeater possible?
Hi subscribers, can multiday timestamp ranges be made repeatable? Case in point: I'd like to create the timestamp(s) for an "after-hour" time span ranging from 18:00 in the evening til the following morning 10:00, repeated every day. I tried these: * Overnighter (listed for 2000-01-03 and -04 only) <2000-01-03 Mo 18:00>--<2000-01-04 Di 10:00> * Overnighter (has cookie, but doesn't repeat beyond -04) <2000-01-03 Mo 18:00 +1d>--<2000-01-04 Di 10:00 +1d> * 6 o'clock Repeater (repeats, but is overnight only notionally) <2000-01-03 Mo 18:00-10:00 +1d> Agenda week view looks like this (when opening the last timestamp): Week-agenda (W01): Montag 3 Januar 2000 W01 manual: 18:00.. (1/2): Overnighter (listed for 2000-01-03 and -04 only) manual: 18:00.. (1/2): Overnighter (has cookie, but doesn't repeat beyond -04) manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only notionally) Dienstag4 Januar 2000 manual: 10:00.. (2/2): Overnighter (listed for 2000-01-03 and -04 only) manual: 10:00.. (2/2): Overnighter (has cookie, but doesn't repeat beyond -04) manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only notionally) Mittwoch5 Januar 2000 manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only notionally) Donnerstag 6 Januar 2000 manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only notionally) Freitag 7 Januar 2000 manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only notionally) Samstag 8 Januar 2000 manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only notionally) Sonntag 9 Januar 2000 manual: 18:00-10:00 6 o'clock Repeater (repeats, but is overnight only notionally) I'd like the "Overnighter" to be listed for every day. Thanks for any suggestions! Thomas
Re: [O] [PATCH 2/2] test-ob-emacs-lisp: Test :lexical src block header argument
Nicolas Goaziou writes: > [...] > > > However, your tests are very convoluted. It is better than no test, but > if, unfortunately, one of them fail in some distant future, it may take > more time understanding what happens in the test than actually fixing > the bug. > > Would you mind rewriting them with simple macros like, e.g., > `org-test-with-temp-text', and use as little helper functions as > possible? IMO, code repetition in tests is not a problem. > After some initial tooth-grinding, I did rewrite them, and actually like the result more than the previous version. Thank you for the suggestion! Here is the updated patch: * testing/lisp/test-ob-emacs-lisp.el (ob-emacs-lisp/dynamic-lexical-execute, ob-emacs-lisp/dynamic-lexical-edit): Add tests that check the correct handling of the :lexical header argument when executing source blocks and when creating editing buffers for source blocks. --- testing/lisp/test-ob-emacs-lisp.el | 89 ++ 1 file changed, 89 insertions(+) diff --git a/testing/lisp/test-ob-emacs-lisp.el b/testing/lisp/test-ob-emacs-lisp.el index 078cad988..24a373f86 100644 --- a/testing/lisp/test-ob-emacs-lisp.el +++ b/testing/lisp/test-ob-emacs-lisp.el @@ -76,6 +76,95 @@ (buffer-substring-no-properties (line-beginning-position 2) (line-end-position 2)) +(ert-deftest ob-emacs-lisp/dynamic-lexical-execute () + (cl-flet ((execute (text) + (org-test-with-temp-text-in-file text + (org-babel-next-src-block) + (org-babel-execute-maybe) + (re-search-forward "results" nil t) + (re-search-forward ": " nil t) + (buffer-substring-no-properties (point) (point-at-eol) + +(should (string= "dynamic" (execute " +#+begin_src emacs-lisp :lexical no :results verbatim +(let ((x 'dynamic)) (funcall (let ((x 'lexical)) (lambda () x +#+end_src"))) + +(should (string= "lexical" (execute " +#+begin_src emacs-lisp :lexical yes :results verbatim +(let ((x 'dynamic)) (funcall (let ((x 'lexical)) (lambda () x +#+end_src"))) + +(should (string= "dynamic" (let ((x 'dynamic)) (execute " +#+begin_src emacs-lisp :lexical no :results verbatim +x +#+end_src" + +(should (string= "lexical" (let ((x 'dynamic)) (execute " +#+begin_src emacs-lisp :lexical '((x . lexical)) :results verbatim +x +#+end_src" + +;; Src block execution uses `eval'. As of 2019-02-26, `eval' does +;; not dynamically bind `lexical-binding' to the value of its +;; LEXICAL parameter. Hence, (eval 'lexical-binding LEXICAL) +;; evaluates to the same value that just `lexical-binding' +;; evaluates to, even if LEXICAL is different. So tests like the +;; following do not work here: +;; +;; (should (string= "t" (execute " +;; #+begin_src emacs-lisp :lexical yes :results verbatim +;; lexical-binding +;; #+end_src"))) +;; +;; However, the corresponding test in +;; `ob-emacs-lisp/dynamic-lexical-edit' does work. +)) + +(ert-deftest ob-emacs-lisp/dynamic-lexical-edit () + (cl-flet ((execute (text) + (org-test-with-temp-text-in-file text + (org-babel-next-src-block) + (org-edit-src-code) + (goto-char (point-max)) + (prog1 (eval-last-sexp 0) + (org-edit-src-exit) + +(should (eq 'dynamic (execute " +#+begin_src emacs-lisp :lexical no :results verbatim +(let ((x 'dynamic)) (funcall (let ((x 'lexical)) (lambda () x +#+end_src"))) + +(should (eq 'lexical (execute " +#+begin_src emacs-lisp :lexical yes :results verbatim +(let ((x 'dynamic)) (funcall (let ((x 'lexical)) (lambda () x +#+end_src"))) + +(should (eq 'dynamic (let ((x 'dynamic)) (execute " +#+begin_src emacs-lisp :lexical no :results verbatim +x +#+end_src" + +(should (eq 'lexical (let ((x 'dynamic)) (execute " +#+begin_src emacs-lisp :lexical '((x . lexical)) :results verbatim +x +#+end_src" + +(should (equal nil (execute " +#+begin_src emacs-lisp :lexical no :results verbatim +lexical-binding +#+end_src"))) + +(should (equal t (execute " +#+begin_src emacs-lisp :lexical yes :results verbatim +lexical-binding +#+end_src"))) + +(should (equal '((x . 0)) (execute " +#+begin_src emacs-lisp :lexical '((x . 0)) :results verbatim +lexical-binding +#+end_src") + (provide 'test-ob-emacs-lisp) ;;; test-ob-emacs-lisp.el ends here -- 2.21.0
Re: [O] org-clock-rounding-minutes -- non-zero value can cause double clocking
Hello, Raymond Zeitler writes: > There is a problem when org-clock-rounding-minutes is non-zero, say > N. The problem is that the clockin-time of a task can be N less than > the clockout-time of the previous task at certain times. Thus, clock > reports can show an extra N minutes total time for each occurrence of > this effect. > Consider this. > Set org-clock-rounding-minutes to 6. (This allows for tracking time in 0.1 > hour increments.) > Create an org file with two tasks: > * Tasks** TODO Foo** TODO Bar > > Clock into Task Foo at, say, 12:54 plus or minus 2 minutes. Its LOGBOOK will > show the expected 12:54 timestamp. > Clock into Bar at 12:57, which is halfway between 0.90th hour and 1.00th hour. > Result, the clockout time for Foo is rounded up. But the clockin time for > Bar is rounded *down*. Thus, two tasks have started at the same time. > * Tasks** TODO Foo :LOGBOOK: CLOCK: [2019-03-08 Fri 12:54]--[2019-03-08 > Fri 13:00] => 0:06 :END:** TODO Bar :LOGBOOK: CLOCK: [2019-03-08 Fri > 12:54] :END: > So when I use org-mode to track time for my weekly timesheet, it will report > that my total clocked time for any given day is several minutes more than the > time I've been at work! > I expect that the clockin time of Bar will be the same as the clockout time > of Foo. > Is there another variable I need to set in order to enforce > clockin-time=clockout-time? What about `org-clock-continuously'? Regards, -- Nicolas Goaziou
Re: [O] org-lint reports non-existent file for html links
Hello, Dominik Schrempf writes: > I have the following in-buffer variable set: > > #+SETUPFILE: https://path/to/some/setupfile.setup > > Org lint reports > > 17 low Non-existent setup file "https://path/to/some/seutpfile.setup > > This is true, but also not very relevant. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] org-sbe: error when passing strings as parameters to/from Python blocks
* Karl Voit wrote: > > * Daniel Herzig wrote: >> Karl Voit writes: >> >> After some trying I found that the variables as set in the source-code >> header need standard values set: >> >> #+NAME: classificationfm >> #+BEGIN_SRC python :var prob="high" :var impact="high" >> if prob == "high" and impact == "high": >> return "A" >> if prob == "low" and impact == "high": >> return "B" >> if prob == "high" and impact == "low": >> return "C" >> if prob == "low" and impact == "low": >> return "D" >> #+END_SRC >> >> If I don't set them I get exactly the same errors as you. Like this I >> get the following: >> >>| prob | impact | class | >>|--++---| >>| high | high | A | >>| low | high | B | >>| high | low| C | >>| low | low| D | >> #+TBLFM: @2$3..@>$3='(org-sbe classificationfm (prob $$1) (impact $$2)) >> >> Evaluation is being asked for each line then. > > Thanks for the workaround to circumvent the bug. Now, it's working > with my older Org as well. > > Is somebody fixing the bug in Org as well? (Or adding a statement to > the manual?) On reddit[1] loskutak-the-ptak pointed out that the manual states that the default value is not optional: [2] So it is not a bug and it was my own fault from the start. Default values might be omitted for non-string parameters but it is not backed by the documentation. [1] https://www.reddit.com/r/orgmode/comments/b0ll1v/embedding_python_code_in_table_formula/ [2] https://orgmode.org/manual/var.html -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [O] [PATCH 2/2] test-ob-emacs-lisp: Test :lexical src block header argument
Hello, Sebastian Miele writes: > * testing/lisp/test-ob-emacs-lisp.el > (test-ob-emacs-lisp-dynamic-lexical-text, > test-ob-emacs-lisp-dynamic-lexical-expr, > ob-emacs-lisp/dynamic-lexical-execute, > ob-emacs-lisp/dynamic-lexical-edit): Add tests that check the > correct handling of the :lexical header argument when executing > source blocks and when creating editing buffers for source blocks. Thank you. However, your tests are very convoluted. It is better than no test, but if, unfortunately, one of them fail in some distant future, it may take more time understanding what happens in the test than actually fixing the bug. Would you mind rewriting them with simple macros like, e.g., `org-test-with-temp-text', and use as little helper functions as possible? IMO, code repetition in tests is not a problem. Regards, -- Nicolas Goaziou
Re: [O] [PATCH 1/2] ob-emacs-lisp: Set `lexical-binding' in edit buffers
Hello, Sebastian Miele writes: > * lisp/ob-emacs-lisp.el (org-babel-execute:emacs-lisp, > org-babel-emacs-lisp-lexical): Factor out the conversion of the > :lexical source block argument to a form that is appropriate for > `lexical-binding' and the LEXICAL argument to `eval'. > > * lisp/ob-emacs-lisp.el (org-babel-edit-prep:emacs-lisp): Set > `lexical-binding'. > > * lisp/ob-emacs-lisp.el (org-babel-default-header-args:emacs-lisp): > Update docstring. > > * etc/ORG-NEWS: Create entry about this under Miscellaneous. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [bug] org-sbe: error when passing strings as parameters to/from Python blocks
Hi Daniel, * Daniel Herzig wrote: > Karl Voit writes: > > After some trying I found that the variables as set in the source-code > header need standard values set: > > #+NAME: classificationfm > #+BEGIN_SRC python :var prob="high" :var impact="high" > if prob == "high" and impact == "high": > return "A" > if prob == "low" and impact == "high": > return "B" > if prob == "high" and impact == "low": > return "C" > if prob == "low" and impact == "low": > return "D" > #+END_SRC > > If I don't set them I get exactly the same errors as you. Like this I > get the following: > >| prob | impact | class | >|--++---| >| high | high | A | >| low | high | B | >| high | low| C | >| low | low| D | > #+TBLFM: @2$3..@>$3='(org-sbe classificationfm (prob $$1) (impact $$2)) > > Evaluation is being asked for each line then. Thanks for the workaround to circumvent the bug. Now, it's working with my older Org as well. Is somebody fixing the bug in Org as well? (Or adding a statement to the manual?) -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [O] org-sbe: error when passing strings as parameters to/from Python blocks
Karl Voit writes: > Hi! Hi! > > I want to test/use Python with org-sbe: > > #+NAME: classificationfm > #+BEGIN_SRC python :exports none :var prob :var impact > > result = "" > if prob == 'high' and impact == 'high': > return 'A' > if prob == 'low' and impact == 'high': > return 'B' > if prob == 'high' and impact == 'low': > return 'C' > if prob == 'low' and impact == 'low': > return 'D' > return 'undefined' > #+END_SRC > After some trying I found that the variables as set in the source-code header need standard values set: #+NAME: classificationfm #+BEGIN_SRC python :var prob="high" :var impact="high" if prob == "high" and impact == "high": return "A" if prob == "low" and impact == "high": return "B" if prob == "high" and impact == "low": return "C" if prob == "low" and impact == "low": return "D" #+END_SRC If I don't set them I get exactly the same errors as you. Like this I get the following: | prob | impact | class | |--++---| | high | high | A | | low | high | B | | high | low| C | | low | low| D | #+TBLFM: @2$3..@>$3='(org-sbe classificationfm (prob $$1) (impact $$2)) Evaluation is being asked for each line then. > (Yes, I should move to elif and the Python code might be coded with > less characters in general: this should not be the point here ;-) ) > > | prob | impact | class | > |--++| > | high | high | #ERROR | > | low | high | #ERROR | > | high | low| #ERROR | > | low | low| #ERROR | > > #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob $1) (impact $2)) > > I'd expect to get the values of the "class" table column: A, B, C, D > instead of #ERROR. > > > Reading the manual, I found: > | NOTE: By default, string variable names are interpreted as > | references to source-code blocks, to force interpretation of a > | cell’s value as a string, prefix the identifier a "$" (e.g.,"$$2" > | instead of "$2" or "$@2$2" instead of "@2$2"). > > Therefore, I tried the following lines ... > > #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob "$1") (impact "$2")) > #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob $$1) (impact $$2)) > > #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob "$$1") (impact "$$2")) > ... all with same error in the result. > > > My setup: Org mode version 9.1.6 on GNU Emacs 26.0.90 and GNU Emacs 25.1.1 > > > I started a reddit thread[1]. In this thread, somebody was posting > this table showing the error: > > #+NAME: myfunc > #+BEGIN_SRC python :var n="1" > > return "ok" > #+END_SRC > > | 10.3 | 9 | -18 | a | 14 | 11 | 1 | > | ok | ok | ok | #ERROR | ok | ok | ok | > > #+TBLFM: @2='(org-sbe myfunc (n @1)) > > > However, using the comment from the manual about strings, I > prepended the reference with "$" ... > > | 10.3 | 9 | -18 | a | 14 | 11 | 1 | > | ok | ok | ok | ok | ok | ok | ok | > > #+TBLFM: @2='(org-sbe mytestfunc (n $@1)) > > ... which now looks OK ;-) > > > So, back to the initial situation: what is my error or do we have a > bug in Org? > > > [1] > https://www.reddit.com/r/orgmode/comments/b0ll1v/embedding_python_code_in_table_formula/ I hope this helps, I'm on orgmode 8.2.1 here. Cheers, Daniel
[O] [PATCH 1/2] ob-emacs-lisp: Set `lexical-binding' in edit buffers
* lisp/ob-emacs-lisp.el (org-babel-execute:emacs-lisp,
org-babel-emacs-lisp-lexical): Factor out the conversion of the
:lexical source block argument to a form that is appropriate for
`lexical-binding' and the LEXICAL argument to `eval'.
* lisp/ob-emacs-lisp.el (org-babel-edit-prep:emacs-lisp): Set
`lexical-binding'.
* lisp/ob-emacs-lisp.el (org-babel-default-header-args:emacs-lisp):
Update docstring.
* etc/ORG-NEWS: Create entry about this under Miscellaneous.
---
etc/ORG-NEWS | 6 ++
lisp/ob-emacs-lisp.el | 24
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 039ad4c69..15af28bfd 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -160,6 +160,8 @@ dynamic block in ~org-dynamic-block-alist~.
*** ~org-table-cell-down~
*** ~org-table-cell-left~
*** ~org-table-cell-right~
+*** ~org-babel-emacs-lisp-lexical~
+*** ~org-babel-edit-prep:emacs-lisp~
** Removed functions
*** ~org-babel-set-current-result-hash~
@@ -193,6 +195,10 @@ The ~:mkdirp~ header argument used to only work for
~:tangle~ tangle
files. Now ~:mkdirp~ works for ~:dir~ too. This is more convenient for
specify default directory and with ~:file~ header argument.
+*** ob-emacs-lisp sets ~lexical-binding~ in Org edit buffers
+When editing an Elisp src block, the editing buffer's
+~lexical-binding~ is set according to the src block's =:lexical=
+parameter.
* Version 9.2
** Incompatible changes
*** Removal of OrgStruct mode mode and radio lists
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index cd86f4a20..ab7dac879 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -43,7 +43,8 @@
A value of \"yes\" or t causes source blocks to be eval'd using
lexical scoping. It can also be an alist mapping symbols to
their value. It is used as the optional LEXICAL argument to
-`eval', which see.")
+`eval', which see. And it is used as the value for
+`lexical-binding' in buffers created by `org-edit-src-code'.")
(defun org-babel-expand-body:emacs-lisp (body params)
"Expand BODY according to PARAMS, return the expanded body."
@@ -71,9 +72,7 @@ their value. It is used as the optional LEXICAL argument to
(member "pp" result-params))
(concat "(pp " body ")")
body))
-(if (listp lexical)
-lexical
- (member lexical '("yes" "t"))
+(org-babel-emacs-lisp-lexical lexical
(org-babel-result-cond result-params
(let ((print-level nil)
(print-length nil))
@@ -88,6 +87,23 @@ their value. It is used as the optional LEXICAL argument to
(org-babel-pick-name (cdr (assq :rowname-names params))
(cdr (assq :rownames params
+(defun org-babel-emacs-lisp-lexical (lexical)
+ "Interpret :lexical source block argument.
+Convert LEXICAL into the form appropriate for `lexical-binding'
+and the LEXICAL argument to `eval'."
+ (if (listp lexical)
+ lexical
+(not (null (member lexical '("yes" "t"))
+
+(defun org-babel-edit-prep:emacs-lisp (info)
+ "Set `lexical-binding' in Org edit buffer.
+Set `lexical-binding' in Org edit buffer according to the
+corresponding :lexical source block argument."
+ (setq lexical-binding
+(org-babel-emacs-lisp-lexical
+ (org-babel-read
+ (cdr (assq :lexical (nth 2 info)))
+
(org-babel-make-language-alias "elisp" "emacs-lisp")
(provide 'ob-emacs-lisp)
--
2.21.0
[O] [PATCH 2/2] test-ob-emacs-lisp: Test :lexical src block header argument
* testing/lisp/test-ob-emacs-lisp.el (test-ob-emacs-lisp-dynamic-lexical-text, test-ob-emacs-lisp-dynamic-lexical-expr, ob-emacs-lisp/dynamic-lexical-execute, ob-emacs-lisp/dynamic-lexical-edit): Add tests that check the correct handling of the :lexical header argument when executing source blocks and when creating editing buffers for source blocks. --- testing/lisp/test-ob-emacs-lisp.el | 86 ++ 1 file changed, 86 insertions(+) diff --git a/testing/lisp/test-ob-emacs-lisp.el b/testing/lisp/test-ob-emacs-lisp.el index 078cad988..a48f0c7dd 100644 --- a/testing/lisp/test-ob-emacs-lisp.el +++ b/testing/lisp/test-ob-emacs-lisp.el @@ -76,6 +76,92 @@ (buffer-substring-no-properties (line-beginning-position 2) (line-end-position 2)) +(defun test-ob-emacs-lisp-dynamic-lexical-text (expr lexical) + (concat "\n" + "#+begin_src emacs-lisp :lexical " lexical " :results verbatim\n" + (format "%S" expr) "\n" + "#+end_src")) + +(defvar test-ob-emacs-lisp-dynamic-lexical-expr + '(let ((x 'dynamic)) + (funcall + (let ((x 'lexical)) + (lambda () x) + +(ert-deftest ob-emacs-lisp/dynamic-lexical-execute () + (cl-flet ((execute (text) + (org-test-with-temp-text-in-file text + (org-babel-next-src-block) + (org-babel-execute-maybe) + (re-search-forward "results" nil t) + (re-search-forward ": " nil t) + (buffer-substring-no-properties (point) (point-at-eol) +;; +(cl-flet ((text (lexical) + (test-ob-emacs-lisp-dynamic-lexical-text +test-ob-emacs-lisp-dynamic-lexical-expr +lexical))) + (should (string= "dynamic" (execute (text "no" + (should (string= "lexical" (execute (text "yes") +;; +(cl-flet ((text (lexical) + (test-ob-emacs-lisp-dynamic-lexical-text +'x +lexical))) + (should (string= "dynamic" (let ((x 'dynamic)) + (execute (text "no") + (should (string= "lexical" (execute (text "'((x . lexical))") +;; +;; Src block execution uses `eval'. `eval' does not dynamically +;; bind `lexical-binding' to the value of its LEXICAL +;; parameter. Hence, (eval 'lexical-binding LEXICAL) evaluates to +;; the same value that just `lexical-binding' evaluates to, no +;; matter what is given as the LEXICAL parameter to eval. So the +;; following does not work as intended: +;; +;;(cl-flet ((text (lexical) +;; (test-ob-emacs-lisp-dynamic-lexical-text +;; 'lexical-binding +;; lexical))) +;; (should (string= "nil" (execute (text "no" +;; (should (string= "t" (execute (text "yes" +;; (should (string= "((x . 0))" (execute (text "'((x . 0))") +)) + +(ert-deftest ob-emacs-lisp/dynamic-lexical-edit () + (cl-flet ((execute (text) + (org-test-with-temp-text-in-file text + (org-babel-next-src-block) + (org-edit-src-code) + (goto-char (point-max)) + (prog1 (eval-last-sexp 0) + (org-edit-src-exit) +;; +(cl-flet ((text (lexical) + (test-ob-emacs-lisp-dynamic-lexical-text +test-ob-emacs-lisp-dynamic-lexical-expr +lexical))) + (should (eq 'dynamic (execute (text "no" + (should (eq 'lexical (execute (text "yes") +;; +(cl-flet ((text (lexical) + (test-ob-emacs-lisp-dynamic-lexical-text +'x +lexical))) + (should (eq 'dynamic (let ((x 'dynamic)) +(execute (text "no") + (should (eq 'lexical (execute (text "'((x . lexical))") +;; +(cl-flet ((text (lexical) + (test-ob-emacs-lisp-dynamic-lexical-text +'lexical-binding +lexical))) + (should (equal nil(execute (text "no" + (should (equal t (execute (text "yes" + (should (equal '((x . 0)) (execute (text "'((x . 0))") +)) + + (provide 'test-ob-emacs-lisp) ;;; test-ob-emacs-lisp.el ends here -- 2.21.0
[O] org-sbe: error when passing strings as parameters to/from Python blocks
Hi! I want to test/use Python with org-sbe: #+NAME: classificationfm #+BEGIN_SRC python :exports none :var prob :var impact result = "" if prob == 'high' and impact == 'high': return 'A' if prob == 'low' and impact == 'high': return 'B' if prob == 'high' and impact == 'low': return 'C' if prob == 'low' and impact == 'low': return 'D' return 'undefined' #+END_SRC (Yes, I should move to elif and the Python code might be coded with less characters in general: this should not be the point here ;-) ) | prob | impact | class | |--++| | high | high | #ERROR | | low | high | #ERROR | | high | low| #ERROR | | low | low| #ERROR | #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob $1) (impact $2)) I'd expect to get the values of the "class" table column: A, B, C, D instead of #ERROR. Reading the manual, I found: | NOTE: By default, string variable names are interpreted as | references to source-code blocks, to force interpretation of a | cell’s value as a string, prefix the identifier a "$" (e.g.,"$$2" | instead of "$2" or "$@2$2" instead of "@2$2"). Therefore, I tried the following lines ... #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob "$1") (impact "$2")) #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob $$1) (impact $$2)) #+TBLFM: @2$3..@>$3='(org-sbe "classificationfm" (prob "$$1") (impact "$$2")) ... all with same error in the result. My setup: Org mode version 9.1.6 on GNU Emacs 26.0.90 and GNU Emacs 25.1.1 I started a reddit thread[1]. In this thread, somebody was posting this table showing the error: #+NAME: myfunc #+BEGIN_SRC python :var n="1" return "ok" #+END_SRC | 10.3 | 9 | -18 | a | 14 | 11 | 1 | | ok | ok | ok | #ERROR | ok | ok | ok | #+TBLFM: @2='(org-sbe myfunc (n @1)) However, using the comment from the manual about strings, I prepended the reference with "$" ... | 10.3 | 9 | -18 | a | 14 | 11 | 1 | | ok | ok | ok | ok | ok | ok | ok | #+TBLFM: @2='(org-sbe mytestfunc (n $@1)) ... which now looks OK ;-) So, back to the initial situation: what is my error or do we have a bug in Org? [1] https://www.reddit.com/r/orgmode/comments/b0ll1v/embedding_python_code_in_table_formula/ -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
[O] excluding lines from the export to latex
Hello, I meet a small problem that org-mode or lisp code could probably solve, but again I need help. Here is my question. In my gnus setup, via selecting identity, I get the following sample: #+BEGIN_SRC emacs-lisp From: Joseph Vidal-Rosset To: Subject: Gcc: nnfolder+archive:sent.2019-03 Organization: Université de Lorraine :noexport: X-Url: http://philo.shs-nancy.univ-lorraine.fr/131/membre/joseph-vidal-rosset --text follows this line-- #+LaTeX_CLASS: smfart-fr #+CSL_STYLE: ~/MEGA/org/bjps.csl [[bibliography:/home/joseph/MEGA/org/reforg.bib]] [[bibliographystyle:apalike]] -- Joseph Vidal-Rosset #+END_SRC Now, I would be happy to export into latex the part that is below "--text follows this line--", excluding from the export into latex what is above this line: i.e. the mention of "From: ... X-Url: " If you see quickly how I can get this result, your help would be welcome. Thanks, -- Jo.
