Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

Den tis 25 juli 2023 kl 19:26 skrev Jonathan Gregory :

> Hi Henrik,
>
> On 25 Jul 2023, Henrik Frisk wrote:
>
> > Den tis 25 juli 2023 kl 18:16 skrev Henrik Frisk
> > :
>
> > My bad, putting :file ionian.cropped.png only results in
> > ionian.cropped.cropped.png (as expected). Unclear why it worked
> > the first couple of times.
> >
> > /Henrik
>
> No need to crop the output. If you need png, you should use:
>
> #(ly:set-option 'tall-page-formats 'png)
>
> Makes sense, but I have to admit that I find this a bit confusing. I was
under the impression that the 'crop' option was the preferred way to
accomplish this.

Thanks for resolving this anyway!

/Henrik

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

[Jens Schmidt]

On 2023-07-25  01:08, Ypo wrote:

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


To be honest: Because I haven't read your mail properly and because I
didn't know about "pretty entities".  I just noticed the subscripting
done on such_file_names in Org HTML exports and searching from that
direction found variables `org-use-sub-superscripts' and
`org-export-with-sub-superscripts'.

After a second look, though, it seems that `org-use-sub-superscripts' is
in fact a bit more general than
`org-pretty-entities-include-sub-superscripts'.  But I don't get the
logic in that area completely, so others may comment here as well ...

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

On 22 Jul 2023, Ihor Radchenko wrote:

I guess I do not fully understand what your patch is trying to 
achieve. I thought that the patch would make it not necessary to 
write some extra boilerplate code, like \version or specifying 
the page size.


The purpose of the patch was to fix the problem described in 
https://masto.ai/@rfc1149/110674961710491363. I wasn't trying to 
introduce anything new.


Anyway, I can add version and paper settings as well, but those 
are user settings and I'm not sure that hard-coding them is a good 
idea. What I don't like is having to repeat <> 
everywhere. Is there a way of telling org-mode to insert a noweb 
reference from the header? Something like:


#+PROPERTY: header-args:lilypond :prepend <>


--
Jonathan

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Jonathan Gregory]

Hi Henrik,

On 25 Jul 2023, Henrik Frisk wrote:

Den tis 25 juli 2023 kl 18:16 skrev Henrik Frisk 
:


My bad, putting :file ionian.cropped.png only results in 
ionian.cropped.cropped.png (as expected). Unclear why it worked 
the first couple of times.


/Henrik


No need to crop the output. If you need png, you should use:

#(ly:set-option 'tall-page-formats 'png)


--
Jonathan

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

[Evgenii Klimov]

Ihor Radchenko  writes:

[...]
> Thanks!
> The second patch is malformed. May you please resend?

Sorry, resend with rewritten test.

[...]
> If you can, please avoid using `org-test-at-id'. This is much less
> readable compared to explicit org-test-with-temp-text because one needs
> to reach out to another file in order to understand what the test is
> about.

Now it's less verbose, handles both cases
(with and without TARGET-FILE) and prints detailed ert explanation.

> Evgenii Klimov  writes:
[...]
>> 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.
>
> In `org-babel-tangle', TARGET-FILE is set as fallback value for the
> blocks that have no :tangle value at all, including inherited; including
> :tangle yes.

This exactly idea I wanted to add to the docstring.

> The manual asserts
>
> ‘yes’
>  Export the code block to source file.  The file name for the source
>  file is derived from the name of the Org file, and the file
>  extension is derived from the source code language identifier.
>  Example: ‘:tangle yes’.
>
> So, "yes" should imply :tangle 
>
> `org-babel-tangle-collect-blocks' handles this by
>
> (unless (or (string= src-tfile "no")
> (and tangle-file (not (equal tangle-file src-tfile)))
> (and lang-re (not (string-match-p lang-re src-lang
>
> So, :tangle no is always excluded.
> When TANGLE-FILE is set and not equal to :tangle value (including
> "yes"), block is also excluded.

Indeed, but later

   ‘no’
The *default*.  Do not extract the code in a source code file.
Example: ‘:tangle no’.

in conjunction with TARGET-FILE's description in ~org-babel-tangle~
docstring:

   Optional argument TARGET-FILE can be used to specify a *default*
   export file for all source blocks.

made me feel doubt about TARGET-FILE's effect.

Anyway, probably it was my incorrect interpretation, so let's leave it
as it is.
>From a5b4faec9b58b8e56512c03e4f1a1fe295900d3f Mon Sep 17 00:00:00 2001
From: Evgenii Klimov 
Date: Fri, 21 Jul 2023 22:40:06 +0100
Subject: [PATCH v4 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.
---
 testing/lisp/test-ob-tangle.el | 111 +
 1 file changed, 111 insertions(+)

diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index 07e75f4d3..55e1f7aa3 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -569,6 +569,117 @@ another block
 (set-buffer-modified-p nil))
   (kill-buffer buffer
 
+(ert-deftest ob-tangle/collect-blocks ()
+  "Test block collection into groups for tangling."
+  (org-test-with-temp-text-in-file
+  "* H1 with :tangle in properties
+:PROPERTIES:
+:header-args: :tangle relative.el
+:END:
+
+#+begin_src emacs-lisp
+\"H1: inherited :tangle relative.el in properties\"
+#+end_src
+
+#+begin_src emacs-lisp :tangle yes
+\"H1: :tangle yes\"
+#+end_src
+
+#+begin_src emacs-lisp :tangle no
+\"H1: should be ignored\"
+#+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
+
+* H2 without :tangle in properties
+
+#+begin_src emacs-lisp
+\"H2: without :tangle\"
+#+end_src
+
+#+begin_src emacs-lisp :tangle yes
+\"H2: :tangle yes\"
+#+end_src
+
+#+begin_src emacs-lisp :tangle no
+\"H2: should be ignored\"
+#+end_src
+
+#+begin_src emacs-lisp :tangle relative.el
+\"H2: :tangle relative.el\"
+#+end_src
+
+#+begin_src emacs-lisp :tangle ./relative.el
+\"H2: :tangle ./relative.el\"
+#+end_src
+
+#+begin_src emacs-lisp :tangle /tmp/absolute.el
+\"H2: :tangle /tmp/absolute.el\"
+#+end_src
+
+#+begin_src emacs-lisp :tangle ~/../../tmp/absolute.el
+\"H2: :tangle ~/../../tmp/absolute.el\"
+#+end_src
+"
+(letrec ((org-file (buffer-file-name))
+ (test-dir (file-name-directory org-file))
+ (el-file-abs (concat (file-name-sans-extension org-file) ".el"))
+ (el-file-rel (file-name-nondirectory el-file-abs))
+ (sort-fn (lambda (lst) (seq-sort-by #'car #'string-lessp lst)))
+ (expected-targets-fn
+  (lambda (nblocks-el-file)
+"Convert to absolute file names and sort expected targets"
+(funcall sort-fn
+ 

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

Den tis 25 juli 2023 kl 18:16 skrev Henrik Frisk :

> Hi,
>
> I have been struggling with the same issues to but have completely missed
> this thread. I haven't tried the patch of ob-lilypond but testing the file
> https://git.sr.ht/~bzg/worg/tree/6f69d212f41bc372426dc9b4df286638fe8f2a92/item/org-contrib/babel/examples/lilypond.org
> I'm getting cropped output with pdf, but not png (generates full page).
> Also, omitting the paper stuff I still get the same cropped output wit pdf:
>
> #+begin_src lilypond :file ionian.png
>  \version "2.24.1"
> \relative c' {
>   c d e f
>   g a b c
>   b a g f
>   e d c d
>   e f g a
>   b c b a
>   g f e d
>   c1
> }
> #+end_src
>
> Adding  #(ly:set-option 'crop #t) to the file gives a cropped output in
> the file 'ionian.cropped.png' but the ionian.png is still fullpage. I was
> looking in ob-lilypond to change the outputfile name but the easy solution
> is to just give the cropped name as the :file argument:
>
> :file ionian.cropped.png
>
> Then the file is shown inline in the #+RESULT: block. This works for other
> file formats two, like pdf and eps.
>
> Here's a short version:
>
> #+begin_src lilypond :file ionian.cropped.png
>   \Version "2.24.1"
> #(ly:set-option 'crop #t)
> \relative c' {
>   c d e f
> }
> #+end_src
>
> My bad, putting :file ionian.cropped.png only results in
ionian.cropped.cropped.png (as expected). Unclear why it worked the first
couple of times.

/Henrik

Re: [ANN] lisp/ob-tangle-sync.el

[Ihor Radchenko]

Mehmet Tekman  writes:

>> Another meetup is on July 26. https://emacs-berlin.org/
>> Or we can arrange a jitsi call.
>
> Sure, I can be there tomorrow!

Ok.
There are several talks planned at the beginning, and we may discuss your
patch after those.

>> The tests are indeed not passing on vanilla Org. I assume that you
>> tested them with your other patch applied.
>
> I tested them on upstream/main... or so I thought, though I now
> realise that I needed to delete the =~/.emacs.d/straight/build/org=
> directory to trigger a rebuild of org-mode for the current branch I
> was on. (Live and learn...)

That should not normally be necessary. Not sure what happened in your
setup.

> Problem: My testing patch is indeed not working on vanilla Org, but it
>  contains tests that will (presumably) work with the new
>  merge-params patch.
>
> Question: What is the order of submission of patches?
>
>   Do I submit a testing patch first which works strictly with
>   vanilla Org first, and then a new merge-params function, and
>   then yet another testing patch that is compliant with the
>   new merge-params function?
>
>   Or do I submit the new merge-params function, and then my
>   testing patch on top?

Either way is fine. The latter should be easier for you though.

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

Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

[Henrik Frisk]

Hi,

I have been struggling with the same issues to but have completely missed
this thread. I haven't tried the patch of ob-lilypond but testing the file
https://git.sr.ht/~bzg/worg/tree/6f69d212f41bc372426dc9b4df286638fe8f2a92/item/org-contrib/babel/examples/lilypond.org
I'm getting cropped output with pdf, but not png (generates full page).
Also, omitting the paper stuff I still get the same cropped output wit pdf:

#+begin_src lilypond :file ionian.png
 \version "2.24.1"
\relative c' {
  c d e f
  g a b c
  b a g f
  e d c d
  e f g a
  b c b a
  g f e d
  c1
}
#+end_src

Adding  #(ly:set-option 'crop #t) to the file gives a cropped output in the
file 'ionian.cropped.png' but the ionian.png is still fullpage. I was
looking in ob-lilypond to change the outputfile name but the easy solution
is to just give the cropped name as the :file argument:

:file ionian.cropped.png

Then the file is shown inline in the #+RESULT: block. This works for other
file formats two, like pdf and eps.

Here's a short version:

#+begin_src lilypond :file ionian.cropped.png
  \Version "2.24.1"
#(ly:set-option 'crop #t)
\relative c' {
  c d e f
}
#+end_src

/Henrik


Den lör 22 juli 2023 kl 10:13 skrev Ihor Radchenko :

> Jonathan Gregory  writes:
>
> > On 21 Jul 2023, Ihor Radchenko wrote:
> >
> >> The png is still a full page on my side.
> >
> > That's not what I get. You're probably missing the paper settings:
> >
> > #+begin_src lilypond :exports none
> > \version "2.20"
> > \paper {
> >   indent=0\mm
> >   tagline=""
> >   line-width=170\mm
> >   oddFooterMarkup=##f
> >   oddHeaderMarkup=##f
> >   bookTitleMarkup=##f
> >   scoreTitleMarkup=##f
> > }
> > #+end_src
>
> I feel confused. Isn't you patch aiming for auto-sizing the resulting
> page to fit the music fragment?
>
> >> Also, I am getting
> >>
> >> Processing `/tmp/babel-xQweBZ/lilypond-WGdEvi'
> >> Parsing...
> >> /tmp/babel-xQweBZ/lilypond-WGdEvi:1: warning: no \version
> >> statement found, please add
> >>
> >> \version "2.24.0"
> >>
> >> which does not look necessary.
> >
> > What is not necessary? The warning is expected. Other than that
> > everything looks fine.
>
> I guess I do not fully understand what your patch is trying to achieve.
> I thought that the patch would make it not necessary to write some extra
> boilerplate code, like \version or specifying the page size.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

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

[Max Nikulin]

On 25/07/2023 14:43, Ihor Radchenko wrote:

"Rick Lupton" writes:
 >> 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.



What about inherited CUSTOM_ID?


I am not excited by the idea of extending id links for heading 
hierarchy. From my point of view it is more natural to add the ID 
property to the heading that should be link target.


Sometimes I do not mind to disambiguate heading search link by 
specifying title of its ancestor. I usually add the CUSTOM_ID property 
or rename heading to be unique.


I am afraid that allowing arbitrary link types to specify path to an 
element is overkill. It is not XPath and not CSS selectors.

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

[Max Nikulin]

On 25/07/2023 03:29, Gavin Downard wrote:

Max Nikulin writes:

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


Yeah, I guess my current patch only supports column names in column
formulas. Allowing column names inside of arbitrary references will take
some more comprehensive changes. I'll see what I can do.


The regexp for parsing formulas does not allow named references after @. 
I have no idea if other code should be modified as well. I consider it 
as more important than detection of duplicated definitions.


A crazy idea: several columns may have the same name:

|   | Jun sum | Jun count | Jun avg | Jul sum | Jul count | Jul avg |
| ! | |   | average | |   | average |
|---+-+---+-+-+---+-|
|   |  150| 10| | 200 |14 | |
#+tblfm: $average=$-2/$-1

It has no sense for numeric references but with names it can help to 
avoid repeated expressions.

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

[Marcin Borkowski]

On 2023-07-25, at 07:19, Ihor Radchenko  wrote:

> 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

Thanks!  This was far from obvious, but works exactly as I needed!

Best,

-- 
Marcin Borkowski
http://mbork.pl

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

[Gavin Downard]

Max Nikulin  writes:
> 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

Yeah, I guess my current patch only supports column names in column
formulas. Allowing column names inside of arbitrary references will take
some more comprehensive changes. I'll see what I can do.

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]

Ihor Radchenko  writes:

> You can increase `icalendar-export-sexp-enumeration-days' to get the
> anniversary occurrences exported up to that number of days ahead.

I now documented this in the manual.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5f7cfdfd1
Handled.

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

Re: [ANN] lisp/ob-tangle-sync.el

[Mehmet Tekman]

Ihor Radchenko  writes:

> Another meetup is on July 26. https://emacs-berlin.org/
> Or we can arrange a jitsi call.

Sure, I can be there tomorrow!

> To name them, you can use separate ert-deftest statements.

Oh sure, but I don't want to clutter the library.

> Also, see the attached modified version of your diff - I made it so
> that `should' failures immediately provide some clue about expected
> result value, that can help to identify which of the should clauses
> fails.

Ah nice, much appreciated thank you. I was hesitant to split out the
main testing function (previously called by `funcall') into its own
function out of the same fears as above, but I see now it's not the
only one.

> The tests are indeed not passing on vanilla Org. I assume that you
> tested them with your other patch applied.

I tested them on upstream/main... or so I thought, though I now
realise that I needed to delete the =~/.emacs.d/straight/build/org=
directory to trigger a rebuild of org-mode for the current branch I
was on. (Live and learn...)

Problem: My testing patch is indeed not working on vanilla Org, but it
 contains tests that will (presumably) work with the new
 merge-params patch.

Question: What is the order of submission of patches?

  Do I submit a testing patch first which works strictly with
  vanilla Org first, and then a new merge-params function, and
  then yet another testing patch that is compliant with the
  new merge-params function?

  Or do I submit the new merge-params function, and then my
  testing patch on top?

Best,
Mehmet

Re: org-bibtex manual

[Ihor Radchenko]

Ihor Radchenko  writes:

> I should factor out that lambda into a separate readable function name,
> like `org-bibtex-headline-from-title'.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ac0042184

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

Re: ox-publish index allows alternative formats?

[Ihor Radchenko]

Britt Anderson  writes:

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

Yes.

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

You can introduce :makeindex-function property that will override
`org-publish-index-generate-theindex', or at least its part after ";;
Write "theindex.inc" in DIRECTORY.".

Alternatively (or additionally), you can introduce
:makeindex-format-entry keyword that will hold function used to format
an item in the index.

Should not be too hard. You can follow the existing examples with
sitemap generation code.

And feel free to ask anything, if you have difficulties along the way.

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

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

[Ihor Radchenko]

"Rick Lupton"  writes:

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

I think that it will be a reasonable addition.

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

What about inherited CUSTOM_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.

Yes, on both questions.
See https://orgmode.org/worg/org-contribute.html#copyright

> +   ((and (featurep 'org-id)
> +(eq org-id-link-to-org-use-id 'inherit))

What if none of the parents have an ID?

> +   ;; Store a link using the inherited ID and search string
> +   (setq cpltxt (condition-case nil
> +(prog1 (org-id-store-link 'inherit)
> ...
> +   "NONE"))

This is code duplication from another branch of the same function.
Please, rewrite without copy-pasting large chunks of code.

For example, you can extract the common parts of the code into a private
helper function.

>  ;;;###autoload
> -(defun org-id-store-link ()
> +(defun org-id-store-link ( inherit)
>"Store a link to the current entry, using its ID.
>  
> +If INHERIT is non-nil, consider also parents' IDs if the current
> +entry does not have an ID.
> +

This will no longer store a link to current entry with INHERIT argument.
The search string will be missing from the link path.

Ideally, we should have all the necessary logic to store the link within
`org-id-store-link' and then use `org-link-set-parameters' to configure
id links.

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

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]

Jens Schmidt  writes:

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

That would be welcome. Thanks in advance!

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

Ok. Then, if no further objections, I will apply the patch tomorrow.

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

We haven't had many bug reports about ol-gnus in the past, so I do not
have much statistics on whether getting such errors is common.

I do not think that implementing error handling is worth an effort here.
If killing summary buffer is already calling for trouble when using
Gnus itself, Org mode handling the error will not make things much
better.

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

>> Please provide mode details about what you tried.  
>
> OK, I will try.  I start emacs with
> ...
> Org mode version 9.5.5 (release_9.5.5 @ 
> /snap/emacs/current/usr/share/emacs/28.2/lisp/org/)

I can also reproduce with this Org version.
But not with Org 9.6 (the latest release).

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

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

[Ihor Radchenko]

Evgenii Klimov  writes:

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

Thanks!
The second patch is malformed. May you please resend?

(You can see the problem if you try to download the second patch in 
)

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

If you can, please avoid using `org-test-at-id'. This is much less
readable compared to explicit org-test-with-temp-text because one needs
to reach out to another file in order to understand what the test is
about.

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

In `org-babel-tangle', TARGET-FILE is set as fallback value for the
blocks that have no :tangle value at all, including inherited; including
:tangle yes.

The manual asserts

‘yes’
 Export the code block to source file.  The file name for the source
 file is derived from the name of the Org file, and the file
 extension is derived from the source code language identifier.
 Example: ‘:tangle yes’.

So, "yes" should imply :tangle 

`org-babel-tangle-collect-blocks' handles this by

  (unless (or (string= src-tfile "no")
  (and tangle-file (not (equal tangle-file src-tfile)))
  (and lang-re (not (string-match-p lang-re src-lang

So, :tangle no is always excluded.
When TANGLE-FILE is set and not equal to :tangle value (including
"yes"), block is also excluded.

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