BUG: org-todo-keywords-for-agenda is nil in custom agenda view

[Charles Pence]

Hello,

I was requested by the maintainer of org-modern to report this bug upstream. It 
looks like there’s a regression where org-todo-keywords-for-agenda is 
incorrectly set to nil during the display of custom agenda command views. This 
breaks org-modern’s TODO formatting (as well as other things, I assume).

You can find a reasonably minimal config that will reproduce the bug with emacs 
-Q here:

https://github.com/minad/org-modern/discussions/211

I am not a mailing list member, so if you would like more detail please contact 
me off-list. Thanks for your help!

Thanks,
Charles

-- 
Charles H. Pence

Re: SMART goals and bolding the first letter

[Berry, Charles]

Sharon,

> On May 27, 2024, at 8:07 AM, Sharon Kimble  
> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> 
> How can I bold the first letter of a word please? I'm trying to do this -
> 
> 
> - - *S*pecific -  You don’t want a vague goal. 
> 


I think the usual approach is to use a zero width space.

See `Section 17.12 Escape Character` of the org manual.

Here is an example:

Type `*S*` then  `C-x 8  ZERO WIDTH SPACE ` then `port`

On LaTeX export, this renders as 

`\textbf{S}​port`

HTH,

Chuck 
  

Fwd: Bug: Final zero after decimal point is stripped when inline code evaluated

[Charles Millar]

 Forwarded Message 
Subject: Re: Bug: Final zero after decimal point is stripped when inline 
code evaluated

Date: Tue, 7 May 2024 10:25:05 -0400
From: Charles Millar 
To: Max Nikulin 

On 5/7/24 7:49 AM, Max Nikulin wrote:

On 07/05/2024 03:05, Charles Millar wrote:
I appreciate that mathematically a trailing zero or zeros may be 
non-significant; however, in my use case, i.e. correct format in a 
text, they are necessary. Another example, in addition to my Dollars 
and cents scenario, may be a table that that has been created by using 
append, and the table appears as follows because trailing zeros were 
disregarded.


This 1.222
that 3.444
it   5.6
last 7.691

Question arises - is the correct number reported on line "it" 5.600 or 
has some editing omitted the last two decimal places?


I am unsure what do you mean by "using append".


Nor sure myself! What I meant was each number in the second column was a 
result of a :var evaluation that called a table and that there was a 
different table for each number.



 From my point of view there are 2 cases:
- When output format is fixed
   | 2 | 1.41 |
   | 3 | 1.73 |
   #+TBLFM: $2=(sqrt $1);%.2f
- When calculations should be performed with fixed point,
   usual floating point representation gives unexpected results
   src_elisp{(- 0.3 (+ 0.1 0.1 0.1))}
   {{{results(=-5.551115123125783e-17=)}}}

Some programming languages have decimal type for numbers:
https://docs.python.org/3/library/decimal.html

As to finances, I was surprised that ledger, hledger, and beancount have 
different internal representations for amounts and there are various 
issues with rounding.


Org just should avoid unnecessary conversions between strings an 
numbers, but Ihor is right and implementation would require enough efforts.



(setq toconvert 5.000)
(number-to-string toconvert)

evaluates to "5".


I get "5.0" (Linux), so I suspect some mistake.




I am using Debian Testing, full upgrade as of last Saturday.

Re: Bug: Final zero after decimal point is stripped when inline code evaluated

[Charles Millar]

On 5/6/24 12:42 PM, Ihor Radchenko wrote:

Max Nikulin  writes:


On 06/05/2024 19:44, Ihor Radchenko wrote:

Charles Millar writes:

#+NAME: TABLE2
|22578.60|

src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


This is expected. When you assign :var, Org mode reads the table data,
converting it to number.


After discussion of ob-shell related issues I am in doubts if org-babel
should eagerly convert strings to numbers. Perhaps numbers should be
recognized for specific backends only (or vice versa conversion should
be suppressed for specific backends).


Maybe. But changing the current behavior is not trivial - a lot of code
relies upon it implicitly. If anyone wants to work on more
fine-grained control over Org markup -> Elisp conversion, feel free.

Thanks for the feedback. For the moment I will create separate tables 
that have the the desired data in quotes.


I appreciate that mathematically a trailing zero or zeros may be 
non-significant; however, in my use case, i.e. correct format in a text, 
they are necessary. Another example, in addition to my Dollars and cents 
scenario, may be a table that that has been created by using append, and 
the table appears as follows because trailing zeros were disregarded.


This 1.222
that 3.444
it   5.6
last 7.691

Question arises - is the correct number reported on line "it" 5.600 or 
has some editing omitted the last two decimal places?


As an aside, I am not a coder; however I was playing around in the 
scratch butter, and it appears to me that this issue may run deeper that 
Org Mode, for instance:


(number-to-string 5.000)

evaluates to "5.0"

Furthermore, and more closely related to the topic,

(setq toconvert 5.000)
(number-to-string toconvert)

evaluates to "5".

Just my 0.020 cents

Charlie Millar

Re: Bug: Final zero after decimal point is stripped when inline code evaluated

[Charles Millar]

Forgot to include that i also used the numprint package.

On 5/5/24 2:30 PM, Charles Millar wrote:
Please note that in the second src_latex the zero is stripped from the 
results. The final zero is required for my purposes, i.e. dollars and 
cents. This occurs in both results and on export to pdflatex,


Does org's evaluation cause this or does latex? I have attempted to use 
the siunutx and currency packages.as follows,


#+NAME: TABLE2
|22578.60|

src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results scalar 
:results replace :exports 
results]{\num[round-precision=2,round-mode=places,round-pad = 
false]{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
:exports results]{\vUSD{printthis}} {{{results(@@latex:\vUSD{22578.6}@@)}}}

(I also tried \dUSA and \cUSA)

On the other hand this has no problem:

#+NAME: TABLE1
|22578.59 |

src_latex[:var printthis=TABLE1[-1,-1] :eval yes :results replace 
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.59}@@)}}}


The missing zero is important - the result is supposed to be dollars and 
cents.


Org mode version 9.7-pre (release_9.6.27-1391-gba7475 @ 
/usr/local/share/org-mode/lisp/)


GNU Emacs 30.0.50 (build 100, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0) of 2024-04-27

Bug: Final zero after decimal point is stripped when inline code evaluated

[Charles Millar]

Please note that in the second src_latex the zero is stripped from the 
results. The final zero is required for my purposes, i.e. dollars and 
cents. This occurs in both results and on export to pdflatex,


Does org's evaluation cause this or does latex? I have attempted to use 
the siunutx and currency packages.as follows,


#+NAME: TABLE2
|22578.60|

src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results scalar 
:results replace :exports 
results]{\num[round-precision=2,round-mode=places,round-pad = 
false]{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
:exports results]{\vUSD{printthis}} {{{results(@@latex:\vUSD{22578.6}@@)}}}

(I also tried \dUSA and \cUSA)

On the other hand this has no problem:

#+NAME: TABLE1
|22578.59 |

src_latex[:var printthis=TABLE1[-1,-1] :eval yes :results replace 
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.59}@@)}}}


The missing zero is important - the result is supposed to be dollars and 
cents.


Org mode version 9.7-pre (release_9.6.27-1391-gba7475 @ 
/usr/local/share/org-mode/lisp/)


GNU Emacs 30.0.50 (build 100, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0) of 2024-04-27

Re: [BUG] Exporting lists of >100 items to markdown

[Berry, Charles]

Bastien,

> On May 5, 2024, at 9:17 AM, Bastien  wrote:
> 
> Exporting the attached document with a list of >100 items results in a
> misformed markdown list, with missing spaces at the beginning of items.
> 
> Can anyone reproduce this?

Yes. 

With Org mode version 9.6.6 I see that org-md-item hard codes the padding to 
indent the item 4 spaces past the start of the bullet.

Lists of 1000 items will raise an error.

Coincidentally, there was a thread last month about adding spaces *before* the 
bullet in org-md-item, but I think the effect you noted was not mentioned.

Chuck

[BUG] Invalid search bound (wrong side of point) [9.6.25 ( @ /Users/cchoi/.config/emacs/elpa/org-9.6.25/)]

[Charles Choi]

Hi folks -

Got this warning when running Org Agenda, thought I'd report it in.

⛔ Warning (org-element-cache): org-element--cache: Org parser error in 
2024_04_07.org::#. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point(#)
  org-element-cache-map(#f(compiled-function (el) #) :next-re \"]+)>\" :fail-re 
\"]+)>\" :narrow t)
  org-agenda-get-deadlines()
  org-agenda-get-day-entries(\"/Users/cchoi/org/2024_04_07.org\" (4 8 2024) 
:closed :deadline :scheduled :timestamp :sexp)
  apply(org-agenda-get-day-entries \"/Users/cchoi/org/2024_04_07.org\" (4 8 
2024) (:closed :deadline :scheduled :timestamp :sexp))
  org-agenda-list(nil)
  funcall-interactively(org-agenda-list nil)
  call-interactively(org-agenda-list)
  #f(compiled-function () #)()
  funcall(#f(compiled-function () #))
  (let nil (funcall '#f(compiled-function () #)))
  org-agenda-run-series(\"Agenda and all TODOs\" (((agenda \"\") (alltodo 
\"\"
  org-agenda(nil \"n\")
  menu-function-91()
  funcall-interactively(menu-function-91)
  popup-menu((keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ...) 
(down-mouse-3 ...))
  mac-mouse-context-menu((down-mouse-3 (# 765 (788 
. 626) 741232365 nil 765 (87 . 16) nil (788 . 182) (6 . 26
  funcall-interactively(mac-mouse-context-menu (down-mouse-3 (# 765 (788 . 626) 741232365 nil 765 (87 . 16) nil (788 . 182) (6 
. 26
  command-execute(mac-mouse-context-menu)
"
 Please report this to Org mode mailing list (M-x org-submit-bug-report).



-
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.




Emacs  : GNU Emacs 29.3 (build 1, aarch64-apple-darwin23.2.0, Carbon Version 
170 AppKit 2487.3)
 of 2024-04-10
Package: Org mode version 9.6.25 ( @ 
/Users/cchoi/.config/emacs/elpa/org-9.6.25/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-hide-emphasis-markers t
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-export-with-sub-superscripts '{}
 org-log-done 'time
 org-show-notification-handler 'cc/display-notification
 org-babel-after-execute-hook '(org-redisplay-inline-images)
 org-agenda-files '("~/org/")
 org-publish-project-alist '(("pages" :base-directory 
"~/Projects/Captee/Development/Captee/docs/help" :base-extension "org" 
:recursive t :publishing-directory
  
"~/Projects/Captee/Development/Captee/Captee.help/Contents/Resources/en.lproj" 
:publishing-function org-html-publish-to-html)
 ("static" :base-directory 
"~/Projects/Captee/Development/Captee/docs/help" :base-extension
  
"css\\|txt\\|jpg\\|gif\\|png\\|svg\\|helpindex\\|cshelpindex" :recursive t 
:publishing-directory
  
"~/Projects/Captee/Development/Captee/Captee.help/Contents/Resources/en.lproj" 
:publishing-function org-publish-attachment)
 ("captee-help-book" :components ("pages" 
"static")))
 org-capture-templates '(("a" "Appointment" entry (file+function 
cc/--current-org-default-notes-file cc/--find-capture-point-in-current)
  "* %^{description}\n%^T\n:PROPERTIES:\n:CREATED: 
%U\n:END:\n%?" :empty-lines 1 :doct
  (:doct-name "Appointment" :keys "a" :type entry :file 
cc/--current-org-default-notes-file :function cc/--find-capture-point-in-current
   :empty-lines 1 :template ("* %^{description}" "%^T" 
":PROPERTIES:" ":CREATED: %U" ":END:" "%?"))
  )
 ("b" "BeOrg TODO" entry (file 
"~/org/refile-beorg.org") "* TODO %^{description}\nSCHEDULED: 
%^T\n:PROPERTIES:\n:CREATED: %U\n:END:\n%?"
  :empty-lines 1 :doct
  (:doct-name "BeOrg TODO" :keys "b" :type entry :file 
"~/org/refile-beorg.org" :empty-lines 1 :template
   ("* TODO %^{description}" "SCHEDULED: %^T" 
":PROPERTIES:" ":CREATED: %U" ":END:" "%?"))
  )
 ("s" "TODO: Scheduled" entry (file+function 
cc/--current-org-default-notes-file cc/--find-capture-point-in-current)
  "* TODO %^{description} %^G\nSCHEDULED: 
%^T\n:PROPERTIES:\n:CREATED: %U\n:END:\n%?" :empty-lines 1 :doct
  (:doct-name "TODO: Scheduled" :keys "s" :type entry 
:file cc/--current-org-default-notes-file :function
   cc/--find-capture-point-in-current :empty-lines 1 
:template
   ("* TODO %^{description} %^G" "SCHEDULED: %^T" 
":PROPERTIES:" ":CREATED: %U" ":END:" 

Re: Search and replace excluding code blocks?

[Berry, Charles]

> On Jan 29, 2024, at 3:47 PM, Vikas Rawal  wrote:
> 
> Hi all,
> 
> Is it possible to search and replace a regex/string in an org file excluding 
> the code blocks from its scope?
> 
> Say, I want to replace all opening quotes (") by backticks(``) in the text 
> but not in the code blocks. Is there a way one could achieve that?
> 

Sure, the recommended way to search and replace programmatically is given in 

(info "(elisp) Search and Replace")

Hacking that slightly to test if point is in a src block and using the double 
quote preceded by white space as the search string and replacing by that white 
space and double backticks gives:



#+begin_src elisp
  (goto-char 0)
  (while (re-search-forward "\\([[:space:]]\\)\"" nil t)
(unless (eq (org-element-type (org-element-at-point)) `src-block)
  (replace-match "\\1``")))
#+end_src

You can roll this into a function and add arguments as desired to allow 
different search/replacement strings. 

Best,

Chuck

Re: Feature request: Allow export to convert broken links to plain text

[Berry, Charles]

Ryan,

> On Sep 9, 2023, at 9:13 PM, Ryan C. Thompson  wrote:
> 
> So, this isn't an ideal solution, since it requires me to prefix any 
> potential offending links with "maybe:". But it's good enough for me.
> 

It is good that you have a solution, albeit with the caveat you mention above.

A couple of thoughts:

There is a hook that operates on the copy buffer before parsing viz. 
"org-export-before-parsing-functions is a variable defined in ‘ox.el’." (In 
older versions, it was org-export-before-parsing-hook.) Maybe you can add a 
hook that will add that prefix to all links, so you do not need to put it in 
your working files.

Or you could write an elisp macro that takes two arguments (link, desc) and 
uses them to either construct a link or your preferred substitute if it fails 
validation. 

HTH,

Chuck

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Berry, Charles]

> On Jul 15, 2023, at 9:11 AM, Thomas S. Dye  wrote:
> 
> 
> Ihor Radchenko  writes:
> 
>> "Thomas S. Dye"  writes:
>> 
 Am I correct that language-specific header arguments are not yet covered
 in the manual?  I can't find any reference of "lexical" there.
>>> 
>>> Yes, I believe so.  Language-specific header arguments for many languages 
>>> are documented at 
>>> https://orgmode.org/worg/org-contrib/babel/languages/index.html. Several 
>>> languages are not documented there; in these cases the documentation is 
>>> typically in the source code.
>> 
>> It is actually slightly awkward that built-in babel backends are not
>> documented in the manual, while, for example, export backends are.
>> 
> Agreed, but the two differ.  With export, the goal is to produce code 
> recognized as correct by the target software.  With babel, the general goal 
> is to provide language agnostic literate programming, which often produces 
> something that meets standards of correctness not implemented in software.  
> The idea of built-in babel backends, as distinct from contributed backends, 
> or backends distributed by package archive is a function of maintenance 
> burden and distribution channel, rather than something intrinsic to the 
> backend itself and how it contributes to literate programming.  
>> However, unless my memory deceives me, Bastien or Nicolas previously
>> voiced against adding babel documentation. Though I cannot find the
>> relevant discussion now and cannot recall the arguments (if there was
>> such discussion at all).
> 
> IIRC, there wasn't much discussion.   The current situation doesn't seem ripe 
> for documentation in the manual.
> 


Agreed. Maybe it would suffice to use enhanced docstrings for the 
org-babel-execute: functions and point to them in the manual.


The params argument could list the language specific keys and the language 
specific handling of key common to all languages (e.g. `:results graphics' in R 
jumps through a number of hoops that might deserve mention)

Chuck 


> Here are some potential hurdles:
> - there are likely too many built-in backends;
> - the built-in backends are a mixed bag--ob-lua seems half-finished to me, 
> though I don't program in lua and struggled to set up the language to write 
> the documentation stub on Worg;
> - nearly a dozen of the built-in babel backends lack documentation outside 
> the source code (see 
> https://orgmode.org/worg/org-contrib/babel/languages/index.html#orgbc466c5); 
> and
> - language support is inconsistent (see 
> https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html), which 
> introduces complications for language agnostic literate programming.
> 
> One way forward might distinguish between babel backends for GNU software and 
> babel backends for non-GNU software, with the former built in, guaranteed to 
> be consistent to some standard (which needs to be formulated), and documented 
> in the manual and the latter moved to contrib or a package archive, with 
> documentation (if any) on Worg.
> 
> Others might have better ideas.
> 
> All the best,
> Tom
> -- 
> Thomas S. Dye
> https://tsdye.online/tsdye
> 
> 

Re: Preserving leading zeros

[Berry, Charles]

William,

Have you considered http://gewhere.github.io/org-bibtex ??

Or using the approach therein, viz. use properties to store bib data in org?

HTH,
Chuck

> On May 28, 2023, at 7:46 AM, William Denton  wrote:
> 
> I'm thinking about moving a personal library catalogue system into Org.  This 
> would involve ISBNs, and when ISBNs had 10 digits some would have leading 
> zeros. It turns out leading zeros are removed when something looks like a 
> number.
> 

[snip]

Re: [BUG] org-manual: Using bookmarklet for org-capture is no longer reliable

[Charles Philip Chan]

>>>>> "Ihor" == Ihor Radchenko  writes:

Hi  Ihor,

Ihor> This is bad news.

Ihor> 17.16.2 The ‘capture’ protocol section of Org manual recommends

Ihor> To use this feature, add a bookmark with an arbitrary name, e.g.,
Ihor> ‘Org: capture’, and enter this as ‘Location’:

Ihor> javascript:location.href='org-protocol://capture?' + new
Ihor> URLSearchParams({ template: 'x', url: window.location.href, title:
Ihor> document.title, body: window.getSelection()});

Ihor> With the annoying Firefox dialogue, things get very annoying.  Even
Ihor> though I do understand the motivation of devs.  But they broke
Ihor> bookmarklets :'(

I have been using this org-protocol addon[1] for more than a year and it has
been rock solid for me. According to the author, bookmarklets are getting less
and less useful because CSP (Content Security Policy) blocking them on many
sites (for example Github)[2].

Charles

Footnotes:
[1] 
https://addons.mozilla.org/en-US/firefox/addon/org-protocol/?utm_source=addons.mozilla.org_medium=referral_content=search

[2]  https://github.com/vifon/org-protocol-for-firefox




signature.asc
Description: PGP signature

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/)]

[Berry, Charles]

Bastien et al,

> On Dec 29, 2022, at 8:00 AM, Bastien Guerry  wrote:
> 
> I think it would make sense to convert Elisp lists into R lists
> directly.  Jeremie, would you be okay with this?
> 


Perhaps there are some hiccups. 

The R `data.frame' type is a list with some added attributes. In that list each 
top level element is a *column* in the data.frame.

In the elisp list produced by rendering a table as in `:var mydf=atab', each 
top level element is a sequence containing one *row* of the table `atab'.

So if elisp lists are to be converted to R lists, ob-R will need to know 
whether the list came from a table to decide whether to render top level 
elements as list elements or as data.frame rows.

---

There might be some useful applications for converting org lists to R lists and 
vice versa. But it looks like a significant amount of effort to get it right.

Best,

Chuck
 

Re: [BUG] Header-args :results output of code block don't take precedence above headline header-args [9.6 (release_9.6-32-gc59d6d @ /tmp/org/org-mode/lisp/)]

[Berry, Charles]

Rens,

This is not a bug. Seee below.

> On Dec 7, 2022, at 9:47 AM, Rens Oliemans  wrote:
> 
> Hi all,
> 
> A code block with ":results output" as header argument still has its
> output silenced if it's inside a headline with ":results none". MWE:
> 
> 1. Create an .org file with the following content:
> 
> * Sub-tree with =:results none=
> :PROPERTIES:
> :header-args: :results none
> :END:
> 
> #+BEGIN_SRC bash :results output
>  echo "is silent"
> #+END_SRC


This is the correct handling.

See (info "(org) Results of Evaluation").

`output' is a `Collection' option. `none' is a `Handling' option. 

If you want to override a `Handling' option you need another `Handling' option. 
e.g.

#+BEGIN_SRC bash :results output replace
  echo "is silent"
#+END_SRC

HTH,

Chuck

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/)]

[Berry, Charles]

Hi Greg,


> On Dec 5, 2022, at 4:41 PM, Greg Minshall  wrote:
> 
> hi, Charles,
> 
>> This makes a list like '("a" "b" "c") into a data.frame with one column.
> 
> 1. which version of Org are you running?
> : Org mode version 9.6 (9.6-g60de19 @ 
> /home/minshall/.emacs.d/straight/build/org/):
> 

Org mode version 9.6 (release_9.6-14-g53814a (dated 2022-12-02)

> 2. is my below example yours?


Not with the change I indicated (which includes your changes of sequencep to 
listp)

I have


#+begin_src R :var list='("a" "b" "c")
 list
#+end_src

#+RESULTS:
| a |
| b |
| c |



> 
> i think i used to see the behavior you describe in 9.5.
> 

So, isn't that what is wanted?


HTH,

Chuck


> cheers, Greg
> 
> 
> 
> #+begin_src R :var list='("a" "b" "c")
>  list
> #+end_src
> 
> #+RESULTS:
> | a | b | c |

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/)]

[Berry, Charles]

> On Dec 4, 2022, at 6:43 PM, Greg Minshall  wrote:
> 
> 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.)
> 
> i don't understand how (org-babel-R-assign-elisp) thinks.  it seems to
> assign =max= and =min= assuming that =value= is a list of (at least one)
> list(s).
> 
> this *might* be a fix.  but, i don't have a lot of confidence it will
> not have bad side effects for other cases.  (though i tested it with a
> simple list, and a simple table with more than one row, and a list of
> two lists, the first of length 3, the second of length 2.):
> 
> modified   lisp/ob-R.el
> @@ -241,7 +241,7 @@ This function is called by `org-babel-execute-src-block'."
> (defun org-babel-R-assign-elisp (name value colnames-p rownames-p)
>   "Construct R code assigning the elisp VALUE to a variable named NAME."
>   (if (listp value)
> -  (let* ((lengths (mapcar 'length (cl-remove-if-not 'sequencep value)))
> +  (let* ((lengths (mapcar 'length (cl-remove-if-not 'listp value)))
>(max (if lengths (apply 'max lengths) 0))
>(min (if lengths (apply 'min lengths) 0)))
> ;; Ensure VALUE has an orgtbl structure (depth of at least 2).

- (unless (listp (car value)) (setq value (list value)))
+ (unless (listp (car value)) (setq value (mapcar 'list value)))


> 

This makes a list like '("a" "b" "c") into a data.frame with one column.

HTH,
Chuck

Re: Release 9.6

[Charles Millar]

On 12/1/22 18:10, Tim Cross wrote:


Max Nikulin  writes:


On 29/11/2022 13:58, Bastien wrote:

Last but not least: thanks to Ihor his
truly amazing work and for being the de facto maintainer.


I think, Ihor's role in this release is crucial. He spent a lot of time fixing 
bugs and
reviewing patches, not to mention the org-fold framework to overcome performance
limitation of overlays (the latter has been recently addressed in Emacs though).


I agree. The amount of time and effort Ihor has put into org mode is
both crucial and hugely appreciated.

One question I do have is with respect to the new folding code, the
changes in Emacs to improve overlay performance and the correct way
forward.

On one hand, it was an immense amount of work for Ihor to implement a
better performing solution and something I'm sure those with large org
files will appreciate. However, on the other hand, I guess it also puts
a greater burden from a maintenance perspective on org maintainers as
org is now using its own unique approach to hiding/showing content
(folding).

Has anyone done any comparisons between the new overlay implementation
in Emacs 29 and the new folding approach in org 9.6? Is there still
sufficient performance benefit with org's approach over using Emacs
overlays or do we need to seriously consider changing the default back
to native Emacs overlays?


Is this the cause for the behavior I described a few days ago in

Bug org-cycke fails after "replace-string"

Charlie Millar

P.S. Sorry for the typo

Re: [BUG] ob-R: session evaluation returns empty ouputs with Org 9.6 [9.6 ( @ /home/fsantos/.emacs.d/elpa/org-9.6/)]

[Berry, Charles]

> On Nov 30, 2022, at 5:48 PM, Ihor Radchenko  wrote:
> 
> William Denton  writes:
> 
>> I tried that, but it didn't fix it. :(
> 
> Ok. I was able to reproduce on my side.
> 
>> With a minimal setup, running the R block with a :session makes it ask where 
>> the 
>> working directory should be (the default in the prompt is the directory the 
>> test 
>> Org file is in).  Setting ess-startup-directory to 'default-directory 
>> doesn't 
>> change that, or the output problem.
> 
> It looks like there is something wrong with comint-prompt-regexp in R
> buffers. It somehow does not match the prompt.
> 
> I will need to look further.
> 

The older (commit bed47b437d8cde7a98bafdb07996e248b40f70e6e) version of 
org-babel-comint-with-output used comint-prompt-regexp and works fine.

I don't really follow how `org-babel-comint-prompt-separator` gets set to 
something useful in the current version. 

Reverting org-babel-comint-with-output to that older commit (and eval-ing the 
defun for org-babel-R-evaluate-session) seems to fix this case for those who 
need `:results output` in R src blocks till this gets sorted out.

HTH,

Chuck

Bug org-cycke fails after "replace-string" is

[Charles Millar]

Attached is an example

1. Open all headings etc. show the contents then Collapse all headings
2. Cycle First Heading to show its content
3. Cycle Second Heading to show only the subheadings, but not the 
content of each subheading

3. Cycle Subheading B, to show its content.
4. go to point-min and then replace "Charlie" with a string of your choice

After the replace string is executed, I cannot cycle Subheading A or 
Subheading B


Likewise if all headings are collapsed and I execute a replace-string 
"Chas" I cannot org-cycle through "First heading" and "Second heading", 
but I can cycle "Third heading"


If you add a Fourth heading with the string to be replaced, you cannot 
cycle through any headings if a string.is replaced in the fourth heading


I just pulled Org 9.6 from git. However I noticed this behavior a while 
ago but cannot recall exactly when. I searched the list but no luck.


Org mode version 9.6 (release_9.6 @ /usr/local/share/org-mode/lisp/)

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, 
cairo version 1.16.0) of 2022-11-25


Charlie Millar* First heading
Chas


* Second heading
** Subheading A
Chas
** Subheading B
Chaz
** Subheading C
Chat


* Third heading
some more text

Re: Init.el need just for org-mode?

[Charles Millar]

On 11/2/22 13:31, Renato Pontefice wrote:

I’m sorry for this simply question, but I’m starting using emacs and org-mode 
and I made some confusion.

Init.el

Need just for org -mode? Not for emacs right?

Thank you

Renato

Forgot to mention, and you may already be aware of this,

use

C-h v user-init-file

to find your init.el file

Re: Init.el need just for org-mode?

[Charles Millar]

On 11/2/22 13:31, Renato Pontefice wrote:

I’m sorry for this simply question, but I’m starting using emacs and org-mode 
and I made some confusion.

Init.el

Need just for org -mode? Not for emacs right?


You  may use init.el (or .emacs of .emacs.d/init.el) file for all of 
emacs.not just Org mode.


For instance my init.el includes settings for the display, printer 
selection, what spelling package to use,  and others.


Is also is used to load packages that are not included in the "basic" 
emacs distribution (which contains quite a few).


HTH.

Charlie Millar

Re: 'make autoloads' works but 'make ; make autoloads' fails with a version mismatch?

[Charles Philip Chan]

> Thanks for reporting!
> Fixed on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2d3802658156153974f540877a82bf5a384a2ad4

Thanks that fix it for me too.

Charles


signature.asc
Description: PGP signature

Re: Reinstalling compat fixed everything breaking

[Charles Philip Chan]

William Denton  writes:

Hello,

> Yesterday I pulled the current source trees for Org and Emacs and compiled as
> I usually do ... and everything broke, with Org complaining about mixed
> versions, and all kinds of warnings and backtraces and "Invalid function:
> compat-declare-version" errors.
>
> After looking at various things I noticed a couple of mild warnings related to
> the package compat, which I'd seen for a while (several weeks, at least) but
> never bothered about, because everything worked.  I thought maybe it was all
> connected, what with the new version-checking and such, and indeed "M-x
> package-reinstall compat" did the trick and now everything works.

I am seeing the same problem. However, it did not resolve for me after upgrading
the compat library to the current git version. I am still getting:

,
| Warning (emacs): Org version mismatch.  Make sure that correct ‘load-path’ is
| set early in init.el This warning usually appears when a built-in Org version 
is
| loaded prior to the more recent Org version.
`

during "make install". I never had this problem before.

Charles


signature.asc
Description: PGP signature


signature.asc
Description: PGP signature

Re: Reinstalling compat fixed everything breaking

[Charles Philip Chan]

William Denton  writes:

Hello,

> Yesterday I pulled the current source trees for Org and Emacs and compiled as
> I usually do ... and everything broke, with Org complaining about mixed
> versions, and all kinds of warnings and backtraces and "Invalid function:
> compat-declare-version" errors.
>
> After looking at various things I noticed a couple of mild warnings related to
> the package compat, which I'd seen for a while (several weeks, at least) but
> never bothered about, because everything worked.  I thought maybe it was all
> connected, what with the new version-checking and such, and indeed "M-x
> package-reinstall compat" did the trick and now everything works.

I am seeing the same problem. However, it did not resolve for me after upgrading
the compat library to the current git version. I am still getting:

,
| Warning (emacs): Org version mismatch.  Make sure that correct ‘load-path’ is
| set early in init.el This warning usually appears when a built-in Org version 
is
| loaded prior to the more recent Org version.
`

during "make install". I never had this problem before.

Charles


signature.asc
Description: PGP signature

Re: substitutions in html export?

[Berry, Charles]

Kevin,

> On Jul 17, 2022, at 1:54 PM, kevinbanjo  wrote:
> 
> When I look at the doc string for (org-macro-replace-all) it says:
> 
> Optional argument KEYWORDS, when non-nil is a list of keywords,
> as strings, where macro expansion is allowed.
> 
> I tried passing it '("export-block") but it didn't work, but it seems like 
> something like that should be close.
> 

Does this help?

Adding this to your example:

Here is an inline code src_emacs-lisp[
:results html :exports results :var num=numbers()]{
(format "the result is %d." num )} End.


Produces a paragraph:


Here is an inline code the result is 40. End.



> This whole area of org documentation seems pretty obtuse, with few examples.

Did you browse worg? Especially this:

https://orgmode.org/worg/org-contrib/babel/index.html


Agree that documentation is a WIP and export blocks are mentioned only in 
reference to specific exporters, so there is that.

HTH,
Chuck

Re: substitutions in html export?

[Berry, Charles]

Kevin,

> On Jul 17, 2022, at 10:18 AM, kevinbanjo  wrote:
> 
> 
> 
> On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko  wrote:
> See inline calls in 
> https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks
> 
> I did this and it didn't work (but the one outside the export block did):
> 
> #+title:test
> 
> #+name: numbers
> #+begin_src emacs-lisp :exports none
> 40 
> #+end_src
> 
> #+begin_export html
> 
> the result is call_numbers()
> 
> #+end_export


The export block provides text that is to be used "as is" by the html backend. 
So, "call_numbers()" is treated as html.

You need to construct the export block programmatically. Maybe something like 

#+begin_src emacs-lisp :results html :exports results :var num=numbers()
   (format "the result is %d" num )
#+end_src

 
HTH,

Chuck

Re: idea for capture anywhere in x

[Charles Philip Chan]

Samuel Wales  writes:

Hi Samuel,

> with the org capture firefox extension broken, i recalled this old
> thread, thinking it might be a fix,  and i think i understand the
> issue.  so i thought i would summarize here in this one post.

This new addon:

 
https://addons.mozilla.org/en-US/firefox/addon/org-protocol/?utm_source=addons.mozilla.org_medium=referral_content=search

is working well for me.

Charles


signature.asc
Description: PGP signature

Re: Bug: ob-R.el breaks when :session is specified

[Berry, Charles]

Um...

> On May 15, 2022, at 2:46 AM, Christian Heinrich 
>  wrote:
> 
> I run 
> 
> emacs -q --load /tmp/init.el --file=/tmp/test.org 
> 
> with my /tmp/init.el being only
> 
>> (require 'package)
>> (package-initialize)
>> (add-to-list 'load-path "~/.emacs.d/straight/repos/org/lisp/")
>> (require 'org)
>> 
>> ;(require 'ess-site)

The line above is commented out. So how do you load ess-site?


>> (org-babel-do-load-languages
>>   'org-babel-load-languages
>>'((R . t)))
> 
> I hope this constitutes a minimal example for a config - please correct me if 
> I'm wrong.


Just spitballing here:

Have you tried instrumenting `org-babel-R-evaluate-session'? 

Maybe watching changes made to the session buffer on first evaluation and 
comparing to subsequent evals helps.

HTH,
Chuck

Re: How to export to markdown programmatically without the table of contents?

[Berry, Charles]

> On May 1, 2022, at 2:20 AM, Marcin Borkowski  wrote:
> 
> Hi fellow Orgers,
> 
> I'd like to export a Org-mode formatted string to markdown, but without
> the table of contents.
> 
> (org-export-string-as my-string 'md t '(toc nil))
> 
> didn't work (the ToC was still there).  What am I missing?


It does seem odd that BODY-ONLY as `t' gives a toc. With latex it does not 
regardless of `:with-toc'.

: (org-export-string-as my-string 'md t '(:with-toc nil))

seems to give what you want.

HTH,
Chuck

Re: handling as special special block in derived export

[Berry, Charles]

Matt,

> On Jan 19, 2022, at 5:52 AM, Matt Price  wrote:
> 
> However, I'd really like to add a less verbose syntax, like this:
> 
> #+begin_r-stack :frag (appear appear)
> [[imglink1]]
> [[imglink2]]
> #+end_r-stack
> 
> My question is: will the exporter preserve information from these header-like 
> arguments, and is 
> there a mechanism I can use in a custom ~special-block-function~ to make use 
> of htem?
> 

Not as you have it there, but

#+header: :frag (appear appear)
#+begin_r-stack
[[imglink1]]
[[imglink2]]
#+end_r-stack


parses as 

(special-block
 (:type "r-stack" :begin 727 :end 815 :contents-begin 775 :contents-end 801 
:post-blank 0 :post-affiliated 759 :header
(":frag (appear appear)")
:mode nil :granularity element :parent nil))

if that helps.

Chuck

Re: should a "wrapped" table result behave differently than one that is not?

[Berry, Charles]

Eric,

> On Jan 18, 2022, at 9:05 AM, Eric S Fraga  wrote:
> 
> been wrapped in a RESULTS special block be different than one that is
> not wrapped (beyond the wrapping, of course)?  Specifically, wrapping
> the results seems to cause org to ignore that ATTR_LATEX :center toggle
> [1].  A minimal example, both org and resulting LaTeX, attached.
> 
> I guess it makes sense in that the attr line will probably be applied to
> the results special block.  I am not sure how to get around this.
> Suggestions very welcome indeed!  I do need to wrap the results in a
> block of some type so I can control the formatting in the resulting PDF
> export but I do not want the table centred necessarily [2].
> 


This is annoying, but I think you can get the product you want by 
"pre-wrapping" the results.

Here is an example:

#+begin_src org
  Show default:

  ,#+begin_src emacs-lisp :exports both
  org-latex-tables-centered
  ,#+end_src

  ,#+name: awrappedtable
  ,#+header: :exports results
  ,#+header: :results value
  ,#+begin_src emacs-lisp
'((1 2) (3 4))
  ,#+end_src

  ,#+begin_results
  ,#+attr_latex: :center nil
  ,#+RESULTS: awrappedtable
  : initial filler
  ,#+end_results
#+end_src


On export I get

Show default:

\begin{verbatim}
org-latex-tables-centered
\end{verbatim}

\begin{verbatim}
t
\end{verbatim}


\begin{results}
\begin{tabular}{rr}
1 & 2\\
3 & 4\\
\end{tabular}
\end{results}


HTH,
Chuck

Re: Way to mark contents of an Org special block as verbatim?

[Berry, Charles]

> On Jan 9, 2022, at 8:58 AM, Kaushal Modi  wrote:
> 
> How do we disable Org from transforming this:
> 
>E = -J \sum_{i=1}^N s_i s_{i+1}
> 
> to this:
> 
> 
>E = -J i=1^N s\_i si+1

Ahh! Sorry!

So,
:   (format "{{<%s>}}\n%s{{}}\n" type contents type)

has the contents already parsed and transcoded which you do not want. So use 
something like:

#+begin_src emacs-lisp

(let ((raw-contents
  (buffer-substring-no-properties
   (org-element-property :contents-begin special-block)
   (org-element-property :contents-end special-block
 (format "{{<%s>}}\n%s{{}}\n" type raw-contents type))

#+end_src

HTH,

Chuck

Re: Way to mark contents of an Org special block as verbatim?

[Berry, Charles]

> On Jan 8, 2022, at 3:29 PM, Kaushal Modi  wrote:
> 
>> What am I missing?
>> 
>> It seems like you want your derived backend to transcode special blocks 
>> somewhat differently than the parent backend. And adding a special block 
>> export filter doesn't quite do the job.
> 
> I tried out the example Juan posted and it works perfectly well. But
> it would require to user to do something similar for each arbitrary
> new special block they need. E.g. #+being_katex, #+begin_tikz,
> #+begin_tikzjax (could be anything!) where the content needs to be
> kept unmodified.
> 

Right, so maybe use `(member type )' rather than 
'(equals type "newlatex")' in the3 example below.


>> For that purpose, you should write a special block transcoder - perhaps 
>> falling back to the parent backend for block types you do not wish to handle 
>> as described above.
> 
> Can you please point me to an example?
> 

A simple one here:

#+begin_src emacs-lisp
  ;; minimal backend with latex parent
  (org-export-define-derived-backend 'newlatex 'latex
:translate-alist
'((special-block . org-newlatex-special-block)))

  ;; special block transcoder
  (defun org-newlatex-special-block (special-block contents info)
"Newlatex special block transcoder."
(let
 ((type (org-element-property :type special-block)))
  (if (equal type "newlatex")
  (format "{{}}\n%s{{}}\n" contents)
;; not `newlatex` so default to latex transcoder
(org-export-with-backend 'latex special-block contents info
#+end_src

Eval the above, then use this as an example by copying the following
src block to an org buffer and entering

M-; (org-export-to-buffer 'newlatex "*Org NEW LATEX Export*" nil nil nil t) RET

#+begin_src org

  ,#+begin_newlatex
  This is the new content
  ,#+end_newlatex


  ,#+attr_latex: :caption \MyCaption{HeadingA}
  ,#+BEGIN_proof
 dot-dot-dot
  ,#+END_proof

#+end_src

I get an *Org NEW LATEX Export* buffer like this:

#+begin_example
{{}}
This is the new content
{{}}


\begin{proof}
dot-dot-dot
\MyCaption{HeadingA}
\end{proof}

#+end_example


>> Block specific customizations could rely on a backend specific attribute.
> 
> Yes, I am doing block-specific customization (like support
> #+attr_shortcode above special blocks here[1]). But I don't know how
> to get back the original content of the special block because the
> `contents` arg received by the exporter's org-hugo-special-block
> already has the Org entities, and sub/super replacements done.
> 
> [1]: 
> https://urldefense.com/v3/__https://github.com/kaushalmodi/ox-hugo/blob/458142675bb5a0e7ee26ecea07d75c10aa52184b/ox-hugo.el*L2872__;Iw!!LLK065n_VXAQ!xZhh--YwGpo06BbAHLF_A2MY_4mk4gBxHgFG3InZakP_7mdFDpyBNMgqvDVvBimzWQ$
>  

Re: Way to mark contents of an Org special block as verbatim?

[Berry, Charles]

> On Jan 6, 2022, at 11:46 AM, Kaushal Modi  wrote:
> 
> On Thu, Jan 6, 2022 at 2:33 PM Juan Manuel Macías
>  wrote:
>> I just realized that there is a much simpler solution for your katex
>> environment :-)
>> 
>> You can use an example block, and define your custom environment using
>> the attribute :environment
> 
> Sorry, but this exporter is derived from md, and before exporting the
> verbatim body of the special block needs to be surrounded with some
> special syntax, with some optional stuff that the user specifies. Also
> it could any special block name:
> - katex
> - tikz
> - tikzjax
> 
> In any case, if user has this in Org:
> 
> #+begin_FOO
> 
> #+end_FOO
> 
> I need to export:
> 
> {{< FOO custom stuff >}}
> 
> {{< /FOO >}}
> 
> 

What am I missing? 

It seems like you want your derived backend to transcode special blocks 
somewhat differently than the parent backend. And adding a special block export 
filter doesn't quite do the job.

For that purpose, you should write a special block transcoder - perhaps falling 
back to the parent backend for block types you do not wish to handle as 
described above.

Block specific customizations could rely on a backend specific attribute.

HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

Max,

> On Dec 31, 2021, at 4:05 AM, Max Nikulin  wrote:
> 
> 
> Should some function a macro be provided to facilitate declaring languages as 
> data format (config files, JSON, YAML, etc.) rather than executable source 
> code?

I think we already have this in the form of export blocks, viz.

#+name: yaml_header_1
#+begin_export yaml
output:
  html_document:
toc: true
toc_depth: 2
#+end_export

will be ignored by babel and by exporters that do not define a transcoder for 
`yaml' blocks.

The data can be used in transcoders for derived backends or in src blocks like 
this one:

#+begin_src emacs-lisp :var yaml_dat_1=yaml_header_1
  yaml_dat_1
#+end_src

And =C-c '= will invoke an edit buffer in yaml mode (if available).

And it seems that fontifying natively works just as with src blocks.

Best,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

Rudy,

> On Dec 29, 2021, at 11:26 PM, Rudolf Adamkovič  wrote:
> 
> (Note: I do not know what ECM stands for.)


ECM stands for =Exemple Complet Minimal=, per 
https://orgmode.org/worg/org-faq.html#ecm, which says "The term refers to test 
files that can reliably reproduce a bug with the minimal amount of code."

It also references 
https://list.orgmode.org/orgmode/80oc3s13rg@somewhere.org/ for more details.

Roughly, an ECM is something a reader should be able to copy into a file and 
run "as is" on his/her setup. 

HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

Max,

> On Dec 29, 2021, at 4:53 AM, Max Nikulin  wrote:
> 
> On 25/12/2021 02:52, Berry, Charles wrote:
>> For that case, setting buffer or heading properties, such as:
>> #+begin_src org
>>   :PROPERTIES:
>>   :header-args: :eval yes :exports results
>>   :header-args:bibtex: :eval no
>>   :END:
>> #+end_src
>> resolves the issue.
> 
> Chuck, is it expected that the following form to specify properties 
> suppresses of evaluation during export but allows execution during processing 
> of `org-babel-execute-buffer'? I am puzzled that behavior for property drawer 
> is different.
> 

It isn't different when you have `:header-args:elisp: :eval no' in the drawer.

I get the message `Evaluation of this elisp code block is disabled.' either way.

Caveat: I am running release_9.5.1-233-ged5335.

But a couple of things:

1) Be sure to refresh when introducing `#+property' lines. If you paste in a 
property line and then org-babel-execute-src-block, the property will not be 
acknowledged. AFAICS, property drawers do not suffer from this. 

2) Property drawers only affect the heading under which they are placed unless 
placed at the top of the file. And either way, it is an error to insert a blank 
line above a property drawer. org-lint will complain although the message may 
be cryptic.

3) You probably know this, but exports use `org-babel-exp-process-buffer' which 
may perform differently than `org-babel-execute-buffer'. 




>  >8 
> #+property: header-args :eval yes :exports both
> #+property: header-args:elisp :eval no
> 
> #+begin_src elisp
>  (message "From elisp")
> #+end_src
>  8< 


HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

Rudy,

Thanks for the comment, but ...

> On Dec 25, 2021, at 1:37 PM, Rudolf Adamkovič  wrote:
> 
> I think we look at the problem from two different perspectives.  You
> look at the problem from the "how" perspective, whereas I look at it
> from the "why" perspective.  Sure, we can work around everything in Org.
> Now, does that mean that Org should try to execute BibTeX blocks when
> executing a buffer?  I do not think so.

Using standard features (properties, header-args) in a standard way does not 
strike me as a `work around'.

You have not made a clear case that src blocks are even needed to support your 
use case. It may well be that export blocks (which never execute) would work 
just as well.  But with no ECM, one can only guess.

I'm still inclined to call this a feature request, not a bug. And decisions 
about adding complexity to an already complicated code base should take that 
point of view, IMO.

Best,

Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 23, 2021, at 8:09 PM, Ihor Radchenko  wrote:
> 
> Rudolf Adamkovič  writes:
> 
>>> So, Org cannot distinguish between language backends that are simply
>>> not loaded and the ones that do not define org-babel-execute:lang.
>> 
>> Oh, if we have this architectural limitation in place, then Org cannot
>> help the user, and every user will have "explain" to Org that executing
>> BibTeX makes no sense.  I guess we can then close this bug then!
> 
> Not necessarily close. As I proposed above, one way is adding a user
> customisation. And we do not have to force the users adding trivial
> things like bibtex. Bibtex may be one of the defaults.

Honestly, I think there is no problem here to solve. 

If there is a use case that you think I didn't cover below, please provide an 
ECM and directions for triggering the unwanted behavior.

Details:

---

Exports do not eval blocks for which there is no org-babel-execute:.

So, `C-c C-e l L' (and so on) will *not eval* bibtex src blocks.

The problem cited here *only* exists for execution using 
org-babel-execute-buffer or similar functions.

For that case, setting buffer or heading properties, such as:

#+begin_src org
  :PROPERTIES:
  :header-args: :eval yes :exports results
  :header-args:bibtex: :eval no
  :END:
#+end_src

resolves the issue.

So the user needs to add just one-line per language to set this up.

Following (info "(org) Property Syntax") the user can set this behavior for all 
Org files by customize-ing `org-global-properties', whose docstring gives 
plentiful details.

---



HTH,
Chuck

Re: exporter: How to get :file property on a src block in an exporter

[Berry, Charles]

> On Dec 22, 2021, at 2:16 PM, Yasushi SHOJI  wrote:
> 
> Hi,
> 
> On Thu, Dec 23, 2021 at 3:22 AM Berry, Charles  
> wrote:
>>> On Dec 22, 2021, at 8:07 AM, Yasushi SHOJI  wrote:
>>> On Thu, Dec 23, 2021 at 12:52 AM Yasushi SHOJI  
>>> wrote:
>>>> Then, why don't I have :file in the info?
>>> 
>>> The :exports must be "file" to have the file name in the info.  I used
>>> to have "code" because
>>> I wanted to export code with the file name as an attribute.
>> 
>> I don't see that here:
>> 
>> #+begin_src emacs-lisp :exports code :file abc
>>  (assq :file (caddr (org-babel-get-src-block-info 'light)))
>> #+end_src
>> 
>> #+RESULTS:
>> : (:file . abc)
> 
> Indeed, this one works.  But I don't see :file, or the whole
> :parameters in the info arg passed to my function.

Of course. Your function is called after the buffer is parsed.

> 
>> `org-export-as' runs `org-babel-exp-process-buffer' *before*  it parses the 
>> buffer and the header args get stripped from the copy buffer at that time.
> 
> Would you mind telling me where the stripping part is in the code, and
> the reason why it strips?

'...at that time' was meant to refer to when `org-babel-exp-process-buffer' 
runs. So look there.

Why? I didn't have a hand in that decision, but my guess is that almost always 
the header args are only useful in babel per se, so there is no reason to hang 
onto them.


> 
>> So you need to find a way to get the :file header arg whilst babel runs and 
>> hang onto it for later use.
> 
> I'm still learning but :parameters, which holds :file, are already
> gone from the info arg when org-myexporter-src-block is called.
> 

That is what I tried to say.

Best,
Chuck

Re: exporter: How to get :file property on a src block in an exporter

[Berry, Charles]

> On Dec 22, 2021, at 8:07 AM, Yasushi SHOJI  wrote:
> 
> On Thu, Dec 23, 2021 at 12:52 AM Yasushi SHOJI  
> wrote:
>> Then, why don't I have :file in the info?
> 
> The :exports must be "file" to have the file name in the info.  I used
> to have "code" because
> I wanted to export code with the file name as an attribute.
> 


I don't see that here:

#+begin_src emacs-lisp :exports code :file abc
  (assq :file (caddr (org-babel-get-src-block-info 'light)))
#+end_src

#+RESULTS:
: (:file . abc)

---

Another problem for you: 

`org-export-as' runs `org-babel-exp-process-buffer' *before*  it parses the 
buffer and the header args get stripped from the copy buffer at that time. 

So you need to find a way to get the :file header arg whilst babel runs and 
hang onto it for later use.

This can be a tricky business.

HTH,

Chuck



> I think I can work on it.
> 
> Thanks Ihor for your hint!
> 
> Best regards,
> -- 
> yashi
> 
> 

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 21, 2021, at 2:53 PM, Rudolf Adamkovič  wrote:
> 
> I struggle to understand.  Why do we need a customization?  If Org knows
> that some backend exists but has no execute function, why does it even
> try to execute it?  It cannot.  Do I miss something?


Sorry if my prior posts were garbled. To clarify:

When exporting src blocks for which there is no execute function for the lang, 
the block will not be executed and the export will proceed.

When evaluating src blocks in other circumstances, e.g. M-x 
org-babel-execute-buffer, the process will terminate when 
org-babel-execute-src-block issues `(error "No org-babel-execute function for 
%s!" lang))'

The latter can be a clue that the name of a lang is misspelled or that 
org-babel-load-languages needs to be customized to provide the execute function.

IMO, nothing needs fixing. The ability to handle OP's original issue is already 
in place.

HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 18, 2021, at 11:57 AM, Charles Berry  wrote:
> 
> There are workable approaches under the current setup. 
> 
> -


Also, when exporting it looks `org-babel-exp-results' does not attempt to run 
src blocks for which

(fboundp (intern (concat "org-babel-execute:" lang)))

is nil.

So doing an export should `just work'.

HTH,

Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 18, 2021, at 1:49 AM, Ihor Radchenko  wrote:
> 
> "Berry, Charles"  writes:
> 
>> If I have a typo in the name of a language, the error message you quote 
>> tells me what my mistake was. 
>> 
>> I'd say that is a feature, not a bug.
> 
> Agree. However, some languages simply do not define babel execute
> function. The error is same regardless whether a language backend is not
> available/not loaded or the backend is loaded, but does not provide
> babel execute function.
> 
> Maybe we can provide a custom list of languages where we do not throw
> the error? If a language is in the list and there is no babel execute
> function, we can simply ignore the source block. If a language is in the
> list, but there is babel execute function, we throw another error.
> 
> Though I am not a big fan of introducing yet another customisation.
> Maybe someone has better ideas?
> 

I believe there is a feeling that org-babel is already so complicated that 
adding features should be avoided. 

There are workable approaches under the current setup. 

---

For one, you can define lang specific header-args, so just define :eval no for 
the lang's that you want to use, but that do not have org-babel-execute: 
defined: 

#+property: header-args:nada :eval no
#+property: header-args :exports both :eval yes

The code here will be rendered, but the block will not execute:

#+begin_src nada
  "haha"
#+end_src

---

Another is to use a custom :eval arg like this:

#+property: header-args :eval (my-eval-p) :exports both

#+begin_src not_defined
  "haha"
#+end_src

Where `my-eval-p' is defined as:

#+begin_src emacs-lisp
  (defun my-eval-p ()
(let ((lang (car (org-babel-get-src-block-info 'light
  (if (fboundp (intern (concat "org-babel-execute:" lang)))
  "yes"
"no")))
#+end_src

Obviously, you can elaborate `my-eval-p' to satisfy individual needs.

Best,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

[Berry, Charles]

> On Dec 16, 2021, at 8:51 PM, Kyle Meyer  wrote:
> 
> Rudolf Adamkovič:
> 
>> I have a .org file with two kinds of src blocks:
>> 
>> 1. sqlite blocks
>> 2. bibtex blocks
>> 
>> I want to execute all sqlite blocks with org-babel-execute-buffer.
>> 
>> When I try to do so, org-mode complains:
>> 
>> org-babel-execute-src-block: No org-babel-execute function for bibtex!
>> 
>> I know I can work around the problem (as one does in org-mode) with:
>> 
>> #+property: header-args:bibtex+ :eval no
>> 
>> Then, why not skip the irrelevant blocks, the ones with no execute 
>> functions, by default?


If I have a typo in the name of a language, the error message you quote tells 
me what my mistake was. 

I'd say that is a feature, not a bug.

HTH,
Chuck

> 
> I don't know, but I've reassigned this bug in order to redirect this to
> the Org list, which serves as the primary place for Org development and
> discussion.
> 

:eval yes use and documentation

[Charles Millar]

Org mode version 9.5.1 (release_9.5.1-279-g8908fb @ 
/usr/local/share/org-mode/lisp/)
GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, 
cairo version 1.16.0) of 2020-12-31


Here is a use case.

I have many files each with as many as 60 tables that are generated 
using ob -rec. So that the tables are not evaluated during export it is 
convenient for me to set a buffer wide


#+PROPERTY: header-args :eval never-export.

On other hand, each file may also include, under a sub-tree latex source 
code blocks for signature lines, letter heads, etc.


In another sub-tree, called correspondence, those source code blocks are 
called using :noweb yes, such as


  #+begin_src latex :noweb yes
  <>
  #+end_src

\begin{center}
\today
\end{center}

[Body of letter]

  #+begin_src latex :noweb yes
  <>
  #+end_src

If I include in the correspondence sub-tree
:PROPERTIES:
:header-args: :eval yes
:END:

the results are a complete letter, i.e. letterhead followed by the body 
and then signature line.


If I do not include the ":eval yes" property in the sub-tree, only the 
body of the letter results, as expected.


So after all that, here are some questions:

Is ":eval yes" officially allowed and, if so, why is it not documented?

Should it be?

May its use be inferred from other examples such as those from :cache or 
colnames?


I found the following discussion, but it is fairly old:

https://emacs.stackexchange.com/questions/2945/org-babel-eval-with-no-confirmation-is-explicit-eval-yes

Charlie Millar

Re: reference a remote named block in #+CALL: line

[Berry, Charles]

Matt,

> On Nov 2, 2021, at 3:19 AM, Matt Price  wrote:
> 
> I am getting used to calling library-of-babel functions with local data 
> structures as input variables, e.g. in this line:
> 
> #+CALL: list2table(data=common-issues-list, order="rows") :results  table  
> raw 
> 
> where `common-issues-list` is a named org-mode list in the current file, e.g. 
> 
> #+NAME: common-issues-list
> - some
> - things
> - here
> 
> In this particular case, I'd like to maintain a single data structure and use 
> it in a bunch of places (it's a document I re-use in several courses, all of 
> which are published online with different metadata stored in headings). Is 
> there a syntax for referring to #+NAME'd elements in remote files?
> 
> Sorry if I'm missing something that is explained in the docs -- I am not 
> finding this in what I think of as the obvious places.  
> 

AFAIK, there is nothing like this.

However, it looks like it would be easy to modify `org-babel-lob-ingest' by 
adding another argument giving the name (or a list of names) of src blocks that 
you want added to `org-babel-library-of-babel' by replacing the `when 
source-name' with something like `when (member source-name only-these-names)' 
so only src blocks you want to invoke are ingested.

HTH,

Chuck

Re: [PATCH] async process in R

[Berry, Charles]

Jeremie,

> On Sep 28, 2021, at 12:34 AM, Jeremie Juste  wrote:
> 
> Thanks for the feedback. With the following patch, I made sure that
> ess-inject-source is set to default before evaluating the buffer.
> 
> So even if I set
> (setq ess-inject-source 'function-and-buffer), I get the following
> output. Note that I get the same output in the IESS console buffer when
> I execute the command following command.
> 
> #+begin_src R :session *R*  :results output :async yes
>  Sys.sleep(2)
>  1:5
> 
>  10:20
>  1:2
> #+end_src


OK. The patch works when applied on top of the previous 2 (but the second one 
has the same name, so there is that to watch out for).

However, I think we are not quite home free. With `:async no', this works as 
expected:

#+begin_src R :session *R*  :results output :async no
  Sys.sleep(2)
  1:5
  10:
a
  1:2
#+end_src

#+RESULTS:
: 
: [1] 1 2 3 4 5
: 
: Error: object 'a' not found
: 
: [1] 1 2


But changing to `:async yes', the error aborts in a way that omits the output.

HTH,
Chuck

Re: [PATCH] async process in R

[Berry, Charles]

Jeremie,

> On Sep 27, 2021, at 3:56 PM, Berry, Charles  wrote:
> 
> There is something in my init that doesn't play nice with this.  



(setq ess-inject-source nil)


seems to be the culprit.


Also note, even with ess-inject-source set to t, there is an indentation issue:

#+begin_src R :session *R*  :results output :async yes
Sys.sleep(2)
1:5

10:20
#+end_src

#+RESULTS:
: [1] 1 2 3 4 5
:  [1] 10 11 12 13 14 15 16 17 18 19 20



HTH,

Chuck

Re: [PATCH] async process in R

[Berry, Charles]

Jeremie,


There is something in my init that doesn't play nice with this.  

IOW, emacs -q and then load the minimal stuff works OK, but my usual startup 
does not.

#+begin_src R :session *R*  :results output :async yes
Sys.sleep(5)
1:5
#+end_src

#+RESULTS:
: > > 
: [1] 1 2 3 4 5
: >

It may take me a while to figure out what it is.

:-(

HTH,

Chuck


> On Sep 27, 2021, at 1:28 PM, Jeremie Juste  wrote:
> 
> Hello Chuck,
> 
> On Monday, 27 Sep 2021 at 18:28, Berry, Charles wrote:
>> 
>> It looks like you have `(setq ess-eval-visibly t)' here. I think that is a 
>> default setting.
> 
> Thanks again for your suggestion. The following patch to be applied on
> top of the previous one, solves the issue.
> 
> 
> #+begin_src R :session *R*  :results output :async yes
> Sys.sleep(5)
> 1:5
> #+end_src
> 
> #+RESULTS:
> : [1] 1 2 3 4 5
> 
> 
> The function (ess-eval-buffer), when the parameter VIS is nil,  misled me in 
> the sense that it inverses
> the value of ess-eval-visibly.
> 
> Note as well that all the tests in test-ob-R.el passed including the
> tests for async evaluation from [1] ob-session-async.
> 
> [1]: 
> https://urldefense.com/v3/__https://github.com/jackkamm/ob-session-async/__;!!LLK065n_VXAQ!wfTTIQ1fHIH2f6FmnUYZow4BoKA9_bQyOgBdm4tgLfJxbDF0vVs4sTbSQ0Zm-7YjVg$
>  .
> 
> <0001-ob-R.el-Patch-async-evaluation-when-results-output.patch>
> Thanks again to Jack for this useful feature.
> 
> Best regards,
> Jeremie

Re: [PATCH] async process in R

[Berry, Charles]

Jeremie,

> On Sep 26, 2021, at 10:13 AM, Jeremie Juste  wrote:
> 
> But for the time being result output produces the following output.
> 
> #+begin_src R :session *R*  :results output :async
> Sys.sleep(1)
> print(1:5)
> #+end_src
> 
> #+RESULTS:
> : > Sys.sleep(1)
> : > print(1:5)
> : [1] 1 2 3 4 5
> : > 'ob_comint_async_R_end_53c0a42fed17cf78f5508e5293029430'
> 
> 
> From my understanding the async command of python does not suffer from
> this issue. I'm not sure if the issue needs to be solve at the ob-R.el
> or at the ob-core.el. I welcome any comments on this patch or any idea
> to move it forward.


It looks like you have `(setq ess-eval-visibly t)' here. I think that is a 
default setting.

With (setq ess-eval-visibly nil), I get 

#+RESULTS:
: > 
: [1] 1 2 3 4 5
: > >


which is better, but the prompts still need cleaning along the lines of 
`org-babel-R-evaluate-session'.

It seems like this is an ob-R.el issue.

HTH,
Chuck

Re: Org babel source blocks ignore buffer-local variables

[Berry, Charles]

> On Sep 6, 2021, at 1:53 AM, Dominik Schrempf  
> wrote:
> 
> Thank you, this solution works. May I ask about the reasons of such a
> distinction?


[i.e. between exec-path and (getenv "PATH")]

Well, this is how `shell' and `shell-command-on-region' both do it, and they 
seem to be the underlying engines.  So you might ask elsewhere why it is so.

There are probably a lot of circumstances in which the distinction makes sense 
in babel shell blocks. 

You would not want to use exec-path if your src block was being executed 
remotely, for example.

I think different shells can sensibly use different PATH defaults, so that 
might be another circumstance in which the default to exec-path could trip you 
up.

HTH,
Chuck

Re: Org babel source blocks ignore buffer-local variables

[Berry, Charles]

> On Sep 4, 2021, at 5:30 AM, Dominik Schrempf  
> wrote:
> 
> Hello,
> 
> I use directory local environments with =envrc= [1], and run into trouble when
> using (Bash) Org Babel source code blocks. The buffer local environment seems 
> to
> be ignored (see the example at the bottom).
> 
> This seems to have been discussed in the course of a GitHub issue of
> =inheritenv= [2], which is pulled in by =envrc=. Also, on this mailing list,
> there was a short discussion [3].
> 
> Do you have any thoughts on this? Is there an easy way to make Org Babel 
> source
> blocks honor buffer local setups?
> 
> Thank you!
> Dominik
> 
> #+name: Scratch
> #+begin_src sh :exports both :results output verbatim
> function path () { echo "$PATH" | tr ':' '\n'; }
> path
> #+end_src
> 
> #+RESULTS: Scratch
> #+begin_example
> /home/dominik/Evolutionary-Biology/Scripts/nix-flakes
> /home/dominik/Evolutionary-Biology/Scripts
> /home/dominik/bin/nix-flakes
> /home/dominik/bin
> /run/wrappers/bin
> /home/dominik/.nix-profile/bin
> /etc/profiles/per-user/dominik/bin
> /nix/var/nix/profiles/default/bin
> /run/current-system/sw/bin
> /nix/store/3l9lddwxz1mayaxvw8iy50ygzzfh1s1b-emacs-27.2/libexec/emacs/27.2/x86_64-pc-linux-gnu
> #+end_example
> 
> The Emacs =exec-path= variable has the following value:
> 
> #+begin_quote
> exec-path is a variable defined in ‘C source code’.
> Its value is
> ("/nix/store/cnxncxyghj3gfpfvng6z4l8k4hfl48wq-ghc-8.10.6-with-packages/bin/" 
> "/nix/store/435paza0j48aa9vgvf6r2l12nrg4ld11-patchelf-0.12/bin/" 

[snip]

Indeed, ~exec-path~ and ~(getenv "PATH")~ can differ.

If you want to set PATH for a shell src block, you can do something like:

#+begin_src sh :results output verbatim :var PATH=(mapconcat 'identity 
exec-path ":")
  echo $PATH
#+end_src

HTH,

Chuck

  

Fwd: Greater than, less than bug in emacs-lisp source block

[Charles Millar]

Thank you, Arthur.


 Forwarded Message 
Subject: Re: Greater than, less than bug in emacs-lisp source block
Date: Fri, 03 Sep 2021 00:36:23 +0200
From: Arthur Miller 
To: John Kitchin 
CC: Charles Millar , emacs-orgmode@gnu.org 



John Kitchin  writes:


I think this issue is described in
https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch.
 There are also some
solutions there.


I wasn't able to get that to work in my Emacs. I did something simpler 
though,

that seems to work for me:

#+begin_src emacs-lisp
(defmacro gt (n1 n2)
  `(> ,n1 ,n2))

(defmacro gte (n1 n2)
  `(>= ,n1 ,n2))

(defmacro lt (n1 n2)
  `(< ,n1 ,n2))

(defmacro lte (n1 n2)
  `(<= ,n1 ,n2))

;; example usage

(dolist (s templist)
 (while (lt (length s) l)
 (setq s (concat s " ")))
 (push (concat "[ " s " ]") kwdlist))

#+end_src

re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Charles Millar]

Thank you, John.

I will give it a try.

However, is this a bug that should be fixed within org source code?

Charlie Millar


On 9/2/21 2:24 PM, John Kitchin wrote:

I think this issue is described in
https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch.
There are also some solutions there.


John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Thu, Sep 2, 2021 at 2:10 PM Charles Millar  wrote:


Set up:
GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+ Version 3.24.23,
cairo version 1.16.0) of 2020-12-31
Org mode version 9.4.6 (release_9.4.6-637-gd70f28 @
/usr/local/share/org-mode/lisp/)

The following code will evaluate

#+begin_src emacs-lisp
(defun Foo ()
(if (= 2 4) bar))
#+end_src

#+RESULTS:
: Foo
and the opening and closing parentheses match.

If a greater than is inserted instead of equals, thus

#+begin_src emacs-lisp
(defun Foo ()
(if (> 2 4) bar))
#+end_src

it apparently evaluates, however, the closing parenthesis immediately
following the "4" is paired with the opening paren before "if" and not
the opening paren immediately before the ">"

A "less than" results with stranger parenthesis matching - the closing
paren after the "4" matches no others; the closing paren immediately
after "bar" matches the opening paren before "if"

Charlie Millar

Greater than, less than bug in emacs-lisp source block

[Charles Millar]

Set up:
GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, 
cairo version 1.16.0) of 2020-12-31
Org mode version 9.4.6 (release_9.4.6-637-gd70f28 @ 
/usr/local/share/org-mode/lisp/)


The following code will evaluate

#+begin_src emacs-lisp
(defun Foo ()
(if (= 2 4) bar))
#+end_src

#+RESULTS:
: Foo
and the opening and closing parentheses match.

If a greater than is inserted instead of equals, thus

#+begin_src emacs-lisp
(defun Foo ()
(if (> 2 4) bar))
#+end_src

it apparently evaluates, however, the closing parenthesis immediately 
following the "4" is paired with the opening paren before "if" and not 
the opening paren immediately before the ">"


A "less than" results with stranger parenthesis matching - the closing 
paren after the "4" matches no others; the closing paren immediately 
after "bar" matches the opening paren before "if"


Charlie Millar

Bug: org-agenda-sort-notime-is-late is not correctly handled by timestamp comparison [9.4.6 (9.4.6-12-gdcc3a8-elpaplus @ /Users/charlestam/.emacs.d/elpa/org-plus-contrib-20210830/)]

[Charles Tam]

org-agenda-sorting-strategy claims that scheduled-up (-down) causes
items to be sorted in ascending (descending) order by scheduled
timestamp.

org-agenda-sort-notime-is-late claims that if it is non-nil, the absence
of a timestamp is treated as being maximal.

Instead, when using the scheduled-up (-down) sorting strategy, with
non-nil org-agenda-sort-notime-is-late, the absence of a timestamp is
treated as being minimal. Note that the documentation is not strictly
wrong; the correct behavior is exhibited for time-of-day comparisons,
just not timestamp comparisons.

Steps to Reproduce:

  (setq org-agenda-sorting-strategy '((agenda scheduled-up)
  (todo scheduled-up)
  (tags scheduled-up)
  (search scheduled-up))
org-agenda-sort-notime-is-late t)

  Place the following text in an org agenda file:

  * Reproduce ordering bug
  ** TODO Early item
 SCHEDULED: <1990-01-01 Mon>
  ** TODO Late item
 SCHEDULED: <2020-01-01 Wed>
  ** TODO Unscheduled item

  (Replace TODO with any non-DONE todo state if you need to.)

  Place the point on the "Reproduce" item and `M-x org-agenda < < t`
  (that is, list all TODO items restricted to the "Reproduce" subtree).

Expected:

  TODO Early item
  TODO Late item
  TODO Unscheduled item

Actual:

  TODO Unscheduled item
  TODO Early item
  TODO Late item

Suggested fix:

  Find `defsubst org-cmp-ts` in org-agenda.el. The definition of `def`
  in the `let*` should be something like

  (if org-agenda-sort-notime-is-late  -1)

(In the state dump below, `org-agenda-sort-notime-is-late` is not mentioned
but has its default value of t.)

Thanks,
Charles

Emacs  : GNU Emacs 27.2 (build 1, x86_64-apple-darwin18.7.0, NS
appkit-1671.60 Version 10.14.6 (Build 18G95))
 of 2021-03-27
Package: Org mode version 9.4.6 (9.4.6-12-gdcc3a8-elpaplus @
/Users/charlestam/.emacs.d/elpa/org-plus-contrib-20210830/)

current state:
==
(setq
 org-roam-db-location "/Users/charlestam/mise/roam/org-roam.db"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-checklist)
 org-capture-prepare-finalize-hook '(org-roam-capture--install-finalize-h)
 org-link-shell-confirm-function 'yes-or-no-p
 org-expiry-wait "+30d"
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-roam-db-node-include-function #[0 "\300\207" [t] 1]
 org-refile-targets '((nil :maxlevel . 2) (org-agenda-files :maxlevel . 1))
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-pretty-entities t
 org-special-ctrl-a/e t
 org-agenda-files '("~/mise/TODO")
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-reveal-start-hook '(org-decrypt-entry)
 org-modules '(org-expiry org-habit ol-w3m ol-bbdb ol-bibtex ol-docview
ol-gnus ol-info ol-irc ol-mhe ol-rmail
   ol-eww)
 org-startup-folded 'showall
 org-archive-location "%s_archive::datetree/"
 org-mode-hook '((lambda nil (font-lock-add-keywords nil '(("{{{.+}}}" 0
'org-macro-face))) (set-fill-column 92))
 #[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 #[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2] turn-on-font-lock
 auto-fill-mode org-eldoc-load)
 org-tags-match-list-sublevels nil
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-expiry-handler-function 'org-toggle-archive-tag
 org-agenda-deadline-faces '((1.0 . org-warning) (0.8 .
org-imminent-deadline) (0.5 . org-upcoming-deadline)
 (0.0 . org-upcoming-distant-deadline))
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-hide-leading-stars t
 org-babel-load-languages '((python . t))
 org-log-done 'time
 org-roam-capture-preface-hook '(org-roam-dailies--override-capture-time-h)
 org-hide-emphasis-markers t
 org-export-backends '(ascii html latex md)
 org-roam-completion-everywhere t
 org-roam-capture-templates '(("d" "default" plain "%?"

proposed additions to org-collector code

[Charles Millar]

First, I thank Slava Barinov for his proposed patch to appending a 
#+tblfm line to an org-collector table. Date: 17 Mar 2019 13:22:58 +0300

Message-ID: <87sgvl4wes@gmail.com> (raw)

Attached is my, in all modesty named, cm-org-collector.el in which I 
have added code to prepend name and attribute headers to the table, for 
example:


* orgcollector experiment
:PROPERTIES:
:ID: test
:END:

** Heading One


** Heading two

#+BEGIN: propview :id "test" :cols (ITEM) :noquote t :defaultval "" 
:tblfm "@>$>" :tblname "That" :tblattributes "#+attr_latex: 
somethingelse" :content ""

#+name: That
#+attr_latex: somethingelse
| ITEM|
|-|
| orgcollector experiment |
| Heading One |
| Heading two |
|-|
| |
#+tblfm: @>$>
#+END:

Please note that the :content param must be set to an empty string on 
the #+BEGIN: propview line. Without doing so, upon evaluation of the 
block, the table is updated; however, the following conditions result:

(error "(user-error Not at a table)")
the #+tblfm line is not replaced but an additional #+tblfm line is 
added, and
the #+name and #+attr headers do not reflect any changes to :tblname and 
tblattributes if made in the propview line.


I realize that org-collector is an orphan and that it requires 
additional documentation. (See Bastien's comments to Slava's message.)


That said, if anyone so desires, please consider these additions, make 
all appropriate changes and corrections and patch them to 
org-coolector.el. I believe that this additional code makes 
org-collector more useful as database tool. Instead of having to add 
headers after evaluation, those headers would be inserted at the correct 
point when the propview is evaluated. The resulting table can be called 
from other code blocks. Also, the #+attr header allows, I believe, for 
exporting as desired. (I tried only a latex to pdf and it worked OK.)


I imagine other header params may be included as well.

Charlie Millar

;;; cm-org-collector --- Eric Schulte's org-collector modified to for Charlie

;; Copyright (C) 2008-2021 Free Software Foundation, Inc.

;; Author: Eric Schulte 
;; Keywords: outlines, hypermedia, calendar, wp, experimentation,
;;   organization, properties
;; Homepage: https://orgmode.org
;; Version: 0.01

;; This file is not yet part of GNU Emacs.

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 3, or (at your option)
;; any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see .

;;; Commentary:

;; Pass in an alist of columns, each column can be either a single
;; property or a function which takes column names as arguments.
;;
;; For example the following propview block would collect the value of
;; the 'amount' property from each header in the current buffer
;;
;; #+BEGIN: propview :cols (ITEM amount)
;; | "ITEM"  | "amount" |
;; |-+--|
;; | "December Spending" |0 |
;; | "Grocery Store" |56.77 |
;; | "Athletic club" | 75.0 |
;; | "Restaurant"|30.67 |
;; | "January Spending"  |0 |
;; | "Athletic club" | 75.0 |
;; | "Restaurant"|50.00 |
;; |-+--|
;; | |  |
;; #+END:
;;
;; This slightly more selective propview block will limit those
;; headers included to those in the subtree with the id 'december'
;; in which the spendtype property is equal to "food"
;;
;; #+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols (ITEM amount)
;; | "ITEM"  | "amount" |
;; |-+--|
;; | "Grocery Store" |56.77 |
;; | "Restaurant"|30.67 |
;; |-+--|
;; | |  |
;; #+END:
;;
;; Org Collector allows arbitrary processing of the property values
;; through elisp in the cols: property.  This allows for both simple
;; computations as in the following example
;;
;; #+BEGIN: propview :id "results" :cols (ITEM f d list (apply '+ list) (+ f d))
;; | "ITEM" | "f" | "d" | "list"  | "(apply (quote +) list)" | "(+ f d)" |
;; |+-+-+-+--+---|
;; | "run1" |   2 |  33 | (quote (9 2 3 4 5 6 7)) | 36   |35 |
;; | "run2" |   2 |  34 | :na | :na  |36 |
;; | "run3" |   2 |  35 | :na | :na 

Re: Number format for table results outut from R data.frame/tibble

[Berry, Charles]

> On Aug 21, 2021, at 9:58 AM, John Hendy  wrote:
> 
> 
> Interesting, and thanks for taking a look. I don't think I specified
> sufficiently that I'm actually aiming for latex/pdf output and
> therefore want the org table. 

John,

If you want a latex export, you should use one of the many R packages[1] that 
format R objects for latex output.

For example:

#+begin_src R :session foo :results output latex
library(tibble)
library(xtable)
tmp <- tibble(x=1:5, y=x/pi)
xtable(tmp)
#+end_src

#+RESULTS:
#+begin_export latex

% latex table generated in R 4.1.0 by xtable 1.8-4 package
% Sat Aug 21 10:23:18 2021
\begin{table}[ht]
\centering
\begin{tabular}{rrr}
  \hline
 & x & y \\ 
  \hline
1 &   1 & 0.32 \\ 
  2 &   2 & 0.64 \\ 
  3 &   3 & 0.95 \\ 
  4 &   4 & 1.27 \\ 
  5 &   5 & 1.59 \\ 
   \hline
\end{tabular}
\end{table}
#+end_export

The xtable() and its print method have loads of options for formatting, setting 
environments and labels, and adding captions.

If you insist on doing this in org without the assistance of an R package, you 
will need to use a `:post' header argument.  If you have solid elisp skills, 
this is a viable option.

HTH,
Chuck

[1] One list of such is at: 
https://stackoverflow.com/questions/5465314/tools-for-making-latex-tables-in-r

Re: Bug: :session results in unfriendly error reporting

[Berry, Charles]

James,

> On Aug 15, 2021, at 4:41 PM, James Powell  wrote:
> 
> I write a deliberate syntax error into a code block:
> 
> : #+begin_src R :session
> :   x <- 1
> :   y xx z
> : #+end_src
> 
> I put my cursor in there and C-c C-c.
> 
> What I expect: a gentle useful report about the error.

Right. But there is no error as far as babel is concerned. R has handled the 
condition. So there is nothing for babel to see/do.


> Maybe even org would move the cursor to the point of the
> error in the org buffer.  If not, at least the buffer
> "*Org-Babel Error Output*" will open and show me the error,
> something like this (see also [1]),
> 
> : Error: unexpected symbol in:
> : "x <- 1
> : y xx"
> : -UUU:@**--F2  *Org-Babel Error Output*   All L17(Compilation etu) 
> 4:13PM 0.53 Mail --$
> 

`:results output' might help you here, since it will send the terminal output 
back to babel.

If that doesn't suffice, you might use handlers provided by R to find your way 
out. But I think that will get sticky as what you create in your example is a 
parse error.  

If the source blocks are eval'ed as part of an export, you have the option of 
exporting via ox-ravel[*] and using the knitr chunk options to handle errors in 
the way you want.

> What happens instead:
> 
> - the *R* buffer is displayed.  It contains a long spammy traceback
>   that has run off of the top of the screen.  To learn more I have to
>   move the cursor into the *R* buffer and page back to the top of the
>   traceback.
> 
> On the other hand, if I set ":session none", I get much friendlier
> behavior.  The Error Output buffer opens with the simple error message
> in it as I showed above when I use this source block:
> 
> : #+begin_src R :session none
> :   x <- 1
> :   y xx z
> : #+end_src
> 

Running R in this fashion starts a fresh process which signals an error that 
babel can handle.  I see no easy way to get sessions to sends signals that 
babel can process.

> I do not want to abandon :session because my code reads in a lot of
> data to get started and I want my scripts, not my environment to be
> "real" so I am not depending on R's ability to save and reload the
> workspace at all [2] or on "Org's (clever and useful but) somewhat clunky
> and inflexible method of passing data explicitly" [3].

One of the motivating factors for creating ox-ravel[*] was to have flexible 
caching of R objects. This is provided in knitr, Sweave, and similar report 
generators. For interactive use, knit-ing a document that has caching enabled 
at the start of a session is a fast and painless way to get all the objects 
needed to modify a document.

HRH,

Chuck

[*] https://github.com/chasberry/orgmode-accessories


> 
> Is there a way to get back to the "Error Output" buffer opening with a
> simple message /while/ having :session being enabled?
> 
> thank you,
>   James P.
> 
> References
> 
> [1] "Currently the only action Babel takes with STDERR is to display it in a
> pop-up buffer when code block evaluation fails" (Eric Schulte in 2012, at
> https://lists.gnu.org/archive/html/emacs-orgmode/2012-03/msg00057.html).
> 
> [2] « what will you save as your lasting record of what happened?
>   [...[ As a beginning R user, it's OK to consider your environment
>   [...]  "real."  However, in the long run, you'll be much better off
>   if you consider your R scripts as "real." » (p. 111, Wickham, H. "R
>   for data science : import, tidy, transform, visualize, and model
>   data" O'Reilly Media, 2016).  To facilitate this, I have disabled
>   'save workspace' permanently:
>   : q <- function (save = "no", status = 0, runLast = TRUE)
>   : .Internal(quit(save, status, runLast))
> 
> [3] «When I look at Org and think of "session-based" blocks, I see a
> potential big benefit in having multiple source-blocks throughout
> my document share the same session»
> (https://lists.gnu.org/archive/html/emacs-orgmode/2011-06/msg00654.html,
> the only good hit for a search for "session Org-Babel Error Output" at
> https://lists.gnu.org/archive/html/emacs-orgmode/ as of
> [2021-08-15 Sun]).
> 
> 
> -- 
> James E. Powell, MS
> Pronouns: he/him/his
> Applied Physics PhD Candidate
> Department of Physics
> Portland State University
> Home page: http://web.pdx.edu/~powellj
> Office: SRTC 409B Phone: +1-503-725-8515
> 
> 
> 

Re: ob-R: Error about longer than max-lines even with :result silent

[Berry, Charles]

> On Aug 15, 2021, at 6:19 AM, Yasushi SHOJI  wrote:
> 
> Hello,
> 
> It seems like the following ECM cause an error:
> Error (org-babel): Error reading results: (user-error "Region is
> longer than ‘org-table-convert-region-max-lines’ (999) lines; not
> converting")
> 
> I assumed that with ":results silent" it shouldn't warn or error about
> the output.  Is it expected or a bug?
> 

This is expected per the `org-babel-insert-result' docstring.

However, the documentation does not mention that `:results none' is an option.  
Is that what you want?

HTH,
Chuck

Re: bug: Error handling in source blocks.

[Berry, Charles]

> On Aug 9, 2021, at 9:13 PM, James Powell  wrote:
> 
>  Error handling is important and hard to get right.  Me, I prefer to
>   treat every warning as an error (-Werror in gcc, "options(warn=2)" in
>   R, etc).  I want the system to grind to a halt at the least sign of
>   trouble.

If the effect of an error is to return no result (as in your example), you can 
use a :post header-arg to check for a nil value in `*this*' and issue a 
user-error. 

Example:

#+name: check-res
#+begin_src emacs-lisp
(or *this* (error "nil result")) 
#+end_src


#+begin_src R :exports both :post check-res()
  x <- f838293483$x8483848
#+end_src


See (info "(org) Results of Evaluation") and scroll to `post-processing' for 
details on the :post header.

The user-error halts export.

HTH,
Chuck

Re: Number format for table results outut from R data.frame/tibble

[Berry, Charles]

John,

> On Aug 6, 2021, at 8:38 AM, John Hendy  wrote:
> 
> Greetings,
> 
> I'm wondering how to align the results from the R buffer (which I
> like) vs. the results printed by Org-mode for table results. Here's a
> toy example:
> 

`tbl_df' objects come with their own print/show method. And it does things like 
add color and text formats. This is nice in a terminal, but not when you want 
to display them in org.

Turning off the color might be enough to give you a usable result:

#+begin_src R :session foo :results output drawer
library(tibble)
options( cli.num_colors=1 )
tmp <- tibble(x=1:5, y=x/pi)
tmp
#+end_src

#+RESULTS:
:results:

# A tibble: 5 x 2
  x y
   
1 1   0.3
2 2   0.6
3 3   1. 
4 4   1. 
5 5   2.
:end:


If this is not close to what you need, I suggest writing your own formatting 
function. If you have limited emacs-lisp skill, I suggest doing this in R.

HTH,

Chuck

Re: Headings and Headlines

[Charles Millar]

On 7/23/21 10:06 PM, Tim Cross wrote:


André A. Gomes  writes:


Hi,

The project's documentation refers to headings and headlines as
synonyms.  Relying on a single definition would be beneficial.  If I had
to choose between the two, I'd go with heading.

If the community finds this valuable, I could prepare a patch.



I think heading is better than headline - to me headline is a line at
the top of the buffer (like a newpaper headline). Note that in addition
to changes in the manual, it will probably be necessary to make changes
to variable and function names in the code. This may require marking
some old names as obsolete and creating aliases to allow a transition to
the new names and avoid breakage etc.



Since org requires outline.el, org.el line 4793, why not follow and 
mirror outline.el conventions?


It appears that outline.el uses
`
"header" for some early set-up(?) functions and

"heading" for what appears to provide the outline itself.

Furthermore, "headline" shows up only in comments, and only four or five 
times, at that.


After all, org is an, "Outline-based notes management and organize."


Best,

Charlie Millar

Re: setting export options in headline properties

[Berry, Charles]

Matt,

Check (info "(org) Export Settings")

and especially, the para near bottom:

When exporting sub-trees, special node properties can override the
above keywords.  These properties have an ‘EXPORT_’ prefix.  For
example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific
sub-tree.  Except for ‘SETUPFILE’, all other keywords listed above have
an ‘EXPORT_’ equivalent.

HTH,

Chuck

> On Jul 21, 2021, at 11:52 AM, Matt Price  wrote:
> 
> Hi,
> 
> I'm not sure if I'm reading the documentation properly, but my understnading 
> is that I ought to be able to set export options as subtree properties, and 
> that if I do so, they should be picked up by export engines when exporting 
> subtrees.  However, that doesn't see to be happening for me, and from what I 
> can tell, `org-export-get-environment` is not overriding global values when 
> passed the `subtreep` parameter.
> 
> I tried the following with emacs -Q , which seems to confirm my issue. Is 
> this the expected behaviour, and if so, is there some other way for me to set 
> subtree-level export options?
> 
> --
> ** subtree
> :PROPERTIES:
> :SUBTITLE: testing
> :REVEAL_TITLE_SLIDE: nil
> :HTML_CONTAINER: section
> :END:
> 
> 
> #+begin_src emacs-lisp 
> (let ((info (org-export-get-environment 'html t)))
>   (string-join `(,(plist-get info :subtitle) ,(plist-get info 
> :html-container)) "\n")
>   )
> #+end_src
> 
> #+RESULTS:
> : 
> : div
> --
> 
> thanks as always!

Re: [PATCH] ob-R output file with graphics parameter

[Berry, Charles]

Jack,

I will be going offline for a week or so, so I will have to defer more 
discussion.

I know that `silent' silences an unwanted file link. 

And there are a few other ways to do this.  

So, if it is determined to proceed, adding an implicit `file' will not prohibit 
uses in which it was not actually wanted.

Best,
Chuck

> On Jul 10, 2021, at 2:00 PM, Jack Kamm  wrote:
> 
> Hi Chuck,
> 
>> If you modify the ECM to change `:exports results' to `:exports
>> none' and clean older fig[12].png's from the directory, the export
>> fails.
> 
> Thanks for this example. I had mistakenly thought that code blocks
> with ":exports none" would be evaluated for side effects, but you are
> right, these blocks are skipped altogether during export.
> 
> Instead, I think this use case could be handled by the ":results silent"
> header. Blocks with that header are evaluated during export, but the
> result is not inserted into the org buffer or the exported document. It
> seems like a more general way to evaluate code blocks for side effects
> only.
> 
> To test this out, you could replace the header arguments in your
> example with:
> 
> ":exports results :results graphics file silent :file fig1.png"
> 
>> So if everyone else is determined to make this change I can live
>> with it.
> 
> I do hope someone submits an RFC, so we can discuss this more
> concretely. I still think it would be nice if we could go back to just
> ":results graphics" to insert a figure. Unfortunately, I'm not currently
> able to propose the patch, as I'm still in limbo w.r.t. my employer
> agreement.

Re: A requires/provides approach to linking source code blocks

[Berry, Charles]

Tim,

> On Jul 8, 2021, at 12:32 PM, Tim Cross  wrote:
> 
> My concern here is with the additional complexity. This is already a
> somewhat complex aspect of org mode and the behaviour you describe can
> effectively be done using noweb, although as you say, not as
> declarative in style.


This (and the rest of what you said) is very well taken.

I share your concern that adding features to an already rich feature suite will 
make babel very difficult to penetrate.

Best,
Chuck

p.s. Extracting code from src blocks need not depend on `org-babel-tangle' and 
friends. Custom exporters have to potential to render code using attribute keys 
and other export features.  And such exporters have the virtue of not adding 
complexity to the org code base.

Re: [PATCH] ob-R output file with graphics parameter

[Berry, Charles]

> On Jul 6, 2021, at 12:20 PM, Jack Kamm  wrote:
> 
> Hi Chuck,
> 
>> Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for 
>> each `y' depending on your setup)
> 
> I don't see the example on your last email, could you try re-attaching
> it?
> 
> Thanks,
> Jack

Mea culpa.

#+begin_src org

  ,* subfig ECM
  :PROPERTIES:
  :EXPORT_FILE_NAME: subfigures.tex
  :EXPORT_OPTIONS: toc:nil
  :EXPORT_LATEX_HEADER: \usepackage{subfig}
  :END:

  ,#+macro: subfig @@latex: 
\subfloat[$1]{\includegraphics[width=0.49\linewidth]{$2}}@@

  ,#+name: sub1
  ,#+begin_src R :exports results :results graphics :file fig1.png
plot(0:1,0:1)
text(0.5,0.5,"Fig 1")
  ,#+end_src


  ,#+name: sub2
  ,#+begin_src R :exports results :results graphics  :file fig2.png
plot(0:1,0:1)
text(0.5,0.5,"Fig 2")
  ,#+end_src


  ,#+begin_figure
  @@latex: {\centering@@
  {{{subfig(First,fig1)}}}
  {{{subfig(Second,fig2)}}}
  @@latex: }@@
  ,#+end_figure
#+end_src

Re: [PATCH] ob-R output file with graphics parameter

[Berry, Charles]

> On Jul 6, 2021, at 8:04 AM, Jack Kamm  wrote:
> 
> Hello again,
> 
>>> A user might like to construct a figure consisting of various subfigures 
>>> such as in a subfloat environment.
>>> 
>>> Will this be reasonably simple to accomplish if `:results graphics' (with 
>>> no `file' element) automatically inserts a link?
>>> 
>>> Currently, omitting the file element leaves the link out, which I believe 
>>> is the most direct way to approach subfloats.
>> 
>> Thanks for bringing up this use case, it hadn't occurred to me before.
> 
> Thinking about this more, it occurred to me that the ":exports code" or
> ":exports none" header should already handle this.
> 
> When that header is set, the graphics result won't be added to the latex
> document, and the user can construct the subfigure separately in latex.
> 
> Then we wouldn't need to support the use-case of ob-R creating a graphic
> but not producing a result from it...which still feels a little strange
> to me, to be honest.
> 
> Or am I missing something still?


Well, if the src blocks export nothing, the graphics results are not produced 
and no files are created. 

Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for each 
`y' depending on your setup)


1) Produces two graphics files:
   - fig1.png
   - fig2.png

2) Produces file `subfigures.pdf` with a page with one figure containing those
   subfigures rendered side-by-side.

If you modify the ECM to change `:exports results' to `:exports none' and clean 
older fig[12].png's from the  directory, the export fails.

Of course, there are workarounds to having Type=file implied by 
Format=graphics. So if everyone else is determined to make this change I can 
live with it.

Best,
Chuck


 

Re: using previous =#+results= when =:eval never=

[Berry, Charles]

> On Jul 3, 2021, at 10:19 PM, Greg Minshall  wrote:
> 
> Chuck,
> 
> thanks.  (i'm not surprised at an e-lisp suggestion from you! :)
> 
> i worry about accidental modification of the base case results during
> the chaos of development.  it occurs to me (reading through
> (org-babel-ref-resolve)) to keep my base case source blocks marked with
> [:results silent], which should prevent accidental modification. (*)
> 

This seems unnecessary. 

Be warned that the behavior of `org-babel-update-intermediate` is not intuitive 
- at least to me.  My reading of the doctstring is that the result of a named 
src block can be changed when it is non-nil. AFAICS, this never happens.  
Instead, the return value from `org-babel-ref-resolve` is copied from the named 
result.

For your ECM, after deleting the `:eval never`, if I append `+ 1` to the 
`mtcars[1:3,]` and execute then next src block, I get 

#+begin_src emacs-lisp
(compare-old-to-new "testcountsdecompose")
#+end_src

#+RESULTS:
: Comparison failed for block testcountsdecompose

and the original in-buffer value did not change.

I can remove the `+ 1` and rerun the above block and the result is `t`

HTH,

Chuck

> then, i would change [:results silent] to, e.g., [:results silentx], in
> the base case source blocks whenever i wanted to re-create those
> results.
> 
> for, e.g., inspecting the results when things differ, it would be nice
> to stay in the language of the rest of the code.  but i suspect i'll be
> able to do some e-lisp magic on the RHS of a :var, e.g., crudely
> 
> : #+begin_src R :var basecaseresults=(org-babel-read-named-result 
> "testcountsdecompose")

> 
> i'll play around with it.  (i suspect i'll be motivated to use an e-lisp
> macro, to eliminate the quotes, for example.)
> 
> again, thanks.
> 
> cheers, Greg
> 
> (*) this relies on current org-mode behavior, where
> (org-babel-read-result) will return results from a result block from a
> source block marked [:results silent].  i have no idea how likely this
> behavior is to change in the long run.

Re: using previous =#+results= when =:eval never=

[Berry, Charles]

> On Jul 3, 2021, at 9:35 AM, Greg Minshall  wrote:
> 
> hi.
> 
> i am trying to simplify adding regression test cases to a program.
> 
> to generate the base, "compared-to" results, i want to write some code
> in a source block, then evaluate it, producing the "true" value.
> 
> then, later during development, i want to check if the code that ran in
> that block gives the same results.  to do this, i preface the test check
> block with, e.g., =:var fu=bar=.  obviously, i do *not* want to
> re-create the base results; so, after producing the base case results, i
> tried marking the source block that produces the results =:eval never=.
> 
> but, doing that, using `:var fu=bar` on a test check source block, fu's
> value is nil. (*)
> 
> is there a way to convince org-mode to, in the face of =:eval never=, go
> ahead and pass the *previous* results?  or, some other idea of how to do
> this?  there will be a large number of these test cases.
> 
> cheers, Greg


Greg,

I think it would be easier to leave :eval alone and instead evaluate the src 
block using `org-babel-ref-resolve' and compare to the current value. Something 
like this is a start:


#+begin_src emacs-lisp
  (defun org-babel-read-named-result (blkname)
(save-excursion
  (org-babel-goto-named-result blkname)
  (org-babel-read-result)))
#+end_src


#+begin_src emacs-lisp
(defun compare-old-to-new (refname)
  (let ((new (org-babel-ref-resolve refname))
(old (org-babel-read-named-result refname)))
(or (equal old new)
(format "Comparison failed for block %s" refname
#+end_src

Then eval'ing `(compare-old-to-new "testcountsdecompose")` for the ECM you gave 
will give `t` if the result is the same and return a string saying which block 
failed the test.

I suppose you could loop thru `(org-babel-src-block-names)` if you want to 
check all the named blocks in a file.

HTH,

Chuck


> 
> (*) this is sort of confusing, so here's an example:
> 
> #+begin_src org
>  ,#+name: testcountsdecompose
>  ,#+begin_src R :eval never
>mtcars[1:3,]
>  ,#+end_src
> 
>  ,#+RESULTS: testcountsdecompose
>  |   21 | 6 | 160 | 110 |  3.9 |  2.62 | 16.46 | 0 | 1 | 4 | 4 |
>  |   21 | 6 | 160 | 110 |  3.9 | 2.875 | 17.02 | 0 | 1 | 4 | 4 |
>  | 22.8 | 4 | 108 |  93 | 3.85 |  2.32 | 18.61 | 1 | 1 | 4 | 1 |
> 
>  ,#+name: testcounts
>  ,#+header: :var testcountsdecompose=testcountsdecompose :results output
>  ,#+begin_src R
>str(testcountsdecompose)
>  ,#+end_src
> 
>  ,#+RESULTS: testcounts
>  :  chr "nil"
> #+end_src
> 
> whereas, if the =testcountsdecompose= source block does *not* have
> =:eval never=, my =testcountsdecompse= variable has all the rows and
> columns i was hoping for.
> 
> 

Re: [PATCH] ob-R output file with graphics parameter

[Berry, Charles]

Sorry if I have misunderstood the proposals here, but ...

A user might like to construct a figure consisting of various subfigures such 
as in a subfloat environment.

Will this be reasonably simple to accomplish if `:results graphics' (with no 
`file' element) automatically inserts a link?

Currently, omitting the file element leaves the link out, which I believe is 
the most direct way to approach subfloats.

If you deem it important to have the default behavior of `:results graphics` 
generate a link, maybe you can assure that there is a mechanism to avoid 
inserting the link when that is what the user wants.

Best,
Chuck
> On Jul 2, 2021, at 9:21 PM, Jack Kamm  wrote:
> 
> Hi Jeremie,
> 
>>> The requirement for a second file parameter was added in Org 9.3 to
>>> support the use case in this thread:
>>> 
>>> https://urldefense.com/v3/__https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/__;!!LLK065n_VXAQ!wrIx4O0aTDnjRc6QXnCty-Wf2_U0nrUvZzibHsZuLd3mjHpT9S5oQZbENlolMfVxcA$
>>>  
>>> 
>>> But this syntax is annoyingly verbose for ob-R users, and also broke
>>> lots of ob-R examples prior to Org 9.3.
>>> 
>>> A simple fix might be to have the "graphics" flag implicitly add the
>>> "file" flag as well. But we would need to first check that this doesn't
>>> break other use cases.
>> 
>> I do agree with this solution. If the current specification works, we
>> could make it easy for ob-R user by implicitly adding a file flag. But
>> as far as I understand, the change will have to be made in ob-core.el.
> 
> Hmm, I think you're right -- this would have to be done in ob-core.el.
> 
> I think it would still make sense though, and would be beneficial beyond
> ob-R. According to [1], the "graphics" and "link" arguments don't do
> anything unless used with "file", so it would make sense for them to
> automatically add the "file" argument.
> 
> [1] 
> https://urldefense.com/v3/__https://orgmode.org/manual/Results-of-Evaluation.html*Results-of-Evaluation__;Iw!!LLK065n_VXAQ!wrIx4O0aTDnjRc6QXnCty-Wf2_U0nrUvZzibHsZuLd3mjHpT9S5oQZbENlqSa5Lb1Q$
>  

Re: Passing a variable into an R source block.

[Berry, Charles]

> On May 28, 2021, at 8:52 AM, Roger Mason  wrote:
> 
> Hello,
> 
> I have an SQL source block that returns this:
> 
> #+RESULTS: query
> 
> 

[snip]

> I would like to pass this into R for further processing.  At the moment
> I have this:
> 
> #+begin_src R :session :colnames yes :var data=query
>  r <- data.frame($data)

[snip]

data.frame($data) is not valid R syntax. If you are new to R doing some 
tutorials will help.

I suggest you use C-c C-v C-v (org-babel-expand-src-block) to see what the R 
code is and debug the result given in the the *Org Babel Preview...* buffer.

HTH,
Chuck

Re: when executing a src block with latex construct, display problem because of +

[Berry, Charles]

Uwe,

You used `:exports code :eval never-export' (from an earlier posting). 

I think you want `:exports both :eval never-export' to keep babel from removing 
the results.

HTH,
Chuck

> On May 15, 2021, at 1:18 PM, Uwe Brauer  wrote:
> 
> Chuck, 
>> Uwe,
>> [snip]
> 
> 
>> [screenshot deleted]
> 
>> Oh, I misunderstood.
> 
>> The result looks like latex. So why not use `:results output latex' ?
> 
> I tried that also, then however the result is 
> #+RESULTS:
> #+begin_export latex
> \begin{align*}
> P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\
> P(\text{No-Covid19}) &= 1- P(\text{Covid19}) = 1-0.1=0.9\\ 
> P(\text{+}|\text{No-Covid19}) &= 1-P(\text{-}|\text{No-Covid19}) = 
> 1-0.95=0.05 \\ 
> &=\frac{0.95 \cdot 0.1}{0.95\cdot0.1 + (1-0.95)\cdot 0.9}\\ 
> P(\text{Covid19}|-)&=0.608696 \\ 
> P(\text{No-Covid19}|+)&=1-P(\text{Covid19}|+)=0.391304 \\ 
> \end{align*}
> #+end_export
> 
> That is ok for displaying, but if I now want also to export this org
> file to latex, the align construct is not exported, sigh. 
> 
> As the great philosopher M. Jagger said:
> 
> «You Can't Always Get What You Want»

Re: when executing a src block with latex construct, display problem because of +

[Berry, Charles]

Uwe,

[snip]

> On May 15, 2021, at 11:10 AM, Uwe Brauer  wrote:
> 
> Thanks, it did not help. To make this clear the problem occurs in the
> result block, not in the source block. 
> 
> 
> 
> That is exported to 
> #+RESULTS:
> \begin{align*}
> P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\
> P(\text{No-Covid19}) &= 1- P(\text{Covid19}) = 1-0.1=0.9\\ 
> P(\text{+}|\text{No-Covid19}) &= 1-P(\text{-}|\text{No-Covid19}) = 
> 1-0.95=0.05 \\ 
> &=\frac{0.95 \cdot 0.1}{0.95\cdot0.1 + (1-0.95)\cdot 0.9}\\ 
> P(\text{Covid19}|-)&=0.000139982 \\ 
> P(\text{No-Covid19}|+)&=1-P(\text{Covid19}|+)=0.99986 \\ 
> \end{align*}
> 
> 
> I attach a screenshot just in case
> 
> Uwe 

[screenshot deleted]

Oh, I misunderstood.

The result looks like latex. So why not use `:results output latex' ?

HTH,
Chuck 

Re: when executing a src block with latex construct, display problem because of +

[Berry, Charles]

Uwe,

> On May 15, 2021, at 6:31 AM, Uwe Brauer  wrote:
> 
> 
> Hi 
> 
> I have the following src block
> 
> #+begin_src matlab :results output raw :exports code  :eval never-export
> addpath /home/oub/ALLES/HGs/Matlab-init/Statistic
> sens=0.7;
> spec=0.95;
> aspec=1-spec;
> prob=0.1;
> sal=1-prob;
> [bp,bpinv,bn,bninv]=mibayes(sens,spec,prob);
> disp('\begin{align*}')
> disp('P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\')
> fprintf('P(\\text{No-Covid19}) &= 1- P(\\text{Covid19}) = 1-%g=%g 
> \n',prob,sal)
> fprintf('P(\\text{+}|\\text{No-Covid19}) &= 1-
> P(\\text{-}|\\text{No-Covid19}) = 1-%g=%g  \n',spec,aspec)
> fprintf('&=\\frac{%g \\cdot %g}{%g\\cdot%g + (1-%g)\\cdot %g} 
> \n',spec,prob,spec,prob,spec,sal)
> fprintf('P(\\text{Covid19}|-)&=%g  \n', bp);
> fprintf('P(\\text{No-Covid19}|+)&=1-P(\\text{Covid19}|+)=%g  \n', bpinv);
> disp('\end{align*}')
> #+end_src
> 
> That is exported to 
> #+RESULTS:
> \begin{align*}
> P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\
> P(\text{No-Covid19}) &= 1- P(\text{Covid19}) = 1-0.1=0.9\\ 
> P(\text{+}|\text{No-Covid19}) &= 1-P(\text{-}|\text{No-Covid19}) = 
> 1-0.95=0.05 \\ 
> &=\frac{0.95 \cdot 0.1}{0.95\cdot0.1 + (1-0.95)\cdot 0.9}\\ 
> P(\text{Covid19}|-)&=0.000139982 \\ 
> P(\text{No-Covid19}|+)&=1-P(\text{Covid19}|+)=0.99986 \\ 
> \end{align*}
> 
> Now in my org mode file, the lines between the +
> 
> \text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\
>  
> 
> Get a overstrike.
> 
> How can I avoid that?


Customize `org-src-lang-modes' adding ` ("matlab" . octave)'.

HTH,

Chuck

Re: displaying equations with ob-latex

[Berry, Charles]

> On May 6, 2021, at 7:39 PM, michael-franz...@gmx.com wrote:
> 
> Ok, I got some progress, I did "C-C C-x C-l" and got the equation.
> 

Great!


> The equation in extremely small though.
> 


Try customizing `org-format-latex-options'. The :scale element controls size. I 
tried 2.0 and it seems like a good value for my screen.

Best,

Chuck

>> Sent: Friday, May 07, 2021 at 1:36 PM
>> From: "Berry, Charles" 
>> To: "michael-franz...@gmx.com" 
>> Cc: "Help Emacs Orgmode" 
>> Subject: Re: displaying equations with ob-latex
>> 
>> 
>> 
>>> On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
>>> 
>>> After I do "C-c C-c", I just get a message saying "Code block evaluation 
>>> complete."
>>> 
>> 
>> 
>> Are you doing this in a buffer that has ONLY the text between the `cut here' 
>> lines and exactly that?
>> 
>> If not, please try it in such a buffer.
>> 
>> It may help to copy and paste as typos in header names or values can be 
>> unnoticed and drastically alter behavior. If your mail client reformats 
>> text, maybe try copy and paste from the mail list archive.
>> 
>> Also, check with point in the src block using C-c C-v C-i that the header 
>> args got processed properly. You should see lines like these in the *Help* 
>> buffer:
>> 
>> ::exportsnone
>> 
>> ::resultsdrawer replace
>> 
>> 
>> If you did it in such a buffer and the buffer is unaltered but still 
>> displays the message, I have to admit that I cannot tell from here what the 
>> problem might be.
>> 
>> On my setup, things behave just as outlined.
>> 
>> When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste 
>> the text to *scratch* and delete the lisp comment at the top, then M-x 
>> org-mode RET, then C-c C-c with point in the src block, answer 'y e s RET' 
>> to the query, I get the equation displayed in the results drawer. And the 
>> export goes OK.
>> 
>> I am using org-version 9.4.5.
>> 
>> HTH,
>> 
>> Chuck
>> 
>> 
>> 

Re: displaying equations with ob-latex

[Berry, Charles]

> On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
> 
> After I do "C-c C-c", I just get a message saying "Code block evaluation 
> complete."
> 


Are you doing this in a buffer that has ONLY the text between the `cut here' 
lines and exactly that?

If not, please try it in such a buffer.

It may help to copy and paste as typos in header names or values can be 
unnoticed and drastically alter behavior. If your mail client reformats text, 
maybe try copy and paste from the mail list archive.

Also, check with point in the src block using C-c C-v C-i that the header args 
got processed properly. You should see lines like these in the *Help* buffer:

:   :exportsnone

:   :resultsdrawer replace


If you did it in such a buffer and the buffer is unaltered but still displays 
the message, I have to admit that I cannot tell from here what the problem 
might be.

On my setup, things behave just as outlined.

When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste the 
text to *scratch* and delete the lisp comment at the top, then M-x org-mode 
RET, then C-c C-c with point in the src block, answer 'y e s RET' to the query, 
I get the equation displayed in the results drawer. And the export goes OK.

I am using org-version 9.4.5.

HTH,

Chuck

Re: displaying equations with ob-latex

[Berry, Charles]

> On May 6, 2021, at 3:08 PM, michael-franz...@gmx.com wrote:
> 
> Did you manage to get the equations displayed, I have tried again and could 
> not do
> it.  It might be beneficial to give more details and some more examples on 
> what to do.
> 

Yes, the one equation was displayed as a preview. 

Maybe I was not clear in my directions so try this bit:

--8<---cut here---start->8---

1. Copy the text between the `cut here' lines to its own org buffer.
2. Place cursor in the eqn1 src block.
3. Type ~C-c C-c~ and respond to any prompt about evaluating with ~y~.
4. An eqn1 results block should appear with a :results: drawer
   containing an equation in it.
5. Type ~C-c C-x C-l~.
6. The equation should be previewed in the :results: drawer.
7. Export to LaTeX Buffer with ~C-c C-e C-b l L y~ 
8. Only an enumerate environment and the equation should appear in the
   LaTeX buffer.

#+name: eqn1
#+begin_src latex :exports none :results drawer 
  \(y = x\beta + \epsilon\)
#+end_src

#+call: eqn1() :results latex

--8<---cut here---end--->8---




> Can I export on a window that is to right window of the code window?

IIUC, the question is 

:  when I export (as in item 5 in the list above), will the LaTeX buffer
:  open in a window to the right of the one containing the org buffer?

This is what happens in my setup when I have the org buffer displayed in a 
frame with just one window.

But how windows are displayed depends on many factors. See (info "(emacs) 
Windows") for some of the details. So you may need to customize or resize your 
frame to get the same behavior.


>  I can one use plain
> tex commands.  Texinfo mainly supports plain tex, org mode in basically 
> latex, so the
> two programs do not currently work well together.
> 

Um, I don't see how this gets to the original question.

> Texinfo has the good feature to show equations (but only for plain tex) 
> whereas org
> is good with latex (but not very adept at displaying the output in an emacs 
> window).

There are probably a lot of opinions in the org community about how well org 
handles previewing output. For me it works well. YMMV.

HTH,

Chuck

Re: displaying equations with ob-latex

[Berry, Charles]

> On May 6, 2021, at 12:50 AM, michael-franz...@gmx.com wrote:
> 
> 
> I am trying to use ob-latex but equations are not being displayed in emacs
> when I try to execute with "C-c C-c".

Right. This is because `:results latex replace' is the default for latex src 
blocks and the leads to wrapping everything in a latex export block. 

The context inside that block is `export-block' - i.e. it is not a 
`greater-element' and cannot contain other elements.  AFAIK, there is not 
previewer for export blocks - latex or otherwise.

The context for an equation inside a greater-element is latex-fragment. And 
those can be rendered via `org-latex-preview'.

If you want to render equations for previewing, you could put them into a 
drawer that is not repeated in the export.

To make this work, you probably want something like this

#+begin_src org

  ,#+name: eqn1
  ,#+begin_src latex :exports none :results drawer 
  \(y = x\beta + \epsilon\)
  ,#+end_src

 
  Here is the equation for export:

  ,#+call: eqn1() :results latex

#+end_src

Evaluating the latex src block (C-c C-c) will create a `results' drawer line 
this:

#+RESULTS: eqn1
:results:
\(y = x\beta + \epsilon\)
:end:

but the `:exports none' will strip that out on export. The call line will 
create this on export:

#+RESULTS:
#+begin_export latex
\(y = x\beta + \epsilon\)
#+end_export


HTH,

Chuck

Re: Is it possible to #+include: src blocks and tangle them too?

[Berry, Charles]

Hi Greg,

> On Apr 16, 2021, at 8:27 AM, Greg Minshall  wrote:
> 
> Rama,
> 
> one other comment/suggestion.
> 
>> I haven’t been able to fully work with Donald Knuth’s suggestion of
>> writing a Literate Program directly in a tool like orgmode/noweb since
>> it is a nuisance to keep having to type C-c ' to go into the editing
>> mode of the language concerned.
> 
> while i have not much experience with it, you might look at the emacs
> packages polymode, poly-org, and poly-whatever-other-languages-you-use.
> it seems as if they might give you [C-c ']-like behavior when editing
> source blocks in line in an org mode buffer.
> 
> (others who use polymode: does this make sense?)


I have tried it a few times, but not had satisfactory results. 

I use mostly R src blocks, so I want to have ESS like functionality. And I 
really like to be able to execute src blocks with 
`org-babel-execute-src-block'. 

Unfortunately, it seems like polymode gets into conflicts with org mode from 
time to time. My memory is a bit dim on exactly the issues, but I think there 
were freezes. Maybe turning off all the stops and whistles in org mode (like 
fontification) would solve this, but I never gave it a go. 

Having said that, I will say it is easy enough to install and try out. And 
perhaps your mileage will vary.

Best,
Chuck

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Berry, Charles]

> On Mar 31, 2021, at 9:41 AM, Timothy  wrote:
> 
> I anticipate that this change may be somewhat contentions because ox-md
> explicitly follows only the original Markdown spec from 2003, however
> I've thought this over and come to the conclusion that this change is
> still in keeping with that, and beneficial.


Will this handle LaTeX macros[1] gracefully and other things intended as raw 
LaTeX?

Best,
Chuck

[1] https://pandoc.org/MANUAL.html#latex-macros

Re: org-capture-template: table lines including newline of sorts

[Charles Millar]

On 3/16/21 3:34 AM, Uwe Brauer wrote:


> On 3/15/21 5:00 PM, Uwe Brauer wrote:
> My bad; I did not pay attention to a four line comment, so here it is
> again, with the comment and final line for the template, etc.

> (setq org-capture-template '(

> . . . some capture templates

> ("s" "timeslip" table-line
> (file "/mnt/Data/ActiveFiles/timeslips.org")
>;;  (file "d:/ActiveFiles/timeslips.org")
>  "\| %(org-read-date)\| %^{FileName} %i\|
>  %^{Narrative} %i\| %^{Time} %i\| %^{Expense} %i"

> ;; Note that there is no escape and pipe after the final content input
>expansion
> ;; if there were a \| then an empty column is added
> ;; (org-read-date) added 2013-07-12; see Sacha Chua's use of same as in
> ;; the ledger templates below.
>  :empty-lines 1)

> , , , some more capture templates

> ))


I still obtain

| Bad template


Even copying your code without any modifications! I am running org
9.3.7

I'm running org 9.4.4 and emacs 28.0.50, (both from source) on Debian 
testing. According to my notes in my init file I created the template in 
early July 2011, modified it slightly two years later. I do not recall 
any problems with it.


Just to  make sure that there is no problem with the timeslips template, 
at least on my system, I commented out all of the capture templates 
before and after the timeslips template and reloaded my init file. I ran 
org-capture (bound to C-cm). The timeslips came up in the dispatcher and 
it ran OK.


I notice that I was off by a key and typed periods and not semicolons in 
the two lines "some capture templates," and, "some more capture templates."


Charlie Millar

Re: org-capture-template: table lines including newline of sorts

[Charles Millar]

On 3/15/21 5:00 PM, Uwe Brauer wrote:

"CM" == Charles Millar  writes:


> On 3/15/21 10:13 AM, Uwe Brauer wrote:
>>
>>> Hi,
>>> On 3/14/21 1:00 PM, TRS-80 wrote:
>>> You may have to escape the pipes. I did that in a similar capture 
template.
>> Can you give me an example, please?
>>

> HTH

> ("s" "timeslip" table-line
> (file "/mnt/Data/ActiveFiles/timeslips.org")
>  "\| %(org-read-date)\| %^{FileName} %i\|
>  %^{Narrative} %i\| %^{Time} %i\| %^{Expense} %i"

There is a ) missing, no?

I tried

("s" "timeslip" table-line
(file "/home/oub/timeslips.org")
  "\| \| %fromname\|
  :%subject\| %a \| %:date")

But I obtain bad template when executing the code


My bad; I did not pay attention to a four line comment, so here it is
again, with the comment and final line for the template, etc.

(setq org-capture-template '(

. . . some capture templates

("s" "timeslip" table-line
 (file "/mnt/Data/ActiveFiles/timeslips.org")
   ;;   (file "d:/ActiveFiles/timeslips.org")
	  "\| %(org-read-date)\| %^{FileName} %i\| %^{Narrative} 
%i\| %^{Time} %i\| %^{Expense} %i"


;; Note that there is no escape and pipe after the final content input 
expansion

;; if there were a \| then an empty column is added
;; (org-read-date) added 2013-07-12; see Sacha Chua's use of same as in
;; the ledger templates below.
 :empty-lines 1)

, , , some more capture templates

))

Re: Problems while trying to load feature

[Charles R (Charlie) Martin]

This is a problem I’ve noticed as well. Now, I am a programmer — my code or
it’s descendants is still in the distribution — I do update org mode
regularly, and I get messages when I start up Emacs about Org mode files
that can’t be loaded. I wouldn’t be surprised if the cause is this
renaming. But honestly I stopped having time to hack emacs 30 years ago.
Wouldn’t it be desirable if changes that aren’t backward-compatible
included some kind of assistance for users?

On Mon, Mar 15, 2021 at 11:16 Nick Dokos  wrote:

> The renaming was e.g org-bbdb to ol-bbdb, *NOT* to ol-org-bbdb.
>
> Similarly for all the rest: you won't find any of them in any installation.
>
> --
> Nick
>
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
>
>
>

Re: org-capture-template: table lines including newline of sorts

[Charles Millar]

On 3/15/21 10:13 AM, Uwe Brauer wrote:



Hi,
On 3/14/21 1:00 PM, TRS-80 wrote:
You may have to escape the pipes. I did that in a similar capture template.


Can you give me an example, please?



HTH

("s" "timeslip" table-line
(file "/mnt/Data/ActiveFiles/timeslips.org")
	  "\| %(org-read-date)\| %^{FileName} %i\| %^{Narrative} 
%i\| %^{Time} %i\| %^{Expense} %i"



Charlie Millar

Re: org-capture-template: table lines including newline of sorts

[Charles Millar]

Hi,

On 3/14/21 1:00 PM, TRS-80 wrote:

On 2021-03-13 02:24, Uwe Brauer wrote:

Hi

Currently I have the following setting for one org-capture-template:


("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress |
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
)

That line is too long, I'd like something like this
("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress\n
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
)

Or

("mu" "Stat+Num:Exercises English"
table-line (file+headline "~/Somefile.org" "Exercise Group-E")
"| %:fromname|%:fromaddress\n
%(my-extract-cc)|%^{Sheet|1|2|3|4|5|6}|%^{Exercise|1|} |  %a|%:date |
"  :prepend t
"|   | %(my-extract-cc) |   |   |   |   |   |   |    |  |   |   |    |
   | "  :prepend t
)


But nothing worked, any ideas?

Thanks and regards

Uwe Brauer


Do you need to add more pipes to keep the table structure on the line
after the newline?

Cheers,
TRS-80


You may have to escape the pipes. I did that in a similar capture template.

Charlie Millar

Re: org-in-org

[Berry, Charles]

Greg,

> On Mar 7, 2021, at 11:44 PM, Greg Minshall  wrote:
> 
> i guess when i used the term "recursive execute function" (i tend to
> confuse "execute" and "export"), i was thinking of something like: when
> i export an org file, and it runs into an org-in-org block to export,
> then your code runs on that block.  the recursive part is that, when
> your code is runninng on the org-in-org block, and runs into an
> "org-in-org-in-org" block (that is also marked to export), it runs on
> *that*.  ad, but not normally infinitum.

I admit to being baffled by this.

If you have nested org src blocks and you recursively enter each org block 
using `org-edit-special' and execute the src blocks other than org lang, then 
exit with `org-edit-src-exit', when you complete this the org buffer will have 
nested src blocks and results with one or more comma escapes prepended to lines 
that start with `#+` or `*`. 

When you export this, you end up with a document that has the comma escapes 
reduced by one in those nested blocks. The appearance of these is not 
altogether pleasing to my eye.

Have you tried creating a document with nested org src blocks and stepping 
through the recursion to be sure it is something you want and really need?

If you have a particular use case, maybe it can be handled in a one-off manner.

Best,
Chuck

Re: org-in-org

[Berry, Charles]

> On Mar 7, 2021, at 8:14 AM, Greg Minshall  wrote:
> 
> Charles,
> 
> thanks.  any thing you'd like to add to the R-via-ESS/org-mode
> repository, that would be great.
> 
> in general, afaik, the contents of org-in-org buffers export okay.  at
> least plain ones.  would could like to have the embedded code blocks go
> through some pretty-printer, but currently i don't see that as an issue.
> 
> as i mentioned to Jeremie, an issue is getting the org-in-org block to
> do its export.  i don't know if creating a recursive "execute" function
> for org source blocks -- which would cause them (modulo :eval, :exports,
> etc.) to evaluate their source blocks -- might be useful.
> 

Sorry, I do not know what a  `recursive "execute" function' would be/do in this 
context.

---

You said to Jeremie:
 
"during export of the *outer* org document, it could cause
the inner org block(s) to be executed and their results revealed."

AFAICS, the document below does exactly that upon export and can be exported 
using a command line idiom with proper attention to init-file issues (and let 
binding `org-confirm-babel-evaluate' to nil if you want to run in batch mode). 

As an example, html export will create a document that displays a ` block with the R src block named `readdata-code' and 
the `#+RESULTS: readdata-code' block in it. 

--8<---cut here---start->8---
#+begin_src emacs-lisp :exports results :results none
  (org-babel-map-executables nil 
(let ((org-confirm-babel-evaluate nil))
  (org-edit-src-code)
  (org-babel-execute-buffer)
  (org-edit-src-exit)))
#+end_src


#+NAME: readdata-code
#+BEGIN_SRC org
  ,#+NAME: readdata-code
  ,#+BEGIN_SRC R :results output

  read.csv(text="a,b,c\n1,2,3\n4,5,6",header=T) -> mydata1

  summary(mydata1)
  ,#+END_SRC

#+END_SRC
--8<---cut here---end--->8---


If that isn't what is needed, maybe you can provide the desired output when 
exporting the above sans the emacs-lisp src block.


Best,
Chuck

Re: org-in-org

[Berry, Charles]

Greg, 

See inline

> On Feb 23, 2021, at 6:24 AM, Greg Minshall  wrote:
> 
> i have a question about org-in-org source blocks.  i volunteered to help
> in an effort to provide a tutorial of using the ESS (Emacs Speaks
> Statistics) package for R, in particular, from org mode.
> 
> i'd like to write my contribution as a .org file.  i'd like to include
> fragments of org code, including source blocks (in R).  and, i'd like to
> show various result types.  so, i'd like to be able to have the
> #+RESULTS show up in the org-in-org source block as exported inside the
> containing .org file.

I think I get your intention. You want the visual to look like it would if the 
src-edit buffer was opened in emacs as org.

> 
> and, i'd like to trigger all this from a makefile, using some emacs
> batch script to export the containing .org file into a .html or .pdf
> file.
> 
> (i *think*) what i would like to end up with is what it would like if i
> had manually opened the org-in-org source blocks (C-c‌'), then went to
> each (or, possibly, selected, i guess) source blocks inside *that*
> (org-in-org) source block, and executed each, producing a #+RESULTS
> block for each, then closed the org-in-org source block (C-c‌', again),
> and then exported the containing .org file.
> 
> is this possible?  any ideas?


I have two alternative approaches:

1) Add an export engine for "org" to ox-ravel[1]. This is a trivial 
customization of `org-ravel-engines' to add a '("org" . "engine='org'") 
element.  Then add a custom language engine[2] for rmarkdown or knitr.

The actions for the makefile would be a ravel export to generate *.Rmd, *.Rnw, 
or *.Rhtml files followed by rmarkdown::render or knitr::knit on the generated 
files.

2) Define this function:

#+begin_src emacs-lisp
  (defun org-exe-org ()
(let ((org-confirm-babel-evaluate nil))
  (org-edit-src-code)
  (org-babel-execute-buffer)
  (org-edit-src-exit)))
#+end_src

In an org buffer with one or more org src blocks containing R src blocks:

eval this

 (org-babel-map-executables nil (org-exe-org))

Then export the buffer to pdf or html.

I haven't tested this much, but for the snippet below evaluating that line and 
exporting to html produces two framed blocks with R src blocks and the results 
displayed in each:

--8<---cut here---start->8---
#+begin_src org
  ,#+begin_src R
print("abc")
  ,#+end_src
#+end_src


#+begin_src org
  ,#+begin_src R
print("def")
  ,#+end_src
#+end_src
--8<---cut here---end--->8---

I expect doing this in batch mode will not be a challenge.

For pdf output the result is rather plain. Maybe there is some minted idiom 
that would help?

HTH,
Chuck

p.s. I am an `ess-intro' member, in case it helps to move the conversation to 
there.


[1] https://github.com/chasberry/orgmode-accessories

[2] https://bookdown.org/yihui/rmarkdown-cookbook/custom-engine.html 

Re: Org failing to format a link with verbatim text

[Berry, Charles]

> On Feb 17, 2021, at 4:25 PM, Okam  wrote:
> 
> 
> I have attached a minimum working example.  The bad formatting also
> occurs when just pasting the link.  In the example, Org mode highlights
> from beginning of the phrase "=verbatim text 1=" to the end of the
> phrase "=verbatim text 3=" in the verbatim font style. Part of the link
> is hidden as normal, but the text within the region of now verbatim text
> is not hidden, including some of the brackets.
> 
> I have reproduced this without loading a configuration, so it is present
> in version of Org included in the Gccemacs branch of Emacs.
> 
> Does that help?


Yes. Thank You.

Use

#+begin_src emacs-lisp 
(setq org-fontify-emphasized-text nil)
#+end_src

to fix this. Note that an emacs restart is needed. See (info "(org) Emphasis 
and Monospace").

You might complain about the wording that suggests that only exports are 
affected, but I am not sure that claiming the behavior per se is a bug will get 
much traction.

HTH,
Chuck

Re: Org failing to format a link with verbatim text

[Berry, Charles]

> On Feb 16, 2021, at 1:20 PM, Okam  wrote:
> 
> I am using the Emacs gccemacs branch with Org version "9.5-dev".
> I have noticed that when I try to insert the stored link
> 
> file:doc/loopy-doc.org::*Destructuring with =dash=
> 
> and use the heading as the link description, that Org cannot format this 
> link correctly in all circumstances, and tries to make the verbatim text 
> break out from the link.

The last para of (info "(org) External Links") says in part:

#+begin_quote
If spaces must be part of the link (for example in
‘bbdb:R.*Stallman’), or if you need to remove ambiguities about the
end of the link, enclose the link in square or angular brackets.
#+end_quote

To me, this sounds like advice not to drop external links amid normal text. 
i.e. put them in brackets instead.

HTH,

Chuck

Re: [question] lisp code in :results header arg.?

[Berry, Charles]

> On Feb 16, 2021, at 8:30 AM, Juan Manuel Macías  
> wrote:
> 
> Hi,
> 
> I'm exploring some ways to include a complex LaTeX preamble using source
> blocks. Consider this (code at the end of this message), that works fine.
> 
> My question is: In order to do it all in a single block, would there be
> any way to pass the output of the first block as an argument to a
> function, and put that function as a header arg (results)...?


[rest deleted]

I think you might do better to use noweb chunks, viz.

#+name: pre-amble
#+begin_src latex :exports none
  \usepackage{luacode}
  \usepackage{fontspec}
  \directlua
  {
  [...]
  }
  }
  \setmainfont{Linux Libertine O}
  [RawFeature={+ktest}]
#+end_src


#+begin_src latex :noweb yes :results drawer
,#+LaTeX_HEADER: <>
#+end_src


Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex . 
t)) gives what I suspect you want.

Note that using a drawer allows replacement of the result.

HTH,
Chuck

Re: na=\"nil\" in ob-R.elo

[Berry, Charles]

> On Jan 14, 2021, at 3:42 PM, Brett Presnell  wrote:
> 
> 
> Probably a silly question, but in ob-R.el, what is the reason for
> setting na=\"nil\" when defining org-babel-R-write-object-command?  Is
> this an elisp compatibility thing?
> 

I don't get it either. The value corresponding to the NA becomes a string in 
emacs-lisp whether \"nil\" or \"\" is used.

So when passed to elisp via a :post header referencing an emacs-lisp src block, 
its treated as a string.   


> Regardless, I generally (always?) want na=\"\" for this, so I am finding
> all those "nil"s very annoying, and the only way that I see to defeat
> them is to redefine org-babel-R-write-object-command.
> 
> If there is no reason for the current behavior (doubtful I know) and if
> I am not missing an obvious work-around, then I would like to suggest
> changing this behavior.  Otherwise, would it be feasible to add an
> option for R code blocks (:nastring?) where one could specify the NA
> replacement string?
> 
> What do you think?  It's easy to suggest I know and certainly beyond my
> elisp coding skills at present, but I am supposing that someone more
> fluent in elisp could do this safely without too much trouble.
> 


You can use a :post header to customize outputs like this to make them more 
pleasing. Or just use your own `org-babel-R-write-object-command'.

Adding another header arg qualifies as feature creep and in this case would 
require non-trivial work to implement.

HTH,

Chuck

Call org-collector dynamic block

[Charles Millar]

I'd like to format (latex export) the output from a captured 
org-collector dynamic block by  using the resulting org-collector table 
as a variable for  source code block.


I have place #+name: before the collector block.

#+name: bar
#+BEGIN: propview :id "conveyances" :match "BreezyCorners" :cols (ITEM 
CUSTOM_ID CONVEYANCEDATE RECORDDATE BOOK PAGE) :colnames (Title ID Dated 
Recorded Book Page) :noquote t :defaultval "" :inherit (CONVEYANCEDATE 
DEEDDATE RECORDDATE BOOK PAGE)


#+END:

When called from the source block (using :var table=bar) results
(error "Reference not found")

I have placed the #+name inside the block, e.g.,

#+BEGIN: propview :id "conveyances" :match "BreezyCorners" :cols (ITEM 
CUSTOM_ID CONVEYANCEDATE RECORDDATE BOOK PAGE) :colnames (Title ID Dated 
Recorded Book Page) :noquote t :defaultval "" :inherit (CONVEYANCEDATE 
DEEDDATE RECORDDATE BOOK PAGE)

#+name: bar
#+END:

When I attempt to generate the table -Lisp error: (error "(user-error 
Not at a table)")


The above idea was in StackOverflow concerning a columnview block - see

https://emacs.stackexchange.com/questions/30700/calling-dynamic-blocks.

Additionally I have reviewed the org-collector source code and I find no 
provision concerning formatting the output, such as, I believe, 
clocktable has in its code. I have attempted to use


#+BEGIN: propview :id "conveyances" :match "BreezyCorners" :cols (ITEM 
CUSTOM_ID CONVEYANCEDATE RECORDDATE BOOK PAGE) :colnames (Title ID Dated 
Recorded Book Page) :noquote t :defaultval "" :inherit (CONVEYANCEDATE 
DEEDDATE RECORDDATE BOOK PAGE)

#+attr_latex: :mode table :align p{150pt}p{10pt}p{75pt}p{75pt}p{20pt}p20pt}
#+END:

again the Lisp error: (error "(user-error Not at a table)")

Any suggestions?

Charlie Millar

Re: accounting

[Charles Millar]

On 1/4/21 3:54 AM, Uwe Brauer wrote:


Hi

https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ledger.html

Points out how to use ledger within org mode.

Is there any simpler solution?

Regards

Uwe Brauer


If "simpler" means just making entries into your ledger.dat file using 
orgmode you may wish to refer to Sacha Chua's capture template for that 
very purpose. She posted it a few years ago.


https://sachachua.com/blog/2010/11/emacs-recording-ledger-entries-with-org-capture-templates/

Charlie Millar

Re: did behaviour of RET change again?

[Berry, Charles]

> On Dec 18, 2020, at 5:06 AM, Eric S Fraga  wrote:
> 
> Just a quick heads-up:
> 
> I have just installed org from git (a few hours ago) and now it seems
> that RET no longer indents.  Is this intentional?
> 
> I know that there has been some discussion on the mailing list but I
> seem to have lost track of the decision, if any, taken.  


That was Subject: How to preserve empty headings

X-Universally-Unique-Identifier: 3B7C5634-13EF-4F54-B9A6-C3D8C4342A8D


AFAICS, the behavior discussed there is unchanged as of this moment (9.4.3 from 
git master), viz RET and C-j behave differently and honor electric-indent-mode 
in doing so.

Also, I don't see any git log entries that are suggestive since that time.
HTH,

Chuck


[snip]

Re: How to preserve empty headings

[Berry, Charles]

> On Nov 30, 2020, at 11:25 AM, Diego Zamboni  wrote:
> 
> What are RET and C-j bound to?
> 
> In my setup, RET is bound to =org-return=, which does not delete spaces, but 
> C-j is bound to =org-return-and-maybe-indent=, which does. So I have the 
> opposite behavior as yours.
> 


Probably you have `electric-indent-mode' set to nil.

C-j is org-return-and-maybe-indent.

RET is org-return.

If I read the docstrings correctly, org-return (thru org--newline) and 
org-return-and-indent-maybe both trefer to electric-indent-mode, but in 
opposite manner (nil vs. t).

Chuck

[rest deleted]

Re: How to preserve empty headings

[Berry, Charles]

> On Nov 30, 2020, at 9:21 AM, Titus von der Malsburg  
> wrote:
> 
> 
> When I start a new line with '* ' followed by RET, the space is automatically 
> deleted and I’m left with a line that just has the asterisk (i.e. not a 
> headline).
> 
> Unfortunately there are use cases where empty headlines make sense and they 
> occur often in my work.  One example is Beamer slides where each headline at 
> some level produces a slide.  If the user needs a slide without title 
> (common, e.g., for a large images that fill the slide), an empty headline is 
> needed.
> 
> Is there a way to teach Org to leave the empty headline intact?
> 
> I may be old-fashioned but when I type '* ', I do it for a reason and I wish 
> that my text editor respects that. :)
> 


Instead of `* SPACE RET', try `* SPACE C-j'.

This works for me and leaves a blank heading intact through export.

HTH,

Chuck