Re: Table column formula with remote reference

[Wu Ming]

> On 15 Mar 2024, at 2:58 AM, Ihor Radchenko  wrote:
> 
> Wu Ming  writes:
> 
>>> See "Remote references" subsection. It explains that in
>>> remote(NAME,REF), REF is inside the remote table. Relative and current
>>> column/row is ambiguous there.
>>> 
>>> In contrast, @# and $# are special - they are replaced before
>>> remote(...) is processed.
>> ...
>> I have some trouble at understanding your answer. Do you mean @# refers a 
>> row on the table where the formula belongs and @0 refers a row on the remote 
>> table? Was tempted to describe the former as “current” but remote table is 
>> also current when accessed. A better noun may be needed.
> 
> Let me elaborate.
> 
> When Org mode sees something like
> 
> #+TBLFML: $1 = $2 + remote(A,@@#$1) 
> 
> 1. it goes to every cell in column 1 and remembers current column and
>   row numbers (original cell)
> 
> 2. In the right side of the formula $2 + remote(A,@@#$1), Org replaces
>   all the instances of @# and $# with current column and row.
>   So, when we are calculating the value for @1$1, we get
>   $2 + remote(A,@1$1)
> 
> 3. Org moves to table A and replaces remote(A,@1$1) with cell contents
>   of @1$1 inside table A. At this point, it is not allowed to have
>   relative references like $1 or $-1, because "current" column and row
>   are set inside remote table A - the original cell coordinates are not
>   available.
> 
> 4. Org goes back to the original table, takes the updated formula
>   $2 + , and replaces relative reference $2
>   according to the current column - with the value stored in @1$2
>   column
> 
> 5. Org passes the resulting expression  +value A@1$1> to GNU cal and assigns the result as the value of the
>   current cell @1$1.
> 
> 6. Repeat for @2..$1 cells.
> 
> As you can see, @# and $# substitution always uses local cell
> coordinates. Any other relative reference is not allowed inside
> remote(...).
> 

Very clear now. Thank you. But I was mostly confounded by references $0 and #0 
versus the @@# (and $$#) you just described the processing of. Don’t want to 
abuse your time. I can figure it out when needed. But if you feel inclined to 
unravel this little detail of the manual as well I would clearly appreciate the 
effort. 

>> This made me worry about reliability of simple biz calculations I am trying 
>> on Org spreadsheet for the first time. Please advise.
> 
> Formula debugger is really helpful to understand the process.
> 
>> Finally I moved columns but now column numbers in formulas don’t relate to 
>> column order on display. How to understand which column formula affect which 
>> column?
> 
> Normally, if you use org-table-* commands, the formulas get updated when
> you move the columns.

One side effect of using remote formulas is re-organizing columns doesn’t 
update them automatically. I should find the balance of readability and 
formulas maintenance cost. But you may have suggested the solution below 
already with named columns.
> 
> To make things more readable, you can also assign names to columns:
> 
> | ! | | P1 | P2 | P3 |   Tot |  |
> |   | Maximum | 10 | 15 | 25 |50 | 10.0 |
> 
> Then, you can write $P1 = ... instead of $3 = ...
> See "3.5.10 Advanced features" section of the manual.

Clever. And we are at the “Advanced“ features already. Are advanced-advanced in 
the realm of Calc? 

Asking because was also wondering how to optimize parameters (“solver”) and 
deal with locales (“,” vs “.” separators). For the latter I could possibly ‘tr’ 
them before sharing the output. But will possibly mess the alignment. Happened 
while trialling groff’s tbl.

Re: Table column formula with remote reference

[Wu Ming]

> On 14 Mar 2024, at 9:40 PM, Fraga, Eric  wrote:
> 
> On Thursday, 14 Mar 2024 at 09:16, Wu Ming wrote:
>> Unrelated, but appeared on the same trial, noticed a cell was
>> mis-calculated. [...] This made me worry about reliability of simple
>> biz calculations I am trying on Org spreadsheet for the first
>> time. Please advise.
> 
> I've not seen any problems with spreadsheet/table calculations in org and use 
> it extensively.  I don't use remote access generally however.
> 
> In any case, one very nice feature of org tables is you can see exactly how 
> and what it calculates when you ask it to.  Turn on debugging by "C-c {" 
> (org-table-toggle-formula-debugger) and you can see all the information you 
> should need to identify what, if anything, is going wrong.
> 
> Turn off debugging with the same key sequence.

Thanks for the reference to formula debugger. In the heat of debugging an error 
as obvious, and worrying, as the one I saw forgot about it. Though I am still 
new to Emacs and Org so that’s not so surprising. 

I have one table retrieving data from two more. 18 columns x 7 rows total. I 
could have everything into one larger table but splitting makes them more 
readable I think. And possibly simplifies sharing end results. Haven’t tried 
Org export options yet. What is your organization system with tables?

Re: [BUG] Re: The orgframe construct in the Beamer exporter as a default needs a rethink

[Leo Butler]

On Sat, Mar 16 2024, Leo Butler  wrote:

> On Fri, Mar 15 2024, Ihor Radchenko  wrote:
>
>> Leo Butler  writes:
>>
 Leo, may you improve the patch to avoid defining
 `org-beamer-frame-environment' when it is not used in all the frames?
>>>
>>> "all the" should be "any of" in that last sentence.
>>
>> Indeed.
>>
>>> How about the attached patch?
>>> ...
>>> +(defvar org-beamer--frame-environment-used nil
>>> +  "Nil unless `org-beamer-frame-environment' is used.
>>> +See `org-beamer--frame-environment'.")
>>
>> I'd prefer to keep this information in the INFO channel.
>> It will be more consistent.

Apologies, I messed up the patch in the previous email.

Attached is a patch that compiles cleanly and uses INFO.

Leo

From 003cf1d417fe8f5d1a9f8fe20980f7f4b7c5d3c4 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 12 Mar 2024 15:11:27 -0500
Subject: [PATCH] lisp/ox-beamer.el: constrain use of
 org-beamer-frame-environment

* lisp/ox-beamer.el (org-beamer--format-frame, org-beamer-template):
Only use `org-beamer-frame-environment' when a frame is marked as
fragile and the frame's contents include either \begin{frame} or
\end{frame}.  When `org-beamer-frame-environment' is used and not
equal to "frame", add the property :define-frame to INFO and set it to
t.  When that property is t, `org-beamer-template' emits a definition
of the alternative frame environment.

Refs: https://list.orgmode.org/orgmode/87bk7jeik8.fsf@localhost/
https://list.orgmode.org/87a5nux3zr@t14.reltub.ca/T/
---
 lisp/ox-beamer.el | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 4fad37b59..090d3d9ab 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -429,8 +429,21 @@ used as a communication channel."
 	  ;; among `org-beamer-verbatim-elements'.
 	  (org-element-map headline org-beamer-verbatim-elements 'identity
 			   info 'first-match))
- (frame (or (and fragilep org-beamer-frame-environment)
-"frame")))
+ ;; If FRAGILEP is non-nil and CONTENTS contains an occurrence
+ ;; of \begin{frame} or \end{frame}, then set the FRAME
+ ;; environment to be `org-beamer-frame-environment';
+ ;; otherwise, use "frame". If the selected environment is not
+ ;; "frame", then add the property :define-frame to INFO and
+ ;; set it to t.
+ (frame (let ((selection
+   (or (and fragilep
+(or (string-search "\\begin{frame}" contents)
+(string-search "\\end{frame}" contents))
+org-beamer-frame-environment)
+   "frame")))
+  (unless (string= selection "frame")
+(setq info (plist-put info :define-frame t)))
+  selection)))
 (concat "\\begin{" frame "}"
 	;; Overlay specification, if any. When surrounded by
 	;; square brackets, consider it as a default
@@ -851,8 +864,8 @@ holding export options."
  (org-latex--insert-compiler info)
  ;; Document class and packages.
  (org-latex-make-preamble info)
- ;; Define the alternative frame environment.
- (unless (equal "frame" org-beamer-frame-environment)
+ ;; Define the alternative frame environment, if needed.
+ (when (plist-get info :define-frame)
(format "\\newenvironment<>{%s}[1][]{\\begin{frame}#2[environment=%1$s,#1]}{\\end{frame}}\n"
org-beamer-frame-environment))
  ;; Insert themes.
-- 
2.43.0

Re: [PATCH] Allow external libraries (org-roam) to supply org-id locations

[Rick Lupton]

On Wed, 13 Mar 2024, at 12:30 PM, Ihor Radchenko wrote:
> I think that we can do it simpler. [...]
> The idea is to use Emacs' advice machinery to allow third-party code
> alter the functions stored in link parameters.

I was avoiding this because I thought it was only recommended (in the elisp 
manual) to use advice directly by users, not in libraries (like, I assume, 
org-roam):

> If you are writing code for release, for others to use, try to avoid 
> including advice in it. If the function you want to advise has no hook to do 
> the job, please talk with the Emacs developers about adding a suitable hook. 
> Especially, Emacs’s own source files should not put advice on functions in 
> Emacs. (There are currently a few exceptions to this convention, but we aim 
> to correct them.) It is generally cleaner to create a new hook in foo, and 
> make bar use the hook, than to have bar put advice in foo.

(https://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Named-Functions.html)

But I don't mind either way.  I agree your approach is simpler if it's a 
reasonable way for a third party library like org-roam to extend the org id 
functions.

Thanks,
Rick

Re: Things got very slow: profiler output

[Ihor Radchenko]

Bruno Cardoso  writes:

> On 2024-03-16, 15:56 +, Ihor Radchenko  wrote:
>
>> Ok.
>> Then, what about the latest main?
>
> Updated and tested again on Emacs -Q.
>
> org-fold-core--property-symbol-get-create  145790  0.5319647139  
> 3.648...e-06

It is a few times faster. And the profiler shows no slowdown, AFAIU.
Is the problem solved?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Things got very slow: profiler output

[Bruno Cardoso]

On 2024-03-16, 15:56 +, Ihor Radchenko  wrote:

> Ok.
> Then, what about the latest main?

Updated and tested again on Emacs -Q.

org-fold-core--property-symbol-get-create  145790  0.5319647139  
3.648...e-06

GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.40, cairo 
version 1.18.0)
Org mode version 9.7-pre (release_9.6.21-1289-gae50b9)


[profiler-profile "28.1" cpu #s(hash-table size 65 test equal rehash-size 1.5 
rehash-threshold 0.8125 data ([display-buffer-use-some-window display-buffer 
pop-to-buffer switch-to-buffer-other-window 
profiler-report-profile-other-window profiler-report-cpu profiler-report progn 
elisp--eval-last-sexp eval-last-sexp funcall-interactively command-execute nil 
nil nil nil] 3 [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil 
nil] 111 [line-move next-line funcall-interactively command-execute nil nil nil 
nil nil nil nil nil nil nil nil nil] 24 [next-line funcall-interactively 
command-execute nil nil nil nil nil nil nil nil nil nil nil nil nil] 3 
[redisplay_internal\ \(C\ function\) nil nil nil nil nil nil nil nil nil nil 
nil nil nil nil nil] 2 [font-lock-default-fontify-region 
font-lock-fontify-region "#" 
jit-lock--run-functions jit-lock-fontify-now jit-lock-function 
redisplay_internal\ \(C\ function\) nil nil nil nil nil nil nil nil nil] 7 
[timer-inc-time timer-event-handler nil nil nil nil nil nil nil nil nil nil nil 
nil nil nil] 4 [eval redisplay_internal\ \(C\ function\) nil nil nil nil nil 
nil nil nil nil nil nil nil nil nil] 2 [progn elisp--eval-last-sexp 
eval-last-sexp funcall-interactively command-execute nil nil nil nil nil nil 
nil nil nil nil nil] 7 [Automatic\ GC] 12)) (26101 65122 534040 823000) nil]

Re: Things got very slow: profiler output

[Ihor Radchenko]

William Denton  writes:

>> Then, what about the latest main?
>
> I tried it, and I'm sorry to say all the same problems keep happening.  
>
> I tried the test you mentioned here:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2024-03/msg00362.html
>
> I loaded up my big Org file and moved around a while.  I got:
>
> Function Name  Call Count  Elapsed Time  Average 
> Time
> org-fold-core--property-symbol-get-create  33325   0.0058796690  
> 1.764...e-07
>
> I don't know if that's helpful.

You are getting similar numbers with me.
I suspect that your problem is different from Bruno's.

> For me all this is triggered by my work-diary.org file, which has fair bit of 
> fontification in it: headings, 1200 clock entries, links, and so on.  It had 
> a big clockable at the bottom, which gave me the "Stack overflow in regexp 
> matcher" I mentioned last month:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00347.html

Did you try setting org-highlight-latex-and-related to nil?

> Ihor and Bruno, might it help if we did a video call and shared screens to 
> see problems live?  My Lisp is limited but I'll help how I can.

We may. Although I suspect that something peculiar in your Org file is
making the Emacs regexp engine choke. I am wondering what happens when
you try the default value of org-highlight-latex-and-related.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Things got very slow: profiler output

[William Denton]

On Saturday, March 16th, 2024 at 11:56, Ihor Radchenko  
wrote:

> > > What if you try the following version of `org-activate-folds'?
> > > ...
> > 
> > It makes almost no difference.
> 
> Ok.
> Then, what about the latest main?

I tried it, and I'm sorry to say all the same problems keep happening.  

I tried the test you mentioned here:

https://lists.gnu.org/archive/html/emacs-orgmode/2024-03/msg00362.html

I loaded up my big Org file and moved around a while.  I got:

Function Name  Call Count  Elapsed Time  Average 
Time
org-fold-core--property-symbol-get-create  33325   0.0058796690  
1.764...e-07

I don't know if that's helpful.

For me all this is triggered by my work-diary.org file, which has fair bit of 
fontification in it: headings, 1200 clock entries, links, and so on.  It had a 
big clockable at the bottom, which gave me the "Stack overflow in regexp 
matcher" I mentioned last month:

https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00347.html

I moved the clocktable to another file and the error stopped.  But now it's 
back.  I've been adding to work-diary.org in the meantime, so perhaps the 
problem was triggered by going over some limit, and I got it down under that 
limit, but now it's back over.  Bruno's problem is triggered by a large 
file---but surely many people here have large files in Org, so why aren't they 
seeing this?  Frustrating.

I turned on debugging and will the regex overflow stack trace below in case 
it's helpful.  (This is beyond my debugging skills, so I'm just pasting in 
anything I've got now.)

To be clear:  all these problems happen when I use the latest Org development 
source.  Using the Org in the current Emacs development tree (I'm on 30.0.50), 
there's no problem.  The Emacs source doesn't have the commit I identified 
earlier as being where my problems started.  I'm toggling between versions by 
commenting this on or off:

(use-package org
;; :pin manual
;; :load-path "/usr/local/src/org-mode/lisp"

Ihor and Bruno, might it help if we did a video call and shared screens to see 
problems live?  My Lisp is limited but I'll help how I can.


Thanks,

Bill
--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

 Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
  re-search-forward("^[ 
\11]*\\(begin{\\([a-zA-Z0-9\\*]+\\)\\(?:.\\|\n\\)+?end{\\2}\\)\\|\\([^$]\\|^\\)\\(\\$[^
 
\11\15\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|\\([^$]\\|^\\)\\(\\(\\$\\([^
 \11\n,;.$][^$\n\15]*?\\(\n[^$\n\15]*?\\)\\{0,2\\}[^ 
\11\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|(\\(?:.\\|\n\\)*?)\\|\\[\\(?:.\\|\n\\)*?\\]\\|\\$\\$\\(?:.\\|\n\\)*?\\$\\$"
 nil t)
  org-do-latex-and-related(#)
  font-lock-fontify-keywords-region(522 # nil)
  font-lock-default-fontify-region(522 # nil)
  font-lock-fontify-region(522 #)
  #f(compiled-function (beg end) #)(522 #)
  font-lock-ensure(522 #)
  org-table-align()
  org-table-map-tables(org-table-align t)
  org-mode()
  set-auto-mode-0(org-mode nil)
  set-auto-mode--apply-alist((("\\.yml$" . yaml-mode) 
("\\.\\(r\\(?:ng\\|ss\\)\\|s\\(?:ch\\|vg\\)\\|x\\(?:ml\\|s\\(?:d\\|lt\\)\\)\\)\\'"
 . nxml-mode) ("\\.[pP][dD][fF]\\'" . pdf-view-mode) ("README\\.md\\'" . 
gfm-mode) 
("\\(?:\\(?:\\.\\(?:b\\(?:\\(?:abel\\|ower\\)rc\\)\\|json\\(?:ld\\)?\\)\\|composer\\.lock\\)\\'\\)"
 . json-mode) ("\\.hva\\'" . LaTeX-mode) ("\\.tsv\\'" . tsv-mode) 
("\\.[Cc][Ss][Vv]\\'" . csv-mode) ("\\.[Ss][Aa][Ss]\\'" . SAS-mode) 
("\\.Sout\\'" . S-transcript-mode) ("\\.[Ss]t\\'" . S-transcript-mode) 
("\\.Rd\\'" . Rd-mode) ("DESCRIPTION\\'" . conf-colon-mode) 
("/Makevars\\(\\.win\\)?\\'" . makefile-mode) ("\\.[Rr]out\\'" . 
ess-r-transcript-mode) ("CITATION\\'" . ess-r-mode) ("NAMESPACE\\'" . 
ess-r-mode) ("\\.[rR]profile\\'" . ess-r-mode) ("\\.[rR]\\'" . ess-r-mode) 
("/R/.*\\.q\\'" . ess-r-mode) ("\\.[Jj][Aa][Gg]\\'" . ess-jags-mode) 
("\\.[Bb][Mm][Dd]\\'" . ess-bugs-mode) ("\\.[Bb][Oo][Gg]\\'" . ess-bugs-mode) 
("\\.[Bb][Uu][Gg]\\'" . ess-bugs-mode) ("/git-rebase-todo\\'" . 
git-rebase-mode) ("\\.\\(?:md\\|markdown\\|mkd\\|mdown\\|mkdn\\|mdwn\\)\\'" . 
markdown-mode) ("\\.\\(e?ya?\\|ra\\)ml\\'" . yaml-mode) 
("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" . 
elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil jka-compr) 
("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr) ("\\.lz\\'" nil 
jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" nil jka-compr) ("\\.Z\\'" 
nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode) 
("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gemspec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Brew\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'"
 . ruby-mode) ("\\.re?st\\'" . rst-mode) ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" . 
conf-mode) ("\\.py[iw]?\\'" . python-mode) ("\\.m\\'" . octave-maybe-mode) 

Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]

[Damien Cassou]

Ihor Radchenko  writes:
> Yes. You can add
> #+property: header-args:text :eval no
> on top of your Org file or add
> (setq org-babel-default-header-args:text '((:eval . "no")))
> to your config.

org is amazing!

Thank you very much for all your work.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: Forcing tab-width to be 8 makes using Python source blocks very difficult

[Rudi C]

Thanks, I don't have any problems now, so we can consider this closed.

On Sat, Mar 16, 2024 at 2:32 PM Ihor Radchenko  wrote:

> Rudi C  writes:
>
> > ... runs `evil-shift-right`, which
> > indents the selected region by the `evil-shift-width` amount.
> > `evil-shift-width` is set based on `tab-width`.
>
> Are you sure?
> I am looking at
> https://github.com/emacs-evil/evil/blob/master/evil-vars.el#L175
> and it appears that `evil-shift-width' has nothing to do with
> `tab-width'. It is a customization with default value of 4.
>
> Also, do note that `evil-shift-width' in python code blocks may break
> things when the code block itself is also indented. Org mode normally
> discards this common indentation and takes care about distinguishing
> (and not merging!) the tabs belonging to the code itself and the
> tabs/spaces that are used to indent the whole code block:
>
>  This whole code block is indented
>  #+begin_src python
>  def foo():
>if True:
>  return 1;
>  #+end_src
>
> Indentation in Org mode blocks can be tricky and generic editing
> commands may not cut it. Org mode itself does the indentation using the
> code block's major mode in a separate buffer in order to keep things
> consistent.
>
> > ... I solved this specific
> > problem by overriding `evil-shift-width` using a timer in an org-mode
> hook.
> > The delay introduced by the timer was necessary, as something kept
> > overriding my settings. Perhaps the magic machinery that sets `tab-width`
> > in the source blocks can also set `evil-shift-width`. The best-case
> > scenario would be to have a list of variables that need to be set from
> > their major-mode buffer in the source blocks.
>
> Why not simply setting `evil-shift-width' to 4?
>
> >> May you please provide a detailed example where 8 spaces causes issues?
> >
> > My lists are still indenting with 2 spaces, so I am not actually seeing 8
> > spaces. I have no idea why that is, but I very much like the 2-space
> > indentation.
> >
> > ```
> > - a
> >   - b
> > ```
> >
> > I see 4 spaces in numerical lists, which again, I have no idea about:
> >
> > ```
> > 1. hi
> >2. hi
> >   3. hi
> > ```
>
> Org mode aligns child sub-lists with parent item text. So, "-" is right
> below "a" and "2." is right below "hi". List depth is not defined by the
> absolute number of spaces/tabs.
> See https://orgmode.org/manual/Plain-Lists.html
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Things got very slow: profiler output

[Ihor Radchenko]

Bruno Cardoso  writes:

> On 2024-03-16, 08:56 +, Ihor Radchenko  wrote:
>
>> Bruno Cardoso  writes:
>>
>> What if you try the following version of `org-activate-folds'?
>> ...
>
> It makes almost no difference.

Ok.
Then, what about the latest main?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: `:export' attribute?: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 15/03/2024 23:26, Juan Manuel Macías wrote:

Tomorrow I will make a new commit with your code.


An update with a couple of bugs fixed. Now it is possible to specify 
different export rules for a backend and all its derivatives:


(ignore
 (pp
  (let ((rules
 (org-export--inline-special-block-make-backend-list
  (org-split-string "latex/ html./ html+= ascii+ *"
(mapcar (lambda (backend)
  (let ((hierarchy
 (org-export--backend-hierarchy backend)))
(list backend
  (org-export--inline-special-block-export-decision
   rules hierarchy
'(odt latex beamer html md ascii)

((odt content)
 (latex nil)
 (beamer nil)
 (html nil)
 (md full)
 (ascii full))



(defun org-export--inline-special-block-make-backend-list
(rules)
  (let (result)
(dolist (spec rules)
  (if (string-match

"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\([=.]\\)?\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
   spec)
  (let ((name (match-string 1 spec))
(inherit (or (match-string 3 spec)
 (match-string 4 spec)))
(what (or (match-string 2 spec)
  (match-string 5 spec
(push (cons
   (if (string-equal "" name) '@ (intern name))
   (cons (or (not inherit) (string-equal inherit "="))
 (if what (string-to-char what) ?+)))
  result))
(message "invalid :export specification %S" spec)))
(nreverse result)))

(defun org-export--backend-hierarchy (backend)
  "Result may be cached in INFO."
  (let ((hierarchy))
(when (not (symbolp backend))
  (setq backend (org-export-backend-name backend)))
(while backend
  (push backend hierarchy)
  (setq backend (org-export-backend-parent
 (org-export-get-backend backend
hierarchy))

(defun org-export--inline-special-block-export-decision
(rule-list hierarchy)
  (let ((hierarchy (cons '@ hierarchy))
(decision ?+))
(while (and hierarchy rule-list)
  (let* ((rule (pop rule-list))
 (tail (memq (car rule) hierarchy)))
(when (and tail
   (or (not (cdr tail)) ; Current backend.
   (cadr rule))) ; Inherits.
  (setq hierarchy (cdr tail))
  (setq decision (cddr rule)
(pcase decision
  (?+ 'full)
  (?* 'content)
  (?/ nil)
  (_ 'full

Re: Things got very slow: profiler output

[Bruno Cardoso]

On 2024-03-16, 08:56 +, Ihor Radchenko  wrote:

> Bruno Cardoso  writes:
>
> What if you try the following version of `org-activate-folds'?
>
> (defun org-activate-folds (limit)
>   "Arrange trailing newlines after folds to inherit face before the fold."
>   (let ((next-unfolded-newline (search-forward "\n" limit 'move)))
> (while (and next-unfolded-newline (org-fold-folded-p) (not (eobp)))
>   (goto-char (org-fold-core-next-visibility-change nil limit 'only-folds))
>   (setq next-unfolded-newline (search-forward "\n" limit 'move)))
> (when next-unfolded-newline
>   (org-with-wide-buffer
>(when (and (> (match-beginning 0) (point-min))
>   (org-fold-folded-p (1- (match-beginning 0)))
>   (not (org-fold-folded-p (1- (match-beginning 0)) 
> 'org-link)))
>  (put-text-property
>   (match-beginning 0) (match-end 0)
>   'face
>   (get-text-property
>(org-fold-previous-visibility-change
> (1- (match-beginning 0)))
>'face)))
>t
>

It makes almost no difference.


[profiler-profile "28.1" cpu #s(hash-table size 145 test equal rehash-size 1.5 
rehash-threshold 0.8125 data ([nil nil nil nil nil nil nil nil nil nil nil nil 
nil nil nil nil] 736 [line-move previous-line funcall-interactively 
command-execute nil nil nil nil nil nil nil nil nil nil nil nil] 4 
[org-eldoc-documentation-function eldoc-documentation-default 
eldoc--invoke-strategy eldoc-print-current-symbol-info "#" apply 
timer-event-handler nil nil nil nil nil nil nil nil nil] 2 
[org-fold-core--property-symbol-get-create org-fold-core-get-region-at-point 
org-fold-core--fix-folded-region "#" apply 
org-self-insert-command funcall-interactively command-execute nil nil nil nil 
nil nil nil nil] 63 [org-fold-core--property-symbol-get-create 
org-fold-core-get-folding-spec org-fold-folded-p and while let 
org-activate-folds font-lock-fontify-keywords-region 
font-lock-default-fontify-region font-lock-fontify-region "#" jit-lock--run-functions jit-lock-fontify-now 
jit-lock-function redisplay_internal\ \(C\ function\) nil] 332 
[org-fold-core--property-symbol-get-create org-fold-core-get-folding-spec 
org-fold-folded-p and if save-restriction save-excursion progn if let 
org-activate-folds font-lock-fontify-keywords-region 
font-lock-default-fontify-region font-lock-fontify-region "#" jit-lock--run-functions] 322 
[org-fold-core--property-symbol-get-create "#" mapcar 
org-fold-core-next-folding-state-change org-fold-core-get-regions 
org-fold-region org-unfontify-region font-lock-unfontify-region 
font-lock-default-fontify-region font-lock-fontify-region "#" jit-lock--run-functions jit-lock-fontify-now 
jit-lock-function redisplay_internal\ \(C\ function\) nil] 235 
[jit-lock-fontify-now jit-lock-function redisplay_internal\ \(C\ function\) nil 
nil nil nil nil nil nil nil nil nil nil nil nil] 27 [org-at-table-p "#" apply org-self-insert-command funcall-interactively 
command-execute nil nil nil nil nil nil nil nil nil nil] 5 
[org-fold-core--check-spec mapc org-fold-core-next-folding-state-change 
org-fold-core-get-regions org-fold-region org-unfontify-region 
font-lock-unfontify-region font-lock-default-fontify-region 
font-lock-fontify-region "#" 
jit-lock--run-functions jit-lock-fontify-now jit-lock-function 
redisplay_internal\ \(C\ function\) nil nil] 8 
[org-fold-core--property-symbol-get-create "#" mapcar 
org-fold-core-next-folding-state-change org-fold-core--fix-folded-region 
"#" apply org-self-insert-command 
funcall-interactively command-execute nil nil nil nil nil nil] 21 
[org-fold-core--property-symbol-get-create org-fold-core-get-folding-spec 
org-fold-core-get-regions org-fold-region org-unfontify-region 
font-lock-unfontify-region font-lock-default-fontify-region 
font-lock-fontify-region "#" 
jit-lock--run-functions jit-lock-fontify-now jit-lock-function 
redisplay_internal\ \(C\ function\) nil nil nil] 225 
[font-lock-extend-jit-lock-region-after-change jit-lock-after-change "#" apply org-self-insert-command funcall-interactively 
command-execute nil nil nil nil nil nil nil nil nil] 4 
[font-lock-fontify-keywords-region font-lock-default-fontify-region 
font-lock-fontify-region "#" 
jit-lock--run-functions jit-lock-fontify-now jit-lock-function 
redisplay_internal\ \(C\ function\) nil nil nil nil nil nil nil nil] 105 
[org-fold-check-before-invisible-edit-maybe apply org-self-insert-command 
funcall-interactively command-execute nil nil nil nil nil nil nil nil nil nil 
nil] 1 [org-fold-region org-unfontify-region font-lock-unfontify-region 
font-lock-default-fontify-region font-lock-fontify-region "#" jit-lock--run-functions jit-lock-fontify-now 
jit-lock-function redisplay_internal\ \(C\ function\) nil nil nil nil nil nil] 
17 [font-lock-default-fontify-region font-lock-fontify-region "#" jit-lock--run-functions jit-lock-fontify-now 
jit-lock-function redisplay_internal\ \(C\ function\) nil nil 

Re: [BUG] Re: The orgframe construct in the Beamer exporter as a default needs a rethink

[Leo Butler]

On Fri, Mar 15 2024, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>>> Leo, may you improve the patch to avoid defining
>>> `org-beamer-frame-environment' when it is not used in all the frames?
>>
>> "all the" should be "any of" in that last sentence.
>
> Indeed.
>
>> How about the attached patch?
>> ...
>> +(defvar org-beamer--frame-environment-used nil
>> +  "Nil unless `org-beamer-frame-environment' is used.
>> +See `org-beamer--frame-environment'.")
>
> I'd prefer to keep this information in the INFO channel.
> It will be more consistent.

See attached.

Leo

From 1df8520f2a4cfc7a7d8d971adc82cbd95d97735c Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 12 Mar 2024 15:11:27 -0500
Subject: [PATCH 1/2] lisp/ox-beamer.el: constrain use of
 org-beamer-frame-environment

* lisp/ox-beamer.el (org-beamer--format-frame, org-beamer-template):
Only use `org-beamer-frame-environment' when a frame is marked as
fragile and the frame's contents include either \begin{frame} or
\end{frame}.  When `org-beamer-frame-environment' is used and not
equal to "frame", add the property :define-frame to INFO and set it to
t.  When that property is t, `org-beamer-template' emits a definition
of the alternative frame environment.

Refs: https://list.orgmode.org/orgmode/87bk7jeik8.fsf@localhost/
https://list.orgmode.org/87a5nux3zr@t14.reltub.ca/T/
---
 lisp/ox-beamer.el | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 4fad37b59..713978477 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -429,8 +429,21 @@ used as a communication channel."
 	  ;; among `org-beamer-verbatim-elements'.
 	  (org-element-map headline org-beamer-verbatim-elements 'identity
 			   info 'first-match))
- (frame (or (and fragilep org-beamer-frame-environment)
-"frame")))
+ ;; If FRAGILEP is non-nil and CONTENTS contains an occurrence
+ ;; of \begin{frame} or \end{frame}, then set the FRAME
+ ;; environment to be `org-beamer-frame-environment';
+ ;; otherwise, use "frame". If the selected environment is not
+ ;; "frame", then add the property :define-frame to INFO and
+ ;; set it to t.
+ (frame (let ((selection
+   (or (and fragilep
+(or (string-search "\\begin{frame}" contents)
+(string-search "\\end{frame}" contents))
+org-beamer-frame-environment)
+   "frame")))
+  (unless (string= selection "frame")
+(setq into (plist-put info :define-frame t)))
+  selection)))
 (concat "\\begin{" frame "}"
 	;; Overlay specification, if any. When surrounded by
 	;; square brackets, consider it as a default
@@ -851,8 +864,9 @@ holding export options."
  (org-latex--insert-compiler info)
  ;; Document class and packages.
  (org-latex-make-preamble info)
- ;; Define the alternative frame environment.
- (unless (equal "frame" org-beamer-frame-environment)
+ ;; Define the alternative frame environment, if needed.
+ (when (plist-get info :define-frame)
+   (setq org-beamer--frame-environment-used nil)
(format "\\newenvironment<>{%s}[1][]{\\begin{frame}#2[environment=%1$s,#1]}{\\end{frame}}\n"
org-beamer-frame-environment))
  ;; Insert themes.
-- 
2.43.0

Re: [PATCH] Estonian translation in org-export-dictionary

[Ihor Radchenko]

Jan Zavitski  writes:

> Submitting a patch to improve on Estonian translation in
> org-export-dictionary.

Thanks!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c5ede5321

You are now listed as an Org contributor.
https://git.sr.ht/~bzg/worg/commit/c1450566

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[PATCH] Estonian translation in org-export-dictionary

[Jan Zavitski]

Submitting a patch to improve on Estonian translation in
org-export-dictionary.

Jan
--- emacs/lisp/org/ox.el	2024-03-16 01:14:08.103053052 +0200
+++ ox.el	2024-03-16 01:29:47.269460615 +0200
@@ -6025,6 +6025,7 @@
  ("cs" :default "Pokračování z předchozí strany")
  ("de" :default "Fortsetzung von vorheriger Seite")
  ("es" :html "Contina de la pgina anterior" :ascii "Continua de la pagina anterior" :default "Continúa de la página anterior")
+ ("et" :default "Jätk eelmisele leheküljele" :html "Jtk eelmisele lehekljele" :utf-8 "Jätk eelmisele leheküljele")
  ("fa" :default "ادامه از صفحهٔ قبل")
  ("fr" :default "Suite de la page précédente")
  ("it" :default "Continua da pagina precedente")
@@ -6043,6 +6044,7 @@
  ("cs" :default "Pokračuje na další stránce")
  ("de" :default "Fortsetzung nächste Seite")
  ("es" :html "Contina en la siguiente pgina" :ascii "Continua en la siguiente pagina" :default "Continúa en la siguiente página")
+ ("et" :default "Jätkub järgmisel leheküljel" :html "Jtkub jrgmisel lehekljel" :utf-8 "Jätkub järgmisel leheküljel")
  ("fa" :default "ادامه در صفحهٔ بعد")
  ("fr" :default "Suite page suivante")
  ("it" :default "Continua alla pagina successiva")
@@ -6058,6 +6060,7 @@
  ("tr" :default "Devamı sonraki sayfada"))
 ("Created"
  ("cs" :default "Vytvořeno")
+ ("et" :default "Loodud")
  ("fa" :default "ساخته شده")
  ("nl" :default "Gemaakt op")  ;; must be followed by a date or date+time
  ("pt_BR" :default "Criado em")
@@ -6072,7 +6075,7 @@
  ("de" :default "Datum")
  ("eo" :default "Dato")
  ("es" :default "Fecha")
- ("et" :html "Kuupev" :utf-8 "Kuupäev")
+ ("et" :default "Kuupäev" :html "Kuupev" :utf-8 "Kuupäev")
  ("fa" :default "تاریخ")
  ("fi" :html "Pivmr")
  ("hu" :html "Dtum")
@@ -6099,7 +6102,7 @@
  ("da" :default "Ligning")
  ("de" :default "Gleichung")
  ("es" :ascii "Ecuacion" :html "Ecuacin" :default "Ecuación")
- ("et" :html "Vrrand" :utf-8 "Võrrand")
+ ("et" :default "Võrrand" :html "Vrrand" :utf-8 "Võrrand")
  ("fa" :default "معادله")
  ("fr" :ascii "Equation" :default "Équation")
  ("is" :default "Jafna")
@@ -6168,7 +6171,7 @@
  ("de" :html "Funoten" :default "Fußnoten")
  ("eo" :default "Piednotoj")
  ("es" :ascii "Notas al pie de pagina" :html "Notas al pie de pgina" :default "Notas al pie de página")
- ("et" :html "Allmrkused" :utf-8 "Allmärkused")
+ ("et" :default "Allmärkused" :html "Allmrkused" :utf-8 "Allmärkused")
  ("fa" :default "پانوشت‌ها")
  ("fi" :default "Alaviitteet")
  ("fr" :default "Notes de bas de page")
@@ -6281,6 +6284,7 @@
  ("cs" :default "Reference")
  ("de" :default "Quellen")
  ("es" :default "Referencias")
+ ("et" :default "Viited")
  ("fa" :default "منابع")
  ("fr" :ascii "References" :default "Références")
  ("it" :default "Riferimenti")
@@ -6291,6 +6295,7 @@
  ("tr" :default "Referanslar"))
 ("See figure %s"
  ("cs" :default "Viz obrázek %s")
+ ("et" :default "Vaata joonist %s")
  ("fa" :default "نمایش شکل %s")
  ("fr" :default "cf. figure %s"
   :html "cf.figure%s" :latex "cf.~figure~%s")
@@ -6303,6 +6308,7 @@
  ("tr" :default "bkz. şekil %s"))
 ("See listing %s"
  ("cs" :default "Viz program %s")
+ ("et" :default "Vaata loendit %s")
  ("fa" :default "نمایش برنامه‌ریزی %s")
  ("fr" :default "cf. programme %s"
   :html "cf.programme%s" :latex "cf.~programme~%s")
@@ -6318,7 +6324,7 @@
  ("da" :default "jævnfør afsnit %s")
  ("de" :default "siehe Abschnitt %s")
  ("es" :ascii "Vea seccion %s" :html "Vea seccin %s" :default "Vea sección %s")
- ("et" :html "Vaata peatkki %s" :utf-8 "Vaata peatükki %s")
+ ("et" :default "Vaata peatükki %s" :html "Vaata peatkki %s" :utf-8 "Vaata peatükki %s")
  ("fa" :default "نمایش بخش %s")
  ("fr" :default "cf. section %s")
  ("it" :default "Vedi sezione %s")
@@ -6335,6 +6341,7 @@
  ("zh-CN" :html "%s" :utf-8 "参见第%s节"))
 ("See table %s"
  ("cs" :default "Viz tabulka %s")
+ ("et" :default "Vaata tabelit %s")
  ("fa" :default "نمایش جدول %s")
  ("fr" :default "cf. tableau %s"
   :html "cf.tableau%s" :latex "cf.~tableau~%s")

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

[சனி மார்ச் 16, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Subject: [PATCH] ob-calc.el: Add support for tables in Calc source block :var
>
> Thanks!
> Applied, onto main.
> I modified the patch to enable ob-calc tests by default.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=89b0773c3

Thanks!

>>> Would you mind using `org-test-with-temp-text' instead of
>>> `org-test-at-id' as much as possible? Otherwise, looking at tests like
>>
>> OK, I wasn't sure what test style to use since the README in testing/
>> does not talk about writing new tests.  Now I have adapted the tests to
>> use org-test-with-temp-text.
>
> Yeah. We do not have a dedicated style document for Org mode tests.

Re: Suggestion for org-agenda-list: pre-open org-agenda-files

[John Wiegley]

Understood, I just haven’t had the time to dig into this. I’ll let you know 
once I find out.

John

On Sat, Mar 16, 2024, at 12:46 AM, Ihor Radchenko wrote:
> Ihor Radchenko  writes:
>
>> Ihor Radchenko  writes:
>>
>>> So, may you dig a bit further and check why `org-agenda-prepare' is not
>>> opening the agenda files?
>>
>> A gentle ping :)
>
> Canceled.
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: The org--math-p advice around texmathp

[Tony Zorman]

On Sat, Mar 16 2024 10:07, Ihor Radchenko wrote:
> In Org mode, there is a significant difference between \alpha and
> \(\alpha\). The former is natively fontified (with `org-pretty-entities'
> set to t) and natively exported to HTML/ASCII/ODT/etc. In contrast,
> \(\alpha\) is very generic and Org mode has to invoke LaTeX, and
> transform the contents into an image to render it. This includes export.
>
> So, plain \alpha entity is generally more universal when in Org mode.

That's fair enough, I didn't know about org-pretty-entities! I guess
for me org-cdlatex-mode was always something to insert *LaTeX* in Org,
and not arbitrary Unicode (especially since there's currently no check
in place that verifies whether the entered symbol can actually be
rendered correctly via org-pretty-entities and cdlatex-math-symbol can
insert arbitrary LaTeX code) 

> Further on the topic of the advice, the original texmathp has no idea
> about Org-mode's syntax. If you have something like
>
> Verbatim text: =\(= followed by \alpha \)
>
> Then, (texmathp) will return non-nil on "\alpha" disregarding Org mode's
> syntax.

Ah indeed, this is a good point. I guess I would wish for more granular
advice, but I recognise the difficulty in getting this exactly right.
Thanks for your patience!

  Tony

-- 
Tony Zorman | https://tony-zorman.com/

Re: [PATCH] Add support for tables in Calc src block :var

[Ihor Radchenko]

Visuwesh  writes:

> Subject: [PATCH] ob-calc.el: Add support for tables in Calc source block :var

Thanks!
Applied, onto main.
I modified the patch to enable ob-calc tests by default.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=89b0773c3

>> Would you mind using `org-test-with-temp-text' instead of
>> `org-test-at-id' as much as possible? Otherwise, looking at tests like
>
> OK, I wasn't sure what test style to use since the README in testing/
> does not talk about writing new tests.  Now I have adapted the tests to
> use org-test-with-temp-text.

Yeah. We do not have a dedicated style document for Org mode tests.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]

[Ihor Radchenko]

Damien Cassou  writes:

> If I understand correctly, you are saying that it is better to let the
> command crash as soon as possible instead of letting it execute
> potentially problematic code because some previous block has not been
> executed. I think it makes perfect sense. I'm now convinced that my
> patch is not desirable. Feel free to close the issue.

Yup, you understand correctly.
Although, we previously discussed a similar issue with bibtex
blocks in https://list.orgmode.org/87ilvnx29d@kyleam.com/, but the
proposed approach to solve the issue was different.

> Just because I didn't know it exists. Thank you for telling me. I have
> now added it to all my code blocks generating non-executable results
> using the :wrap keyword like this:
>
> #+name: show-tree
> #+begin_src sh :exports both :results output drawer :tangle yes :wrap 
> "SRC text :eval no"
> echo foo
> #+end_src
> 
> #+RESULTS: show-tree
> #+begin_SRC text :eval no
> foo
> #+end_SRC
>
> It works very well, thanks! Would you say this is how you would have
> done it as well or is there a better way?

Yes. You can add

#+property: header-args:text :eval no

on top of your Org file or add

(setq org-babel-default-header-args:text '((:eval . "no")))

to your config.

See https://orgmode.org/manual/Using-Header-Arguments.html

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh]

[சனி மார்ச் 16, 2024] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>> Attached patch adds support for passing tables as matrices (or vector)
>> to a Calc source block through the :var parameter.  There might be a
>> better way to do it than manually construct the data structure expected
>> by Calc for a matrix but given that it rarely sees changes in this area,
>> it shouldn't be a bother.
>> I also added tests for this feature, and other simple tests to ensure
>> everything works.  I checked that all the tests passed on my side.
>
> Thanks!
> Since you are adding a new feature, may you also add an entry to etc/ORG-NEWS?

Now done.

>> -   (calc-push-list (list (cdr pair)))
>> +   (let ((val (cdr pair)))
>> + (calc-push-list
>> +  (list (if (listp val)
>> +(cons 'vec
>> +  (if (null (cdr val))
>> +  (car val)
>> +(mapcar (lambda (x) (if (listp x) (cons 'vec x) 
>> x))
>> +val)))
>> +  val
>
> It would be nice to add code comments explaining the Calc's internal
> format. Ideally, with references to Calc's manual or source code.
> Otherwise, this code looks like black magic :)

I hope the comment I added in the attached patch is clear enough.

>> +++ b/testing/examples/ob-calc-test.org
>> @@ -0,0 +1,57 @@
>> +#+TITLE: Tests for ob-calc
>> +#+OPTIONS: ^:nil
>
> Thanks a lot for adding many tests!
> Would you mind using `org-test-with-temp-text' instead of
> `org-test-at-id' as much as possible? Otherwise, looking at tests like

OK, I wasn't sure what test style to use since the README in testing/
does not talk about writing new tests.  Now I have adapted the tests to
use org-test-with-temp-text.

>From 29962bc3ec33e1e25f83f153b681d49182368592 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Sat, 16 Mar 2024 17:04:14 +0530
Subject: [PATCH] ob-calc.el: Add support for tables in Calc source block :var

A table with MxN dimensions is converted to a MxN matrix when given in
:var to a Calc source block.  A table with a single row is converted
to a vector (i.e., row vector).

* lisp/ob-calc.el (org-babel-execute-src-block:calc): Construct the
right data structure to pass tables as matrices to Calc.
* testing/lisp/test-ob-calc.el: Add tests for ob-calc, and this new
feature.
* etc/ORG-NEWS: Announce the feature.
---
 etc/ORG-NEWS |   7 +++
 lisp/ob-calc.el  |  14 -
 testing/lisp/test-ob-calc.el | 115 +++
 3 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 testing/lisp/test-ob-calc.el

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ca73f06e7..197d7503d 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1121,6 +1121,13 @@ Maxima's graphics packages (~draw~ or ~plot~); the default remains
 ~plot~.  The graphics terminal is now determined from the file-ending
 of the file-name set in the ~:file~ header argument.
 
+*** =ob-calc.el=: Support for tables in ~:var~
+
+=ob-calc= now supports tables in ~:var~.  They are converted to a
+matrix or a vector depending on the dimensionality of the table.  A
+table with a single row is converted to a vector, the rest are
+converted to a matrix.
+
 *** Images and files in clipboard can be pasted
 
 Org asks the user what must be done when pasting images and files
diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index f36df77ff..810ed1735 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -64,7 +64,19 @@
 	 (var-names (mapcar #'symbol-name org--var-syms)))
 (mapc
  (lambda (pair)
-   (calc-push-list (list (cdr pair)))
+   (let ((val (cdr pair)))
+ (calc-push-list
+  ;; For a vector, Calc follows the format (vec 1 2 3 ...)  so
+  ;; a matrix becomes (vec (vec 1 2 3) (vec 4 5 6) ...).  See
+  ;; the comments in "Arithmetic routines." section of
+  ;; calc.el.
+  (list (if (listp val)
+(cons 'vec
+  (if (null (cdr val))
+  (car val)
+(mapcar (lambda (x) (if (listp x) (cons 'vec x) x))
+val)))
+  val
(calc-store-into (car pair)))
  vars)
 (mapc
diff --git a/testing/lisp/test-ob-calc.el b/testing/lisp/test-ob-calc.el
new file mode 100644
index 0..6d6ca104d
--- /dev/null
+++ b/testing/lisp/test-ob-calc.el
@@ -0,0 +1,115 @@
+;;; test-ob-calc.el --- tests for ob-calc.el -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2024  Visuwesh
+
+;; Author: Visuwesh 
+
+;; 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 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but 

Re: Principled Handling of Breaking Changes

[Ihor Radchenko]

Rudi C  writes:

>> what other breaking changes caused problems for you?
>
> I remember these three:
>
> - `tab-width`
> - fontification in example blocks (
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9daad41cc)
> - `org-fold-core-style` changing to `text-properties` (from `overlays`)
> broke custom code I had for coloring links.

I think I need to clarify a bit about how we consider changes in Org mode.

- We rarely touch default values in user customization - same as what
  Emacs does. Every time we do go ahead with changing customization
  defaults, we consider such a change very carefully.

  Changing tab-width has a strong justification - we are aiming to
  stabilize Org mode markup and register it officially. So, all aspects
  of Org markup will eventually be decoupled from Emacs customization.
  (the other question is whether we can avoid co-lateral damage; let's
  discuss it in the other thread)

- We reserve the right to change internal implementation details of Org
  mode at will. Like the details how folding is implemented. Any other
  policy would make it impossible to add new and improve existing
  features of Org mode. Emacs has the same policy.

  Yet, we take care to communicate major changes in the internals to
  users who might be relying upon implementation details.

- We also reserve the right to alter undocumented features of Org mode.
  We do not exercise this right at will though - if we can keep some
  undocumented feature without too much effort, we do.

  Example block fontification was one of the undocumented features. As
  per the commit you linked to, we restored example block fontification
  and added a comment in the code to avoid future accidental breakage
  upon reporting.

>> The very first section in https://orgmode.org/Changes.html lists
>> breaking and important changes.
>
> I don't care about "important changes" though, I just want the breaking
> changes ... I guess I should allocate the needed time for reading this
> anyway.

The exact name of the section is "Important announcements and breaking
changes". By "important announcements", we really mean important -
something that may need action. For example, changes in folding
machinery where not breaking (they did not break any documented
feature), but certainly important enough to bring to everyone's
attention.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-babel-execute-subtree removes all overlays (org-fold-save-outline-visibility) [9.7-pre, gfb61e8]

[Bruno Barbier]

Ihor Radchenko  writes:

>
> Thanks for reporting!
> Fixed, on bugfix and main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8b73c8b98
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=712ef988c

It now works.

Thanks Ihor!


> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Forcing tab-width to be 8 makes using Python source blocks very difficult

[Ihor Radchenko]

Rudi C  writes:

> ... runs `evil-shift-right`, which
> indents the selected region by the `evil-shift-width` amount.
> `evil-shift-width` is set based on `tab-width`.

Are you sure?
I am looking at
https://github.com/emacs-evil/evil/blob/master/evil-vars.el#L175
and it appears that `evil-shift-width' has nothing to do with
`tab-width'. It is a customization with default value of 4.

Also, do note that `evil-shift-width' in python code blocks may break
things when the code block itself is also indented. Org mode normally
discards this common indentation and takes care about distinguishing
(and not merging!) the tabs belonging to the code itself and the
tabs/spaces that are used to indent the whole code block:

 This whole code block is indented
 #+begin_src python
 def foo():
   if True:
 return 1;
 #+end_src

Indentation in Org mode blocks can be tricky and generic editing
commands may not cut it. Org mode itself does the indentation using the
code block's major mode in a separate buffer in order to keep things
consistent.

> ... I solved this specific
> problem by overriding `evil-shift-width` using a timer in an org-mode hook.
> The delay introduced by the timer was necessary, as something kept
> overriding my settings. Perhaps the magic machinery that sets `tab-width`
> in the source blocks can also set `evil-shift-width`. The best-case
> scenario would be to have a list of variables that need to be set from
> their major-mode buffer in the source blocks.

Why not simply setting `evil-shift-width' to 4?

>> May you please provide a detailed example where 8 spaces causes issues?
>
> My lists are still indenting with 2 spaces, so I am not actually seeing 8
> spaces. I have no idea why that is, but I very much like the 2-space
> indentation.
>
> ```
> - a
>   - b
> ```
>
> I see 4 spaces in numerical lists, which again, I have no idea about:
>
> ```
> 1. hi
>2. hi
>   3. hi
> ```

Org mode aligns child sub-lists with parent item text. So, "-" is right
below "a" and "2." is right below "hi". List depth is not defined by the
absolute number of spaces/tabs.
See https://orgmode.org/manual/Plain-Lists.html

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Principled Handling of Breaking Changes

[Rudi C]

> what other breaking changes caused problems for you?

I remember these three:

- `tab-width`
- fontification in example blocks (
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9daad41cc)
- `org-fold-core-style` changing to `text-properties` (from `overlays`)
broke custom code I had for coloring links.

> Rather for Emacs in general. Would you be interested to post this
> suggestion on emacs-devel list?

That's also a good idea, but I don't remember being bitten by changes in
emacs itself. It might help emacs adopt better defaults for new users
though, as the backward compatibility of emacs makes its UX terrible for
new users.

> The very first section in https://orgmode.org/Changes.html lists
> breaking and important changes.

I don't care about "important changes" though, I just want the breaking
changes ... I guess I should allocate the needed time for reading this
anyway.

Thanks.

On Sat, Mar 16, 2024 at 1:48 PM Ihor Radchenko  wrote:

> Rudi C  writes:
>
> > The recent upgrades to Org mode have been a source of great frustration
> for
> > me. Many of the configurations I had previously set up stopped working as
> > intended, and it took me several days to properly identify the issues,
> > debug them, and find suitable workarounds.
>
> Apart from the issue with tab-width you reported, what other breaking
> changes caused problems for you?
>
> > To address this concern, I suggest that all breaking changes in Org mode
> > follow a versioning scheme similar to Perl's `use v5.34.0;`. This could
> be
> > achieved by introducing an `org-defaults-use-version` variable, which
> would
> > be set to nil by default, allowing the package to adapt its behavior as
> > necessary. However, when `org-defaults-use-version` is set to a specific
> > version, all configuration variables should adhere to the behavior
> > associated with that particular version. Furthermore, I propose that all
> > breaking changes be accompanied by a configuration flag, enabling users
> to
> > disable the change if they so desire. By implementing these suggestions,
> > users would be able to upgrade Org mode without the fear of spending
> hours
> > dealing with frustration and debugging.
>
> This might be a good idea, but not necessary for Org mode in particular.
> Rather for Emacs in general. Would you be interested to post this
> suggestion on emacs-devel list?
>
> > PS: Is there a changelog that ONLY lists breaking changes? There should
> be
> > one ...
>
> The very first section in https://orgmode.org/Changes.html lists
> breaking and important changes. Users are free to limit reading the
> changelog to this first section. It is not clear for me why we need a
> separate page.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]

[Damien Cassou]

Hi Ihor,

Ihor Radchenko  writes:
> For example, consider
>
> #+begin_src bash
> mkdir foo
> #+end_src
>
> #+begin_src emacs-lisp
> (write-file "foo/result")
> #+end_src
>
> The second block relies upon side effects of the first block.
> However, if ob-shell is not loaded, with your patch, the side effect
> will not happen.  One can construct more nasty examples when not
> executing prior block leads to unexpected or even damaging results.


If I understand correctly, you are saying that it is better to let the
command crash as soon as possible instead of letting it execute
potentially problematic code because some previous block has not been
executed. I think it makes perfect sense. I'm now convinced that my
patch is not desirable. Feel free to close the issue.


> Why not simply adding :eval no header argument?


Just because I didn't know it exists. Thank you for telling me. I have
now added it to all my code blocks generating non-executable results
using the :wrap keyword like this:

#+name: show-tree
#+begin_src sh :exports both :results output drawer :tangle yes :wrap "SRC 
text :eval no"
echo foo
#+end_src

#+RESULTS: show-tree
#+begin_SRC text :eval no
foo
#+end_SRC

It works very well, thanks! Would you say this is how you would have
done it as well or is there a better way?

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: Forcing tab-width to be 8 makes using Python source blocks very difficult

[Rudi C]

`evil-org->` doesn't matter per se. It runs `evil-shift-right`, which
indents the selected region by the `evil-shift-width` amount.
`evil-shift-width` is set based on `tab-width`. I solved this specific
problem by overriding `evil-shift-width` using a timer in an org-mode hook.
The delay introduced by the timer was necessary, as something kept
overriding my settings. Perhaps the magic machinery that sets `tab-width`
in the source blocks can also set `evil-shift-width`. The best-case
scenario would be to have a list of variables that need to be set from
their major-mode buffer in the source blocks.

> May you please provide a detailed example where 8 spaces causes issues?

My lists are still indenting with 2 spaces, so I am not actually seeing 8
spaces. I have no idea why that is, but I very much like the 2-space
indentation.

```
- a
  - b
```

I see 4 spaces in numerical lists, which again, I have no idea about:

```
1. hi
   2. hi
  3. hi
```

So I don't see the effects of `tab-width` anywhere except in
`evil-shift-width`, as far as I can see currently.

On Sat, Mar 16, 2024 at 1:11 PM Ihor Radchenko  wrote:

> Rudi C  writes:
>
> > Recently, a breaking change has been introduced in Org mode that sets the
> > default tab-width to 8 spaces (
> > https://list.orgmode.org/orgmode/8734y5d2gs.fsf@localhost/). This change
> > has made using Python source blocks in Org mode challenging, as
> operations
> > like `evil-org->` rely on `tab-width`, and Python code conventions
> > typically use 4 spaces for indentation.
>
> May you please provide more details on what exactly "evil-org->" refers
> to and what specific problems you encountered?
>
> > Moreover, using 8 spaces for indentation is generally unsuitable for
> small
> > laptop screens, where screen real estate is of utmost importance.
>
> May you please provide a detailed example where 8 spaces causes issues?
> In source blocks specifically, we make sure that tab width visually
> looks as in the corresponding source code buffer.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Reproducible work with natively compiled Emacs

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

>> Do I understand correctly that the reason you implemented cleaneln make
>> target is working around issues with make test/make repro?
>>
> Yes, that's one of the reasons. And, also because when I set
> native.comp-eln-cache-path,
> anything that is not part of the Emacs distribution gets compiled into that
> directory. For example,
> the clone of org-mode main as well as the packages from elpa/melpa/nungnu.

Sorry, but I do not fully understand.
May you please explain in more details what kind of problems you
encountered in practice?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Principled Handling of Breaking Changes

[Ihor Radchenko]

Rudi C  writes:

> The recent upgrades to Org mode have been a source of great frustration for
> me. Many of the configurations I had previously set up stopped working as
> intended, and it took me several days to properly identify the issues,
> debug them, and find suitable workarounds.

Apart from the issue with tab-width you reported, what other breaking
changes caused problems for you?

> To address this concern, I suggest that all breaking changes in Org mode
> follow a versioning scheme similar to Perl's `use v5.34.0;`. This could be
> achieved by introducing an `org-defaults-use-version` variable, which would
> be set to nil by default, allowing the package to adapt its behavior as
> necessary. However, when `org-defaults-use-version` is set to a specific
> version, all configuration variables should adhere to the behavior
> associated with that particular version. Furthermore, I propose that all
> breaking changes be accompanied by a configuration flag, enabling users to
> disable the change if they so desire. By implementing these suggestions,
> users would be able to upgrade Org mode without the fear of spending hours
> dealing with frustration and debugging.

This might be a good idea, but not necessary for Org mode in particular.
Rather for Emacs in general. Would you be interested to post this
suggestion on emacs-devel list?

> PS: Is there a changelog that ONLY lists breaking changes? There should be
> one ...

The very first section in https://orgmode.org/Changes.html lists
breaking and important changes. Users are free to limit reading the
changelog to this first section. It is not clear for me why we need a
separate page. 

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name

[Ihor Radchenko]

Matt  writes:

> Finally had time to commit it. 
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0e2a9524dc6da8b4d60672e85aba74076baac211

Thanks!

I notice that you changed the commit author and only referenced Aaron in
Submitted By: metadata.

For future, we prefer keeping the original commit author in the "author"
field of the commits - this is important to keep track of the number of
changed lines for contributors without FSF copyright assignment.

You may consider using https://git.kyleam.com/piem/about/ to apply
patches submitted as emails automatically. Or you can assign the commit
author manually, using -A git commit switch (magit also provides a
transient menu option for this).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: The org--math-p advice around texmathp

[Ihor Radchenko]

Tony Zorman  writes:

>> For example, something like \alpha is a valid Org mode entity.
>> Without `org--math-p' advice, if you do "`a" in Org buffer with
>> org-cdlatex-mode, you will see $\alpha$ inserted. With the advice, just
>> \alpha will be inserted.
> ...
>
> For example, I would think it's expected behaviour that "`a" in a string
> produces "\(\alpha\)" with CDLaTeX; indeed, so far I thought it was just
> a bug that it didn't! Likewise, that a standalone `a produces \alpha
> instead of \(\alpha\). Why is this not expected behaviour in Org?

In Org mode, there is a significant difference between \alpha and
\(\alpha\). The former is natively fontified (with `org-pretty-entities'
set to t) and natively exported to HTML/ASCII/ODT/etc. In contrast,
\(\alpha\) is very generic and Org mode has to invoke LaTeX, and
transform the contents into an image to render it. This includes export.

So, plain \alpha entity is generally more universal when in Org mode.

Further on the topic of the advice, the original texmathp has no idea
about Org-mode's syntax. If you have something like

Verbatim text: =\(= followed by \alpha \)

Then, (texmathp) will return non-nil on "\alpha" disregarding Org mode's
syntax.


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Add support for tables in Calc src block :var

[Ihor Radchenko]

Visuwesh  writes:

> Attached patch adds support for passing tables as matrices (or vector)
> to a Calc source block through the :var parameter.  There might be a
> better way to do it than manually construct the data structure expected
> by Calc for a matrix but given that it rarely sees changes in this area,
> it shouldn't be a bother.
> I also added tests for this feature, and other simple tests to ensure
> everything works.  I checked that all the tests passed on my side.

Thanks!
Since you are adding a new feature, may you also add an entry to etc/ORG-NEWS?

> -   (calc-push-list (list (cdr pair)))
> +   (let ((val (cdr pair)))
> + (calc-push-list
> +  (list (if (listp val)
> +(cons 'vec
> +  (if (null (cdr val))
> +  (car val)
> +(mapcar (lambda (x) (if (listp x) (cons 'vec x) 
> x))
> +val)))
> +  val

It would be nice to add code comments explaining the Calc's internal
format. Ideally, with references to Calc's manual or source code.
Otherwise, this code looks like black magic :)

> +++ b/testing/examples/ob-calc-test.org
> @@ -0,0 +1,57 @@
> +#+TITLE: Tests for ob-calc
> +#+OPTIONS: ^:nil

Thanks a lot for adding many tests!
Would you mind using `org-test-with-temp-text' instead of
`org-test-at-id' as much as possible? Otherwise, looking at tests like

> +(ert-deftest ob-calc/simple-program-mult ()
> +  "Test of simple multiplication."
> +  (org-test-at-id "40e4cd26-fe15-45c0-938b-111e021a5a99"
> +(org-babel-next-src-block)
> +(should (equal "2" (org-babel-execute-src-block)

it is very difficult to understand what exactly the tests is checking.
`org-test-with-temp-text' would make things a lot more readable as we
would see the calc code being tested right inside the test code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Forcing tab-width to be 8 makes using Python source blocks very difficult

[Ihor Radchenko]

Rudi C  writes:

> Recently, a breaking change has been introduced in Org mode that sets the
> default tab-width to 8 spaces (
> https://list.orgmode.org/orgmode/8734y5d2gs.fsf@localhost/). This change
> has made using Python source blocks in Org mode challenging, as operations
> like `evil-org->` rely on `tab-width`, and Python code conventions
> typically use 4 spaces for indentation.

May you please provide more details on what exactly "evil-org->" refers
to and what specific problems you encountered?

> Moreover, using 8 spaces for indentation is generally unsuitable for small
> laptop screens, where screen real estate is of utmost importance.

May you please provide a detailed example where 8 spaces causes issues?
In source blocks specifically, we make sure that tab width visually
looks as in the corresponding source code buffer.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-babel-execute-subtree removes all overlays (org-fold-save-outline-visibility) [9.7-pre, gfb61e8]

[Ihor Radchenko]

Bruno Barbier  writes:

> Org removes all overlays when calling org-babel-execute-subtree.
> ...
> After investigation, it seems that any use of
> `org-save-outline-visibility' will call:
>
> (org-fold-core-region START END nil)
> ^^^
>
> which will, indeed, remove any overlay (except for those that are
> both 'org-invisible and 'invisible).

Thanks for reporting!
Fixed, on bugfix and main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8b73c8b98
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=712ef988c

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Things got very slow: profiler output

[Ihor Radchenko]

Bruno Cardoso  writes:

> My call count is in fact higher:
>
> org-fold-core--property-symbol-get-create  196278  3.2828460320  
> 1.672...e-05

Makes sense.

What if you try the following version of `org-activate-folds'?

(defun org-activate-folds (limit)
  "Arrange trailing newlines after folds to inherit face before the fold."
  (let ((next-unfolded-newline (search-forward "\n" limit 'move)))
(while (and next-unfolded-newline (org-fold-folded-p) (not (eobp)))
  (goto-char (org-fold-core-next-visibility-change nil limit 'only-folds))
  (setq next-unfolded-newline (search-forward "\n" limit 'move)))
(when next-unfolded-newline
  (org-with-wide-buffer
   (when (and (> (match-beginning 0) (point-min))
  (org-fold-folded-p (1- (match-beginning 0)))
  (not (org-fold-folded-p (1- (match-beginning 0)) 'org-link)))
 (put-text-property
  (match-beginning 0) (match-end 0)
  'face
  (get-text-property
   (org-fold-previous-visibility-change
(1- (match-beginning 0)))
   'face)))
   t

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

[Ihor Radchenko]

Sławomir Grochowski  writes:

> Thank you for asking.
> Yes, I would be interested.
> I will prepare a patch.

May I know if you had a chance to work on this?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Suggestion for org-agenda-list: pre-open org-agenda-files

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> So, may you dig a bit further and check why `org-agenda-prepare' is not
>> opening the agenda files?
>
> A gentle ping :)

Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Reproducible work with natively compiled Emacs

[Pedro Andres Aranda Gutierrez]

Hi Ihor,

Answer inline...

On Fri, 15 Mar 2024 at 18:08, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > I have added the eln version to the patch...
> >
> > Best, /PA
> > PS: Just as an example, I recompiled master today and the version number
> > for eln changed, so the 'old' files from yesterday were not removed ;-)
>
> Yeah. Not ideal.
> The whole system with emacs -Q putting things into .emacs.d is not ideal.
>
> Sometimes, when running things like make test we do not even want to
> litter .emacs.d - .eln files generated during make test might correspond
> to the broken versions of Org mode that were being tested. Then, running
> actual working Emacs session might stumble upon these incorrect versions
> of .eln files.
>
> Do I understand correctly that the reason you implemented cleaneln make
> target is working around issues with make test/make repro?
>

Yes, that's one of the reasons. And, also because when I set
native.comp-eln-cache-path,
anything that is not part of the Emacs distribution gets compiled into that
directory. For example,
the clone of org-mode main as well as the packages from elpa/melpa/nungnu.

When refreshing my local copy of the org-mode repo, I start with a make
cleaneln before pulling and then
make native. Thus I get a predictable build.


> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Best, /PA

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet