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

[David Masterson]

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

-- 
David Masterson

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

[João Pedro]

Em domingo, 05/05/2024 às 18:47 (+02), Mehmet Tekman  
escreveu:

> Hello João and org!

Hi Mehmet!

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

Thank you for the summary. Albeit long, it was quite important to
understand all of the discussions and decisions so far. I tried keeping
track of every thing on this long, long thread, but couldn't follow up
with everything, so it was incredibly helpful of you to give such a
complete summary.

> So, my code is hosted at =https://gitlab.com/mtekman/org-mode= and with
> the exception of the =header-reform= branch, is about 1 year behind
> upstream.

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.

> * Where we are now
>
> The branch I have most recently worked on (I rebased it earlier this
> week) is called =header-reform=. It splits a :tangle header such as
>
> this =:tangle filename with space.txt export=
> into =:tangle-params ("filename with space.txt" "export")=
>
> such that it does not interfere with the rest of org headers.
>
> This is where I would greatly need you help, João.
>
> The work still to be done from my perspective:
>
> 1. Implement tests  <<- we are here
>
>We need to know what the desired behaviour of :tangle and
>:tangle-params will be in different contexts.
>
>I have written 12 test cases as a start, but some contexts are
>still unclear to me and I cannot do this alone.
>
>Please see the second and third patches attached to this email.

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

> 2. Unified merge function

I do have a couple of questions regarding this:

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

>as well
>something that can handle mutually exclusive groups such as tangle
>and results, especially when the :any keyword is involved.

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? We can just define a pattern of parsing them into
   individual *-params and handling that in a unified manner.

> I've attached the two working patches from the =header-reform= branch to
> this mail, and one floating WIP inline patch which should get things
> started.

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

> Apologies for the length, I just wanted to summarize the efforts and
> show where you could come in.

As I said in the beginning, I'm actually quite grateful for the
summarizing!

Best regards,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: [PATCH] Add support for shortdoc link type

[Bruno Cardoso]

On 2024-05-05, 18:01 +0700, Max Nikulin  wrote:

> I would consider explicit mention that it is related to Emacs Lisp and 
> perhaps that the origin of its name is the ~shortdoc-display-group~ user 
> command.  might be a better link.
>
> This line is rather long though I do not have a link where formatting 
> conventions are documented.

I expanded the description on `org-manual.org' and 'ORG-NEWS'.

>> + "shortdoc" link type
>> +(when (version< "27" emacs-version)
>
> Is it correct?
>
> 2a7488d42d8 2020-10-11 05:51:16 +0200 Lars Ingebrigtsen: Add support for 
> displaying short documentation for function groups
>
> git tag --contains 2a7488d42d8
> emacs-28.0.90

Fixed.

> I think, it is enough to use [^:] since next group is started from "::". 
> You may use use non-capturing group \\(?:::# ...\\) (requires update of 
> next index below) unless you are going add search code back. I am unsure 
> concerning your intentions. You dropped search code, but "#" after "::" 
> is still optional.

Thanks. I updated the regexp.

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.

> I do not have strong opinion what is better here: `user-error' (used in 
> earlier revisions) or `error'. However I do not see the point of 
> capturing original error and signalling another one if it is not 
> `user-error'.

Agreed. I replaced it with `user-error'.

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 1feb5ed60..dd4cb6cd0 100644
--- a/doc/org-manual.org
+++ 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]].
+
 
 For =file:= and =id:= links, you can additionally specify a line
 number, or a text search string, separated by =::=.  In Org files, you
@@ -3423,6 +3430,8 @@ options:
 | irc| =irc:/irc.com/#emacs/bob=  |
 | help   | =help:org-store-link=  |
 | info   | =info:org#External links=  |
+| shortdoc   | =shortdoc:text-properties= |
+|| =shortdoc:text-properties::#get-pos-property=  |
 | shell  | =shell:ls *.org=   |
 | elisp  | =elisp:(find-file "Elisp.org")= (Elisp form to evaluate)   |
 || =elisp:org-agenda= (interactive Elisp command) |
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 99dd8839c..1623873c0 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1405,6 +1405,11 @@ place the entry in the ~Misc~ category if ~TEXINFO_DIR_CATEGORY~ is missing.
 =TEXINFO_DIR_TITLE= is renamed to =TEXINFO_DIR_NAME=.
 The old name is obsolete.
 
+*** =ol.el=: Support for =shortdoc= link type
+
+Add support for storing and inserting links to =shortdoc= documentation
+groups for Emacs Lisp functions.
+
 ** New functions and changes in function arguments
 *** New optional argument =UPDATE-HEADING= for ~org-bibtex-yank~
 
diff --git a/lisp/ol.el b/lisp/ol.el
index bc9682e4a..ff0b56378 100644
--- a/lisp/ol.el
+++ 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)
+(let ((group (match-string 1 path))
+  (fn (match-string 2 path)))
+  (condition-case nil
+  (progn
+  (shortdoc-display-group group (intern-soft fn))
+  (unless (intern-soft fn)
+(re-search-forward fn nil t)))
+(user-error "Unknown shortdoc group: %s" group
+
+  (defun org-link--store-shortdoc ( _interactive?)
+"Store \"shortdoc\" type link."
+(when (eq major-mode 'shortdoc-mode)
+  (let* ((buffer (buffer-name))
+ (group (when (string-match "*Shortdoc \\(.*\\)\\*" buffer)
+  (match-string 1 buffer
+(if (and group (assoc (intern-soft group) shortdoc--groups))
+(org-link-store-props :type "shortdoc"
+  :link (format 

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

[Charles Millar]

Forgot to include that i also used the numprint package.

On 5/5/24 2:30 PM, Charles Millar wrote:
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}@@)}}}


src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results scalar 
:results replace :exports 
results]{\num[round-precision=2,round-mode=places,round-pad = 
false]{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


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

(I also tried \dUSA and \cUSA)

On the other hand this has no problem:

#+NAME: TABLE1
|22578.59 |

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


The missing zero is important - the result is supposed to be dollars and 
cents.


Org mode version 9.7-pre (release_9.6.27-1391-gba7475 @ 
/usr/local/share/org-mode/lisp/)


GNU Emacs 30.0.50 (build 100, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0) of 2024-04-27

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

[Charles Millar]

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}@@)}}}


src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results scalar 
:results replace :exports 
results]{\num[round-precision=2,round-mode=places,round-pad = 
false]{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}


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

(I also tried \dUSA and \cUSA)

On the other hand this has no problem:

#+NAME: TABLE1
|22578.59 |

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


The missing zero is important - the result is supposed to be dollars and 
cents.


Org mode version 9.7-pre (release_9.6.27-1391-gba7475 @ 
/usr/local/share/org-mode/lisp/)


GNU Emacs 30.0.50 (build 100, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, 
cairo version 1.16.0) of 2024-04-27

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

[Ihor Radchenko]

Bastien  writes:

> This seems trivial, if nobody bites I'll apply this tomorrow.

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.

And yes, it is annoying. Just not very clear how to address correctly.

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

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

[Ihor Radchenko]

Bastien  writes:

> Recent versions of Emacs complain about org-clock-save.el:
>
>   ⛔ Warning (lexical-binding): File
>   /home/bzg/.emacs.d/org-clock-save.el lacks `lexical-binding'
>   directive on its first line
>
> The attached patch should fix this.  Is it okay to add it to bugfix?

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

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

Re: [BUG] Commit a2e5685e4 introduces a regression

[Ihor Radchenko]

Bastien  writes:

> Since commit a2e5685e4 ("Do not use org-fold to hide link parts"),
> all parts of bracket links are entirely visible in agenda view.
>
> Can anyone reproduce this?

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

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

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

[Ihor Radchenko]

Bastien  writes:

> Exporting the attached document with a list of >100 items results in a
> misformed markdown list, with missing spaces at the beginning of items.
>
> Can anyone reproduce this?

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

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

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

[Berry, Charles]

Bastien,

> On May 5, 2024, at 9:17 AM, Bastien  wrote:
> 
> Exporting the attached document with a list of >100 items results in a
> misformed markdown list, with missing spaces at the beginning of items.
> 
> Can anyone reproduce this?

Yes. 

With Org mode version 9.6.6 I see that org-md-item hard codes the padding to 
indent the item 4 spaces past the start of the bullet.

Lists of 1000 items will raise an error.

Coincidentally, there was a thread last month about adding spaces *before* the 
bullet in org-md-item, but I think the effect you noted was not mentioned.

Chuck

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

[Bastien]

The attached patch silences a warning.

This seems trivial, if nobody bites I'll apply this tomorrow.

Thanks!

-- 
 Bastien
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 0c2dc27ed..3d40a02a1 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -2887,7 +2887,7 @@ list, `literal' is for the format specifier L."
   (if lispp
 	  (if (eq lispp 'literal)
 	  elements
-	(if (and (eq elements "") (not keep-empty))
+	(if (and (string= elements "") (not keep-empty))
 ;; FIXME: This branch of `if' is never used because
 ;; strings are never `eq' here.  But changing to
 ;; `equal' breaks tests.

[BUG] Commit a2e5685e4 introduces a regression

[Bastien]

Since commit a2e5685e4 ("Do not use org-fold to hide link parts"),
all parts of bracket links are entirely visible in agenda view.

Can anyone reproduce this?

-- 
 Bastien

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

[Mehmet Tekman]

Hello João and org!

Mehmet Tekman  on 29/04/2024 wrote:

>> Can you wait until Sunday for me to resolve this, and then we can
>> discuss?

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:

So, my code is hosted at =https://gitlab.com/mtekman/org-mode= and with
the exception of the =header-reform= branch, is about 1 year behind
upstream.

* Ancient History

Here we detail what some of ideas and pitfalls were. The main takeaway
message is that we want to keep all sync actions everything within
":tangle", and we want to unify mutual exclusivity and hierarchical
merging with ":results".

You're probably already familiar with all this, but if not, here goes:


*** Initial PR: `:tangle-sync' adds a sync parameter

This was the initial PR that implemented two-way syncing via a new
:tangle-sync header parameter. The work was performed in the
=ob-tangle-sync-2023= branch, specifically the commit range:
=34727abb6...2f0f54d68=, and specifically localized mainly in the file
=ob-tangle-sync.el=.

This :tangle-sync parameter described in what direction a block should
be synced: either "export", "import", "skip", or "sync".

e.g.1 :tangle filename :tangle-sync action

#+begin_src bash :tangle export_this_file.bash :tangle-sync export
  echo file and sync-action as seperate header args
#+end_src

That git branch also reworked the detangle framework in the
=ob-tangle.el= file, allowing it to detangle on a more block basis than
it was doing before.

*** New effort: Rework the existing `:tangle' to take filename and sync 
parameter

As the code developed and started impacting more of =ob-tangle.el= code
base, it was suggested that instead of creating an entirely new header
argument (which would add to the complexity of the org code base), why
shouldn't we simply compound the sync command to the existing :tangle
header?

e.g.2 :tangle filename sync-action

#+begin_src bash :tangle export_this_file.bash export
  echo file and sync-action under the same banner
#+end_src

with the implication that the last word in the :tangle string would be
a sync keyword.

This now meant that instead of working on the =ob-tangle-sync.el= and
=ob.tangle.el= files, that we would also need to start affecting the
=ob-core.el= code.

This is what commits =4b9d05d8c...HEAD= in the =ob-tangle-sync-2023=
branch attempted to do, by making use of the mutual-exclusive keyword
framework already present for :results

#+begin_src elisp
  ;; see: org-babel-common-header-args-w-values
  '(results . ((file list vector table scalar verbatim)
   (raw html latex org code pp drawer link graphics)
   (replace silent none discard append prepend)
   (output value)))
  ;;
  (tangle . ((tangle yes no :any)
 (import export skip sync))) ;; added
#+end_src

This way someone can specify mutually exclusive values in headers such
as:

e.g.3 
#+begin_src bash :results file raw replace output
  echo multiple compounding results values which are all valid
#+end_src

or, hopefully, in the case for :tangle, something like:

e.g.4:
#+begin_example
:tangle yes sync   ;; filename inherited 
:tangle no export  ;; nothing should happen
:tangle my_custom_file.sh import   ;; imports specifically from that file
#+end_example

*** New problem: `:results' and `:tangle' mutually exclusive groups are not 
alike

You may notice that the `:results' mutually exclusive values and the
`:tangle' mutually exclusive values differ on one problematic value:
":any"

#+begin_src elisp
  (tangle . ((tangle yes no :any)
 (import export skip sync)))
#+end_src

This `:any' parameter means that the first argument of the tangle header
could be of any arbitrary length and take on any value… including those
specific values that we need as the sync-action in the second argument.
Oh dear!

e.g.5:
#+begin_example
:tangle filename.sh export   ;; easily resolvable
:tangle import import;; uh... we import? and assume the filename comes 
up the hirarchy
:tangle import export;; uh... we assume they are both sync-actions but 
only last is valid?
#+end_example

And this gets even worse if we have to consider filenames with spaces:

e.g.6: 
#+begin_example
:tangle filename with spaces.sh ;; filename only, inherit sync action from 
elsewhere
:tangle filename with spaces sync   ;; Um. We sync, and assume the filename is 
"filename with spaces"?
#+end_example

*** Solution: Custom splitting tangle function

Okay, so the problems shown in examples 5 and 6 can be fixed quite
easily - you just split the whole tangle header by spaces, and test if
the last word is a valid sync-action or not.

This was implemented in the splitting function
=org-babel--handle-tangle-args= which specifically handles that header.

But once again, we see the code 

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

[Bastien]

Recent versions of Emacs complain about org-clock-save.el:

  ⛔ Warning (lexical-binding): File
  /home/bzg/.emacs.d/org-clock-save.el lacks `lexical-binding'
  directive on its first line

The attached patch should fix this.  Is it okay to add it to bugfix?

Thanks,

-- 
 Bastien
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 67feb6b35..806bc02de 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -3233,7 +3233,7 @@ The details of what will be saved are regulated by the variable
 		 org-clock-has-been-used
 		 (not (file-exists-p org-clock-persist-file
 (with-temp-file org-clock-persist-file
-  (insert (format ";; %s - %s at %s\n"
+  (insert (format ";; %s - %s at %s -*- lexical-binding: t; -*-\n"
 		  (file-name-nondirectory org-clock-persist-file)
 		  (system-name)
 		  (format-time-string (org-time-stamp-format t

[BUG] Exporting lists of >100 items to markdown

[Bastien]

Exporting the attached document with a list of >100 items results in a
misformed markdown list, with missing spaces at the beginning of items.

Can anyone reproduce this?

-- 
 Bastien


bug.org
Description: Lotus Organizer

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

[András Simonyi]

Thanks Ihor, I have pushed it to main.
best wishes,
András

On Sun, 5 May 2024 at 14:13, Ihor Radchenko  wrote:
>
> András Simonyi  writes:
>
> > there is a rather peculiar set of numeric citation styles (perhaps
> > most famously, that of Nature's) which sets citation numbers in
> > superscript -- similarly to footnote numbers, these citations should
> > not have any space between them and the previous word. The attached
> > patch checks during export whether a citation is produced by a CSL
> > style belonging to this category and removes any leading space
> > present.
>
> LGTM.
> Feel free to push.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

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

[Ihor Radchenko]

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.

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

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

[Ihor Radchenko]

András Simonyi  writes:

> there is a rather peculiar set of numeric citation styles (perhaps
> most famously, that of Nature's) which sets citation numbers in
> superscript -- similarly to footnote numbers, these citations should
> not have any space between them and the previous word. The attached
> patch checks during export whether a citation is produced by a CSL
> style belonging to this category and removes any leading space
> present.

LGTM.
Feel free to push.

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

Re: [DISCUSSION] Sorting strings in Org mode vs. system locale (was: test-org-table/sort-lines: Failing test on macOS)

[Ihor Radchenko]

Ihor Radchenko  writes:

>> The only additional consideration is that compare function should be 
>> configurable. If a user access same files from Linux and macOS then it 
>> may be really annoying to get different order of entries in agenda. For 
>> most of Linux users it is better to use more smart 
>> `string-collate-lessp'. Some care is required to sort entries obtained 
>> from multiple buffers in predictable environment (locale, case 
>> conversion table).
>
> I agree. We can introduce a new customization -
> `org-string-sort-function' that will be used across Org mode to sort
> user text.

See the attached tentative patch.
I added a customization, made everything in Org obey it, and provided
some default options for MacOS users.

>From dbc3929d8c7a26da3bf31fb52a651da68d1f733b Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Sun, 5 May 2024 14:37:52 +0300
Subject: [PATCH] org: New Org-wide custom option `org-sort-function'

* lisp/org-macs.el (org-sort-function): New customization defining how
Org mode should sort headlines, table lines, agenda lines, etc.
(org-string<):
(org-string<=):
(org-string>=):
(org-string>): Use the new customization.
(org-string<>): Add docstring.
(org-sort-function-downcase): New helper function to help users on
MacOS where `string-collate-lessp' is not reliable.
* lisp/oc-basic.el (org-cite-basic--field-less-p):
* lisp/org-agenda.el (org-cmp-category):
(org-cmp-alpha):
* lisp/org-list.el (org-sort-list):
* lisp/org-mouse.el (org-mouse-list-options-menu):
* lisp/org-table.el (org-table-sort-lines):
* lisp/org.el (org-tags-sort-function):
(org-sort-entries):
* lisp/ox-publish.el (org-publish-sitemap): Honor the new
customization.
* lisp/org-mouse.el (org-mouse-tag-menu):
(org-mouse-popup-global-menu):
* lisp/org-agenda.el (org-cmp-tag): Honor `org-tags-sort-function' and
falling back to `org-string<' if note set.
* etc/ORG-NEWS (New option controlling how Org mode sorts things
~org-sort-function~): Announce the change.

This change aims to standardize the way Org mode performs sorting of
user data.  In particular, it addresses issues with oddities of string
collation rules on MacOS and tricky language environments like
Turkish.

Link: https://orgmode.org/list/87jzleptcs.fsf@localhost
---
 etc/ORG-NEWS   | 20 ++
 lisp/oc-basic.el   |  2 +-
 lisp/org-agenda.el | 12 -
 lisp/org-list.el   |  2 +-
 lisp/org-macs.el   | 66 +-
 lisp/org-mouse.el  | 13 +
 lisp/org-table.el  |  4 +--
 lisp/org.el|  6 ++---
 lisp/ox-publish.el |  9 +++
 9 files changed, 98 insertions(+), 36 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3c597db40..af88febb1 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -710,6 +710,26 @@ any more.  Run ~org-ctags-enable~ to setup hooks and advices:
 #+end_src
 
 ** New and changed options
+*** New option controlling how Org mode sorts things ~org-sort-function~
+
+Sorting of agenda items, tables, menus, headlines, etc can now be
+controlled using a new custom option ~org-sort-function~.
+
+By default, Org mode sorts things according to the operation system
+language.  However, language sorting rules may or may not produce good
+results depending on the use case.  For example, multi-language
+documents may be sorted weirdly when sorting rules for system language
+are applied on the text written using different language.  Also, some
+operations systems (e.g. MacOS), do not provide accurate string
+sorting rules.
+
+Org mode provides 4 possible values for ~org-sort-function~:
+1. (default) Sort using system language rules.
+2. Sort using dumb string comparison. It is the most reliable option.
+3. Sort case-insensitively, making use of UTF case conversion.  This
+   may work better for mixed-language documents and on MacOS.
+4. Custom function, if the above does not fit the needs.
+
 *** =ob-latex= now uses a new option ~org-babel-latex-process-alist~ to generate png output
 
 Previously, =ob-latex= used ~org-preview-latex-default-process~ from
diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index 8959bb065..6e3142fa1 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -680,7 +680,7 @@ (defun org-cite-basic--field-less-p (field info)
 INFO is the export state, as a property list."
   (and field
(lambda (a b)
- (string-collate-lessp
+ (org-string<
   (org-cite-basic--get-field field a info 'raw)
   (org-cite-basic--get-field field b info 'raw)
   nil t
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 93c6acef2..05d2f94c0 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7489,8 +7489,8 @@ (defsubst org-cmp-category (a b)
   "Compare the string values of categories of strings A and B."
   (let ((ca (or (get-text-property (1- (length a)) 'org-category a) ""))
 	(cb (or (get-text-property (1- (length b)) 'org-category b) "")))
-(cond ((string-lessp ca cb) -1)
-	  

Re: [PATCH] Add support for shortdoc link type

[Max Nikulin]

On 05/05/2024 00:33, Bruno Cardoso wrote:


I updated the patch to use the optional function argument instead.


Thanks


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

+
+Link to short documentation summary for a function group.  For more 
information, see [[info:emacs#Name Help][Help by Command or Variable Name]].


I would consider explicit mention that it is related to Emacs Lisp and 
perhaps that the origin of its name is the ~shortdoc-display-group~ user 
command.  might be a better link.


This line is rather long though I do not have a link where formatting 
conventions are documented.



+++ b/etc/ORG-NEWS
@@ -1369,6 +1369,10 @@ place the entry in the ~Misc~ category if 
~TEXINFO_DIR_CATEGORY~ is missing.
 =TEXINFO_DIR_TITLE= is renamed to =TEXINFO_DIR_NAME=.
 The old name is obsolete.
 
+*** =ol.el=: Support for =shortdoc= link type

+
+Add support for storing and inserting links to =shortdoc= groups.


Again I am unsure that it is clear to all readers.


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

+(when (version< "27" emacs-version)


Is it correct?

2a7488d42d8 2020-10-11 05:51:16 +0200 Lars Ingebrigtsen: Add support for 
displaying short documentation for function groups


git tag --contains 2a7488d42d8
emacs-28.0.90


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


I think, it is enough to use [^:] since next group is started from "::". 
You may use use non-capturing group \\(?:::# ...\\) (requires update of 
next index below) unless you are going add search code back. I am unsure 
concerning your intentions. You dropped search code, but "#" after "::" 
is still optional.



+(let ((group (match-string 1 path))
+  (fn (match-string 3 path)))
+  (condition-case nil
+  (shortdoc-display-group group (intern-soft fn))
+(error (message "Unknown shortdoc group: %s" group)


I do not have strong opinion what is better here: `user-error' (used in 
earlier revisions) or `error'. However I do not see the point of 
capturing original error and signalling another one if it is not 
`user-error'.

Re: [PATCH] Run latex more than once for LaTeX src block evaluation

[Ihor Radchenko]

Ihor Radchenko  writes:

> (setq org-preview-latex-default-process 'dvisvgm)
>
> #+begin_src latex :results file link :file test.png
> x^2
> #+end_src
>
> #+RESULTS:
> [[attachment:test.png]]
>
> ^ This is actually an svg image, renamed to "test.png".
>
> So, it makes sense for `org-babel-execute:latex' to override
> `org-preview-latex-default-process' temporarily, to something actually
> generating .png file.

Now done on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=43ba00b2b

I introduced a new custom option org-babel-latex-process-alist to
control ob-latex behaviour specifically.

For now, it is preserving the previous process settings. No repetitive
latex runs.

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

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

[András Simonyi]

Dear All,

there is a rather peculiar set of numeric citation styles (perhaps
most famously, that of Nature's) which sets citation numbers in
superscript -- similarly to footnote numbers, these citations should
not have any space between them and the previous word. The attached
patch checks during export whether a citation is produced by a CSL
style belonging to this category and removes any leading space
present.

Best wishes,
András
From fe331b9486d4bac31a559067c565b30474246cea Mon Sep 17 00:00:00 2001
From: Andras Simonyi 
Date: Sun, 5 May 2024 11:07:45 +0200
Subject: [PATCH] oc-csl: Remove spaces before citations in superscript

* lisp/oc-csl.el (org-cite-csl--create-structure): Remove spaces before citation
if it is in superscript.
(org-cite-csl--style-cite-superscript-p): New function to check whether the used
CSL style produces citations in superscript.
---
 lisp/oc-csl.el | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index becdaed81..9bbe5e29d 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -134,6 +134,7 @@
 (declare-function citeproc-render-bib "ext:citeproc")
 (declare-function citeproc-hash-itemgetter-from-any "ext:citeproc")
 (declare-function citeproc-add-subbib-filters "ext:citeproc")
+(declare-function citeproc-style-cite-superscript-p "ext:citeproc")
 
 (declare-function org-element-interpret-data "org-element" (data))
 (declare-function org-element-map "org-element" (data types fun  info first-match no-recursion with-affiliated))
@@ -435,6 +436,13 @@ INFO is the export state, as a property list."
(citeproc-proc-style
 (org-cite-csl--processor info
 
+(defun org-cite-csl--style-cite-superscript-p (info)
+  "Non-nil when bibliography style produces citations in superscript.
+INFO is the export state, as a property list."
+  (citeproc-style-cite-superscript-p
+   (citeproc-proc-style
+(org-cite-csl--processor info
+
 (defun org-cite-csl--nocite-p (citation info)
   "Non-nil when CITATION object's style is nocite.
 INFO is the export state, as a property list."
@@ -681,6 +689,9 @@ INFO is the export state, as a property list."
 (when (and (not footnote) (org-cite-csl--note-style-p info))
   (org-cite-adjust-note citation info)
   (setq footnote (org-cite-wrap-citation citation info)))
+;; Remove white space before CITATION when it is in superscript.
+(when (org-cite-csl--style-cite-superscript-p info)
+  (org-cite--set-previous-post-blank citation 0 info))
 ;; Return structure.
 (apply #'citeproc-citation-create
`(:note-index
-- 
2.34.1