Re: [patch] improved: add TTL as defcustom to ox-icalendar

[Bastien Guerry]

Hi,

Ihor Radchenko  writes:

>> In the meantime I have the paperwork done and have "it" :-)
>
> Bastien, could you please check FSF records?

Yes, I confirm Detlef is registered in the FSF records.

-- 
 Bastien

Re: [PATCH] ox-icalendar: Create export backend options for deadline/scheduled-summary-prefix defcustoms

[Ilya Chernyshov]

Sending the updated patch.

On Wed, Nov 9, 2022 at 8:42 AM Ihor Radchenko  wrote:

> Чернышов Илья  writes:
>
> > This patch will allow to customize
> `org-icalendar-deadline-summary-prefix',
> > `org-icalendar-scheduled-summary-prefix' directly in the `ext-plist' arg
> of
> > org-export-as function
>
> Thanks!
> The patch looks good.
>
> Could you also update the relevant NEWS entry (New custom settings
> =org-icalendar-scheduled-summary-prefix= and
> =org-icalendar-deadline-summary-prefix=)?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
From 74cc1a6b879c1b856fdc9205b4e042582f658f6c Mon Sep 17 00:00:00 2001
From: Ilya Chernyshov 
Date: Mon, 7 Nov 2022 20:12:08 +0600
Subject: [PATCH] ox-icalendar: Create export backend options for
 deadline/scheduled-summary-prefix defcustoms

ox-icalendar.el (org-export-define-derived-backend):

Add export backend options:
:deadline-summary-prefix
:scheduled-summary-prefix

ox-icalendar.el (org-icalendar-entry):

Use :deadline-summary-prefix export backend option instead of
`org-icalendar-deadline-summary-prefix'. If the option is not
explicitly set, use the value of the custom variable.

Use :scheduled-summary-prefix export backend option instead of
`org-icalendar-scheduled-summary-prefix'. If the option is not
explicitly set, use the value of the custom variable.

Convert `deadline/scheduled-summary-prefix' string to iCal-compatible
format via `(org-icalendar-cleanup-string)'
---
 etc/ORG-NEWS |  5 +
 lisp/ox-icalendar.el | 16 +++-
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b542da34b..5943f1749 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -350,6 +350,11 @@ lines in ICS exports.  The customization can be used to disable
 the prefixes completely or make them a little bit more verbose
 (e.g. "Deadline: " instead of the default "DL: ").
 
+The same settings also can be applied via corresponding exporter
+options:
+=:icalendar-scheduled-summary-prefix=,
+=:icalendar-deadline-summary-prefix=
+
 *** A new custom setting =org-hide-drawer-startup= to control initial folding state of drawers
 
 Previously, all the drawers were always folded when opening an Org
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 6e4a9f21f..f4c904da4 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -332,7 +332,9 @@ re-read the iCalendar file.")
 (:icalendar-store-UID nil nil org-icalendar-store-UID)
 (:icalendar-timezone nil nil org-icalendar-timezone)
 (:icalendar-use-deadline nil nil org-icalendar-use-deadline)
-(:icalendar-use-scheduled nil nil org-icalendar-use-scheduled))
+(:icalendar-use-scheduled nil nil org-icalendar-use-scheduled)
+(:icalendar-scheduled-summary-prefix nil nil org-icalendar-scheduled-summary-prefix)
+(:icalendar-deadline-summary-prefix nil nil org-icalendar-deadline-summary-prefix))
   :filters-alist
   '((:filter-headline . org-icalendar-clear-blank-lines))
   :menu-entry
@@ -630,7 +632,9 @@ inlinetask within the section."
 	  ;; "VEVENT" component from scheduled, deadline, or any
 	  ;; timestamp in the entry.
 	  (let ((deadline (org-element-property :deadline entry))
-		(use-deadline (plist-get info :icalendar-use-deadline)))
+		(use-deadline (plist-get info :icalendar-use-deadline))
+(deadline-summary-prefix (org-icalendar-cleanup-string
+  (plist-get info :icalendar-deadline-summary-prefix
 	(and deadline
 		 (pcase todo-type
 		   (`todo (or (memq 'event-if-todo-not-done use-deadline)
@@ -639,10 +643,12 @@ inlinetask within the section."
 		   (_ (memq 'event-if-not-todo use-deadline)))
 		 (org-icalendar--vevent
 		  entry deadline (concat "DL-" uid)
-		  (concat org-icalendar-deadline-summary-prefix summary)
+		  (concat deadline-summary-prefix summary)
   loc desc cat tz class)))
 	  (let ((scheduled (org-element-property :scheduled entry))
-		(use-scheduled (plist-get info :icalendar-use-scheduled)))
+		(use-scheduled (plist-get info :icalendar-use-scheduled))
+(scheduled-summary-prefix (org-icalendar-cleanup-string
+   (plist-get info :icalendar-scheduled-summary-prefix
 	(and scheduled
 		 (pcase todo-type
 		   (`todo (or (memq 'event-if-todo-not-done use-scheduled)
@@ -651,7 +657,7 @@ inlinetask within the section."
 		   (_ (memq 'event-if-not-todo use-scheduled)))
 		 (org-icalendar--vevent
 		  entry scheduled (concat "SC-" uid)
-		  (concat org-icalendar-scheduled-summary-prefix summary)
+		  (concat scheduled-summary-prefix summary)
   loc desc cat tz class)))
 	  ;; When collecting plain timestamps from a headline and its
 	  ;; title, skip inlinetasks since collection will

Re: Interest in an Org video meetup?

[Quiliro Ordóñez]

Hi Sacha :-)

El 2022-11-08 20:45, Sacha Chua escribió:

> - first 5-15 minutes, people propose topics to talk about while you
> write them down in a screenshared text editor (Emacs, of course).

What do you mean by "a screenshared text editor (Emacs, of course)"?  Do
you mean Rudel? There are some options in
https://www.emacswiki.org/emacs/CollaborativeEditing

Re: extended background on org-block-end-line

[Abdul-Lateef Haji-Ali]

Hello Ihor,

On 09/11/2022, Ihor Radchenko wrote:
> This is because Org keeps the last newline visible and Emacs apply
> :extent t to that visible newline.

I saw the bug report on Emacs, but I am not sure how to reply to a thread there 
without being subscribed to the mailing list, so I will reply here.

I think a possible solution that can be implemented in org-mode side would be 
for the outline to include the new line character after `#+end_src` to hide the 
whole line (including the extended background). The final result can then be 
fixed by adding a newline character to the `...` glyph.

Do you think that would work? 

-- Al

Re: Interest in an Org video meetup?

[Sacha Chua]

On Wed, Nov 9, 2022, 09:08 Quiliro Ordóñez  wrote:

> What do you mean by "a screenshared text editor (Emacs, of course)"? Do
you mean Rudel? There are some options in
https://www.emacswiki.org/emacs/CollaborativeEditing

I meant something even simpler, actually - just someone using BBB's share
screen feature to share whatever people are using (Emacs or Etherpad) to
list the breakout rooms and their topics.

Sacha

Re: [PATCH v2] org-attach.el: ID to path functions may return nil

[Max Nikulin]

On 08/11/2022 12:08, Ihor Radchenko wrote:


I feel like this makes the docstring confusing.

Note that `org-attach-id-to-path-function-list':


I have tried to update the docstrings.


if: No attachment directory is associated with the current node, adjust
‘org-attach-id-to-path-function-list’

I do not think this message is unhelpful.


With your patch, such message will be displayed even when
`org-attach-preferred-new-method' is set to something other than 'id.
And the message will be wrong then.


I have moved `error' call despite I have not figured out how to trigger 
the error for other options.



+(defun org-attach-id-fallback-folder-format (id)
+  "May be added last to `org-attach-id-path-function-list'.


This is not a proper first line in a function docstring. First line must
describe what the function does.


I am still unsure that in this case effect is more important than 
purpose. The function is too specific.


P.S. At first I believed that you have some objections concerning 
changed role of the first function in the list, not just how it is 
documented.
From dfc35f46f59d5938f1a520b860c3eda36f49a9d5 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Mon, 7 Nov 2022 23:48:02 +0700
Subject: [PATCH v2] org-attach.el: ID to path functions may return nil

* lisp/org-attach.el (org-attach-dir-from-id): Ignore nil values
returned by entries from `org-attach-id-to-path-function-list'.
(org-attach-dir-get-create): Update error message to suggest
customization of `org-attach-id-to-path-function-list'.
(org-attach-id-to-path-function-list): Add to the docstring examples
how to handle unusual IDs.
(org-attach-id-uuid-folder-format, org-attach-id-ts-folder-format):
Return nil if ID is too short.
(org-attach-id-fallback-folder-format): New function that may be added
as the last element of `org-attach-id-path-function-list' to handle
unexpectedly short IDs.

Earlier an obscure error like 'org-attach-id-ts-folder-format: Args out
of range: "ftt", 0, 6' was signalled in the case of unexpectedly short
ID.

Reported by Janek F 
https://list.orgmode.org/KC8PcypJapBpJQtJxM0kX5N7Z0THL2Lq6EQjBMzpw1-vgQf72egZ2JOIlTbPYiqAVD4MdSBhrhBZr2Ykf5DN1mocm1ANvvuKKZShlkgzKYM=@pm.me
---
 lisp/org-attach.el | 98 ++
 1 file changed, 65 insertions(+), 33 deletions(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index ef183474e..bd3034992 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -166,26 +166,56 @@ When set to `query', ask the user instead."
   "Translate an UUID ID into a folder-path.
 Default format for how Org translates ID properties to a path for
 attachments.  Useful if ID is generated with UUID."
-  (format "%s/%s"
-	  (substring id 0 2)
-	  (substring id 2)))
+  (and (< 2 (length id))
+   (format "%s/%s"
+   (substring id 0 2)
+   (substring id 2
 
 (defun org-attach-id-ts-folder-format (id)
   "Translate an ID based on a timestamp to a folder-path.
 Useful way of translation if ID is generated based on ISO8601
 timestamp.  Splits the attachment folder hierarchy into
 year-month, the rest."
-  (format "%s/%s"
-	  (substring id 0 6)
-	  (substring id 6)))
+  (and (< 6 (length id))
+   (format "%s/%s"
+   (substring id 0 6)
+   (substring id 6
+
+(defun org-attach-id-fallback-folder-format (id)
+  "Use \"__/ID\" folder path as a dumb fallback.
+May be added as the last element of `org-attach-id-path-function-list'
+to avoid errors for customized ID values that other functions
+are unable to handle. An example is too short ID for
+`org-attach-id-ts-folder-format'.  However it is better to define
+a more specific function spreading entries over subfolders."
+  (format "__/%s" id))
 
 (defcustom org-attach-id-to-path-function-list '(org-attach-id-uuid-folder-format
 		 org-attach-id-ts-folder-format)
-  "List of functions parsing an ID string into a folder-path.
-The first function in this list defines the preferred function
-which will be used when creating new attachment folders.  All
-functions of this list will be tried when looking for existing
-attachment folders based on ID."
+  "List of functions tried to get a folder path for an ID string.
+Functions are called in order till some of them returns an existing
+folder.  If no folder has been created yet for the given ID
+then first value defines folder name that will be created
+to store an attachment.  Nil values are skipped.
+
+Preferred storage policy depends on `org-id-method' and should be chosen
+to avoid excessive number of entries in a single directory.  List
+of functions allows to handle the case of mixed ID styles after
+change of ID generator.
+
+If format of some ID strings differs from `org-id-method' you may
+add `org-attach-id-fallback-folder-format' to the end of the list.
+A better option is to keep attachments inside a dedicated folder.
+A function like the following one may be added as first element
+of the list.
+

Re: Can :packages and :headers arguments in latex SRC blocks be made affect EXPORT blocks of results?

[Juan Manuel Macías]

h...@heagren.com writes:

> Is there a way around this? Either to export the src block another way,
> or to add metadata to the to the resulting EXPORT block (or just text,
> though I'm not sure how that would work for `:packages', since they
> require text to be added to the resulting exported LaTeX file in a
> different place from where the text of the block goes).

If I have understood correctly what you want to do, maybe a solution
would be this. You can starting from a single block that includes
the preamble for both preview and export:

#+NAME: preamble
#+begin_src latex :exports none
\usepackage{tikz}
\usetikzlibrary{calc,positioning,patterns}
#+end_src

This block returns the above as a simple string:

#+NAME: pre
#+begin_src emacs-lisp :exports none :results silent :var x = preamble
  (with-temp-buffer
(insert x)
(LaTeX-mode)
(setq preamble-prev (buffer-string)))
#+end_src

And this one adds the necessary LaTeX headers when you export the
document, so LaTeX doesn't crash when compiling.

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

And the final block:

#+header: :results (if (org-export-derived-backend-p  
org-export-current-backend 'latex) "latex" "file raw")
#+header: :file (if (org-export-derived-backend-p  org-export-current-backend 
'latex) nil "foo.png")
#+header: :imagemagick t :fit t
#+header: :headers `(,(progn (org-babel-ref-resolve "pre") preamble-prev))
#+begin_src latex
 \begin{tikzpicture}[on grid,
   font=\footnotesize,
   level distance=2.5cm,
   sibling distance=2.5cm,
   every node/.style={circle,draw,fill=white},
   touch/.style={circle,draw=red!100,fill=red!40,thick},
   invirtueof/.style={circle,draw=red!50,fill=red!20,very thick}]

   \node [invirtueof] {Car}
   child {node {wheel}}
   child {node [invirtueof] {body}
 child {node {driver door}}
 child {node [invirtueof] {passenger door}
   child {node [touch] {region of door;
 \end{tikzpicture}
#+end_src

#+RESULTS:
[[file:foo.png]]

Best regards,

Juan Manuel 

Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects

[Leo Butler]

Ihor, see below.

On Wed, Nov 09 2022, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>> Ihor,
>> Thanks for your feeback and the pointer. I have revised the tests and
>> attach the revised patch.
>
> Thanks!
>
> Note that your patch is over 15LOC, which exceeds legally allowed
> contribution size for people without copyright assignment.
>
> Would you be interested to sign the copyright assignment form and send
> it to FSF? See https://orgmode.org/worg/org-contribute.html#copyright
> for details. The process usually takes a few days on FSF side (they are
> obliged to reply within 5 working days).

Yes, I have done that. I did the paperwork about 10 years ago, but I
cannot find it and, except for my name, all other details have changed.

>
> Below are some comments.
>
>> * testing/lisp/test-ob-octave.el:
>>
>>   Add the tests ob-octave/graphics-file and
>>   ob-octave/graphics-file-session. The first test verifies that the
>
> Please use double space "  " between sentences. See
> https://orgmode.org/worg/org-contribute.html#commit-messages

Done.

>
>> -  (format "print -dpng %s" gfx-file))
>> +  (format "print -dpng %s\nans=%S" gfx-file 
>> gfx-file))
>
> Is there any reason why %S but not %s?

That is a good point. Both should be %S. This change is part of the
modified patch (and an extra test).

>
>>  * Graphical tests
>> -#+begin_src octave :results graphics :file chart.png
>> +
>> +Graphics file. This test is performed by =ob-octave/graphics-file= in 
>> =testing/lisp/test-ob-octave.el=.
>
> By convention, we use double space in distributed Org files and ~code~
> for symbol markup. See doc/Documentation_Standards.org.
>
> (It is not strictly necessary here, but would be nice to be consistent)
>

Done.

>> +  (org-babel-execute-src-block)
>> +  (should (search-forward (format "[[file:%s]]" file) nil nil))
>> +  (should (file-readable-p file))
>> +  (should (let ((size (nth 7 (file-attributes file
>
> It would be more clear to use `file-attribute-size' instead of `nth'.

Thanks. Done.

>
>> +(> size 0)))
>> +  (should (not (get-buffer "*Org-Babel Error Output*"
>
> `should-not' would be a bit more succinct.

Thanks. Done.

>
>> +  (should (let ((size (nth 7 (file-attributes file
>> +(> size 0)))
>> +  (should (not (get-buffer "*Org-Babel Error Output*"
>
> See the previous comment.

Done.

The amended patch is attached. Thanks for your helpful feedback.

Leo

From 3d0a083f11a2b4f395c730a04ca243dda4a3a4e3 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 8 Nov 2022 13:31:47 -0600
Subject: [PATCH] prevent error in Octave process, add tests, update test docs

* lisp/ob-octave.el (org-babel-execute:octave):

  -Ensure that the special Octave variable `ans' is bound when
  GFX-FILE is non-nil.  The glue code in
  ORG-BABEL-OCTAVE-WRAPPER-METHOD causes Octave to exit with a
  non-zero exit code when `ans' is not bound.

  -Change format control string to %S from %s.  Ensure the graphics
  filename is quoted.  If it is not, Octave may create a mis-named
  file or fail entirely.

* testing/examples/ob-octave-test.org:

  Update the Graphical tests section:
  -put in the correct headers;
  -add a remark about where to find each test.

* testing/lisp/test-ob-octave.el:

  Add the three tests ob-octave/graphics-file,
  ob-octave/graphics-file-session and ob-octave/graphics-file-session.
  The first test verifies that the first bug identified above is
  fixed; it also verifies that graphics file creation works correctly
  for scripting.  The second test verifies graphics file creation
  works correctly for sessions.  The third test verifies that a
  graphics filename with a space in it is created correctly.

Thanks to Ihor Radchenko for helpful feedback.
Ref: https://list.orgmode.org/8735asbtfe.fsf@localhost/T/#u
---
 lisp/ob-octave.el   |  2 +-
 testing/examples/ob-octave-test.org | 12 +-
 testing/lisp/test-ob-octave.el  | 64 +
 3 files changed, 75 insertions(+), 3 deletions(-)

diff --git a/lisp/ob-octave.el b/lisp/ob-octave.el
index 55926b789..1cb0e70b5 100644
--- a/lisp/ob-octave.el
+++ b/lisp/ob-octave.el
@@ -91,7 +91,7 @@ end")
  (list
   "set (0, \"defaultfigurevisible\", \"off\");"
   full-body
-  (format "print -dpng %s" gfx-file))
+  (format "print -dpng %S\nans=%S" gfx-file gfx-file))
  "\n")
 		full-body)
 		  result-type matlabp)))
diff --git a/testing/examples/ob-octave-test.org b/testing/examples/ob-octave-test.org
index 9839d637e..bc19051a1 100644
--- a/testing/examples/ob-octave-test.org
+++ b/testing/examples/ob-octave-test.org
@@ -46,10 +46,18 @@ ans = s
 
 
 * Graphical tests
-#+begin_src octave :results graphics :file chart.png
+
+Graphics file.  This test is performed by =ob-octave/graphics-file= in =testing/lisp/test-ob-octave.el=.
+#+begin_src 

Re: [PATCH] Re: Update Org to MathJax 3

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> Is it really recommended by mathjax?

Yes.

> I cannot find any mention of jsdelivr.com.

1. Open MathJax docs (https://docs.mathjax.org/en/latest/).
2. Type "jsDelivr" into the search box.
3. Check the search results.

> You may update the URL to something more precise.

Fixed.

> Are these extensions no longer supported?

MathJax 3+ supports extensions, and one can load them in multiple ways.
See [1].  It deserves some thinking, for the extensions mirror LaTeX
extensions.  So, to make both HTML and PDF work, one has:

  Use the Physics package in both LaTeX and MathJax.

  #+latex_header: \usepackage{physics}
  
  #+html_head_extra: 
  #+html_head_extra:   \(
  #+html_head_extra: \require{physics}
  #+html_head_extra:   \)
  #+html_head_extra: 

(The example taken from my Org notebook.)

[1]: https://docs.mathjax.org/en/latest/input/tex/extensions.html

That said, I do not currently have bandwidth to extend the scope of the
patch to include MathJax extensions.  (Note that they have never worked
anyway, so the user loses nothing, and we correct documentation.)

A slight digression, just FYI:

I realized that I should have improved LaTeX to SVG exports instead of
focusing on MathJax.  Org supports LaTeX environments, but outside of
PDFs, it does so poorly.  Packages such as TikZ, for example, do not
work out of the box, so people use Babel to hack around it.  Worse
still, Org does not even properly adjust baselines for inline math, so
HTML exports remain barely usable for any mathematical work.

If we fix LaTeX, Org could have fast and good mathematics, with no
JavaScript, like Wikipedia has.  Then, we could use it by default,
instead of MathJax.

Having good support for LaTeX would position Org as the king of markup
editors, because LaTeX can do everything under the sun.  For instance,
one can typeset a chess game in a couple of lines.  Or sheet music.  Or
molecules in three dimensions.  No mainstream Markdown editor or web
authoring tool can do that.  Yet, Org can *almost* do it.

> It would be more compact to use `(...) notation.

Fixed.

> nreverse will be more memory-efficient.

Fixed and TIL.

> Mostly because supporting MathJax 2 is an extra maintenance burden.  I
> do not see much point catering bugs of MathJax2 -> MathJax3
> conversion. If users want to use MathJax2 specifically, they should be
> able to customize Org to use MathJax2. If they want MathJax3, they
> need to fix the options. Relying on auto-conversion is calling for
> trouble.

Fixed.

Please see the 6th version of the patch, attached below.

P.S. I also replaced two subsequent `setq' calls with one.

Rudy
>From 5009350869879cce6f083a9b38961b95f1c51f58 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Fri, 7 Oct 2022 15:03:48 +0200
Subject: [PATCH] ox-html: Update from MathJax 2 to MathJax 3+

* lisp/ox-html.el (
org-html-mathjax-options,
org-html-mathjax-template,
org-html--build-mathjax-config
): Update from MathJax 2 to 3 while maintaining compatibility.  All
legacy options should continue to work, except for the 'path' option
which must now point to MathJax 3 or later.
* testing/lisp/test-ox-html.el (
ox-html/mathjax-path-none,
ox-html/mathjax-path-default,
ox-html/mathjax-path-custom,
ox-html/mathjax-path-in-buffer,
ox-html/mathjax-options-default,
ox-html/mathjax-options-custom,
ox-html/mathjax-options-in-buffer,
ox-html/mathjax-legacy-scale-default,
ox-html/mathjax-legacy-scale-custom,
ox-html/mathjax-legacy-scale-in-buffer,
ox-html/mathjax-legacy-scale-message,
ox-html/mathjax-legacy-scale-message-in-buffer,
ox-html/mathjax-legacy-scale-ignore,
ox-html/mathjax-legacy-autonumber-ams,
ox-html/mathjax-legacy-autonumber-ams-in-buffer,
ox-html/mathjax-legacy-autonumber-none,
ox-html/mathjax-legacy-autonumber-none-in-buffer,
ox-html/mathjax-legacy-autonumber-all,
ox-html/mathjax-legacy-autonumber-all-in-buffer,
ox-html/mathjax-legacy-autonumber-message,
ox-html/mathjax-legacy-autonumber-message-in-buffer,
ox-html/mathjax-legacy-font-tex,
ox-html/mathjax-legacy-font-tex-in-buffer,
ox-html/mathjax-legacy-font-stix-web,
ox-html/mathjax-legacy-font-stix-web-in-buffer,
ox-html/mathjax-legacy-font-asana-math,
ox-html/mathjax-legacy-font-asana-math-in-buffer,
ox-html/mathjax-legacy-font-neo-euler,
ox-html/mathjax-legacy-font-neo-euler-in-buffer,
ox-html/mathjax-legacy-font-gyre-pagella,
ox-html/mathjax-legacy-font-gyre-pagella-in-buffer,
ox-html/mathjax-legacy-font-gyre-termes,
ox-html/mathjax-legacy-font-gyre-termes-in-buffer,
ox-html/mathjax-legacy-font-latin-modern,
ox-html/mathjax-legacy-font-latin-modern-in-buffer,
ox-html/mathjax-legacy-line-breaks-true,
ox-html/mathjax-legacy-line-breaks-true-in-buffer,
ox-html/mathjax-legacy-line-breaks-false,
ox-html/mathjax-legacy-line-breaks-false-in-buffer,
ox-html/mathjax-legacy-line-breaks-message,
ox-html/mathjax-legacy-line-breaks-message-in-buffer): Test MathJax in
general and also the conversion of legacy options from MathJax 2 to 3.

Re: [PATCH] ob-java: Define the list of all supported header arguments

[Rudolf Adamkovič]

Ihor Radchenko  writes:

>> ...  The remaining tests (`test-org-num' and `test-org-table') fail
>> in both scenarios.  That said, I run macOS, which has some issues with
>> sorting [*].
>
> This is not because of macOS. Emacs 29 broke some assumptions about
> return value of `overlays-in'. See
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59067

The second one (`test-org-table') still fails on macOS.

Overall, I now see the following failures on the main branch:

   FAILED  ob-java/lint-header-args-block
   FAILED  ob-java/lint-header-args-buffer
   FAILED  ob-java/lint-header-args-heading
   FAILED  test-org-table/sort-lines

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: extended background on org-block-end-line

[Ihor Radchenko]

Abdul-Lateef Haji-Ali  writes:

> I saw the bug report on Emacs, but I am not sure how to reply to a thread 
> there without being subscribed to the mailing list, so I will reply here.

You can reply in https://yhetil.org/emacs-bugs/87o7tfkby9@gmail.com/T/#t

> I think a possible solution that can be implemented in org-mode side would be 
> for the outline to include the new line character after `#+end_src` to hide 
> the whole line (including the extended background). The final result can then 
> be fixed by adding a newline character to the `...` glyph.

Juri proposed a similar idea in
https://yhetil.org/emacs-bugs/87o7tfkby9@gmail.com/T/#m7baceaf9a109cc7ca118b7e834cbfaa7c7e792fd
I replied there.

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

Re: [BUG] EXPORT_FILE_NAME keyword is used by `org-export-output-file-name' before macro expansion/INCLUDEs/removing COMMENTed trees (was: Confused about what the COMMENT keyword means)

[Ihor Radchenko]

Ihor Radchenko  writes:

> There should be no other buffer setting that is taken into account
> in COMMENTed subtrees. EXPORT_FILE_NAME is the only one.
>
> I think that we should not really change the manual unless we have to.
> It will be better to fix the bug instead.

I am attaching a tentative change to ox.el machinery that will allow
calculating EXPORT_FILE_NAME dynamically inside the processed export
buffer.

The change is not yet fixing the bug. I just want to hear feedback
on the approach I used.

Let me know if you see any issues or have better ideas.

>From 57aa366e9d5596741c256688c9b8ef07a9b24e17 Mon Sep 17 00:00:00 2001
Message-Id: <57aa366e9d5596741c256688c9b8ef07a9b24e17.1668044888.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Thu, 10 Nov 2022 09:39:20 +0800
Subject: [PATCH] org-export: Allow export file name to be determined after
 export processing

* lisp/ox.el (org-export-as): When :output-file info property is set
to a list, calculate :output-file after expanding macros, removing
uninterpreted data, and other processing.  Use the list value is used
as argument list for `org-export-output-file-name'.  Add new optional
argument WITH-INFO to return the info channel in addition to the
export string.
(org-export-to-file): Allow FILE argument to be an argument list to be
passed to `org-export-output-file-name' in the processed export
buffer.

This patch allows calculating the output file name after expanding all
the macros, cleaning up commented trees, and other export processing.
In particular, #+EXPORT_FILE_NAME keywords inside commented trees can
be ignored in contrast to what `org-export-output-file-name' returns
on the original Org file.

This patch is not changing any existing behavior and not fixing the
reported byg.  The callers of `org-export-to-file' still need to
change FILE argument to make use of the changes herein.

Reported-by: alain.coch...@unistra.fr
Link: https://orgmode.org/list/25422.27044.980916.495...@gargle.gargle.howl
---
 lisp/ox.el | 59 ++
 1 file changed, 42 insertions(+), 17 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 770f86740..82cf0d166 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2994,7 +2994,8 @@ (defun org-export--remove-uninterpreted-data (data info)
 
 ;;;###autoload
 (defun org-export-as
-(backend &optional subtreep visible-only body-only ext-plist)
+(backend
+ &optional subtreep visible-only body-only ext-plist with-info)
   "Transcode current Org buffer into BACKEND code.
 
 BACKEND is either an export back-end, as returned by, e.g.,
@@ -3020,7 +3021,10 @@ (defun org-export-as
 with external parameters overriding Org default settings, but
 still inferior to file-local settings.
 
-Return code as a string."
+Return code as a string.
+
+When optional argument WITH-INFO is non-nil, return a cons cell with car
+containing return code string and cdr containing the info channel."
   (when (symbolp backend) (setq backend (org-export-get-backend backend)))
   (org-export-barf-if-invalid-backend backend)
   (org-fold-core-ignore-modifications
@@ -3106,6 +3110,14 @@ (defun org-export-as
 			 p
 			 (org-export--remove-uninterpreted-data value info
 	   (_ nil)))
+   ;; Update `:output-file' option if needed.
+   (let ((output-file (plist-get info :output-file)))
+ (when (and output-file (listp output-file))
+   (plist-put
+info :output-file
+(apply #'org-export-output-file-name
+   ;; `:output-file' contains argument list.
+   output-file
 	   ;; Install user's and developer's filters.
 	   (setq info (org-export-install-filters info))
 	   ;; Call options filters and update export options.  We do not
@@ -3155,10 +3167,13 @@ (defun org-export-as
 	 ;; Remove all text properties since they cannot be
 	 ;; retrieved from an external process.  Finally call
 	 ;; final-output filter and return result.
-	 (org-no-properties
-	  (org-export-filter-apply-functions
-	   (plist-get info :filter-final-output)
-	   output info)
+ (let ((final-output
+	(org-no-properties
+	 (org-export-filter-apply-functions
+	  (plist-get info :filter-final-output)
+	  output info
+   (if with-info (cons final-output info)
+ final-output)
 
 ;;;###autoload
 (defun org-export-string-as (string backend &optional body-only ext-plist)
@@ -6637,7 +6652,10 @@ (defun org-export-to-file
 BACKEND is either an export back-end, as returned by, e.g.,
 `org-export-create-backend', or a symbol referring to
 a registered back-end.  FILE is the name of the output file, as
-a string.
+a string.  FILE can also be a list of options to determine file name
+automatically.  The options will be used as arguments of
+`org-export-output-file-name', which will be called ri

Re: [BUG] EXPORT_FILE_NAME keyword is used by `org-export-output-file-name' before macro expansion/INCLUDEs/removing COMMENTed trees (was: Confused about what the COMMENT keyword means)

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> PS: there are a few occurrences of 'sub-tree' in the manual, but many
> of 'subtree'; I suggest to use 'subtree' everywhere -- better
> regarding searching.

Good point.
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=044f09aa6de8f1f38de0f9b517510690807b4ef2

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

[FR] Allow TITLE to be used as default export file name (was: [BUG] EXPORT_FILE_NAME keyword is used by `org-export-output-file-name' before macro expansion/INCLUDEs/removing COMMENTed trees (was: Con

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

>  > I recommend you to use :EXPORT_FILE_NAME: headline property and export
>  > using subtree scope.
>
> Thanks a lot for the tip.  A suggestion: that the :TITLE: property be
> used if it exists.

We currently fall back to file name if nothing else works.
Using TITLE is possible but cannot be done by default as a fallback ---
existing users relying on current behaviour will be affected by such
change.

We may add a defcustom though. It will be nil by default and setting it
to non-nil will make Org export fall back to TITLE rather than file
name.

However, there is no point adding yet another option if not many users
are interested. I am changing the subject of this email to facilitate
the feedback.

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

Re: [PATCH] ob-java: Define the list of all supported header arguments

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> The second one (`test-org-table') still fails on macOS.
>
> Overall, I now see the following failures on the main branch:
>
>FAILED  ob-java/lint-header-args-block
>FAILED  ob-java/lint-header-args-buffer
>FAILED  ob-java/lint-header-args-heading

AFAIK, Max is using Linux. This is strange...
And I cannot really fix it without being able to reproduce on my side.

>FAILED  test-org-table/sort-lines

Could you narrow down the particular test condition which is failing?
Is it similar to previously discussed cases where MacOS sorting is not
consistent with Linux?

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

Re: [patch] give tables their own default placement in LaTeX export

[Ihor Radchenko]

Eric S Fraga  writes:

> attached is a small patch to give tables their own default placement in
> LaTeX export.  Up to now, tables have used the default placement for
> figures but figures and tables are very different creatures so it does
> not make sense to have just one default for both.

Thanks for the patch, and sorry for the late reply.
This looks like a useful addition.

> This patch unfortunately could break documents (if people have changed
> the default for figures, expecting that change to apply to tables as
> well) but I see no way to avoid this.  So maybe not worth incorporating
> but I leave that decision to others.

There is a way to avoid this. See the comments below.

> Subject: [PATCH] lisp/ox-latex.el: give tables their own placement default
>
> * ox-latex.el (org-latex--org-table): define and use a new variable,
> org-latex-default-table-position, for setting the default placement
> option for the export of tables.

Please start sentences from capital letter and quote `symbols'.

> +*** Tables now have separate default placement option for LaTeX export
> +
> +Tables and figures now have separate settings for the default
> +placement in LaTeX export.

Please mention the new variable name.

> +(defcustom org-latex-default-table-position "htbp"

You can use

(defcustom org-latex-default-table-position nil

as the default value. Then, you can fallback for figure position in the
code when the value is nil. Need to update docstring accordingly.

> +  "Default position for LaTeX tables."
> +  :group 'org-export-latex
> +  :type 'string
> +  :version "26.1"

:version is not needed.

> +  :package-version '(Org . "9.0")

9.6

> (or (plist-get attributes :placement)
> -   (format "[%s]" (plist-get info :latex-default-figure-position
> +   (format "[%s]" (plist-get info :latex-default-table-position

Can use

(or (plist-get info :latex-default-table-position)
(plist-get info :latex-default-figure-position))

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

Re: [PATCH] Re: Update Org to MathJax 3

[Ihor Radchenko]

Rudolf Adamkovič  writes:

>> Are these extensions no longer supported?
>
> MathJax 3+ supports extensions, and one can load them in multiple ways.
> See [1].  It deserves some thinking, for the extensions mirror LaTeX
> extensions.  So, to make both HTML and PDF work, one has:
>
>   Use the Physics package in both LaTeX and MathJax.
>
>   #+latex_header: \usepackage{physics}
>   
>   #+html_head_extra: 
>   #+html_head_extra:   \(
>   #+html_head_extra: \require{physics}
>   #+html_head_extra:   \)
>   #+html_head_extra: 
>
> (The example taken from my Org notebook.)
>
> [1]: https://docs.mathjax.org/en/latest/input/tex/extensions.html
>
> That said, I do not currently have bandwidth to extend the scope of the
> patch to include MathJax extensions.  (Note that they have never worked
> anyway, so the user loses nothing, and we correct documentation.)

Then, please mention this in the NEWS. Something like "we drop extension
support as it never worked anyway".

> A slight digression, just FYI:
>
> I realized that I should have improved LaTeX to SVG exports instead of
> focusing on MathJax.  Org supports LaTeX environments, but outside of
> PDFs, it does so poorly.  Packages such as TikZ, for example, do not
> work out of the box, so people use Babel to hack around it.  Worse
> still, Org does not even properly adjust baselines for inline math, so
> HTML exports remain barely usable for any mathematical work.
>
> If we fix LaTeX, Org could have fast and good mathematics, with no
> JavaScript, like Wikipedia has.  Then, we could use it by default,
> instead of MathJax.
>
> Having good support for LaTeX would position Org as the king of markup
> editors, because LaTeX can do everything under the sun.  For instance,
> one can typeset a chess game in a couple of lines.  Or sheet music.  Or
> molecules in three dimensions.  No mainstream Markdown editor or web
> authoring tool can do that.  Yet, Org can *almost* do it.

Patches are always welcome ;)

> + (append `((,(if (plist-member options 'autonumber)
> + 'tags 'autonumber)
> +nil)
> +   (,(if (plist-member options 'linebreaks)
> + 'overflow 'linebreaks)
> +nil))
> + options)))

You may even drop append and use ,@options inside `(...). Not a big deal though.

> +  (`scale
> +   (when (stringp value)
> + (setq value (string-to-number value)))
> +   (when (>= value 10)

If value is invalid string (not an actual number), `string-to-number'
will return 0. This may cause very strange export output I think. 

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

Re: [PATCH] ox-icalendar: Create export backend options for deadline/scheduled-summary-prefix defcustoms

[Ihor Radchenko]

Ilya Chernyshov  writes:

> Sending the updated patch.

Applied onto main with minor amendments.
I added TINYCHANGE cookie to the docstring.
I added double space "  " between sentences according to our conventions.
I also fixed word order in the NEWS entry.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6c285af9fb591908578f8cfdc2aec980b4dbae0a

Thanks for your contribution!

You are now added to Org contributor list.
https://git.sr.ht/~bzg/worg/commit/0e93ede98773eb3ec81d3b030d3a2ca5921c89a8

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

Re: [PATCH] Re: [BUG][Security] begin_src :var evaluated before the prompt to confirm execution

[Ihor Radchenko]

Ihor Radchenko  writes:

> See the attached tentative patch.
> I tried to balance between annoying users with query and not evaluating
> unsafe code: '-quoted lists and symbols are still evaluated without
> prompt.

Fixed.
Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=10e857d42859a55b23cd4206ffce3ebd0f678583

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

[BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Hi,

I am trying to look into RTL language exports.

I tried the following simple-minded Org file:

#+title: Temp
#+LATEX_COMPILER: lualatex
#+LANGUAGE: HE

\begin{equation}
f(x) = \frac{8}{7}
\end{equation}

#+begin_src python :exports code
for i in range(3):
print("hello")
#+end_src

And exported to pdf (C-c C-e l o).
Surprisingly, the output is in English.

Am I missing something?

Emacs  : GNU Emacs 28.1.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, 
cairo version 1.16.0)
 of 2022-07-17
Package: Org mode version 9.6-pre (release_9.5.5-1087-g620a96.dirty @ 
/home/yantar92/.emacs.d/straight/build/org/)
-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Problem when tangling source blocks with custom coderefs

[Ihor Radchenko]

Luis Osa  writes:

> I would like to tangle source code blocks that contain coderefs. I have
> found that the coderefs are correctly filtered out from the tangled files
> if they follow the default format, i.e. "(ref:%s)", but not if I try to
> customize the format using the documented "-l" switch [1] to change them to
> something else, e.g. "|%s|".

I have looked through the ML archives and a similar issue appears to be
fixed already. See
https://orgmode.org/list/878s5rt81v@nicolasgoaziou.fr

> Here is an example:
>
> #+begin_src python -r -l "|%s|" :tangle example.py
> try:
> sys.exit(app.run())
> except:|\label{line:except}\ding{182}|
> sys.exit(1)
> #+end_src
>
> In line \ref{line:except}, marked \ding{182}, we are catching all
> exceptions ...

Note that we only allow _-A-Za-z0-9 in the labels. So, your example will
not work even after the fix.

Not sure if we need to do anything about this.

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

Re: [PATCH v2] org-attach.el: ID to path functions may return nil

[Ihor Radchenko]

Max Nikulin  writes:

> On 08/11/2022 12:08, Ihor Radchenko wrote:
>> 
>> I feel like this makes the docstring confusing.
>> 
>> Note that `org-attach-id-to-path-function-list':
>
> I have tried to update the docstrings.

Thanks!

>>> if: No attachment directory is associated with the current node, adjust
>>> ‘org-attach-id-to-path-function-list’
>>>
>>> I do not think this message is unhelpful.
>> 
>> With your patch, such message will be displayed even when
>> `org-attach-preferred-new-method' is set to something other than 'id.
>> And the message will be wrong then.
>
> I have moved `error' call despite I have not figured out how to trigger 
> the error for other options.

The main reason is code readability.

Also, one can trigger the other error for non-standard values of
`org-attach-preferred-new-method' .

>>> +(defun org-attach-id-fallback-folder-format (id)
>>> +  "May be added last to `org-attach-id-path-function-list'.
>> 
>> This is not a proper first line in a function docstring. First line must
>> describe what the function does.
>
> I am still unsure that in this case effect is more important than 
> purpose. The function is too specific.

That's a function and should follow standards. If we do not follow
standards, it will become harder to maintain Org.

If we want to be really specific, we may allow a special symbol in the
list indicating the fallback. I'd prefer this approach a bit better. No
strong opinion though.

> P.S. At first I believed that you have some objections concerning 
> changed role of the first function in the list, not just how it is 
> documented.

I had. Most importantly, because we are changing the existing meaning of
`org-attach-id-to-path-function-list'. However, the only scenario where
it actually matters is the bug report at hand. So, there will be no
regression.

However, please add NEWS entry detailing the change in
`org-attach-id-to-path-function-list' to the next version of the patch.

I have no other comments apart from various grammar issues and typos.
But that's easy to fix before merging.

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

Re: [FR] Allow TITLE to be used as default export file name (was: [BUG] EXPORT_FILE_NAME keyword is used by `org-export-output-file-name' before macro expansion/INCLUDEs/removing COMMENTed trees (was:

[Alain . Cochard]

Ihor Radchenko writes on Thu 10 Nov 2022 02:03:
 > alain.coch...@unistra.fr writes:
 > 
 > > > I recommend you to use :EXPORT_FILE_NAME: headline property and
 > > > export using subtree scope.
 > >
 > > Thanks a lot for the tip.  A suggestion: that the :TITLE:
 > > property be used if it exists.
 > 
 > We currently fall back to file name if nothing else works.  Using
 > TITLE is possible but cannot be done by default as a fallback ---
 > existing users relying on current behaviour will be affected by
 > such change.
 > 
 > We may add a defcustom though. It will be nil by default and
 > setting it to non-nil will make Org export fall back to TITLE
 > rather than file name.
 > 
 > However, there is no point adding yet another option if not many
 > users are interested. I am changing the subject of this email to
 > facilitate the feedback.

I am surprised by this message: like I said earlier when replying to
myself to the same message as the one to which you are replying, I
discovered the :EXPORT_TITLE: (headline) property, which does exactly
what I was looking for.

It is as if you missed that message of mine (or did not understand
what I wanted to say) AND forgot or don't know about the
:EXPORT_TITLE: property.  As I find it rather unlikely, I guess you
are thinking of something else, which is beyond me.

At any rate, there is no need for anything new in this repect, even
for me.

Best.


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]