Re: [PATCH] Fix regex for determining image width from attribute

[Karthik Chikmagalur]

> 1. #+attr_org is prioritised
> 2. Docstrings are updated
>
> Handled, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fede1c990

Just a note that we already prioritize #+attr_org when
aligning/centering images.  So this change makes sense.

Karthik

RE: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Drew Adams]

Thanks for your reply, Jim.

> On 4/30/2024 2:10 PM, Drew Adams wrote:
> >> I've also fixed a bug in EWW and bug-reference-mode
> >> where it would return nil for (thing-at-point 'url)
> >> if point was at the *end* of a URL.
> >
> > By "at the end" I assume you really mean just
> > _after_ a URL, i.e., no longer on/at the URL.
> >
> > FWIW, that's actually _superior_ behavior.
> >
> > Unfortunately however, Emacs has chosen the
> > behavior you describe here:
> >
> >> It's now consistent with how 'thing-at-point'
> >> works by default.
> >
> >> (If you have two consecutive URLs and point
> >> is between them...it'll prefer the second one.)
> >
> > Which is better!  It's what "at point" means.
> >
> [snip]
> >
> > See bug #9300, " `bounds-of-thing-at-point'
> > does not return nil when just after THING".
> 
> I agree overall that your proposed behavior is more correct, and it's
> probably how I'd have implemented 'thing-at-point' if I were doing it
> from scratch. However, I think an even worse outcome than
> "thing-at-point looks at point or before-point" is "sometimes
> thing-at-point just looks at point, and other times it looks at point or
> before-point" (which is what it does today).

Yes, such inconsistency is arguably worse than
consistent bad behavior.  Arguably worse - and
arguably better.  (That's in the nature of
inconsistency - some will see a glass half
full; others half empty.)

> I'd even be open to something like a 'thing-at-point-is-strict' defvar
> that people could let-bind as wanted, but I'm not going to *argue* for
> that myself.
> 
> Ultimately though, this patch is really just about providing the
> necessary defcustoms for org-mode to be able to use 'thing-at-point'
> (and for Ihor to feel ok about it ;)). Changing 'thing-at-point's
> behavior should probably be handled separately, especially since there'd
> be an uphill battle to revisit the decision in bug#9300.

I hear you.  The behavior should be changed so
that, in general, bounds-of-thing-at-point etc.
return nil when there is _no thing at point_,
including when point is after, including just
after, a thing but not on such a thing.

There can be commands (and noncommand fns) that
return things _near_ point, not only at point.
And "near" can be configurable with an argument.

In particular, they can do what the vanilla fns
currently do: return a thing at OR just before
point.  But the "-at-point" functions shouldn't
do that.  They should do what their names say.

It's important to have such functions.  It's
not just about arguing that strictly at-point
is better than at-or-just-after-point.  The
point (sic) is that currently there's _no way
to determine whether_ there's a thing at point.

That's the real problem - no test for a thing
at a given position.  That means that a whole
slew of possible applications of the feature
are impossible to realize.
___

Along with the fix for this bug, there could
also be a defvar, or even an option, that fuses
the two behaviors (at OR just before), i.e.,
that gives the current, misguided behavior, to
allow existing code or habits compatibility.

It's not hard for Emacs to still DTRT.  It just
takes a decision and admission that the behavior
was misguided and unnecessarily limiting (BIG
time).

Re: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Jim Porter]

On 4/30/2024 2:10 PM, Drew Adams wrote:

I've also fixed a bug in EWW and bug-reference-mode
where it would return nil for (thing-at-point 'url)
if point was at the *end* of a URL.


By "at the end" I assume you really mean just
_after_ a URL, i.e., no longer on/at the URL.

FWIW, that's actually _superior_ behavior.

Unfortunately however, Emacs has chosen the
behavior you describe here:


It's now consistent with how 'thing-at-point'
works by default.



(If you have two consecutive URLs and point
is between them...it'll prefer the second one.)


Which is better!  It's what "at point" means.

[snip]

See bug #9300, " `bounds-of-thing-at-point'
does not return nil when just after THING".


I agree overall that your proposed behavior is more correct, and it's 
probably how I'd have implemented 'thing-at-point' if I were doing it 
from scratch. However, I think an even worse outcome than 
"thing-at-point looks at point or before-point" is "sometimes 
thing-at-point just looks at point, and other times it looks at point or 
before-point" (which is what it does today).


I'd even be open to something like a 'thing-at-point-is-strict' defvar 
that people could let-bind as wanted, but I'm not going to *argue* for 
that myself.


Ultimately though, this patch is really just about providing the 
necessary defcustoms for org-mode to be able to use 'thing-at-point' 
(and for Ihor to feel ok about it ;)). Changing 'thing-at-point's 
behavior should probably be handled separately, especially since there'd 
be an uphill battle to revisit the decision in bug#9300.

Re: Q: org-publish-project-alist and :exclude

[David Masterson]

David Masterson  writes:

> Ihor Radchenko  writes:
>
>> David Masterson  writes:
>>
>>> So I have this form:
>>>
>>>   :exclude "\(init\|calendar-beorg\).org"
>>>
>>> but that doesn't seem to work as I get an ignorable error in processing
>>> calendar-beorg.org (a known Beorg issue).
>>>
>>> Is my regex wrong?
>>
>> Yes. You got to escape the \ inside string.
>> I recommend using `rx' instead to avoid the backslash hell.
>
> Thanks, I didn't know about `rx'.

Hmm.  Couldn't get rx (or rx-to-string) to work for me.  Kept getting an
error that a stringp was expected for the argument to :exclude. I tried
variations on:

  :exclude (rx-to-string (seq (or "init" "calendar-beorg") ".org"))

Reverted to using a simple regex as above with proper escapes.  Can I
suggest making the complex example in 14.3.2 of the Org Manual use a
better example regex (in rx form?) as a hint to what :exclude can do?

-- 
David Masterson

Re: Bug: Final zero after decimal point is stripped when inline code evaluated

[Charles Millar]

On 5/6/24 12:42 PM, Ihor Radchenko wrote:

Max Nikulin  writes:


On 06/05/2024 19:44, Ihor Radchenko wrote:

Charles Millar writes:

#+NAME: TABLE2
|22578.60|

src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


This is expected. When you assign :var, Org mode reads the table data,
converting it to number.


After discussion of ob-shell related issues I am in doubts if org-babel
should eagerly convert strings to numbers. Perhaps numbers should be
recognized for specific backends only (or vice versa conversion should
be suppressed for specific backends).


Maybe. But changing the current behavior is not trivial - a lot of code
relies upon it implicitly. If anyone wants to work on more
fine-grained control over Org markup -> Elisp conversion, feel free.

Thanks for the feedback. For the moment I will create separate tables 
that have the the desired data in quotes.


I appreciate that mathematically a trailing zero or zeros may be 
non-significant; however, in my use case, i.e. correct format in a text, 
they are necessary. Another example, in addition to my Dollars and cents 
scenario, may be a table that that has been created by using append, and 
the table appears as follows because trailing zeros were disregarded.


This 1.222
that 3.444
it   5.6
last 7.691

Question arises - is the correct number reported on line "it" 5.600 or 
has some editing omitted the last two decimal places?


As an aside, I am not a coder; however I was playing around in the 
scratch butter, and it appears to me that this issue may run deeper that 
Org Mode, for instance:


(number-to-string 5.000)

evaluates to "5.0"

Furthermore, and more closely related to the topic,

(setq toconvert 5.000)
(number-to-string toconvert)

evaluates to "5".

Just my 0.020 cents

Charlie Millar

Re: Citations: strip braces {} in titles in bibliographies in basic style?

[William Denton]

On Saturday, May 4th, 2024 at 15:19, Ihor Radchenko  wrote:

> > I tried to ask for bibtex.el to handle the accurate parsing in
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57712, but it looks like
> > it is not of interest upstream. So, we may have to implement a Bibtex
> > entry parser according to the spec.
> 
> Fixed, on main.
> There is no formal Bibtex format reference, so approximate parsing has to do.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d2df9624c

Thanks for coming back to this months later and making it better.

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: Bug: Final zero after decimal point is stripped when inline code evaluated

[Ihor Radchenko]

Max Nikulin  writes:

> On 06/05/2024 19:44, Ihor Radchenko wrote:
>> Charles Millar writes:
>>> #+NAME: TABLE2
>>> |22578.60|
>>>
>>> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
>>> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}
>> 
>> This is expected. When you assign :var, Org mode reads the table data,
>> converting it to number.
>
> After discussion of ob-shell related issues I am in doubts if org-babel 
> should eagerly convert strings to numbers. Perhaps numbers should be 
> recognized for specific backends only (or vice versa conversion should 
> be suppressed for specific backends).

Maybe. But changing the current behavior is not trivial - a lot of code
relies upon it implicitly. If anyone wants to work on more
fine-grained control over Org markup -> Elisp conversion, feel free.

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

Re: Bug: Final zero after decimal point is stripped when inline code evaluated

[Max Nikulin]

On 06/05/2024 19:44, Ihor Radchenko wrote:

Charles Millar writes:

#+NAME: TABLE2
|22578.60|

src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


This is expected. When you assign :var, Org mode reads the table data,
converting it to number.


After discussion of ob-shell related issues I am in doubts if org-babel 
should eagerly convert strings to numbers. Perhaps numbers should be 
recognized for specific backends only (or vice versa conversion should 
be suppressed for specific backends).



#+name: TABLE2
|"22578.60"|


It may require boilerplate code for post-processing causing inconvenience.

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

[Mehmet Tekman]

Hello!

João Pedro  writes:

> So, if I understand correctly, =header-reform= is where we're at right
> now and after we're done with this overhauling of the parsing of
> (mutually exclusive) header params, we'll get back to the actual syncing
> logic, which should be mostly done.

Exactly -- reform the headers first (branch: header-reform) and then
add the sync stuff later (branch: ob-tangle-sync-2023).

> Ok I'll start here as I think writing tests could give me some more
> insights on the core problems that still need solution.

Yeah, at least from my side I got really confused with what the expected
actions of some :tangle parameters were. Let me know if you find any
ambiguous cases too.

> 1. So the idea is to continue parsing multi-option header arguments into
>their separate components, but have a common place to, after parsing
>it into their components, handle them all in a single place? I mean,
>what does "handle" mean in this context?

Hah, good question. I think by "handle" I mean three things:

1. Ensure that :tangle remains as the raw string :tangle so that other
  parts of Org can use it without needing to guess if there is a sync
  action in there or not. I quite like Ihor's suggestion:

  Ihor Radchenko  writes:
  
  > we need something like
  >
  >   (org-babel-get-header-arg :results params) ; get parsed parameter
  >   (org-babel-get-header-arg :results params 'raw) ; get raw parameter
  >
  > Then, babel backends will not need to know the internal details about
  > :results parameter being represented in its two forms stored as :results
  > and as :result-params.

2. Ensure that :tangle or :tangle-params can merge both filenames and
  sync-actions down the hierarchy.

  In my last email I talk about "process-params" (splitting the filename
  and sync-action) and "merge-params" (resolve hierarchy) as two
  separate entities, where a :tangle header is first "merged" down to a
  header, then "merged" down to a subheading, then "merged" down to a
  source block, and then finally "processed"...

  ... but now that I think about it, it's quite likely that "merge" and
  "process" are interlinked, and we will need something that is aware of
  what the "filename sync-action" pair is, at EVERY level of the
  hierarchy. As in, it processes a header first, then merges it down, then
  processes the next header, and then merges that down, and so forth.

  Right now, process-params and merge-params are two independent code
  blocks, but I think one might need to start calling the other.

3. Do this in such a way that :results can also benefit from this
  process/merge strategy.

> 2. Isn't that the same as the previous point? If we can handle any
>*-params doesn't that solve the problem of handling mutually
>exclusive groups?

Yes, it's the same point :-)

Creating a unified *-params handler for mutually exclusive groups would
probably fix all 3 problems. 

> We can just define a pattern of parsing them into individual *-params
> and handling that in a unified manner.

If I'm understanding you correctly, do you mean we leave the normal
header merging and processing alone, and we just treat :tangle-params
and :result-params as their own special group, and handle them
independently of :tangle and :results?

If so, I'm not so sure how easy it is due to my second point above.

> Are these patches also on the branch (apart from the WIP one)?

Yep, those patches as well as the WIP one are also on that branch. My
coding strategy right now is to develop chaotically on =header-reform=
and then do cherry picking/rebasing afterwards.

If you want I can give you push privileges to that branch, or you can
clone it and work in your own tidier manner, or do you prefer working
with email patches?

Best,
Mehmet

Re: [PATCH] test-org-macro.el: Add test for CVE-2024-30202 (was: Re: [ANN] Emergency bugfix release: Org mode 9.6.23)

[Ihor Radchenko]

Max Nikulin  writes:

> On 25/03/2024 00:16, Ihor Radchenko wrote:
>> 
>> I just released Org mode 9.6.23 that fixes several critical
>> vulnerabilities.
>
> Since a variant of exploit has been published, it is time to add a test 
> that might prevent code change re-introducing the most severe vulnerability.
> From af8cddb44f5ee01fb1c7c9cf664ddbc83c63ac56 Mon Sep 17 00:00:00 2001
> From: Max Nikulin 
> Date: Mon, 6 May 2024 19:04:17 +0700
> Subject: [PATCH] test-org-macro.el: Add test for CVE-2024-30202

Thanks!
Applied, onto main, after adding another test case with a call to
(org-mode). Just to be sure.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=51aff8a11

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

[Ihor Radchenko]

João Pedro  writes:

>>Something that handles tangle-params and result-params,
>
> 1. So the idea is to continue parsing multi-option header arguments into
>their separate components, but have a common place to, after parsing
>it into their components, handle them all in a single place? I mean,
>what does "handle" mean in this context?

>From my point of view, we need some API function to retrieve header
argument values. Instead of the current approach with

  (result-params (cdr (assq :result-params params)))

we need something like

  (org-babel-get-header-arg :results params) ; get parsed parameter
  (org-babel-get-header-arg :results params 'raw) ; get raw parameter

Then, babel backends will not need to know the internal details about
:results parameter being represented in its two forms stored as :results
and as :result-params.

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

[Ihor Radchenko]

Mehmet Tekman  writes:

> Okay, I've cleaned up my branches and rebased where I could, and now I
> think my code is at a place where you can jump in.
>
> This will be a long email summarizing what's been done so far, where the
> pitfalls were, where we are now, and what needs to be done:
> ...

Thanks a lot for taking a time to write this summary!

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

Re: Bug: Final zero after decimal point is stripped when inline code evaluated

[Ihor Radchenko]

Charles Millar  writes:

> Please note that in the second src_latex the zero is stripped from the 
> results. The final zero is required for my purposes, i.e. dollars and 
> cents. This occurs in both results and on export to pdflatex,
>
> Does org's evaluation cause this or does latex? I have attempted to use 
> the siunutx and currency packages.as follows,
>
> #+NAME: TABLE2
> |22578.60|
>
> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace 
> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}

This is expected. When you assign :var, Org mode reads the table data,
converting it to number. When numbers are considered, 22578.60 and
22578.6 are the same thing. If you want to retain the non-significant
zeros in numbers, you need to use strings inside the table:

#+name: TABLE2
|"22578.60"|

Not a bug.
Canceled.

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

[PATCH] test-org-macro.el: Add test for CVE-2024-30202 (was: Re: [ANN] Emergency bugfix release: Org mode 9.6.23)

[Max Nikulin]

On 25/03/2024 00:16, Ihor Radchenko wrote:


I just released Org mode 9.6.23 that fixes several critical
vulnerabilities.


Since a variant of exploit has been published, it is time to add a test 
that might prevent code change re-introducing the most severe vulnerability.
From af8cddb44f5ee01fb1c7c9cf664ddbc83c63ac56 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Mon, 6 May 2024 19:04:17 +0700
Subject: [PATCH] test-org-macro.el: Add test for CVE-2024-30202

* testing/lisp/test-org-macro.el (test-org-macro/initialize-templates):
A new test that no code is evaluated when an Org file is opened
(CVE-2024-30202).

Ihor Radchenko [ANN] Emergency bugfix release: Org mode 9.6.23.
Sun, 24 Mar 2024 17:16:50 +.

---
 testing/lisp/test-org-macro.el | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/testing/lisp/test-org-macro.el b/testing/lisp/test-org-macro.el
index 3339945fa..88a51693c 100644
--- a/testing/lisp/test-org-macro.el
+++ b/testing/lisp/test-org-macro.el
@@ -22,6 +22,16 @@ ;;; Code:
 
 ;;; Macros
 
+(ert-deftest test-org-macro/initialize-templates ()
+  "Test `org-macro-initialize-templates'."
+  ;; No code is executed during loading of Org mode files."
+  (should
+   (org-test-with-temp-text
+   "#+MACRO: title (eval (eval-and-compile (error \"CVE-2024-30202\")))"
+ (progn
+   (org-macro-initialize-templates)
+   t
+
 (ert-deftest test-org/macro-replace-all ()
   "Test `org-macro-replace-all' specifications."
   ;; Standard test.
-- 
2.39.2

Re: [BUG] tracker.orgmode.org does not track anything since March 8, 2024

[Bastien Guerry]

Ihor Radchenko  writes:

> A few bug reports and patches arrived but nothing is reflected on the
> Woof! list.

Yes, confirmed, I will have a closer look at this today or tomorrow.

-- 
 Bastien Guerry

Re: [PATCH] oc-csl: Remove spaces before citations in superscript

[Ihor Radchenko]

András Simonyi  writes:

> Thanks Ihor, I have pushed it to main.

Thanks!
Applied. <- a control message for Woof!
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=288e0a11c
^ reference to make life easier when digging mailing list archives for
future maintainers.

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

Re: [BUG] tracker.orgmode.org does not track anything since March 8, 2024

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Woof! does not seem to update the new emails any more.
>> https://tracker.orgmode.org/?sorting-by=date page only contains emails
>> back from March. No new bugs/requests/news are visible.
>
> I restarted Woof, let's see if the dog is barking again.

Silence...
A few bug reports and patches arrived but nothing is reflected on the
Woof! list.

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

Re: [PATCH] Add support for shortdoc link type

[Max Nikulin]

On 06/05/2024 04:35, Bruno Cardoso wrote:

Fixed.


I have tried the patch. It mostly works, so I do not insist on further 
polishing. However it should be resent with proper description.



I had dropped the search code because I wasn't considering the search
option properly. If I understand correctly, both "::" and "::#" should
match a function OR a search string? (e.g.:
`shortdoc:text-properties::#pos-property' will also search for
"pos-property" in the shortdoc buffer). This is the current behavior in
the attached patch.


It seems my comments have led mostly to confusion rather than 
improvements. I am sorry for that. I have in mind 2 kind of links:
-  that may be handled solely by 
`shortdoc-display-group' with second argument.

-  that should cause
  (shortdoc-display-group group)
  (search-forward fn nil t) ; or (word-search-forward fn nil t)

For `re-search-forward' used in the latest patch revision, from my point 
of view, link should be  
(similar to file: links).


Support of search variant may be dropped, but that case I would not 
allow "::" as the separator. Mandatory "::#" allows to add text and 
regexp search later.



+++ b/doc/org-manual.org
@@ -3382,6 +3382,13 @@ Here is the full set of built-in link types:
 
   Execute a shell command upon activation.
 
+- =shortdoc= ::

+
+  Link to short documentation summary for an Emacs Lisp function group.
+  Since Emacs 28, user command ~shortdoc-display-group~ lists all known
+  documentation groups. For more information, see [[info:emacs#Name Help]]
+  and [[info:elisp#Documentation Groups]].


I am unsure that links without description is a bright idea. Try
https://orgmode.org/manual/Activation.html
and M-: (info "(org) Activation") RET
to get an impression of export result.


+++ b/lisp/ol.el
@@ -1582,6 +1582,44 @@ PATH is a symbol name, as a string."
  :follow #'org-link--open-help
  :store #'org-link--store-help)
 
+ "shortdoc" link type

+(when (version<= "28.0.90" emacs-version)
+  (defun org-link--open-shortdoc (path _)
+"Open a \"shortdoc\" type link.
+PATH is a group name, \"group::#function\" or \"group::search_string\"."
+(string-match "\\`\\([^:]*\\)\\(?:::#?\\(.*\\)\\)?\\'" path)


I just have realized that it is better to ignore anything unexpected 
after ":", e.g. if only ::# is allowed (no search text option)


(string-match "\\`\\([^:]*\\)\\(?:::#\\(.*\\).*\\'\\)?" path)

Try [[shortdoc:string:invalid]].

[PATCH] org-manual: Rewrite opening section in Citation handling

[Ihor Radchenko]

Hi,

The current version of Citation handling section of the manual is rather
technical. I tried to rewrite it aiming for ordinary users not familiar
with Org mode internals.

Please, let me know if it reads better.

>From 89e5bd96a1219e85f8e6be7a6eabb840257b021a Mon Sep 17 00:00:00 2001
Message-ID: <89e5bd96a1219e85f8e6be7a6eabb840257b021a.1714984945.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 6 May 2024 11:40:18 +0300
Subject: [PATCH] org-manual: Add better opening description to "Citation
 handling" section

* doc/org-manual.org (Citation handling): Rewrite the opening
paragraphs describing citations using less technical description.  The
new version aims to ordinary Org mode users and avoids talking about
Elisp libraries.
(Citations): Unify markup for citation processor names (use verbatim).
Mention that at least one #+PRINT_BIBLIOGRAPHY is mandatory to render
output.  Indicate that default citation style is "nil".
---
 doc/org-manual.org | 89 ++
 1 file changed, 66 insertions(+), 23 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 1feb5ed60..59663a90f 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17490,30 +17490,68 @@ * Citation handling
 #+cindex: citation
 #+cindex: citation processor
 
-The =oc.el= library provides tooling to handle citations in Org via
-"citation processors" that offer some or all of the following
-capabilities:
+While [[*Hyperlinks][links]] are often sufficient to refer to external
+or internal information from Org, they have their limitations when
+referring to multiple targets or typesetting printed publications.
 
-- activate :: Fontification, tooltip preview, etc.
-- follow :: At-point actions on citations via ~org-open-at-point~.
-- insert :: Add and edit citations via ~org-cite-insert~.
-- export :: Via different libraries for different target formats.
+Org mode provides a more sophisticated markup to "cite" external
+resources.  For example, consider the following Org mode snippet
 
-To use a "citation processor", the user must load them; for example;
+: #+bibliography: citationdata.bib
+:
+: Org mode is used by various communities [cite:teaching: @orgteaching;
+: and TeX: @orgtex].  [cite/author/caps:@orgtex] uses Org mode to simplify
+: writing scientific publications, while [cite/author/caps:@orgteaching]
+: experiment with Org babel to improve teaching.
+:
+: #+print_bibliography:
 
-#+begin_src emacs-lisp
-(require 'oc-bibtex)
-#+end_src
+Org mode will gather citation metadata from =#+bibliography= database
+and use it to typeset the exported document in arbitrary formats.
+For example, below snippet shows ASCII export output.
+
+: Org mode is used by various communities (teaching: Birkenkrahe, Marcus,
+: 2023, and TeX: Somma, Emmanuele F, 2023).  Somma, Emmanuele F uses Org
+: mode to simplify writing scientific publications, while Birkenkrahe,
+: Marcus experiment with Org babel to improve teaching.
+:
+: Birkenkrahe, Marcus (2023). /Teaching Data Science with Literate
+: Programming Tools/, MDPI.
+:
+: Somma, Emmanuele F (2023). /Simplifying LaTeX with ORG-mode in Emacs/,
+: TUGboat volume.
+
+In addition to export, users can use completion to search and insert
+citations from the bibliography (via ~org-cite-insert~).  Citations
+also act like ordinary links, jumping to the citation metadata when
+"following" them (~org-open-at-point~).
+
+You can customize every aspect (/capability/) of citation handling
+using built-in or external /citation processors/.
+
+Org mode ships with several built-in citation processors tailored to
+work with LaTeX export and BiBTeX bibliographies (=bibtex=,
+=biblatex=, and =natbib= processors), or with more generic Citation
+Style Language bibliographies (=csl= processor).
+
+The default citation processor is =basic= - it works with arbitrary
+export formats and recognized both BiBTeX and CSL bibliographies.
+
+More citation processors are distributed as Emacs packages.
 
 #+vindex: org-cite-activate-processor
 #+vindex: org-cite-follow-processor
 #+vindex: org-cite-insert-processor
 #+vindex: org-cite-export-processor
-They can then configure them with ~org-cite-activate-processor~,
-~org-cite-follow-processor~, ~org-cite-insert-processor~, and
-~org-cite-export-processors~ respectively.
+Multiple citation processors can be mixed to meet your preferences.
+Configure ~org-cite-activate-processor~, ~org-cite-follow-processor~,
+~org-cite-insert-processor~, and ~org-cite-export-processors~ to
+select which processor to use for every citation capability:
 
-The included "basic" processor provides all four capabilities.
+- activate :: Fontification, tooltip preview, etc.
+- follow :: At-point actions on citations via ~org-open-at-point~.
+- insert :: Add and edit citations via ~org-cite-insert~.
+- export :: Via different libraries for different target formats.
 
 ** Citations
 
@@ -17567,7 +17605,8 @@ ** Citations
 
   : [cite/style:common 

Re: [PATCH] Remove warning about org-clock-save.el lacking lexical-binding directive

[Bastien Guerry]

Ihor Radchenko  writes:

> I think that it is premature.
> This is a warning recently introduced on Emacs master, and it is still
> being debated upon. See
> https://yhetil.org/emacs-devel/50e29988-d354-4d10-990f-31828dbe6...@gmail.com/t/#u

Okay, fair enough.

-- 
 Bastien Guerry

Re: [BUG] Commit a2e5685e4 introduces a regression

[Bastien Guerry]

Ihor Radchenko  writes:

> Fixed, on main.
> I removed the folding part, but forgot to add invisible property
> handling.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c8bd2092b

Great, thanks!

-- 
 Bastien Guerry

Re: [PATCH] Silence a warning in org-table.el

[Bastien Guerry]

Ihor Radchenko  writes:

> It just _seems_ trivial. This innocently-looking patch will break tests.
>
> Duplicate of https://list.orgmode.org/orgmode/875y2oxfd8@red-bean.com/T/#u
> Canceled.

Doh!  And I already reverted this myself!  I'm getting old.

Thanks.

-- 
 Bastien Guerry

Re: [BUG] Exporting lists of >100 items to markdown

[Bastien Guerry]

Ihor Radchenko  writes:

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

Thanks!

-- 
 Bastien Guerry