Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
Greg Minshall writes:
[snipped]
"Proper list" in the context of this discussion and pertaining
to R
would be a =list()=, not a vector which is what is usually
returned by
=c()=. A =data.frame()= is a special case of a =list()= where
every
column has to have the same length.
well, it's a language mapping problem. what one considers a
"list" in
org-mode is
- well
- something like
- this
- maybe with
- this
whereas in e-lisp, '("well" "something like" '("this" '("maybe
with"
"this"))).
Absolutely, I just wanted to clarify that there is no confusion as
to what an R list is in the context of R itself (as far as I can
tell). Your post made it sound like there is.
[snipped]
--
Johan Tolö
Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
Greg Minshall writes: list(1,2,3) [[1]] [1] 1 [[2]] [1] 2 [[3]] [1] 3 c(1,2,3) [1] 1 2 3 (where =c= is the "concatenation operator".) so, to me, at least, "proper list" is not a well-defined term in R. cheers, Greg =c= is "a generic function which combines its arguments" according to the R documentation. It could do different things depending on the input. =list()= will create an actual R list which are "Generic Vectors" according to the R documentation. Each element of a list can be any other R data structure including other lists, expressions and symbols. "Proper list" in the context of this discussion and pertaining to R would be a =list()=, not a vector which is what is usually returned by =c()=. A =data.frame()= is a special case of a =list()= where every column has to have the same length. Johan -- Johan Tolö
Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
Ihor Radchenko writes: Greg Minshall writes: [snipped] The time span is years and I do not recall any related bug reports. So, nobody seems to care. I do pass org plain lists to R source code blocks which is why I found the current issue. It is easy enough for me to adapt my R code whenever there is a change in the way it is handled. It is unfortunate that it will no longer be possible to access any nested elements of plain lists but it does not affect me because I was not using that feature. I think that the output from R source code blocks should be as close to the example in the org manual as possible. I also think that the handling within ob-R.el should be as simple as possible. I do not mind if that means that I have to convert a data.frame from columns to rows. For anyone wondering, you can simply unlist() a data.frame to get a vector of the columns. Johan -- Johan Tolö
Re: [BUG] (org-babel-result-to-file) adds the relative path even if attachment link is generated [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
Johan Tolö writes: [snipped] * Test :PROPERTIES: :DIR: build :END: #+begin_src R :results output file graphics :file build/test.png plot(1) #+end_src #+RESULTS: [[attachment:build/test.png]] The expected result is: #+RESULTS: [[attachment:test.png]] My ob-core.el has in the org-babel-result-to-file function (on line 2712): (file-relative-name result-file-name) I changed it to: (file-relative-name result-file-name attach-dir) and got the expected result. [snipped] Adding a elisp example that produces the same unwanted behaviour: * Test :PROPERTIES: :DIR: build :END: #+begin_src emacs-lisp :results value file "build/test.png" #+end_src #+RESULTS: [[attachment:build/test.png]] -- Johan Tolö
Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
Greg Minshall writes: i see this same behavior. to me, (org-babel-R-assign-elisp) seems to be the problem, but it hasn't changed any time recently. (nor, if my =git blame= is done correctly, has anything else in ob-R.el.) [snipped] Yeah, the problem is not a change to ob-R.el but the recent change to ob-core.el (see the message of the commit I referenced). But the change to ob-core.el is final if I understand it correctly which means that ob-R.el has to be updated. Sorry if I was unclear in my description. Named plain lists were previously turned into data.frames with each first level item in one row. Second level items were in the second column I believe. After the change to ob-core.el they are still data.frames but first level items form columns instead of rows. Second (or deeper) level items are dropped as they should be after the change to ob-core.el (according to the commit message). -- Johan Tolö
[BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
After the changes to ob-core.el introduced in commit: b4e437f968771df9555f9306467846965857f632 plain lists passed to R source code blocks are generated with extra (empty) items. Example: #+name: alist - first item - second item - third item #+begin_src R :var list=alist list #+end_src #+RESULTS: | first item | second item | third item | | | | | | | | Expected result would be: #+RESULTS: | first item | second item | third item | as generated by: #+begin_src elisp :var list=alist list #+end_src #+RESULTS: | first item | second item | third item | Emacs : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.35, cairo version 1.17.6) of 2022-12-01 Package: Org mode version 9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/) -- Johan Tolö
Re: Adding #+name to result block in babel
Henrik Frisk writes: [snipped] Then you can use the result like this: #+begin_src sh :var value=my_result echo $value #+end_src #+RESULTS: : hello This does not use the result but rather reevaluates the "my_result" code block. Thank you! That was good to be reminded of, but I should have been more explicit in my first email. I'm working with a language (sclang) that for various reasons does not have support for variables in this way. The only option I have to include the results from one block is by using a noweb referens: #+begin_src shell echo "Hello" #+end_src #+RESULTS: #+name: my_result : Hello #+begin_src sclang :noweb yes <> #+end_src You could try adapting the examples for using :post at the end of: https://orgmode.org/manual/Results-of-Evaluation.html But in my (limited) experience it is difficult to get the output right. Another suggestion is to use a templating system for generating the src block and include the #+name: part in the template. I use yasnippet for this. -- Johan Tolö
[BUG] (org-babel-result-to-file) adds the relative path even if attachment link is generated [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]
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 https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. With org 9.6 I am having an issue where the following generates a result with an attachment link that includes the original path to the file. I expect the link to be relative to the attachment directory. * Test :PROPERTIES: :DIR: build :END: #+begin_src R :results output file graphics :file build/test.png plot(1) #+end_src #+RESULTS: [[attachment:build/test.png]] The expected result is: #+RESULTS: [[attachment:test.png]] My ob-core.el has in the org-babel-result-to-file function (on line 2712): (file-relative-name result-file-name) I changed it to: (file-relative-name result-file-name attach-dir) and got the expected result. Johan Emacs : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.35, cairo version 1.17.6) of 2022-12-01 Package: Org mode version 9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/) -- Johan
Re: org-attach-use-inheritance inherits from sibling
Ihor Radchenko writes: I cannot reproduce on current main. Are you still seeing this problem? Yes I believe I am. Also, it does not seem to be an org-attach issue but rather an issue with how org gets properties with inheritance. If "* Top heading" is the first heading in the buffer with nothing above it, not even a whitespace/newline, then '(org-entry-get nil "id" t)' with point in "* Second heading" will return the id of "Top heading". If there is anything before "Top heading" then 'nil' will be returned. This happens when I run 'emacs -Q' from within the "lisp" directory of a newly cloned "org-mode" main branch. This example illustrates the problem: beginning of buffer * Top heading :PROPERTIES: :ID: acf18561-7a84-4703-96c6-1aceccd46b33 :END: * Second heading #+begin_src emacs-lisp (load "org.el") (load "org-id.el") (org-entry-get nil "id" t) #+end_src #+RESULTS: : acf18561-7a84-4703-96c6-1aceccd46b33 end of buffer -- Johan Tolö
org-attach-use-inheritance inherits from sibling
Hi, I have set 'org-attach-use-inheritance' to t. If a heading has no parents it seems to inherit from the first heading in the file which has either the ID or DIR property set, ie from the first sibling above it. I'm guessing this is not the expected behaviour? Johan -- Johan
Allow to set :follow link parameter for "file" links
Hi all, For some time I have been using the suggestion by John Kitchin at: https://kitchingroup.cheme.cmu.edu/blog/2016/11/04/New-link-features-in-org-9/#orgc074278 to "improve" the file link. Since upgrading org mode it no longer works. I believe it was caused by the changes introduced with commit: afd3b04ec Perhaps there is a better way to do this now? Kind regards, Johan -- Johan Tolö, PhD Department of Physiology/Metabolic Physiology Institute of Neuroscience and Physiology The Sahlgrenska Academy at Gothenburg University Visiting address: Medicinaregatan 11 Postal address: Box 432 SE-405 30 Göteborg Sweden Email: johan.t...@gu.se Phone office: +46(0)317863349 Phone lab: +46(0)317863434
Re: Why is `org-element-affiliated-keywords' a var when `org-element--affiliated-re' is a const?
Nicolas Goaziou writes: snip Syntax is not meant to be changed by users. Also, `org-element-affiliated-keywords' is a defconst. Oh, yes you are of course right. Somehow I got the definition mixed up, must have been looking at the definition in 'org-pcomplete.el' or something. Sorry about that. You might abuse #+header: affiliated keyword to add a reference. OK, thanks. I will give it a try. -- Johan
Why is `org-element-affiliated-keywords' a var when `org-element--affiliated-re' is a const?
Dear all, I want to add my own org-element affiliated keyword "REF" in order to provide a reference to some other part of an org mode document (or another document) for a link. For example: #+NAME: a-figure #+REF: [[file:another_document.org]] [[file:a-figure.png]] I want to use `org-element-context' to get the link element and use `org-element-property' to get the `REF' property. I tried changing `org-element-affiliated-keywords' in order to define my own keyword. This is never picked up by `org-element-context' since it uses `org-element--affiliated-re' which is defined as a const and thus is never updated to reflect the change to `org-element-affiliated-keywords'. The help text for `org-element--affiliated-re' even mentions changing `org-element-affiliated-keywords'. Is this an oversight or am I trying to use this is a way that is not intended? Johan -- Johan
