Re: WORG licensing

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko  writes:

> However, I am still puzzled how different licenses may apply to the
> exact same text. In particular, it is not clear how the contradictions
> between licenses are handled in such scenario. (Or are you saying that
> CC BY SA 4.0 is fully compatible with GNU DFL 1.3?)

If a text is published under two different licenses, the user can choose
between them: if he chooses CC BY SA 4.0, he must abide by CC BY SA 4.0;
if he chooses GNU FDL 1.3+, he must abide by GNU FDL 1.3+. He does not
choose both *at the same time*.

If he clones a dual-licensed repo and doesn't change the license notice,
he gives other users the same choice.

Is it a little clearer?

-- 
 Bastien

Re: The Zen of Task Management with Org

[Ihor Radchenko]

Bastien Guerry  writes:

> I've finally found some time to describe my Org workflow:
> https://bzg.fr/en/the-zen-of-task-management-with-org/
> ...
> And I'm curious to see how it compares to other workflows.

Do you ever need to juggle large number of work projects with shifting
priorities and pauses?

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

Re: The Zen of Task Management with Org

[Bastien Guerry]

Ihor Radchenko  writes:

> Fair enough. I tend to have dozens of projects that have to be running
> in parallel and prioritized depending on deadlines or new information
> arriving. So, I personally need an elaborate setup of project priorities
> and statuses. So, I use todo keywords on projects just like on tasks;
> for the same purposes.

I see, but for me that would blur the line between project and task.

A "project" is open and running and contains tasks. A project does not
have a due date, it inherits the due date of the last task if it has to
stop at some point, I have a "Work" project and ~10 personal projects.

>> - STRT tasks do not change often: they are either STRT or DONE (hence
>>   the need for dedicated agenda views).
>
> I personally prefer DOING. IMHO, it creates a better sense that the task
> must be progressed further.

Agreed. I followed Rudolf's advice in this thread and now use "ONGO",
which conveys what I need now.

-- 
 Bastien

Re: Q: org-export-headline-levels doc problem?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> 1. docstring mentions inferior without defining inferior.  I think a
>>natural mistake is to assume inferior is where the headline level is
>>less than org-export-headline-levels (ie. < 3)
>> 2. In "13.2 Export Setting", 'H' says "below that level" -- again where
>>the value is less than 3?
>
> I agree that it might be confusing and that the wording can be improved.
>
>> The issue is level -- is it (1) the number of stars in the header or do
>> the stars mean (2) 1=highest and N=lowest level. Since this is a
>> "programmer's editor", my tendency is toward #1 (level=star#) and avoid
>> the use of inferior/superior in favor of above/below.
>
> Maybe deeper/shallower?

Maybe parent/child(ren) -- I think that is more in keeping with the use
of 'parent' elsewhere in the manual.

Also, I note the use of 'top level' in "2.1 Headlines" and would
probably replace it with 'first level' to keep with the numbering
scheme.

-- 
David Masterson

Re: The Zen of Task Management with Org

[Bastien Guerry]

Rudolf Adamkovič  writes:

> Here are some more details from my setup. :)

Interesting, thanks!

> I used to use NEXT but since realized:
>
>   NEXT is a priority, not a state.

To me, "NEXT" does not mean that the task is more important or urgent
than TODO tasks, it means that the task is in the "queue" of activated
tasks. TODOs are the "inventory", they are not activated until I want
them to appear in the agenda.

I guess you draw a similar line between ONGO and other keywords, with
"ONGO" having a similar meaning to "activated" for me.

Maybe I could find better keywords to express this but nothing comes to
mind at the moment 🙃

-- 
 Bastien

Re: Try gollum wiki to serve WORG

[Bastien Guerry]

Ihor Radchenko  writes:

> I just found https://ikiwiki.info/plugins/contrib/org_mode/ implementing
> exactly this idea for ikiwiki engine.

Great! Also, ikiwiki seems stable and the maintainer is still active, so
he might be interested to know that you're considering using it as an
experimental backend for Worg.

-- 
 Bastien

Re: The Zen of Task Management with Org

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Do you ever need to juggle large number of work projects with shifting
>> priorities and pauses?
>
> I don't really have "work projects", I just have a top level project
> called "work" that contains 2nd level tasks. I could have multiple work
> projects, but I don't have that need right now.

Fair enough. I tend to have dozens of projects that have to be running
in parallel and prioritized depending on deadlines or new information
arriving. So, I personally need an elaborate setup of project priorities
and statuses. So, I use todo keywords on projects just like on tasks;
for the same purposes.

> What I did for a while (and was wrong) was to SCHEDULE reminders for
> important tasks or set a DEADLINE for when I need to see the task pop up
> in my agenda. That's a terrible abuse of scheduling and deadlines...

+100500 :)
That's a terrible terrible idea to pollute agenda view with tasks that
do not absolutely need to be done on a given day. Such agenda is useless
in the long run.

> - STRT tasks do not change often: they are either STRT or DONE (hence
>   the need for dedicated agenda views).

I personally prefer DOING. IMHO, it creates a better sense that the task
must be progressed further.

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

Re: The Zen of Task Management with Org

[Rudolf Adamkovič]

Bastien Guerry  writes:

> - STRT tasks do not change often: they are either STRT or DONE (hence
>   the need for dedicated agenda views).
>
> - What *I* change a lot are (1) priority cookies and (2) NEXT/TODO
>   status. Something that was NEXT suddenly becomes something I can
>   forget, and vice versa.

Here are some more details from my setup. :)

I used to use NEXT but since realized:

  NEXT is a priority, not a state.

Now, priorities decide what is "up next":

  #A shows in agenda on top
  #B shows in agenda
  #C does not show in agenda

Because #B is the Org default, so I do not miss anything by mistake.

My keywords have been stable for a long-long time:

  #+todo: TODO(t) ONGO(o) WAIT(w) | DONE(d) SKIP(s)

Also, I have ONGO highlighted with the "clocked-in" face:

  (with-eval-after-load 'org
  (setq org-todo-keyword-faces
'(("ONGO" . org-agenda-clocking)
  ("WAIT" . org-sexp-date)
  ("SKIP" . org-agenda-dimmed-todo-face

Rudy
-- 
"Great minds discuss ideas; average minds discuss events; small minds
discuss people."  --- Anna Eleanor Roosevelt (1884-1962)

Rudolf Adamkovič  [he/him]
http://adamkovic.org

Re: [PATCH] lisp/org.el: Add ability to sort tags by hierarchy

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Fallback to `org-sort-function'.
>
> I am not sure if it is the best idea to hard-code using
> `org-sort-function' here.
>
> What if a user wants specific `org-sort-function' for, say, table
> sorting, but something else for tags?
> Secondary sorting would better be customizeable.
>
> Maybe you can have a function generator that will work like
>
> (org-tags-sort-hierarchy-by org-sort-function)
> or
> (org-tags-sort-hierarchy-by #'string<)

Morgan, may I know if you are still interested to finish the patch?

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

Re: [BUG] "Invalid search bound (wrong side of point)" [9.8-pre (release_9.7.16-169-ge87ecf @ ~/.emacs.d/org-mode-git/lisp/)]

[Ihor Radchenko]

Paul Stansell  writes:

>> I think that the easiest way to test things would be simply trying the
>> latest main branch.
>>
>
> Okay, I'll do that.

I am reviewing this complex bug report now.
Looks like everything should be fixed.
Fixed.
Let me know if you still see problems.

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

Re: WORG licensing

[Ihor Radchenko]

Bastien Guerry  writes:

> If a text is published under two different licenses, the user can choose
> between them: if he chooses CC BY SA 4.0, he must abide by CC BY SA 4.0;
> if he chooses GNU FDL 1.3+, he must abide by GNU FDL 1.3+. He does not
> choose both *at the same time*.
>
> If he clones a dual-licensed repo and doesn't change the license notice,
> he gives other users the same choice.
>
> Is it a little clearer?

Yes, it is.
I personally see no downsides in dual-licensing (assuming that at least
some users would prefer such a choice).
However, if we want to do it we:
1. Must ask the existing WORG contributors whether they are ok with
   re-licensing
2. May ask RMS whether he has objections.

Do you think it is worth it?

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

Re: WORG licensing

[Bastien Guerry]

Ihor Radchenko  writes:

> Do you think it is worth it?

IMHO no, unless there are many requests to use Worgs content under CC
BY-SA 4.0 that I'm not aware of.

-- 
 Bastien

Fwd: [PATCH]: Add font specifications when exporting to LaTeX

[Pedro Andres Aranda Gutierrez]

I had forgotten the list... sorry. To add to the message, I scan the buffer
for charsets using a variant of the code proposed by Juan Manuel Macías
some time ago...

Sorry and Best, /PA

-- Forwarded message -
From: Pedro Andres Aranda Gutierrez 
Date: Sun, 20 Apr 2025 at 15:34
Subject: Re: [PATCH]: Add font specifications when exporting to LaTeX
To: Ihor Radchenko 


PS: I'm progressing with the font header generation:

The font configuration is done in two variables:

(defvar org-latex-font-mapping-alist
  '(("main" . "Noto Serif")
("sans" . "Noto Sans")
("mono" . "Noto Sans Mono"))
  "Set this alist for your font preferences when exporting to
LuaLaTeX/XeTeX.
. Initially, this will generate a list of strings, each one an expansion
like:
\=\set...font{font name}")

(defvar org-latex-font-fallback-alist
  '(("emoji" . "Noto Color Emoji:mode-harf")
("han"   . "Noto Sans CJK JP:")
("kana"  . "Noto Sans CJK JP:"))
  "Set this alist with your fallback fonts definitions when exporting to
LuaLaTeX/XeTeX.

This will be merged with the charset-font list generated when scanning the
document
and placed in the header in a directlua block.")

It's quite close to pandoc, but much more flexible (they don't consider
\setromanfont{}, which this setup
would allow).

I know I'm working with the Noto fonts and some people will scream, but
this should end up by being a couple of
defcustoms with something reasonable and documentation to help people set
up their environment.

And with this and some code, I generate

\directlua{
 luaotfload.add_fallback("FallbackFonts", {
  "Noto Color Emoji:mode-harf",
 })
}

\setmainfont{Noto Serif}[RawFeature=Fallbackfonts]
\setsansfont{Noto Sans}[RawFeature=Fallbackfonts]
\setmonofont{Noto Sans Mono}[RawFeature=Fallbackfonts]

from an org buffer with UTF-8 and emojis.

Still a couple of weeks of work, now that we are at the end of the lecture
season here and we will start exams,
but this looks like a starting point for me.

WDYT, /PA

On Sun, 20 Apr 2025 at 15:24, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> Hi,
>
> On Sun, 20 Apr 2025 at 13:51, Ihor Radchenko  wrote:
>
>>
>> (Note that another option could be you creating a new git feature branch
>> and accumulating commits there.  Then, you can put NEWS entry after a
>> series of commit, summarizing all the changes.  We can merge that branch
>> after it is finished.)
>>
>> I remember that it was not easy to get git commit access. Could you
> please help me with that,
>
> Thx, /PA
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Sagen's Paradeiser, write BE!
> Year 1 of the New Koprocracy
>
>

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

Sagen's Paradeiser, write BE!
Year 1 of the New Koprocracy



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

Sagen's Paradeiser, write BE!
Year 1 of the New Koprocracy

Re: [PATCH] Re: Summation of effort estimates in columnview dblock

[General discussions about Org-mode.]

Ihor Radchenko  writes:

> [...]
> I am finally back to this request.
> Please see my take on changes to the manual.
> [...]

This looks great, and IMO is a big improvement adding the desired
clarity.

Many thanks for your efforts!

  --alexander

Re: Improve documentation of org-reverse-note-order

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I think we can leave these methods untouched for compatibility but
>> introduce some consistent aliases?
>>
>> | Action  | How to reverse filing order   |
>> |-+---|
>> | Refile  | Introduce org-refile-prepend  |
>> | Capture | Introduce org-capture-prepend |
>> | Note| Introduce org-note-prepend|
>> | Archive | ???   |
>>
>> Any consistent set of names should be fine, so perhaps
>> `org-refile-order', or `org-refile-reverse', and so on.
>> `org-capture-prepend' would be new functionality since there is no way
>> to reverse the default capturing order as far as I know.
>
> Sounds reasonable.

Karthik, did I understand correctly that you plan to submit a patch on
this?

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

Re: The Zen of Task Management with Org

[Bastien Guerry]

Ihor Radchenko  writes:

> Do you ever need to juggle large number of work projects with shifting
> priorities and pauses?

I don't really have "work projects", I just have a top level project
called "work" that contains 2nd level tasks. I could have multiple work
projects, but I don't have that need right now.

Of course, priorities often change. 

What I did for a while (and was wrong) was to SCHEDULE reminders for
important tasks or set a DEADLINE for when I need to see the task pop up
in my agenda. That's a terrible abuse of scheduling and deadlines...

When I managed to stick to using schedules and deadlines properly, I
misused to-do keywords by confusing them with priorities: for example, 
I would set a task to STRT just so it would show up first in the agenda
view.  Another wrong direction.

What happens now is this:

- SCHEDULED and DEADLINE don't move very often because I have very few
  things that are really scheduled or have a deadline.

- STRT tasks do not change often: they are either STRT or DONE (hence
  the need for dedicated agenda views).

- What *I* change a lot are (1) priority cookies and (2) NEXT/TODO
  status. Something that was NEXT suddenly becomes something I can
  forget, and vice versa.

This setup is not for everyone or every work constraint - but it feels
"self-regulating" in a sense.

-- 
 Bastien

Re: [PATCH] org-element.el; significant optimizations for org-element--interpret-affiliated-keywords

[Dwarshuis, Nathan J]

revised/rebased patch attached which no longer skips standard props
>From 528f2f6743afdc2681539f20f724f3b662b6040d Mon Sep 17 00:00:00 2001
From: ndwarshuis 
Date: Mon, 25 Nov 2024 22:04:09 -0500
Subject: [PATCH] org-element.el: Make affiliated keyword interpreter faster

* lisp/org-element.el (org-element--interpret-affiliated-keywords):
Optimize performance by bypassing unnecessary types and reducing
loop complexity. Added new constant
`org-element-elements-no-affiliated` which stores the types to
be bypassed.

This function was doing redundant work on several levels which
dramatically reduced performance of interpreting element nodes
relative to object nodes.

First, all types were interpreted regardless of if they could
possibly contain affiliated keywords. Skipping these types
dramatically speeds up typical use cases since many of these
skipped types are common (headline, item, etc).

Second, the loop was much more complex than needed. The loop included
:standard-properties which should not be necessary here. It also
duplicated some work between calls to `org-element--properties-mapc`
and `mapconcat` (the code was moved entirely under the former). The
result should be faster and more readable.

TINYCHANGE
---
 lisp/org-element.el | 85 -
 1 file changed, 45 insertions(+), 40 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 56c03a0aa..e4e1dd55d 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -335,6 +335,12 @@ specially in `org-element--object-lex'.")
   (append org-element-recursive-objects '(paragraph table-row verse-block))
   "List of object or element types that can directly contain objects.")
 
+(defconst org-element-elements-no-affiliated
+  '(org-data comment clock headline inlinetask item
+ node-property planning property-drawer
+ section table-row)
+  "List of paragraph-level node types that cannot have affiliated keywords.")
+
 (defconst org-element-affiliated-keywords
   '("CAPTION" "DATA" "HEADER" "HEADERS" "LABEL" "NAME" "PLOT" "RESNAME" "RESULT"
 "RESULTS" "SOURCE" "SRCNAME" "TBLNAME")
@@ -5528,49 +5534,48 @@ to interpret.  Return Org syntax as a string."
 			  (make-string blank ?\n)
 (funcall fun data nil)))
 
+(defun org-element--interpret-affiliated-keyword (key value)
+  "Interpret affiliated keyword with KEY and VALUE."
+  (let (dual)
+(when (member key org-element-dual-keywords)
+  (setq dual (cdr value) value (car value)))
+(concat "#+" (downcase key)
+(and dual
+ (format "[%s]" (org-element-interpret-data dual)))
+": "
+(if (member key org-element-parsed-keywords)
+(org-element-interpret-data value)
+  value)
+"\n")))
+
 (defun org-element--interpret-affiliated-keywords (element)
   "Return ELEMENT's affiliated keywords as Org syntax.
 If there is no affiliated keyword, return the empty string."
-  (let ((keyword-to-org
-	 (lambda (key value)
-	   (let (dual)
-	 (when (member key org-element-dual-keywords)
-	   (setq dual (cdr value) value (car value)))
-	 (concat "#+" (downcase key)
-		 (and dual
-			  (format "[%s]" (org-element-interpret-data dual)))
-		 ": "
-		 (if (member key org-element-parsed-keywords)
-			 (org-element-interpret-data value)
-		   value)
-		 "\n")
-(mapconcat
- (lambda (prop)
-   (let ((value (org-element-property prop element))
-	 (keyword (upcase (substring (symbol-name prop) 1
-	 (when value
-	   (if (or (member keyword org-element-multiple-keywords)
-		   ;; All attribute keywords can have multiple lines.
-		   (string-match-p "^ATTR_" keyword))
-	   (mapconcat (lambda (line) (funcall keyword-to-org keyword line))
-			  value "")
-	 (funcall keyword-to-org keyword value)
- ;; List all ELEMENT's properties matching an attribute line or an
- ;; affiliated keyword, but ignore translated keywords since they
- ;; cannot belong to the property list.
- (let (acc)
-   (org-element-properties-mapc
-(lambda (prop _ __)
-  (let  ((keyword (upcase (substring (symbol-name prop) 1
-(when (or (string-match-p "^ATTR_" keyword)
-		  (and
-		   (member keyword org-element-affiliated-keywords)
-		   (not (assoc keyword
-			 org-element-keyword-translation-alist
-  (push prop acc
-element t)
-   (nreverse acc))
- "")))
+  ;; there are some elements that will never have affiliated keywords,
+  ;; so do nothing for these
+  (if (member (org-element-type element)
+  org-element-elements-no-affiliated)
+  ""
+(let (acc)
+  (org-element-properties-resolve element t)
+  (org-element--properties-mapc
+   (lambda (prop value)
+ (when value
+   (let* ((keyword (upcase (substring (symbol-name prop) 1)))
+  (attrp (stri

Re: [PATCH]: Add font specifications when exporting to LaTeX

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> this is the first of a series of patches for font management. This one is
> independent of the
> fallback or font selection mechanism. So I'm sending it separately.

Thanks!

> --- a/etc/ORG-NEWS
> +++ b/etc/ORG-NEWS
> @@ -335,2 +335,2 @@ This option makes ~org-cite~'s ~basic~ insert processor 
> use
>  It can also be set to dynamically compute ~crm-separator~ so that the
>  separator does not appear in completion candidates.
>
> +*** LaTeX export font management is changing
> +Exporting to LaTeX and Beamer is undergoing a gradual change:
> +1. Default font management packages follow 
> [[https://github.com/jgm/pandoc/blob/main/data/templates/fonts.latex][~pandoc~
>  conventions]]

Please write news entry that reflect actual changes made in the patch,
not planned changes. Otherwise, this patch cannot qualify as a separate
patch.

(Note that another option could be you creating a new git feature branch
and accumulating commits there.  Then, you can put NEWS entry after a
series of commit, summarizing all the changes.  We can merge that branch
after it is finished.)

>  (defcustom org-latex-default-packages-alist
> -  '(;; amsmath before fontspec for lualatex and xetex
> -("" "amsmath"   t ("lualatex" "xetex"))
> -;; fontspec ASAP for lualatex and xetex
> -("" "fontspec"  t ("lualatex" "xetex"))
> +  '(;; fontspec is loaded by either of these
> +("" "mathspec" t ("xetex"))
> +("" "unicode-math" t ("lualatex"))

You are replacing amsmath with mathspec in xetex and unicode-math in
lualatex.

According to https://ctan.org/pkg/unicode-math,

here are some differences between the legacy mathematical
definitions in LATEX and amsmath, and the Unicode mathematics
definitions. Care should be taken when transitioning from a legacy
workflow to a Unicode-based one.

We need to explore this further.

https://ctan.org/pkg/mathspec documentation says that it may still
require amsmath:

If amsmath is required, it must be loaded earlier than mathspec

also,

The package is under development and later versions might to be
incompatible with this version, as this version is incompatible with
earlier versions

So, it may not be wise to use mathspec.

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

Re: vsum in tables with a lot of hlines

[Uwe Brauer]

Sent from my iPhone

> On 20. Apr 2025, at 10:52, Christian Moe  wrote:
> 
> 1) @ = @I4. Keep the 'I', but with the option of using a multiplier
> instead of additive notation.

Or
@ = @I*4

smime.p7s
Description: S/MIME cryptographic signature

WORG licensing (was: [DISCUSSION] Contributing policy for WORG)

[Ihor Radchenko]

Bastien Guerry  writes:

>> Maybe I am missing something, but how can we do more than one license
>> for the same WORG page?
>
> There are two ways in which two licences can "apply" to some content:
> either by covering different parts of it, or by offering users a choice
> of which licence to accept.
> ...
> If deemed useful by the community and potential contributors, we could
> also propose to license Worg's documentation non-code parts under both
> GNU FDL 1.3 or later and Creative Commons BY SA 4.0 - this would require
> getting permission to relicense past contents under CC by SA 4.0 though,
> which might be a chore.

I am familiar with applying licenses to different parts of the document.

However, I am still puzzled how different licenses may apply to the
exact same text. In particular, it is not clear how the contradictions
between licenses are handled in such scenario. (Or are you saying that
CC BY SA 4.0 is fully compatible with GNU DFL 1.3?)

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

Re: [PATCH] ob-dot: Add `graphviz-dot' language alias

[Ihor Radchenko]

Ihor Radchenko  writes:

> I would not object making "graphviz" an alias to "dot" lang name for
> babel.
> ...
> I think that the least breaking course of action would be creating
> ob-graphviz.el that simply loads ob-dot.

It has been a while.
Rudolf, may I know if you are still interested in this patch?

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

Re: [PATCH] Have org-string-width's temporary buffer be declared as such

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>>> -  (with-current-buffer (get-buffer-create " *Org string width*")
>>> +  (with-current-buffer (get-buffer-create " *Org string width*" t)
>>
>> ... just one problem - `get-buffer-create' in Emacs 27 does not yet have
>> the second optional argument. And we still support Emacs 27 (until when
>> Emacs 30 is released). See 
>> https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
>>
>> Also, since we are using `get-buffer-create', we only do it once per
>> Emacs session at most. So, I am not sure if it is a big deal.
>> I do not mind merging the patch after Emacs 30 is out though.
>
> Emacs 30 is out, so we may install the patch on main.

Applied, onto main, changing the commit message to have changelog and rewording.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cb36b1627d

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

Re: Org manual: Confused about parentheses in "filename=(buffer-file-name)" in code block header

[Ihor Radchenko]

Ihor Radchenko  writes:
>> Yet, I think it would be clearer hence more helpful if the example were
>> self-contained.  With my poor knowledge of elisp, I still don't know how to
>> construct one...
>
> May you elaborate? I do not understand which example you are referring
> to and what you mean by "self-contained".

Since I do not understand the problem, I see not what can be improved.
Canceled.

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

Re: Code evaluation security and diary-sexps [9.7.27]

[Ihor Radchenko]

Henrik Ahlgren  writes:

>  %%(shell-command "echo ssh-ed25519 C3NzaC1lZDI1NTE5IJjBADKEY >> 
> ~/.ssh/authorized_keys" "*Messages*") X
>
> I believe this poses a risk, particularly if the user has
> `org-agenda-files` pointing to files or directories that may not be
> entirely trustworthy. Consequently, simply executing `org-agenda` will
> evaluate those sexps without any confirmation. This should be thoroughly
> documented, and it would be even better if there were safety checks in
> place for the Lisp expressions. Is there any reason to allow functions
> with side effects?

See https://list.orgmode.org/orgmode/87edsd5o89.fsf@localhost/

Why allow functions with side effects? Because we cannot determine
wether a given function has side effects or not by looking at it.
And any diary sexp is a function call.

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

Re: [PATCH]: Add font specifications when exporting to LaTeX

[Pedro Andres Aranda Gutierrez]

Answers inline

/PA

On Sun, 20 Apr 2025 at 13:51, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > this is the first of a series of patches for font management. This one is
> > independent of the
> > fallback or font selection mechanism. So I'm sending it separately.
>
> Thanks!
>
> > --- a/etc/ORG-NEWS
> > +++ b/etc/ORG-NEWS
> > @@ -335,2 +335,2 @@ This option makes ~org-cite~'s ~basic~ insert
> processor use
> >  It can also be set to dynamically compute ~crm-separator~ so that the
> >  separator does not appear in completion candidates.
> >
> > +*** LaTeX export font management is changing
> > +Exporting to LaTeX and Beamer is undergoing a gradual change:
> > +1. Default font management packages follow [[
> https://github.com/jgm/pandoc/blob/main/data/templates/fonts.latex][~pandoc~
> conventions]]
>
> Please write news entry that reflect actual changes made in the patch,
> not planned changes. Otherwise, this patch cannot qualify as a separate
> patch.
>

OK.


> (Note that another option could be you creating a new git feature branch
> and accumulating commits there.  Then, you can put NEWS entry after a
> series of commit, summarizing all the changes.  We can merge that branch
> after it is finished.)
>



> >  (defcustom org-latex-default-packages-alist
> > -  '(;; amsmath before fontspec for lualatex and xetex
> > -("" "amsmath"   t ("lualatex" "xetex"))
> > -;; fontspec ASAP for lualatex and xetex
> > -("" "fontspec"  t ("lualatex" "xetex"))
> > +  '(;; fontspec is loaded by either of these
> > +("" "mathspec" t ("xetex"))
> > +("" "unicode-math" t ("lualatex"))
>
> You are replacing amsmath with mathspec in xetex and unicode-math in
> lualatex.
>

Yes I was tempted to use unicode-math in both, but refrained...

According to https://ctan.org/pkg/unicode-math,
>
> here are some differences between the legacy mathematical
> definitions in LATEX and amsmath, and the Unicode mathematics
> definitions. Care should be taken when transitioning from a legacy
> workflow to a Unicode-based one.
>
> We need to explore this further.
>

I was just trying to mimic what pandoc is doing as per your suggestion ;-)


> https://ctan.org/pkg/mathspec documentation says that it may still
> require amsmath:
>
> If amsmath is required, it must be loaded earlier than mathspec
>
> also,
>
> The package is under development and later versions might to be
> incompatible with this version, as this version is incompatible with
> earlier versions
>
> So, it may not be wise to use mathspec.
>

So, do you suggest to stay with unicode-math for everybody? That would be
the other
path to go. OK, yes, warning everybody using lualatex/xetex that we are
using unicode-math
and that they may need to fine-tune their documents...


>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> 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

Sagen's Paradeiser, write BE!
Year 1 of the New Koprocracy

Emacs new literate configuration approach

[Moakt Temporary Email]

Greetings everyone,


After I proposed a new customization interface for Emacs [1], I jumped on the 
occasion to rewrite my literate org configuration to replicate this interface 
idea there.

I saw many and various configurations files using org, (from where I took some 
inspiration when I first started), but I did not came across the approach I am 
presenting below.  I am sure it will interest many people already using org to 
configure emacs (and maybe others to jump into org and try it).



What I had before:
--

* package1
#+begin_src emacs-lisp
   (use-package package1 ...)
#+end_src
* package2
#+begin_src emacs-lisp
   (use-package package2 ...)
#+end_src




What I have after:
--

#+TAGS: [ group1 : tag1 tag2 tag3 tag4 tag5 ]
#+TAGS: [ group2 : tag6 tag7 tag8 tag9 ]

   filters
  -
group1 : tag1 tag2 tag3 tag4 tag5
group2 : tag6 tag7 tag8 tag9


* package1 :tag1:tag2:
   ** option1   :tag3:tag4:tag5:
  - [ ] choice1
  - [X] choice2
  - [ ] choice3
   ** option2   :tag4:tag5:tag6:
   ** option3   :tag5:tag6:tag7:
   ** install  
   ** load/enable feature
   ** keymap/keybinding
* package2
   same here.





So what I did, is that, I removed almost all (use-package) declarations.  Some 
of the main advantages are :

- allow tagging options individually, and easily find them later.

- allow adding org comments for each option separatly, (and even sometimes for 
a given choice).

- easily reference (via org links) other options individually, from within org 
comments.

- Also IMO, for new users for example, it is easier to read and understand this 
org configuration, than to see a (use-package) declaration.  It is true that 
org comments will help, but also new users won’t have an additional step to 
learn use-package.

- it introduces new users directly to Emacs Lisp functions, like hook 
functions, etc, which make it easier for them to learn Emacs Lisp, and also to 
easily hack things to their preferences.

- this also allows sharing more granular code snippets (as needed), instead of 
having to copy a whole (use-package) declaration, and sometimes without really 
understanding what the declaration (or a part of it) is supposed to do, and how 
someone is supposed to tweak it, without breaking anything (and without having 
to learn use-package, as a prerequisite).



This is not a with/against use-package discussion at all (please don’t divert 
from the main idea).  The main reason I removed use-package is to be able to 
_tag options individually, to easily find them later_ , (for this, I wanted 
each org code-block to be totally independent from all others code-blocks).  
This is the fundamental idea behind this new literate config approach (besides 
the other advantages it provides, which are numerous)





I will explain briefly each part :


Filters:

These are org links (ex. [[mytagfilter:tag1][tag1]]).  Clicking on tag1 for 
example, will show only options tagged as “tag1” (and at the same time, will 
hide other irrelevant tags that makes no sense to select anymore).  It is a 
known filter mechanism, and is not specific to this approach. (I hope if org 
maintainers and/or contributors can implement this in org, because I find it 
useful in all my org files.  I think many would find it useful too.)




Install:

Is how to install the package.  This is still work in progress, but this is how 
I imagine it :


** install
  - [ ] immediately
  call package functions directly.
  - [ ] at the end of the init
  append the package name in a variable and install the packages at the end.
  - [ ] etc
  other installation methods.

Maybe use-package or others can be (temporary) used here, if someone wants to 
(for its installation part).  Use-package can still be used, anywhere someone 
find it useful, it is not mandatory to completely remove use-package (but only 
for a single purpose).  Emacs is hackable after all, and everyone can use 
whatever they want.


   

Options:


** option
   - [ ] choice1 (default)
 The default value should not be tangled into the init file.
  #+begin_src emacs-lisp
  (setopt option defaultvalue)
  #+end_src
   - [ ] choice2
  #+begin_src emacs-lisp
  (setopt option value2)
  #+end_src
   - [ ] choice3
  #+begin_src emacs-lisp
  Sometimes user needs to write complex regex.
  #+end_src
   - [X] choice4
  #+begin_src emacs-lisp
  Sometimes user needs to add/remove hooks.
  Sometimes user needs to do that for specific mode(s).
  #+end_src
   - [ ] choice5
  #+begin_src emacs-lisp
  Sometimes user needs to write a complex functions.
  #+end_src
   - [ ] etc


Some may say it is sometimes difficult to divide some options into more 
granular cho

Re: Try gollum wiki to serve WORG

[Ihor Radchenko]

Bastien Guerry  writes:

> Thanks for the report!
>
> Ihor Radchenko  writes:
>
>> At least, looking at
>> https://github.com/xwmx/pandoc-ruby/blob/master/lib/pandoc-ruby.rb
>> (366LOC), I do not see why we cannot change it to use emacs instead of
>> pandoc to render html.
>
> It would be interesting indeed.

I just found https://ikiwiki.info/plugins/contrib/org_mode/ implementing
exactly this idea for ikiwiki engine.

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

Re: [Patch] Support png overlay background transparency in a transparent frame

[Ihor Radchenko]

gynamics  writes:

>> However, you can also set :background in `org-format-latex-options' to
>> "Transparent". Did you try it?
>
> Yes, I have reviewed related code and tried it.  Set `:background 
> "Transparent"` in `org-format-latex-option` only makes sure that latex 
> will output png images with a transparent background. But to display the 
> transparent part transparently when my Emacs frame has 
> `alpha-background` set to be transparent, currently `:mask heuristic` 
> seems to be the only way, afaik.

According to my bug#77104 report to Emacs 
(https://yhetil.org/emacs-bugs/87h63q9pxw.fsf@localhost/)
the problem with transparency is indeed an Emacs bug.

However, I am afraid that :mask heuristic will do more harm than benefit
to be applied Org upstream. Specifically, I am afraid that :mask
heuristic may cause ugly rendering when image file happens to _not_ have
background color in the corners. So, while solving your specific issue,
we may introduce another issue for _more_ users.

Thus, I am canceling this patch.
Canceled.

After bug#77104 is fixed, you should be able to setup transparency to
achieve what you need.

Meanwhile, I can only suggest adding an advise to
`org--make-preview-overlay' to apply :mask heuristics.

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

Re: [PATCH]: Add font specifications when exporting to LaTeX

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

>> You are replacing amsmath with mathspec in xetex and unicode-math in
>> lualatex.
>>
>
> Yes I was tempted to use unicode-math in both, but refrained...

Looks like modern unicode-math supports both, so why not?

> According to https://ctan.org/pkg/unicode-math,
>>
>> here are some differences between the legacy mathematical
>> definitions in LATEX and amsmath, and the Unicode mathematics
>> definitions. Care should be taken when transitioning from a legacy
>> workflow to a Unicode-based one.
>>
>> We need to explore this further.
>
> I was just trying to mimic what pandoc is doing as per your suggestion ;-)

My suggestion was "check out how pandoc handles the problem". Whether we
need to do the same should be judged separately, considering our viewpoint.

Note that I am not saying that we should discard the idea. AFAIU,
unicode-math is aiming to replace amsmath completely. So, it should be
*mostly* working fine.

What I am asking you and other interested people is finding what may be
broken if we switch from amsmath to unicode-math. Maybe we can work
around some breakage. Maybe the breakage can be ignored. Who knows. I
just want several people to look for what kinds of bad things we may do
to Org users by replacing amsmath with unicode-math.

>> So, it may not be wise to use mathspec.
>
> So, do you suggest to stay with unicode-math for everybody?

I am inclined to this idea, yes.

> ... That would be
> the other
> path to go. OK, yes, warning everybody using lualatex/xetex that we are
> using unicode-math
> and that they may need to fine-tune their documents...

Of course. But we need to make sure that it is just "fine-tune". Not
"everything broken with cryptic errors".

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

Text editing is very slow when org-highlight-latex-and-related is (latex)

[tanioka]

When the variable `org-highlight-latex-and-related' is set to `(latex)',
opening an Org file and inserting or deleting characters may cause too
much time lag, making text editing difficult.

For example, in my environment, when I opened the `text.org' created
with the command below and inserted a character at the beginning of the
first line, it took about 1 second for the typed character to appear.

┌
│ yes `printf 'ABCDEFGHIJ%.0s' {1..8}` | head -c 10MB > text.org
└

This issue was confirmed with Org 9.7.28 and
`80268c0e075bb69e7890146a8d7240e920fc786c', but it did not occur with an
older version `114de1571af27a5dbf7b103971ceec61de296637'.

The results measured with `profiler.el' by editing `text.org' on Org
9.7.28 are as follows.

┌
│ 71332  99% - redisplay_internal (C function)
│ 71323  99%  - jit-lock-function
│ 71323  99%   - jit-lock-fontify-now
│ 71323  99%- jit-lock--run-functions
│ 71323  99% - #
│ 71323  99%  - font-lock-fontify-region
│ 71323  99%   - font-lock-default-fontify-region
│ 71323  99%- font-lock-fontify-keywords-region
│ 71277  99% - org-do-latex-and-related
│ 71277  99%  - if
│ 71277  99%   - progn
│ 71277  99%- let
│ 71277  99% - catch
│ 71277  99%  - while
│ 71277  99% and
│46   0% + org-cite-activate
│70   0% + command-execute
│15   0% + ...
└

Below are some other things I noticed and my thoughts.

1. The time lag increases in proportion to the file size, intuitively.

2. The closer the edit position is to the end of the file, the smaller
   the time lag.

3. If there is even one LaTeX formula a few lines below the editing
   position, the time lag will almost disappear.

Basically, every time a character is inserted or deleted,
`org-do-latex-and-related' is called. When the variable
`org-highlight-latex-and-related' is non-nil, `re-search-forward' is
called from this function.

When editing the beginning of `text.org', the `re-search-forward' call
took about 1.26 seconds. If the file had no LaTeX expressions, this time
was roughly proportional to the file size.

Versions prior to `80268c0e075bb69e7890146a8d7240e920fc786c' specify the
argument `BOUND' for `re-search-forward', so they are less likely to be
affected by file size and distance to the next LaTeX formula.

My execution environment is as follows.

• Ubuntu 24.04
• Emacs 29.3
• CPU: AMD Ryzen 7 5700G 3.8GHz

Re: [PATCH] Add code element inside src-block in ox-html

[Timothy]

> Timothy, may you take a look?

Sure, sorry for the delay. I'm not quite sure whether we should have `` 
within `` unfortunately. On one hand, it doesn't break from the the whatwg 
intended use case, but the examples do seem to emphasise inline usage and if we 
check https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/code 
we see the element described as "the inline code element". That said, the MDN 
docs do also say "To represent multiple lines of code, wrap the  element 
within a  element.".

So, I think this is probably slightly unusual in practice, but also fine to do. 
Consistency with the klipsify version seems worth it, regardless of which way 
we go.

All the best,
Timothy.

On Wed, Mar 12, 2025, at 1:51 AM, Ihor Radchenko wrote:
> Nikolaos Chatzikonstantinou  writes:
>
>> Shouldn't the source blocks be using the  element?
>>
>> This patch is untested, I can pay more attention to it if first the
>> maintainer(s) agree with my opinion. I thought the  tag is good
>> for semantics.
>
> Timothy, may you take a look?
>
> For me, the patch looks reasonable, especially since  is used with
> `org-html-klipsify-src'. Although, I'd be careful moving class property
> into code - it might potentially block CSS selectors.
>
>> From 61ff4297044beb9d62673557d311475c897f057c Mon Sep 17 00:00:00 2001
>> From: Nikolaos Chatzikonstantinou 
>> Date: Wed, 26 Feb 2025 03:51:36 -0500
>> Subject: [PATCH] Add code element inside src-block in ox-html
>>
>> * lisp/org/ox-html.el (org-html-src-block): Add HTML code element inside
>> pre element for Org source blocks exported to HTML.
>> ---
>>  lisp/org/ox-html.el | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lisp/org/ox-html.el b/lisp/org/ox-html.el
>> index e8ae3a134cb..6f5ce9269ff 100644
>> --- a/lisp/org/ox-html.el
>> +++ b/lisp/org/ox-html.el
>> @@ -3697,7 +3697,7 @@ org-html-src-block
>>" data-editor-type=\"html\""
>>  "")
>>code)
>> -(format "%s"
>> +(format "%s"
>>  ;; Lang being nil is OK.
>>  lang label code))
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at