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

[Rens Oliemans <hallo@rensoliemans.nl>]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

Thanks for the patch, it looks good and is an improvement over the
somewhat terse previous version. I do have some thoughts though so will
chime in. Note that I am not a native speaker, it might be best if we get
extra eyes from a(nother?) native speaker.

Ihor Radchenko <yantar92@posteo.net> writes:

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

In Emacs Info, this renders as

   "While see links. are often sufficient ...".

This seems quite unnatural to me. I would suggest using a different way
of referencing (without "see [link].") if possible, or rewording the
sentence otherwise.

> +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~).

Alternatively:

   when "following" them using ~org-open-at-point~.

For a more natural sentence?

> +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 formats
> +described using [[https://citationstyles.org/][Citation Style
> +Language]] (=csl= processor).
> +
> +The default citation processor is =basic= - it works with arbitrary
> +export formats and recognizes both BibTeX and CSL bibliographies.
> +
> +More citation processors are distributed as Emacs packages.

These very small paragraphs read a bit clunky to me, I think that it's
better to merge them into a single paragraph.

> -  When style is not specified, default style is used
> +  When style is not specified, default style (=nil=) specified by the
> +  citation processor is used

I am only slightly familiar with Org's citation handling, and this part
of the manual is a bit confusing to me. I wrote a small patch on top of
yours with something that is clearer to me, but perhaps this is unique to
me.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-manual-clarify-default-style.patch --]
[-- Type: text/x-patch, Size: 1351 bytes --]

From 70fe33fe0012c124fd011011ee77e544e18d50ad Mon Sep 17 00:00:00 2001
From: Rens Oliemans <hallo@rensoliemans.nl>
Date: Tue, 14 May 2024 20:45:01 +0200
Subject: [PATCH] org-manual: clarify default style

I don't intend this commit to be merged but instead to be squashed in
the existing patch.
---
 doc/org-manual.org | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 50af99c5b..c2f08be17 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17609,16 +17609,16 @@ identifying a reference in the bibliography.
 
   : [cite/style:common prefix ;prefix @key suffix; ... ; common suffix]
 
-  When style is not specified, default style (=nil=) specified by the
-  citation processor is used
+  When =style= is not specified, one of the two default styles are
+  used
 
-  + either the default style specified in =CITE_EXPORT= keyword (see
-    [[*Citation export processors]])
+  + either the default style specified in the =CITE_EXPORT= keyword
+    (see [[*Citation export processors]])
 
     : #+cite_export: basic numeric noauthor/bare
     : [cite:@key] is the same as [cite/noauthor/bare:@key]
 
-  + or using default =nil= style
+  + or, if =CITE_EXPORT= is not set, using the default =nil= style
 
     : [cite:@key] is the same as [cite/nil:@key]
 
-- 
2.44.0


[-- Attachment #3: Type: text/plain, Size: 362 bytes --]


Is this understanding of the 'style' specification correct? This is what
I concluded from reading the manual, if it is incorrect, please forgive
me and let me know how exactly I am incorrect, perhaps that can
illuminate this part ;)


Best,
Rens

PS: is such a way of including a patch (that builds upon a discussed
patch) the best way to communicate changes?