Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings Bastien.

Bastien  writes:

>> Bastien, ob-asymptote is still a part of org-contrib [1].  Should we
>> just go ahead and change the maintainer now?
>>
>> [1] https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/ob-asymptote.el
>
> Yes, done.  Thanks Jarmo for taking over the maintenance!
>
> Feel free to package ob-asymptote.el as a GNU ELPA package so that it
> gets more users and let me know when this is done so that I can remove
> it from org-contrib.

Will do so.

All the best,

Jarmo

Re: Fwd: org-priority: allow customization of priority indicator

[Ihor Radchenko]

Ihor Radchenko  writes:

> Thanks for the patch!
>
> In general, we do not intend to support changing basic elements of Org
> syntax. So, things like your _p may remain buggy because they clash with
> underscore emphasis.
> ...
> More comments below.
> ...

[I am following this up as more than one month passed since the last
activity in the thread]

Have you had a chance to look into my comments?
If you have any objections or issues with addressing them, feel free to
reply.

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

Re: [PATCH] LSP support in org-src buffers

[Ihor Radchenko]

[Just following this up as more than one month have passed since the last
activity in this thread.]

Karthic, have you had a chance to work on this further?

If you stumbled upon difficulties, feel free to ask anything. We can try
to help.

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

Re: test-org-table/sort-lines: Failing test on macOS

[Ihor Radchenko]

Max Nikulin  writes:

>> However, I am not sure if ignoring locale is something we really want.
>> WDYT?
>
> I think we should keep `string-collate-lessp' in the 
> `org-table-sort-lines' implementation. Users expect sorting accordingly 
> to their locales. However it is better to add a warning to 
> `org-table-sort-lines' docstring and to the manual that caseless sort 
> depends on its implementation in libc, so currently it does not work in 
> clang/llvm and so e.g. on MacOS.

Sounds reasonable.

Note that not only `org-table-sort-lines' is using
`string-collate-lessp'. The full list of functions potentially affected
by libc sorting is:

1. Bibliography order in `org-cite-basic-export-bibliography'
   (via org-cite-basic--sort-keys -> org-cite-basic--field-less-p)
2. `org-sort-list'
3. `org-table-sort-lines'
4. `org-set-tags' (tag order), when `org-tags-sort-function' is set to
   "Alphabetical" or "Reverse alphabetical".
5. `org-sort-entries'
6. Agenda sorting, when alphabetical sorting is involved
7. `org-map-entries'

I am not 100% sure where we should add the information to
docstring/manual and where we should not.

> Concerning the test, I would split the current testcase into 2 parts 
> depending on WITH-CASE argument, check if caseless collation is 
> available and skip the related test otherwise.

How can we check the availability?

> As to the thread linked to the bug report 
> https://lists.gnu.org/archive/html/emacs-devel/2022-07/msg00940.html 
> "case-insensitive string comparison." Tue, 19 Jul 2022 13:27:50 -0400, 
> there is a link
> https://stackoverflow.com/questions/319426/how-do-i-do-a-case-insensitive-string-comparison
> unrelated to the issue, but comments and answers there describe a lot of 
> pitfalls and explain why string comparison ignoring case is not trivial. 
> (It is a Sisyphean task in some sense, I like the comment on 3 sigmas.)

Indeed. Also, see https://nullprogram.com/blog/2014/06/13/. However,
what we are concerned about here is consistency. Not the pitfalls per
se.

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

Re: [PATCH] Re: Update Org to MathJax 3

[Ihor Radchenko]

Bastien Guerry  writes:

>> Or should we do something in
>> addition to announce backwards-incompatible change?
>
> I suggest to make this change visible on update.orgmode.org by sending
> an announcement to the list using X-Woof-Change: 9.6 as a header.

Done. Hopefully it is going to work:
https://orgmode.org/list/87o7t1ja2a.fsf@localhost

Rudolf, I have applied your patch onto main with amendments. I have
replaced "MathJax 4" instances with "MathJax 3". I guess it was a typo.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=62e1513b5

Thanks a lot of the important contribution!

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

[ANN] Dropping MathJax 2 support in Org 9.6

[Ihor Radchenko]

Dear Orgers,

We are moving away from the outdated MathJax 2 to MathJax 3 in Org export.
This change is a breaking change as MathJax 2 is not compatible with
MathJax 3+.

We have done all we could to not break the existing usage. However, some
users might still be affected. In particular, people who customized
`org-html-mathjax-options' to point to a custom MathJax 'path to MathJax
2 will experience breakage. Other users, including people who customized
other MathJax options (not 'path), will _not_ be affected as Org will
auto-convert MathJax 2 style options to MathJax 3.

See more context and the discussion in
https://list.orgmode.org/orgmode/m2a667n4ax@me.com/

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

-
Below is the relevant ORG-NEWS entry:

Org now uses MathJax 3 by default instead of MathJax 2.  During HTML
exports, Org automatically converts all legacy MathJax 2 options to
the corresponding MathJax 3+ options, except for the ~path~ option in
which now /must/ point to a file containing MathJax version 3 or
later.  The new Org does /not/ work with the legacy MathJax 2.

Further, if you need to use a non-default ~font~ or ~linebreaks~ (now
~overflow~), then the ~path~ must point to MathJax 3 or later.

See the updated ~org-html-mathjax-options~ for more details.

MathJax 3, a ground-up rewrite of MathJax 2 came out in 2019.  The new
version brings modularity, better and faster rendering, improved LaTeX
support, and more.

For more information about new features, see:

https://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.html
https://docs.mathjax.org/en/latest/upgrading/whats-new-3.1.html
https://docs.mathjax.org/en/latest/upgrading/whats-new-3.2.html

MathJax 3 comes with useful extensions.  For instance, you can typeset
calculus with the ~physics~ extension or chemistry with the ~mhchem~
extension, like in LaTeX.

Note that the Org manual does not discuss loading of MathJax
extensions via ~+HTML_MATHJAX~ anymore.  It has never worked anyway.
To actually load extensions, consult the official documentation:

https://docs.mathjax.org/en/latest/input/tex/extensions.html

Lastly, MathJax 3 changed the default JavaScript content delivery
network (CDN) provider from CloudFlare to jsDelivr.  You can find the
new terms of service, including the privacy policy, at
https://www.jsdelivr.com/terms.

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

Re: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortman

[Ihor Radchenko]

Daniel Ortmann  writes:

> Please see attached which has the following code which reproduces the issue:
>
> #+begin_src sh :shebang #!/bin/bash :results none
> for (( i=1500 ; i>0 ; i-=1 ))
> do
>      head -c 6 /dev/urandom | uuencode -m -
> done |
> tee /dev/null
> #+end_src

Thanks!

I was able to reproduce. However, this particular error appears to be
intentional.

`org-table-convert-region-max-lines' has been introduced explicitly for
such scenarios because table conversion may take significant time when
the output is large.

I think we can do 2 things to address the problem:

1. Tweak the error wording. Probably to something like
   Babel result processing: Region is longer than 
`org-table-convert-region-max-lines' (%s) lines; not converting

2. Maybe introduce something like :results ignore to discard the results
   completely.

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

Re: Problems running ob-julia tests (testing/test-ob-julia.el)

[Ihor Radchenko]

Ihor Radchenko  writes:

> Pedro Bruel  writes:
>
>> I believe the ob-julia version we have on orgmode does not support sessions.
>
> There is definitely session support in lisp/ob-julia.el. ob-julia does
> define org-babel-load-session:julia and org-babel-prep-session:julia.
>
> Session support is even tested in testing/lisp/test-ob-julia.el
> For example, in test-ob-julia/session-multiline.
>
> ob-julia documentation also declares full session support:
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-julia.html

Pedro, have you had a chance to look into this further?
(Bumping this as one month has passed since the last reply).

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

Re: [PATCH] updating manual: visibility of ARCHIVEd subtrees

[Bastien]

Hi Giovanni,

Giovanni Ridolfi  writes:

> please find attached a patch updating the documentation file:

Sorry we overlooked this patch, thanks for it!

Applied as 225d58341 in the bugfix branch.

Best,

-- 
 Bastien

Re: Patch links babel graphviz-dot

[Bastien]

Hi Nicolas,

Nicolas Graves via "General discussions about Org-mode."
 writes:

> Patch to update some links.

Applied to worg as 9a082fc3, thanks.

-- 
 Bastien

Re: test-org-table/sort-lines: Failing test on macOS

[Max Nikulin]

On 20/11/2022 11:18, Ihor Radchenko wrote:

Max Nikulin writes:

  From my point of view it is a reason to file an Emacs bug because I get

  (string-collate-lessp "a" "B" "C" t) ; => t


See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59275


According to the discussion on debbugs, it looks like we can use
`compare-strings' instead. It will be independent of the system locale
and always follow Unicode rules.

However, I am not sure if ignoring locale is something we really want.
WDYT?


I think we should keep `string-collate-lessp' in the 
`org-table-sort-lines' implementation. Users expect sorting accordingly 
to their locales. However it is better to add a warning to 
`org-table-sort-lines' docstring and to the manual that caseless sort 
depends on its implementation in libc, so currently it does not work in 
clang/llvm and so e.g. on MacOS.


Concerning the test, I would split the current testcase into 2 parts 
depending on WITH-CASE argument, check if caseless collation is 
available and skip the related test otherwise.


As to the thread linked to the bug report 
https://lists.gnu.org/archive/html/emacs-devel/2022-07/msg00940.html 
"case-insensitive string comparison." Tue, 19 Jul 2022 13:27:50 -0400, 
there is a link

https://stackoverflow.com/questions/319426/how-do-i-do-a-case-insensitive-string-comparison
unrelated to the issue, but comments and answers there describe a lot of 
pitfalls and explain why string comparison ignoring case is not trivial. 
(It is a Sisyphean task in some sense, I like the comment on 3 sigmas.)