Re: How to get the contents of an Org subtree?

[Ihor Radchenko]

Marcin Borkowski  writes:

> I want to get the contents ("text") of a subtree.  Without the heading,
> without the drawers - just the text.

org-agenda-get-some-entry-text

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

How to get the contents of an Org subtree?

[Marcin Borkowski]

Hi all,

I want to get the contents ("text") of a subtree.  Without the heading,
without the drawers - just the text.  For example, for this:

--8<---cut here---start->8---
** Title
:PROPERTIES:
:CUSTOM_ID: whatever
:END:
This is the text.
--8<---cut here---end--->8---

I need the string "This is the text.".

How to do that?

-- 
Marcin Borkowski
http://mbork.pl

Re: Subscript entity in the name of files or some advise for alternatives

[Ypo]

Thanks, Jens

Why did you try that variable instead of 
"org-pretty-entities-include-sub-superscripts"?


El 24/07/2023 a las 22:33, Jens Schmidt escribió:

On 2023-07-24  21:12, Ypo wrote:

I wanted it, because I usually use (_) to divide words when naming 
my_files, and that looks ugly in Orgmode.


I had that problem myself recently.  Do `org-use-sub-superscripts' and 
its companion `org-export-with-sub-superscripts' help in your case?


See also .

Re: Subscript entity in the name of files or some advise for alternatives

[Jens Schmidt]

On 2023-07-24  21:12, Ypo wrote:

I wanted it, because I usually use (_) to divide words when naming 
my_files, and that looks ugly in Orgmode.


I had that problem myself recently.  Do `org-use-sub-superscripts' and 
its companion `org-export-with-sub-superscripts' help in your case?


See also .

Re: Bug: org-anniversary dates not exported to iCalendar [9.4.6 (9.4.6-3-g37f69b-elpaplus @ /home/marcus/.emacs.d/elpa/org-plus-contrib-20210531/)]

[Marcus Zibrowius]

> Please provide mode details about what you tried.  

OK, I will try.  I start emacs with 

emacs -Q -l emacs_init/minimal-org.el

Here, minimal-org.el has the following contents:

;; Activate debugging.
(setq debug-on-error t
  debug-on-signal nil
  debug-on-quit nil
  icalendar-export-sexp-enumeration-days 400)

;; Add latest Org mode to load path.
(custom-set-variables
 '(package-selected-packages
   '(org-plus-contrib)))

In this setup, `M-x version` and `M-x org-version` bring up the following 
information:

GNU Emacs 28.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo 
version 1.16.0) of 2023-06-23

Org mode version 9.5.5 (release_9.5.5 @ 
/snap/emacs/current/usr/share/emacs/28.2/lisp/org/)

`org-time-stamp` gives `<2023-07-24 Mo>`.

I create a minimal org-file `test.org` with the following contents:

* Test 1  
%%(org-anniversary 2022 07 23) Test1  
* Test 2  
%%(org-anniversary 2022 07 25) Test2 %d

I open this file in emacs and hit `C-c C-e c f` to export it to icalendar.  The 
file `test.ics` has the following contents:

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:test
PRODID:-//Marcus//Emacs with Org mode//EN
X-WR-TIMEZONE:CEST
X-WR-CALDESC:
CALSCALE:GREGORIAN
END:VCALENDAR

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Jens Schmidt]

Uh, I had technical issues and did not get all mails as I expected.
Cobbling things together in one big reply now, with references and
quotes hopelessly broken ... hope you can sort it out.

Anyway, thanks to Eric for chiming in.

> Ideally, it would be nice to have tests, though I have no clue how to
> approach writing them.

I have created a somewhat minimal Gnus setup to develop and test this
patch on my development laptop, where I normally do not use Gnus.  It
consists of a bunch of files and directories and a bit of configuration.
I can follow up on this if you like, but preferably in a separate
thread.

>> If we're currently in article-mode. The call to
>> `gnus-article-show-summary' would protect against the case where the
>> summary buffer has been killed in the meantime [...].

Not really.  The following executed in an article buffer:

  (progn
   (kill-buffer gnus-summary-buffer)
   (gnus-article-show-summary))

results in

  Debugger entered--Lisp error:
  (error "There is no summary buffer for this article buffer")
signal(error ("There is no summary buffer for this article buffer"))
error("There is no summary buffer for this article buffer")
gnus-article-show-summary()
[...]

Which, OTOH, shows that I was wrong in one aspect: Gnus at least in some
cases *does* give a reasonable error message when the summary buffer for
an article buffer is gone.

>> Probably it would be enough to wrap the whole containing `let*' in a
>> (with-current-buffer gnus-summary-buffer ...). If we're already in the
>> summary buffer, no harm done.
>
> I am not sure if it is safe.
> There is
> (save-window-excursion (gnus-summary-select-article))
> which calls (set-buffer gnus-summary-buffer)

I agree with Ihor here and would rather go for individual wraps into
`with-current-buffer'.  As I have done in my patch already,
incidentially.

>> Ugh, this whole thing is a mess. I think the first question is: should
>> this function "fix" the state of Gnus before it makes a link? Should it
>> attempt to re-open the Summary buffer if it's been closed? Should it
>> switch current articles if the open article buffer is not the one that
>> point is on in the Summary buffer?
>>
>> If we make a decision about that, then it should be easier to decide how
>> to handle the code changes themselves.
>
> ol-gnus should store link for thing at point in current buffer. Ideally,
> without side effects. Everything else should be implementation detail.

Could we agree on: ol-gnus should store Gnus links with as little effort
and side-effect as possible while providing reasonable functionality for
the common use cases.  I think, again incidentially, that my patch
matches this criterion.

What optionally could be improved, though, is error handling in these
pathological cases.  But that would probably require some macro

  (ol-gnus-with-current-summary-buffer BODY)

to have the error handling available in the separate places.  Not sure
whether this is worth the effort.

> Or, at least, it was not sufficient at the time when ol-gnus has been
> written (quite a while ago).

I don't think this has changed, really.

Subscript entity in the name of files or some advise for alternatives

[Ypo]

Hi

I tried to don't get the subscripts (_) affected by org-pretty-entities.

I wanted it, because I usually use (_) to divide words when naming 
my_files, and that looks ugly in Orgmode.



I have tried redefining the constant org-match-substring-regexp, but I 
think that broke several other things 


Is it possible to use org-pretty-entities without altering subscripts (_)?

Should I avoid using (_) in the naming of files?

Another option could be to use symbols instead of LaTeX syntax: writing 
Π instead of /Pi. This solution could be more universal, since external 
"org" interpreters like orgzly could show Π while maybe they will never 
show \Pi appropriately.



Bests

Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

[Max Nikulin]

On 19/07/2023 09:36, Gavin Downard wrote:

This patch does prioritize named columns over named fields, which can
break compatibility in tables with a named column and named field with
the same name.


I have tried the patch. The formula for the named column "$three=" does 
not work.


| ! | one | two | three | four |
|---+-+-+---+--|
| # |   1 |   2 |   |3 |
#+tblfm: @>$5=$one+$two::@>$three=$one+$two

P.S. Due to @II-like references it would be harder to consistently 
implement named rows for symmetry with named columns...

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Max Nikulin]

On 23/07/2023 21:13, Jens Schmidt wrote:

Gnus can have a global Message-ID cache, but it's not on by default (at
least not in Emacs 28, haven't checked others).  And anyway, it's a
potentially incomplete *cache*, and not an *index*.


Thank you for clarification. Certainly just Message-ID is not enough 
without the index.



For nntp groups you already have the option to store links as web links
to groups.google.com, by means of `org-gnus-prefer-web-links'.


I believe that links may be converted to web archives either to open or 
to export them. In a document I would prefer a more general form like

news://news.gmane.io/gmane.emacs.orgmode/b0d3fee0-0dc9-a7ee-32dd-478297cb6...@vodafonemail.de
though group name is redundant.

In Thunderbird links to known articles work reasonably well

I do not think, mid: links are ideal, but it is off-topic in this thread.

For storing links I would avoid volatile parts like mail folder where a 
message *currently* resides or name of virtual folder/group specific to 
user configuration as well as application-specific URIs.


I admit that due to gnus design, group names are unavoidable for some 
backends. I do not see a better way than the approach implemented in the 
suggested patch.

ox-publish index allows alternative formats?

[Britt Anderson]

Question:

Could ~:makeindex~ (in the ~org-publish-project-alist~) be expanded to
accept a user provided function for formatting the output differently?

Background: 

I am using org for a static website (brittanderson.github.io). I wanted
to make a list of blog posts subdivided by topic and I decided to use
~:makeindex~. I add ~#+Index: keyword~ lines to the preamble of the
posts and the list is generated, however I did not like the formatting.
It gave me a list of keywords as links (often repeated) with no context
(like title or date). So I hacked this alternative:
https://brittanderson.github.io/posts/theindex.html

It seems like it would be nice to allow users to provide their own
formatting functions to ~org-publish-index-generate-theindex~. Similar
to the way that ~:sitemap-function~ allows a user controlled sitemap.
I altered a few lines to do this for myself (as seen in the diff below),
but am unsure whether there is any more general interest in expanding
the index functionality or where in the org hierarchy would be the best
place to try and code such that ~:makeindex~ can be nil, 'default or the
name of a user provided function that expects one argument (to become
~target~). 

My question is whether this is something that is worth doing, and if it
is worth doing how hard should it be for a novice to attempt, and does
anyone have any pointers for how to tackle it?

-- Britt Anderson

My example of minor edits:

diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index 3c7311b56..d04c15fd5 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -1109,15 +1109,16 @@ publishing directory."
;; Last term: Link it to TARGET, if possible.
(let ((target (nth 2 idx)))
  (format
-  "[[%s][%s]]"
-  ;; Destination.
+  "*%s* [[%s]]"
+   (car (last entry))
+   ;; Destination.
   (pcase (car target)
 (`nil (format "file:%s" file))
 (`id (format "id:%s" (cdr target)))
 (`custom-id (format "file:%s::#%s" file (cdr target)))
 (_ (format "file:%s::*%s" file (cdr target
   ;; Description.
-  (car (last entry)
+  )))
  "\n"
(setq current-letter letter last-entry entry
   ;; Create "theindex.org", if it doesn't exist yet, and provide

[PATCH v3] ob-tangle.el: Blocks overwrite each other when grouping before tangling

[Evgenii Klimov]

Hi

Here are the new tests that demonstrate the bug in block grouping during
block collection, along with the patch to address the issue, taking your
previous remarks into account.

I split it into two patches so you can apply the tests first to see the
bug.  And probably tests should be rewritten as they look too complex
and mostly duplicate each other.  I'd appreciate your suggestions
on how to enhance them.

Ihor Radchenko  writes:

> Evgenii Klimov  writes:
>
>> In this version I just updated the docstrings for the relevant
>> functions, because prior to that it wasn't clear: does this "default
>> export file for *all* source blocks" influence blocks with :tangle
>> "yes"/FILENAME?
>
> Thanks for the patch, but we need to be careful changing things in
> ob-tangle. Not everything is well-documented there.
>
>>  Optional argument TARGET-FILE can be used to specify a default
>> -export file for all source blocks.
>> +export file for all source blocks without :tangle header
>> +argument.
>
> This is confusing.
> Is :tangle yes "without"?
> What about inheritance?
> What about default header args?

I just find current lack of details confusing as well and want to
express the place of TARGET-FILE in the lineage of :tangle in
~org-babel-get-src-block-info~:
1. org-babel-default-header-args
   1. TANGLE-FILE of ~org-babel-tangle~
2. org-babel-default-header-args:
3. org-babel-params-from-properties
4. org-element-property :parameters datum
5. org-element-property :header datum

It wasn't clear for me: will ":tangle yes" or explicit ":tangle no" be
affected by TARGET-FILE.  Maybe if we rephrase as follows it will be
clear for both of us:

Optional argument TARGET-FILE can be used to overwrite a default
export file in `org-babel-default-header-args' for all source
blocks.

> What if we have :tangle "/path/to/foo" and TARGET-FILE = "/path/to/foo"?
> What if they are :tangle "./foo" and TARGET-FILE = "/full/path/to/foo"?

See the new tests in the patch, I tried to take it into account.

>>  (defun org-babel-effective-tangled-filename (buffer-fn src-lang src-tfile)
>> -  "Return effective tangled filename of a source-code block.
>> +  "Return effective tangled absolute filename of a source-code block.
>
> This will likely cause breakage.
> There are two callers of `org-babel-effective-tangled-filename:
> 1. `org-babel-tangle-collect-blocks'
> 2. `org-babel-tangle-single-block'
>
> `org-babel-tangle-single-block' passes (nth 1 result) as BUFFER-FN.
> Its value is
>
> (if org-babel-tangle-use-relative-file-links
>   (file-relative-name file)
> file)
>
> So,
>
>> +  (let* ((fnd (file-name-directory (buffer-file-name
>> +(get-buffer buffer-fn
>
> will fail when FILE contains file path.
> And it does: (file (buffer-file-name (buffer-base-buffer)))

Thanks, fixed: both `org-babel-tangle-single-block' and
`org-babel-tangle-collect-blocks' now pass absolute value to
`org-babel-effective-tangled-filename'.

>From 7235bf0306d12f6644838ad8542ac8822bcde258 Mon Sep 17 00:00:00 2001
From: Evgenii Klimov 
Date: Fri, 21 Jul 2023 22:40:06 +0100
Subject: [PATCH v3 1/2] testing/lisp/test-ob-tangle.el: Test block collection
 into groups for tangling

* testing/lisp/test-ob-tangle.el (ob-tangle/collect-blocks): Test
block collection into groups for tangling.
(ob-tangle/collect-blocks-with-target-file): The same but with
TARGET-FILE.
---
 testing/examples/babel.org | 75 ++
 testing/lisp/test-ob-tangle.el | 60 +++
 2 files changed, 135 insertions(+)

diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index d46afeb5e..2d7b39d4e 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -490,3 +490,78 @@ The =[[= causes a false positive which ~org-babel-detangle~ should handle proper
 :END:
 #+begin_src emacs-lisp :tangle yes :comments link
 #+end_src
+* tangle collect blocks
+:PROPERTIES:
+:ID:   fae6bb5b-555a-4d68-9658-a30ac5d1b2ba
+:END:
+** with :tangle in properties
+:PROPERTIES:
+:ID:   b2021d51-253c-4b26-9988-dac9193eb00b
+:header-args: :tangle relative.el
+:END:
+#+begin_src emacs-lisp
+"H1: no :tangle, but :tangle relative.el in properties"
+#+end_src
+
+#+begin_src emacs-lisp :tangle yes
+"H1: :tangle yes (to babel.el)"
+#+end_src
+
+#+begin_src emacs-lisp :tangle no
+"H1: should be ignored"
+#+end_src
+
+#+begin_src emacs-lisp :tangle ./babel.el
+"H1: :tangle ./babel.el"
+#+end_src
+
+#+begin_src emacs-lisp :tangle relative.el
+"H1: :tangle relative.el"
+#+end_src
+
+#+begin_src emacs-lisp :tangle ./relative.el
+"H1: :tangle ./relative.el"
+#+end_src
+
+#+begin_src emacs-lisp :tangle /tmp/absolute.el
+"H1: :tangle /tmp/absolute.el"
+#+end_src
+
+#+begin_src emacs-lisp :tangle ~/../../tmp/absolute.el
+"H1: :tangle ~/../../tmp/absolute.el"
+#+end_src
+** without :tangle in properties
+:PROPERTIES:
+:ID:   

[PATCH] org-id: allow using parent's existing id in links to headlines

[Rick Lupton]

Hi,

Here is a small new feature for org-id that I have been using and finding 
useful. The patch adds the option to look for ancestors of the current headline 
that have an ID defined and use that together with a link search string to link 
to specific headlines, without needing every single headline to have its own ID.

For example if you have:

#+begin_example
* H1
:PROPERTIES:
:ID: abc
:END:

** H2
Link to here
#+end_example

with `org-id-link-to-org-use-id' set to `t`, the result of org-store-link will 
be that "H2" has a new id generated, and the link is to that new ID: 
`[[id:new-id][H2]]`.

Now, with `org-id-link-to-org-use-id' set to `inherit`, "H2" is not modified, 
and the resulting link is `[[id:abc::*H2][H2]]`, which will still take you to 
the same place as long as the sub-heading is unique within the parent heading 
with an ID.

As an example, I find this useful in situations like this:

#+begin_example
* Project 1
:PROPERTIES:
:ID: project-1
:END:

** <2023-07-01> Meeting A
** <2023-07-08> Meeting B
** <2023-07-15> Meeting C
#+end_example

... so that I can link to specific meetings without needing every one to have 
its own org ID.

Feedback on the patch welcome. If you would like to merge this I will (I 
assume) need to sort out FSF copyright assignment and update ORG-NEWS and the 
manual.

Best
Rick

0001-lisp-org-id.el-Allow-using-a-parent-s-existing-id.patch
Description: Binary data

Re: [PATCH v2] Re: [PATCH] add a function to only refresh inline images under current headline instead of global buffer

[Ihor Radchenko]

"Christopher M. Miles"  writes:

>> Unlike `org-latex-preview', here we need to (1) respect active region;
>> (2) keep the backward compatibility for INCLUDE-LINKED.
>>
>> For (1), for example, it would make sense to respect region when prefix
>> argument is C-u and clear images only there. For (2), we need to at
>> least allow toggling images with description using some prefix argument
>> (previously, any prefix argument would do).
>
> I indeed implemented all same behavior like `org-latex-preview' in new
> `org-toggle-inline-images'.
>
> ...
> And I also implement the toggle inline images in region logic in
> `org-toggle-inline-images' as bellowing:
>
> ;; Display region selected inline images.
>((use-region-p)
> (message "Displaying inline images in region...")
> (org-display-inline-images include-linked t (region-beginning) 
> (region-end))
> (message "Displaying inline images in region... done."))

This is not a toggle. This is unconditional refresh.

> For (2), It's working. The code passed the parameter `include-linked' to
> `org-display-inline-images'. So they works in any case of [C-u] prefix.

My concern is that previously C-u M-x org-toggle-inline-images would
"display links with a text description part". With your patch, it is no
longer the case because INCLUDE-LINKED is not affected by the prefix
argument.

And there is no clean way to allow INCLUDE-LINKED while keeping
consistency with latex preview commands.

What we might do here is making a new defcustom that will control
whether linked images should be displayed. Then, something like C-1
org-toggle-inline-images could toggle that defcustom and refresh all the
image previews in buffer (if any).

WDYT?

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

Re: Bug: org-anniversary dates not exported to iCalendar [9.4.6 (9.4.6-3-g37f69b-elpaplus @ /home/marcus/.emacs.d/elpa/org-plus-contrib-20210531/)]

[Ihor Radchenko]

Marcus Zibrowius  writes:

>> * Test 1  
>> %%(org-anniversary 2022 07 23) Test1  
>> * Test 2  
>> %%(org-anniversary 2022 07 25) Test2 %d
>
> Unfortunately, that still does not work, even with 
> icalendar-export-sexp-enumeration-days set to 400.  

Please provide mode details about what you tried.
I was able to export Test2 to icalendar using the latest Org version.

I did:

1. Created /tmp/bug.org

* Test 1  
%%(org-anniversary 2022 07 23) Test1  
* Test 2  
%%(org-anniversary 2022 07 25) Test2 %d

2. cd /path/to/org/repo; make repro
3. C-x C-f /tmp/bug.org 
4. C-c C-e c f
5. Open /tmp/bug.ics

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:bug
PRODID:-Emacs with Org mode//EN
X-WR-TIMEZONE:EEST
X-WR-CALDESC:
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:DS1-1ebdcf09-a392-48e2-a06a-aeecc1ff56b2
DTSTART;VALUE=DATE:20230725
DTEND;VALUE=DATE:20230726
SUMMARY:Test2 1
END:VEVENT
END:VCALENDAR



Test2 is exported, as expected.

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

Re: Bug: org-anniversary dates not exported to iCalendar [9.4.6 (9.4.6-3-g37f69b-elpaplus @ /home/marcus/.emacs.d/elpa/org-plus-contrib-20210531/)]

[Marcus Zibrowius]

> Sure. Because anniversaries count from 1 year, not from 0.  
> Try
> 
> * Test 1  
> %%(org-anniversary 2022 07 23) Test1  
> * Test 2  
> %%(org-anniversary 2022 07 25) Test2 %d

Unfortunately, that still does not work, even with 
icalendar-export-sexp-enumeration-days set to 400.  

Re: table formula for the second last row

[Ihor Radchenko]

Luca Ferrari  writes:

> #+TBLFM: @>$3=vsum(@3..@-1)
> #+TBLFM: @>$3=round( vsum(@3..@-2)/60 )
>
> but both overwrite the last row of the third column, while I would
> like the former to be on the second last row.

@>>$3

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

Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

[Ihor Radchenko]

Gavin Downard  writes:

> Ihor Radchenko  writes:
>> Do we have any tests covering this part of the code?
>
> Not that I know of. I can add a test case for this specific instance,
> but I'm not sure if I should add more comprehensive tests in this patch.
> What do you think?

I'd prefer to see tests for the aspects of org-table that are modified
by the patch (if there are no tests available).

org-table is an old, not very readable code. So, we should better ensure
test coverage to avoid breakage. Eyeballing the code is not very
reliable in this case.

>> In Emacs 26, we will need (require 'subr-x), but otherwise it is not a
>> problem to use `if-let'.
>
> Oh, I didn't realize that. Sorry about that.

Nothing to sorry about. You do not even need to do anything.
org-compat is already loaded by org-table and org-compat loads subr-x.

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

table formula for the second last row

[Luca Ferrari]

Hi all,
I've a table that is keep growing, and in the end I've added the
following to formulas:

#+TBLFM: @>$3=vsum(@3..@-1)
#+TBLFM: @>$3=round( vsum(@3..@-2)/60 )

but both overwrite the last row of the third column, while I would
like the former to be on the second last row.
Apparently I'm not able to understand how to do @> - 1, and I don't
want to place a fixed row number since the table will add new rows
over the time.
Any help is appreciated.

Thanks,
Luca

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Ihor Radchenko]

Eric Abrahamsen  writes:

> Ugh, this whole thing is a mess. I think the first question is: should
> this function "fix" the state of Gnus before it makes a link? Should it
> attempt to re-open the Summary buffer if it's been closed? Should it
> switch current articles if the open article buffer is not the one that
> point is on in the Summary buffer?
>
> If we make a decision about that, then it should be easier to decide how
> to handle the code changes themselves.

ol-gnus should store link for thing at point in current buffer. Ideally,
without side effects. Everything else should be implementation detail.

Judging from the shaman dances ol-gnus is performing, Gnus API is not
sufficient to get information about thing at point in an arbitrary Gnus
buffer. Or, at least, it was not sufficient at the time when ol-gnus has
been written (quite a while ago).

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

Re: Bug: org-anniversary dates not exported to iCalendar [9.4.6 (9.4.6-3-g37f69b-elpaplus @ /home/marcus/.emacs.d/elpa/org-plus-contrib-20210531/)]

[Ihor Radchenko]

Marcus Zibrowius  writes:

>> You can increase `icalendar-export-sexp-enumeration-days' to get the 
>> anniversary occurrences exported up to that number of days ahead.
>
> The variable `icalendar-export-sexp-enumeration-days` is indeed set to 14.   
> However, even entries of the form 
>
> * Test 1
> %%(org-anniversary 2023 07 22) Test1
> * Test 2
> %%(org-anniversary 2023 07 24) Test2
>
> do not get exported today (2023 07 23).  

Sure. Because anniversaries count from 1 year, not from 0.
Try 

* Test 1
%%(org-anniversary 2022 07 23) Test1
* Test 2
%%(org-anniversary 2022 07 25) Test2 %d

>> Also, `org-anniversary' does not support %d. AFAIK, it is only working 
>> for built-in sexp types, which are handled specially.
>
> %d works perfectly in the agenda view.

You are right. And it also works in icalendar export. (Try the above
example).

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