Re: [PATCH] Use full timestamp in todo-list sorts

[Ihor Radchenko]

Ihor Radchenko  writes:

> Yup, a proper solution would be making a fix there. ...
>
> What might be done to implement the feature properly is ...

Charles, would you be interested to try working on more accurate patch,
as I suggested?

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

Re: [BUG?] in pcomplete???

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> ... Enough for today. I may look by this afternoon.

Did you have a chance to test the patch again?

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

Re: [BUG] ob-shell async session does not work with multiple blocks running [9.7.16 (9.7.16-ba9734 @ /nix/store/6la93ywyb1h055phgyqba7h7qay60p0m-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.7.

[Ihor Radchenko]

Matt  writes:

> On December 19, 2024 12:24:48 AM GMT+01:00, Matt  wrote:
>>Running from the latest commit, eebc9be7c, on Emacs on Android, I'm not able 
>>to reproduce. 
>>
>>Did I miss a change between Dec. 10 and today which fixed this?
>
> My bad.  To reproduce the error, the blocks *must* be run using C-c C-c 
> (org-ctrl-c-ctrl-c). Running with org-babel-execute-buffer produces a correct 
> result for each block.

I genle ping. It has been a while this the last update in this thread.

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

Re: [PATCH] ox-overview.org: Add new section and make minor edits

[Ihor Radchenko]

Ihor Radchenko  writes:

> ...
> What might make sense is listing packages that are not available in
> repositories. ...

Raoul, did you have a chance to look into my comments? 

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

Re: [BUG] org babel #+call: block does not eval :file elisp expression

[Ihor Radchenko]

Ihor Radchenko  writes:

> For side effects, you may introduce an optional argument EVAL instead of
> mandatory API change. That will make it 100% safe even if some
> third-party code is using this internal function.
> ...

It has been a while since the last update in this thread.
Tom, have you had a chance to look into my comments?

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

Re: babel (LaTeX) support in feature/all-tex-fonts branch

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> I have finally added preliminary support for babel (as in LaTeX package) to
> the feature branch.
> it is activated by the
> #+LATEX_BABEL_LANGS
> header keyword, which substitutes the need for
> #+LATEX_HEADER: \usepackage[...]{babel}
> in the header.

Thanks! Do I understand correctly that you are yet to add the relevant
description to the manual?

Also, I noticed that you are using

+   ;;
+   ;; If we intend to use polyglossia, we can put it here.
+   ;; Same for babel on lua/xelatex
+   ;; They will automatically load, among others, fontspec
+   ;; If none are selected, then use fontspec directly
+   ;;
+   (insert (cond (polyglossia-langs
+  ;; polyglossia imports fontspec automatically
+  (format "\\usepackage[%s]{polyglossia}\n" 
polyglossia-langs))

However, we already specify the languages via
setmainlanguage/setotherlanguage. Isn't your code redundant?

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

Re: "Subproduct" of the feature branch

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> could you please take a look at the last patch set I have uploaded to the
> feature branch, specifically at the change to ox-latex.el that starts with
>
> @@ -1813,17 +1823,13 @@ Return the new header."

Could you please provide the commit hash or the commit message title?
I cannot find the commit you are referring to.

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

Re: [PATCH] add lowercase c to languages recognized for CSS highlight

[Ihor Radchenko]

Nikolaos Chatzikonstantinou  writes:

> With an org file like this:
>
> #+begin_src c
> /* ... */
> #+end_src
>
> you get valid recognition by babel, etc,

Not really. You cannot evaluate such a code block.

> ... but it is not recognized by
> ox-html's CSS file. Of course not all cases can be supported, but I
> think that this one is common enough for you to include.

I see no harm in this. Are there any other language names that might be
potentially case-sensitive?

> Subject: [PATCH] add lowercase c to languages recognized for CSS highlight

Could you please add a commit message as described in
https://orgmode.org/worg/org-contribute.html#commit-messages ?

> @@ -318,6 +318,7 @@ This affects IDs that are determined from the ID 
> property.")
>pre.src-asymptote:before { content: 'Asymptote'; }
>pre.src-awk:before { content: 'Awk'; }
>pre.src-authinfo::before { content: 'Authinfo'; }
> +  pre.src-c:before { content: 'C'; }

Because we are changing the default value of a defcustom, we should
announce this in the news and update :package-version keyword.

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

Re: Language support for C# in org-babel

[Ihor Radchenko]

poverobuosodonati  writes:

> On the matter: This is not for a reason, and you are of course both 
> right. Doing something more "advanced" then just hardcoding a fixed 
> version is definitely a good thing. I was actually also planning to move 
> over the heuristic I implemented for the tests to the actual module. As 
> of now, we set the the default framework to the latest available one 
> that can be discovered on the host system.

Unless I miss something, the new code will err on (require 'ob-csharp)
when dotnet command is not available.

Also, you left
(defvar test-ob-csharp-system-dotnet-version (format "net%s.0" (apply #'max 
(org-babel-csharp--find-dotnet-version)))
in the tests.
Why not simply using org-babel-csharp-default-target-framework now?

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

Re: Change in the way polyglossia is handled in the feature/all-tex-fonts

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> I have created a new way to control polyglossia for multi-language
> documents (using lualatex or xelatex) There is no need to add the
> \usepackage[langs...]{polyglossia} in the document header anymore. Instead
> you add
>
> #+LATEX_POLYGLOSSIA_LANGS: lang,lang,AUTO

Does it have to be polyglossia-specific?
What about allowing multiple languages in document:
#+LANGUAGE: main_lang,lang,lang,...

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

Re: TOC is missing in html export when using #+INCLUDE

[Ihor Radchenko]

Ihor Radchenko  writes:

> I am unable to reproduce.
> Could you please provide more details about the files you have problems
> with? Maybe you can share another.org file?
> See https://orgmode.org/manual/Feedback.html#Feedback

Without extra information, the issue is not actionable. Closing.
Canceled.

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

Fixing the Woof tracker?

[Derek Chen-Becker]

I'm looking for a bug to work on and when I went through the Woof tracker I
noticed that several of the bugs I'm looking at appear to be fixed already.
I know this has been called out as an issue with Woof, but I was wondering
if there's anything I can do to help fix that?

Cheers,

Derek

-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: Fixing the Woof tracker?

[Ihor Radchenko]

Derek Chen-Becker  writes:

> I'm looking for a bug to work on and when I went through the Woof tracker I
> noticed that several of the bugs I'm looking at appear to be fixed already.
> I know this has been called out as an issue with Woof, but I was wondering
> if there's anything I can do to help fix that?

Thanks for your interest!
Woof! is developed at https://github.com/bzg/woof
I am CCing Bastien, as he might suggest something more specific.

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

Re: [BUG] Numeric priorities only partially supported

[Derek Chen-Becker]

On Sun, Oct 13, 2024 at 04:11:01PM +, Ihor Radchenko wrote:
> Not so safe. I tried to fix this specific issue in the past and changing
> the org-element parser to handle non-single char priorities broke
> tests (either because I did something stupid or because the tests make
> incorrect assumptions).
> 
> It would be really nice if someone worked on this issue and resolved all
> the possible corner cases in the tests and elsewhere.
> 
> We must eventually support numeric properties, as documented in the manual.

This is actually something I've wanted for a while and never got
around to looking at it. I'm happy to start digging into this if it's
still valid. I can change this to handled for Woof to track if that
helps.

Cheers,

Derek


-- 
+---+
| Derek Chen-Becker |
| http://chen-becker.org|
|   |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+


signature.asc
Description: PGP signature

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

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> I did not change `org-src-get-lang-mode' directly.  Instead I wrapped
> it in `org-src-get-lang-mode-if-bound' which does little more.  WDYT?

Thanks for the patch!
You are introducing a new behavior, so please update etc/ORG-NEWS.
Also, 16.10 Editing Source Code section of the manual needs an update.

> +(defun org-src-get-lang-mode-if-bound (lang &optional fallback 
> fallback-message-p)

> +  "Return major mode for LANG, if bound, and FALLBACK otherwise.
> +LANG is a string.  FALLBACK and the returned value are both symbols.  If
> +FALLBACK-MESSAGE-P is non-nil, display a message when using FALLBACK."
> +  (let ((mode (org-src-get-lang-mode lang)))
> +(if (functionp mode) mode
> +  (when fallback-message-p
> +(message "%s not available, falling back to %s" mode fallback)
> +fallback

Maybe you can suppress the message when FALLBACK == MODE.
Also, what if FALLBACK is also not bound?

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

Re: Querying cached parse trees without opening files

[Ihor Radchenko]

"Martin Edström"  writes:

> I'll conclude a yes on the feasibility analysis.  I do wonder if it'd
> make sense for Org itself to have such an API (think a thin wrapper
> around org-element-parse-buffer results), because then org-agenda /
> org-ql / etc could be rewritten to make use of it, solving their perf
> issues no matter how many files you feed in.

Sure.
Here is one of the long-term projects I have:

*** SOMEDAY #project org-query: Query interface for Org mode 
:COMMON:emacs:project:SOMEDAY:
:PROPERTIES:
:CREATED: [2022-04-24 Sun 14:32]
:ORG-TIME-BALANCE-MULTIPLIER: -1
:CATEGORY: OrgQuery[P]
:END:
:LOGBOOK:
- Refiled on [2024-04-26 Fri 15:37]
- Refiled on [2022-04-24 Sun 14:35]
CLOCK: [2022-04-24 Sun 14:32]--[2022-04-24 Sun 14:34] =>  0:02
:END:
# A short summary about the project.
 #org_query #oq
Inspired by [[id:Github_alphapapaalphap_org_ql_org_mode1ed][alphapapa [Github] 
alphapapa/org-ql: An Org-mode query language, including search commands and 
saved views]]

The idea is to provide centralised caching interface to query org buffers 
quickly

1. Sexp-based quries
2. Query caching
3. Use org-element cache + regex search
4. Allow multiple backends (think of org-roam)
5. Provide better query language (similar to non-sexp org-ql)

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

Re: [PATCH] org-link: Add async-shell link

[pinmacs]

On 2025-06-08 14:11, Ihor Radchenko wrote:

pinmacs  writes:


I see no async-shell link and I propose the following one, see patch
attached

...
+*** =ol.el=: New =async-shell= link type
+
+You can now create links to execute programs asynchronously. This
+means Emacs will not freeze while waiting for the link to execute.

Thanks for the patch, but I am not sure why a new link type is
necessary. You can simply append & to the "path" and the existing shell:
link will be run asynchronously. Example:

   


Oh, that's true, works, thanks!

And with that syntax I can place any space that I want, without using 
the more typical link format [1] [[shell: inkscape &]] but inkscape &>


[1] https://orgmode.org/org.html#Hyperlinks

Re: WORG Patch 1/2 for Org Protocol Page

[Ihor Radchenko]

Christian Moe  writes:

>> Also request guidance on handling obsolete content on an existing WORG page.
>
> I favor keeping things simple, cautiously deleting obsolete content
> without archiving when we can, using the archive sparingly, avoiding
> duplication, and keeping links between worg pages current.
>
> The archive directory is for obsolete *self-contained* documents that
> may somehow be useful for future reference. If we want to keep obsolete
> *snippets* of information for the same reason, they can be placed in a
> clearly marked section at the end of a current document. There's no need
> to archive everything we delete; we can always resurrect it from git.

+1

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

Re: [WORG] Help test style/accessibility change

[Ihor Radchenko]

Christian Moe  writes:

> 1. Keep the TOC under the header and always expanded if it's less than a
>certain length, collapsed/expandable if longer

Another option is making it expanded initially, but up to certain length
limit. + full expansion on click. Not sure if it is something possible
with CSS though.

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

Re: Fixing the Woof tracker?

[Bastien Guerry]

Thanks for the heads up!

Ihor Radchenko  writes:

> Woof! is developed at https://github.com/bzg/woof
> I am CCing Bastien, as he might suggest something more specific.

I won't have any free time until July or August.

When I do, I plan to rewrite Woof entirely: see
https://codeberg.org/bzg/woof#headline-1

In the meantime, if anyone wants to provide fixes, I'll be happy to
review and merge them.

Note that I'll be focusing on Woof during the FSF Hackathon on November
21-23, and I'll be happy to present the ideas and tools and hack with
others there as well.

-- 
 Bastien

Re: How have users managed email tasks with org?

[Kristoffer Balintona]

On Sun, Jun 08 2025, Ihor Radchenko wrote:

> Kristoffer Balintona  writes:
>
>> My main problem with trying to use org-agenda for all tasks created from
>> emails is that the state and relevance of those emails may change
>> without the todos tied to them changing (unless I update it myself). In
>> other words, although capturing emails as todos (e.g. create a todo
>> which has an org link pointing to a given email) is easy enough, email
>> threads develop in a way that makes todos tied to that thread outdated.
>> The result is todos which are no longer necessary, todos scheduled for
>> dates that have already shifted, and so on.
>
> If an email thread evolves, new emails should be coming there, right?
> So, the new emails that introduce new tasks can be captured
> independently (with backlinks).
> When a thread gets long and complex, the individual email-todos can be
> grouped (refiled) under the same "thread project", so that review is
> simplified.
> If an email introduced more than a single todo, one can simply save the
> link to email and capture multiple individual todos - again under some
> "thread project".

Hmmm, interesting.

So, to be clear, you find that having an org project/todo heading for
each email thread suffices, since (i) all todos in the same thread end
up under the same project which makes (ii) finding outdated todos easier
since you see all todos for a thread together.

If that’s right, then am I right in saying that it doesn’t directly
address the problem of todos associated with emails becoming stale
(e.g., additional emails being sent in the thread that invalidate a
task, causing it to become unnecessary or modification in its details)?
Grouping email tasks by thread might make it easier to stumble upon such
stale todos, but if simply forget that a thread has associated todo(s),
then those stale todos would remain.

(N.B. Christian Moe elsewhere in this thread something that gave me
inspiration. As a notmuch user, I think it wouldn’t be too hard to add a
visual indicator on individual emails for whether there is a todo that
links to it. The same could be done for threads in thread views like
notmuch-search-mode. This way, as one browses their email they can be
reminded of the existence of todos that might become stale if they e.g.
archive the thread. This seems at first like a low-tech but effective
solution.[1])

I’ll have to chew on this for a bit. Thank you for sharing.


Footnotes:
[1] Although there is the problem of how long it would take to scrape
 one’s org-agenda files for todos associated for each email. The
 possibility of using more caching to ameliorate such performance
 issues has been brought up recently in the org-mode mailing list:
 https://lists.gnu.org/archive/html/emacs-orgmode/2025-05/msg00310.html.

-- 
Kind regards,
Kristoffer

Re: [BUG] Numeric priorities only partially supported

[Jacob S. Gordon]

Hey Derek,

Just tying this together with a recent thread where numeric default
priorities are interpreted as characters:

https://list.orgmode.org/orgmode/328266e1-4338-4963-a3ae-eb6c51f6d...@frantzen.info/

Thanks,

-- 
Jacob S. Gordon
jacob.as.gor...@gmail.com

==

Please avoid sending me HTML emails and MS Office documents.
https://useplaintext.email/#etiquette
https://www.gnu.org/philosophy/no-word-attachments.html

Re: Querying cached parse trees without opening files

[Kristoffer Balintona]

On Sun, Jun 08 2025, Ihor Radchenko wrote:

> "Martin Edström"  writes:
>
>> I'll conclude a yes on the feasibility analysis.  I do wonder if it'd
>> make sense for Org itself to have such an API (think a thin wrapper
>> around org-element-parse-buffer results), because then org-agenda /
>> org-ql / etc could be rewritten to make use of it, solving their perf
>> issues no matter how many files you feed in.
>
> Sure.
> Here is one of the long-term projects I have:
>
> *** SOMEDAY #project org-query: Query interface for Org mode 
> :COMMON:emacs:project:SOMEDAY:
> :PROPERTIES:
> :CREATED: [2022-04-24 Sun 14:32]
> :ORG-TIME-BALANCE-MULTIPLIER: -1
> :CATEGORY: OrgQuery[P]
> :END:
> :LOGBOOK:
> - Refiled on [2024-04-26 Fri 15:37]
> - Refiled on [2022-04-24 Sun 14:35]
> CLOCK: [2022-04-24 Sun 14:32]--[2022-04-24 Sun 14:34] =>  0:02
> :END:
> # A short summary about the project.
>  #org_query #oq
> Inspired by [[id:Github_alphapapaalphap_org_ql_org_mode1ed][alphapapa 
> [Github] alphapapa/org-ql: An Org-mode query language, including search 
> commands and saved views]]
>
> The idea is to provide centralised caching interface to query org buffers 
> quickly
>
> 1. Sexp-based quries
> 2. Query caching
> 3. Use org-element cache + regex search
> 4. Allow multiple backends (think of org-roam)
> 5. Provide better query language (similar to non-sexp org-ql)

Is there a necessity for org-element’s cache to be sparse? Is it mostly
to avoid having to parse entire buffers (or at least large chunks of
them) when they change? When I first heard about org’s caching, I had
the (extremely) naive question of what technical reasons there are to
not just store entire parse trees in a cache, even an on-disk one.

-- 
Kind regards,
Kristoffer

Re: Querying cached parse trees without opening files

[Ihor Radchenko]

Kristoffer Balintona  writes:

> Is there a necessity for org-element’s cache to be sparse? Is it mostly
> to avoid having to parse entire buffers (or at least large chunks of
> them) when they change? When I first heard about org’s caching, I had
> the (extremely) naive question of what technical reasons there are to
> not just store entire parse trees in a cache, even an on-disk one.

Yes, it is to avoid having to parse the entire buffer.
Full re-parsing on every change is simply too slow. Not just for Org,
but for anything. tree-sitter works the same.

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

Re: [BUG] org babel #+call: block does not eval :file elisp expression

[Tom Gillespie]

> > For side effects, you may introduce an optional argument EVAL instead of
> > mandatory API change. That will make it 100% safe even if some
> > third-party code is using this internal function.
> > ...

Good point. I drafted a version that did that but didn't
go with it because I didn't think about third-party callers.

> It has been a while since the last update in this thread.
> Tom, have you had a chance to look into my comments?

Yes, sorry, a major (positive) life event has delayed my
ability to get back to this. Will try to revisit this week.

Re: [PATCH]: add BEAMER_CLASS_OPTIONS

[Ihor Radchenko]

Ihor Radchenko  writes:

>> So apparently, overwriting the :options-alist doesn't have any effect.
>> What am I not understanding about (org-export-define-derived-backend)
>
> This is a bug.
> I just fixed it on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=95aee91c26

I presume that after the fix, you should be able to address my earlier
comments. Or did you encounter any further difficulties?

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

Re: Select a region and yank a URL to create a link

[Ihor Radchenko]

Ihor Radchenko  writes:

> It has been a while since the last message in this thread.
> Ryan, are you still interested in writing the patch?

No response in over a month. I am thus closing this thread.
Canceled.

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

Re: bug#78037: 30.1; Insert link when using org-yank regardless if file already exists

[Ihor Radchenko]

Ihor Radchenko  writes:

> Visuwesh  writes:
>
>>> Visuwesh, could you take a look?
>>
>> I have multiple deadlines to meet.  Once I'm relatively free, I can take
>> a closer look at this.
>
> Sure. There is no rush.

It has been over a month, so a gentle ping :)

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

Re: [PATCH] Use full timestamp in todo-list sorts

[General discussions about Org-mode.]

Yes; sorry for the lack of response, I did get started on this for a bit,
and will pick it back up.

Charles

On Sun, Jun 8, 2025 at 5:16 AM Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
> > Yup, a proper solution would be making a fix there. ...
> >
> > What might be done to implement the feature properly is ...
>
> Charles, would you be interested to try working on more accurate patch,
> as I suggested?
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [BUG] Cannot tangle src block in capture buffer [9.7.6]

[Ihor Radchenko]

Derek Chen-Becker  writes:

> My copyright assignment has been processed! I've attached the latest
> version of my patches, rebased against the current mainline. It's been a
> while since I created the patches last time, so if I've made a mistake in
> the options please let me know.

Thanks!
Applied, onto main, with minor amendments.
I changed to commit message to explicitly say that it is a fix and that
the fix also concerns indirect buffers. I added proper `quoting' to the
function names in the commit message.  I also changed if-let ->
if-let* because the former is going to be obsolete in the next Emacs
release.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dea0804e6
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0f586e82f

Fixed.

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

Re: "Tab width in Org files must be 8, not 2. Please adjust your ‘tab-width’ settings for Org mode"

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I have tried many things,
>> But I still get the error: Tab width in Org files must be 8, not 
>> 2...  Please report this to Org mode mailing list"
>
> Thanks for reporting!
> Something in your config is overriding Org's settings.
> Since you are using Org 9.7.27, Org is already trying hard to set
> tab-width during init. May you check your org-mode-hook?

Since Org 9.7.29, tab-width is automatically reset to 8 as needed,
avoiding blocking errors. I assume that the problem in this thread will
also be addressed as much as Org can.

Fixed.

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

Re: On oc-csl adding

[Ihor Radchenko]

András Simonyi  writes:

>> The
>> issue I have is with the function `org-cite-csl-render-bibliography':
>> it should not output  elements because when one exports an
>> org-mode document
>
> Thanks for reporting! Unfortunately, I'm not well-versed enough in
> HTML matters to assess how norm violating the current behaviour is,
> but I'm attaching a tentative patch which moves the CSL-related CSS
> fragment to the head of the exported HTML using the same mechanism
> that was injecting the CSL-related LaTeX preamble. Comments on whether
> we should change the current behaviour and the concrete implementation
> in the patch are welcome!
> ...
> +  (let ((insert-part (lambda (anchor part) 
> +(with-temp-buffer
> +  (save-excursion (insert output))
> +  (when (search-forward anchor nil t)
> +(goto-char (match-beginning 0))
> +;; Insert the CSL-specific parts.
> +(insert part))
> +  (buffer-string)
> + (pcase output-format
> +   ('html
> +   (funcall insert-part "" (org-cite-csl--generate-html-head 
> info)))

This looks fishy to me.
There is no guarantee that  is always included into the exported
HTML, so your code may not always add style.
I suspect that a more robust approach could be adding to :html-head.

CCing Timothy as he should know these things better.

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

Re: Question about contribution to improve svg handling in latex export

[Ihor Radchenko]

Emin Martinian  writes:

> Ihor Radchenko  writes:
>
>> I think that rather than inventing something new, we can reuse 
>> the
>> existing semantics of `org-latex-pdf-process' and 
>> `org-compile-file'.
>
> I redid the code (see attached patch) to you use =defcustom= to 
> define only a single variable and have that variable use the =%o= 
> and =%f= syntax similar to =`org-latex-pdf-process=. I also allow 
> the user to set that variable to indicate not to do conversion if 
> desired and issue a warning only if the variable is unset and 
> neither inkscape nor rsvg-convert are found.

Thanks! Any reason you did not just call `org-compile-file' directly?

> I am sorry for not being able to get org-persist working. I tried 
> your suggestions but could not figure out how to do it

Did you try looking into org-persist.el commentary?
(To be clear, using org-persist would be nice to have, but it is not
something I consider necessary for this patch)

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

Re: [FR] org-babel-n-tangle

[Ihor Radchenko]

Lei Zhe  writes:

> Yes, this definitely makes sense, but we need to get rid of the
> `only-this-block` parameter here, since the result of
> `org-babel-tangle-single-block` needs to be a nested list. This must
> be a breaking change that we discussed before.

I have ideas how to avoid that, but let's first address everything else.

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

Re: Question about contribution to improve svg handling in latex export

[Ihor Radchenko]

Thomas Redelberger  writes:

> Regards "rsvg-convert":
> I had installed rsvg-convert to resolve an issue using SVG with /pandoc/ to 
> generate DOCX. But that is unrelated to the built-in Org mode exporter.
> See:
>   https://web222.webclient5.de/doc/swdev/emacs/orgmode/pandoc
>
> rsvg-convert generates PNG. IMHO this defeats starting with SVG in the first 
> place.

Yes, but it is still an ok fallback if inkscape is not available.
Or is there a situation when using rsvg-convert is worse?

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

Re: [PATCH] org-link: Add async-shell link

[Ihor Radchenko]

pinmacs  writes:

>> I see no async-shell link and I propose the following one, see patch 
>> attached
> ...
> +*** =ol.el=: New =async-shell= link type
> +
> +You can now create links to execute programs asynchronously. This
> +means Emacs will not freeze while waiting for the link to execute.

Thanks for the patch, but I am not sure why a new link type is
necessary. You can simply append & to the "path" and the existing shell:
link will be run asynchronously. Example:

  

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

Re: Change in the way polyglossia is handled in the feature/all-tex-fonts

[Pedro Andres Aranda Gutierrez]

Hmmm...

So, we could have something like

#+LATEX_POLYGLOSSIA_LANGS: AUTO

to import all the document languages and define the main? Will see how to
integrate in the feature branch.

Thx, /PA


On Sun, 8 Jun 2025 at 13:01, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > I have created a new way to control polyglossia for multi-language
> > documents (using lualatex or xelatex) There is no need to add the
> > \usepackage[langs...]{polyglossia} in the document header anymore.
> Instead
> > you add
> >
> > #+LATEX_POLYGLOSSIA_LANGS: lang,lang,AUTO
>
> Does it have to be polyglossia-specific?
> What about allowing multiple languages in document:
> #+LANGUAGE: main_lang,lang,lang,...
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
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: Automated naming of tables

[Ihor Radchenko]

Roger Mason  writes:

> 5. Find the heading hierarchy up to the nearest level 1 heading in
> which point lies.  (How?).
> 6. Concatenate the heading names into a string with a separator
> (perhaps '_').

See org-get-heading

> If anyone has already done something like this, please point me to the code.  
> I 
> welcome comments on the proposed 'algorithm' and any hnts on how to implement 
> it
> will also be very welcome.  I have not written any emacs-lisp in a long time 
> and am
> revisiting the elisp intro manual.

Start simple and remember that anything you do in Emacs is a command
(with name revealed by C-h k ).

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

Re: How have users managed email tasks with org?

[Ihor Radchenko]

Kristoffer Balintona  writes:

> My main problem with trying to use org-agenda for all tasks created from
> emails is that the state and relevance of those emails may change
> without the todos tied to them changing (unless I update it myself). In
> other words, although capturing emails as todos (e.g. create a todo
> which has an org link pointing to a given email) is easy enough, email
> threads develop in a way that makes todos tied to that thread outdated.
> The result is todos which are no longer necessary, todos scheduled for
> dates that have already shifted, and so on.

If an email thread evolves, new emails should be coming there, right?
So, the new emails that introduce new tasks can be captured
independently (with backlinks).
When a thread gets long and complex, the individual email-todos can be
grouped (refiled) under the same "thread project", so that review is
simplified.
If an email introduced more than a single todo, one can simply save the
link to email and capture multiple individual todos - again under some
"thread project".

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

Re: Change in the way polyglossia is handled in the feature/all-tex-fonts

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> So, we could have something like
>
> #+LATEX_POLYGLOSSIA_LANGS: AUTO

I rather thought that polyglossia can use #+LANGUAGE value directly and
skip a new keyword altogether.

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

Re: First impression when exporting to iCal

[Ihor Radchenko]

jman  writes:

> The example orgmode snippet provided:
>
> --8<---cut here---start->8---
> * Meeting at location with multi-line address
> <2024-01-08 Mon 14:20-15:00>
> :PROPERTIES:
> :LOCATION:  Someplace
> :LOCATION+: Some Street 5
> :LOCATION+: 12345 Small Town
> :END:
> --8<---cut here---end--->8---
>
> is exported as
> ...

That example is not correct.
Properties drawer cannot be placed after timestamp (it must either
follow headline itself or planning line).

Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3bc197100

The correct example is

* Meeting at location with multi-line address
:PROPERTIES:
:LOCATION:  Someplace
:LOCATION+: Some Street 5
:LOCATION+: 12345 Small Town
:END:
<2024-01-08 Mon 14:20-15:00>

> A few questions:
> - Why isn't the LOCATION parsed?
> - Why isn't the multiline DESCRIPTION fully parsed?
> - Why does the date of the event ends up also in the DESCRIPTION?

When properties drawer is placed in an invalid location, it is treated
as simple plain drawer that does not contain properties. So, nothing is
parsed.

M-x org-lint will warn about such cases.

> - Where does the "CATEGORIES:test" come from?

The default category is taken from file name.

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

Re: [BUG?] ox-latex and *Warnings*

[Ihor Radchenko]

David Masterson  writes:

> The messages about what file is being worked on are sent to *Messages* in
> the first line of org-latex-compile.  The problem, I think, is in the
> following piece of code in org-latex-compile--postprocess:
>
> (let ((warnings (org-latex--collect-warnings log-buf)))
>   (funcall
>(if warnings
>(apply-partially
> #'display-warning
> '(ox-latex))
>  #'message)
>(concat "PDF file produced"
>(cond
> ((eq warnings 'error) " with errors.")
> (warnings (concat " with warnings: " warnings))
> (t ".")))
>
> I think the issue is that display-warning defaults to sending it's
> warnings to *Warnings* which, in this case, doesn't make sense (there
> are other cases in ox-latex which may be okay?).  Another argument needs
> to be given to display-warning to tell it to output to the *Messages*
> buffer, but the buffer name is the last argument to display-warning, so
> how would you do that?

Rather than trying to redirect warnings into messages buffer, you can
augment the warning itself with the file name. It will be easier I think.

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

Re: [PATCH] Use full timestamp in todo-list sorts

[Ihor Radchenko]

Charles T  writes:

> Yes; sorry for the lack of response, I did get started on this for a bit,
> and will pick it back up.

Thanks for the update!
Feel free to ask questions if you encounter any difficulties.

Best,
Ihor

Re: [PATCH] org-link: Add async-shell link

[Ihor Radchenko]

pinmacs  writes:

>>
>
> Oh, that's true, works, thanks!
>
> And with that syntax I can place any space that I want, without using 
> the more typical link format [1] [[shell: inkscape &]] but  inkscape &>

Maybe we can update the manual hinting about this feature.

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

Re: Fixing the Woof tracker?

[Ihor Radchenko]

Bastien Guerry  writes:

> When I do, I plan to rewrite Woof entirely: see
> https://codeberg.org/bzg/woof#headline-1

It would be nice to refer to the new codeberg repository from github.
Because github is where Org's woof! instance points to and sourcehut
mirror has been removed.

Re: How to visually distinguish headlines using colors

[Ihor Radchenko]

mb...@mbork.pl writes:

> I'd like to be able to set the background of a headline to various
> colors depending on a tag or (maybe better) a property.  For instance,
> if the property :color: has value `red', I'd like the headline
> (alternatively, the whole subtree) to have a reddish background, etc.
> (The list of these colors will be fixed and very short.)

For such non-trivial fontification, check out 24.7.3 Customizing Search-Based 
Fontification
section in Elisp manual.

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

Re: "Subproduct" of the feature branch

[Pedro Andres Aranda Gutierrez]

I think, I will provide a patch for main when everything is ready. My
feeling here is that we can use replace-regexp-in-string at some places,
instead of all this string-match / replace-match and that would simplify
the code.

Best, /PA

On Sun, 8 Jun 2025 at 12:47, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > could you please take a look at the last patch set I have uploaded to the
> > feature branch, specifically at the change to ox-latex.el that starts
> with
> >
> > @@ -1813,17 +1823,13 @@ Return the new header."
>
> Could you please provide the commit hash or the commit message title?
> I cannot find the commit you are referring to.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
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: [BUG] Numeric priorities only partially supported

[Ihor Radchenko]

Derek Chen-Becker  writes:

>> We must eventually support numeric properties, as documented in the manual.
>
> This is actually something I've wanted for a while and never got
> around to looking at it. I'm happy to start digging into this if it's
> still valid.

Yes, this bug still needs to be fixed.

> ... I can change this to handled for Woof to track if that
> helps.

You can use Handled. keyword as described in https://tracker.orgmode.org/howto
It is optional though as the tracker is not very stable (and thus not
very useful) for the time being.

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

Re: Fixing the Woof tracker?

[Bastien Guerry]

Ihor Radchenko  writes:

> It would be nice to refer to the new codeberg repository from github.
> Because github is where Org's woof! instance points to and sourcehut
> mirror has been removed.

Done, thanks.

-- 
 Bastien

Re: [PATCH] ox-overview.org: Add new section and make minor edits

[Raoul Comninos]

> Raoul, did you have a chance to look into my comments?

I reviewed your feedback but haven't made any further revisions.

--
Raoul Comninos

Re: Change in the way polyglossia is handled in the feature/all-tex-fonts

[Pedro Andres Aranda Gutierrez]

It would make then difficult to distinguish between people who want/need
polyglossia and people who don't, wouldn't it.
I'd rather not force anyone to load polyglossia if they don't want to use
it.

best, /PA

On Sun, 8 Jun 2025 at 17:27, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > So, we could have something like
> >
> > #+LATEX_POLYGLOSSIA_LANGS: AUTO
>
> I rather thought that polyglossia can use #+LANGUAGE value directly and
> skip a new keyword altogether.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


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