Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

2024-02-19 Thread Ihor Radchenko
Matt  writes:

>  > Note that we already have a WIP an asynchronous API in the works.
>  > Check out `org-async-call' in
>  > https://code.tecosaur.net/tec/org-mode/src/branch/dev/lisp/org-macs.el#L377
>  > If possible, we should reuse it.
>
> :O
>
> - What's the status? 

Finalizing.

> - Anything I could help with?

Check https://github.com/tecosaur/org-latex-preview-todos/issues/

> - Are there any notes or supplements that go along with it?

Docstring should detail the API.

>> I have several general questions:
>>
>> - what if append/prepend to result asynchronously?
>> - what if we replace the result, call async evaluation two times, and they 
>> arrive in opposite order (first called is calculated after the second)?
>> - on failure, Org babel sometimes uses ~org-babel-eval-error-notify~. How 
>> will it interact with asynchronous evaluation? What if we have multiple 
>> simultaneously arriving error notifications?
>> Example: try running
>> #+begin_src bash
>> idontexist
>> #+end_src
>
> Are these open questions for the `org-async-call' implementation?

No. These are about the patch. And have nothing to do with
`org-async-call', which is just a way to call and queue async processes.
`org-async-call' was written for async latex preview, but its interface
should be generic enough to be reused for babel.

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



Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

2024-02-19 Thread Matt
  On Mon, 19 Feb 2024 01:31:42 +0100  Jack Kamm  wrote --- 

 > I don't remember the details, but my past self [1] thought it would be
 > good to find a way to replace `process-file' with `make-process' in
 > `org-babel--shell-command-on-region' or `org-babel-eval', and it seems
 > you are thinking along those lines with `my-org-babel-eval-async'. Hope
 > you're able to make progress on this and get the improvements into
 > ob-eval.el eventually.
 > 
 > [1] https://list.orgmode.org/871rczg7bi@gmail.com/#t

AFAIK, aside from appending "&", =make-process= is the only way.  It would 
probably make sense to continue using =shell= though.  If I understand 
correctly, you (and others) jump between the Org buffer block and the comint 
buffer?

  On Mon, 19 Feb 2024 10:03:36 +0100  Ihor Radchenko  wrote --- 

 > Note that we already have a WIP an asynchronous API in the works.
 > Check out `org-async-call' in
 > https://code.tecosaur.net/tec/org-mode/src/branch/dev/lisp/org-macs.el#L377
 > If possible, we should reuse it.

:O

- What's the status? 
- Anything I could help with?  
- Are there any notes or supplements that go along with it?

> I have several general questions:
>
> - what if append/prepend to result asynchronously?
> - what if we replace the result, call async evaluation two times, and they 
> arrive in opposite order (first called is calculated after the second)?
> - on failure, Org babel sometimes uses ~org-babel-eval-error-notify~. How 
> will it interact with asynchronous evaluation? What if we have multiple 
> simultaneously arriving error notifications?
> Example: try running
> #+begin_src bash
> idontexist
> #+end_src

Are these open questions for the `org-async-call' implementation?

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode




Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax?

2024-02-19 Thread Ihor Radchenko
"Fraga, Eric"  writes:

> On Saturday, 17 Feb 2024 at 14:06, Ihor Radchenko wrote:
>> Inconsistent with LaTeX syntax, Org mode not only allows
>> x^{superscript}, but also x^(superscript) with round braces used for
>> grouping.
>
> Inconsistent with LaTeX is not a sufficient reason for removing this, in
> my opinion.  Org has /dwim/ elements which make it easier to write some
> expressions than in LaTeX.  Another example is ~x^-1~ which works as I
> want but would make no sense in LaTeX (where only the "-" would be
> superscripted, not the 1).

Good point.
Although, do note that unlike x^word, x^(some text) is not documented.
Moreover, options like ^:{} create an impression that only curly braces
are accepted.

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



Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax?

2024-02-19 Thread Fraga, Eric
On Saturday, 17 Feb 2024 at 14:06, Ihor Radchenko wrote:
> Inconsistent with LaTeX syntax, Org mode not only allows
> x^{superscript}, but also x^(superscript) with round braces used for
> grouping.

Inconsistent with LaTeX is not a sufficient reason for removing this, in
my opinion.  Org has /dwim/ elements which make it easier to write some
expressions than in LaTeX.  Another example is ~x^-1~ which works as I
want but would make no sense in LaTeX (where only the "-" would be
superscripted, not the 1).

-- 
: Eric S Fraga, with org release_9.6.18-1158-g8e2ed4 in Emacs 30.0.50


Re: Disable time messages from org-persist

2024-02-19 Thread Colin Baxter
> Ihor Radchenko  writes:

> Colin Baxter  writes:
>> Ho do I disable messages from org-persist telling me how long it
>> took to write to gc-lock.eld? For example,
>> 
>> --8<---cut here---start->8---
>> org-persist: Writing to "~/path/to/org-persist/gc-lock.eld" took
>> 3.08 sec --8<---cut
>> here---end--->8---
>> 
>> I find them a distraction and the information is of no use to me.

> You can set `org-persist--report-time' to nil.

Thank you.



Re: set italian language in LaTeX export

2024-02-19 Thread Juan Manuel Macías
Luca Ferrari writes:

>> #+language:it
>> #+LaTeX_Header: \usepackage[AUTO]{babel}
>>
>
> Thanks, this solved the problem. Out of curiosity, why is not org-mode
> adding it automatically whenever a #+language setting is present?
> I'm just curious because it seems that, as an example, open-office
> exporting understands the language.

Hi, Luca. You may be interested in taking a look at this thread, where
this problem and other related issues such as fallback fonts in LaTeX
export are discussed:

https://list.orgmode.org/?t=20230830082719

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía




Re: footnotes & #+STARTUP:

2024-02-19 Thread Sharon Kimble
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ihor Radchenko  writes:

> Sharon Kimble  writes:
>
>> For various reasons I've recently changed my theme from a home-made one to 
>> 'naquadah' which seems to have some problem in that it forces all footnotes 
>> into the bottom of the file. How can I revert it back to my wanted inline, 
>> of this
>>   format `[fn:3]` and then just above the next heading `[fn:3] lorem ipso 
>> ductem.` I've tried setting this `#+startup: fninline` but it only allows 
>> this `[fn:450:Blind Io]`.
>
> There is no way that /theme/ changes how Org mode inserts footnotes.
> If that is the case, such theme is doing what it is not supposed to do.
>
> What is more likely is that you accidentally changed
> `org-footnote-section' value.
>
>> Second question, is it possible to 'nest' startups like below but into just 
>> one line, please?
>>
>> =
>> #+startup: showeverything
>> #+startup: fninline
>> #+startup: fnadjust
>> #+startup: noinlineimages
>> =
>
> #+startup: showeverything fninline fnadjust noinlineimages

Thanks for replying.

I've debugged my theme and got it working again, and footnotes have now been 
restored to their particular normal place. With regard to 
'org-footnote-section' I've set it to 'nil' on 2020-04-14. Org-footnote-section 
does not appear in
  my theme!

And that `#+STARTUP:' line is now being tested on my current working documents.

Thanks
  Sharon.  
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 12.4, fluxbox 1.3.7, emacs 30.0.50, org 9.7-pre 
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmXTZXcdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1u+Gg/+MlqO22P037PhTldP
sIWpHRmNT2P6YdaJUrRCYCYBRqcic6QZK2g8Yv5yvm9w0wskGuCsEP0TeQOtgx0A
wpEJJLrPuhP9rAGsAesZxIOZqTFP3G6FslcLSXL7RBli4PSjkNqRTb6Hk5SGad80
Kqg+HOPzoDsfKpv3SfWoaAJmBmDqKIkhJjUlSEbhdWYtJbVSG7jbaNT2+Z8+F5r2
i0XdogtlKpCWQG36MusDg3dnk1tXBullyjLyS1UEpKiHRxnYSWKFE/Qz5Wwshbqf
8ArB+PQ541RVWh3iYvYC5Ozop9ftcXhKbodvJAl5Z3/RCOALisE4MTsd7ixuQLjC
LNQxrUqRlEvpkskY2XSMf4eHP3p2axhppL4jH4dYKBu+//VaCjzWfnwWcyFcoPK3
hNeGXhMuOzmFuShnniiSFA2hNeeX8mJUzNakjd8mWO7R8EFVnyf0aVxYPHTaaVNp
JQgqJL/OLk7VCt38sQe4JtGwk2tAEN40vwR6Ek7MbnsSr9jmvdpzfkDGShmkbKqi
NfTvy6d3Skxg6kWfdYqRsHak3p+AY7TXNYRpzJe1RZUxpc6jY68gOmx+szoBbaSo
2s1cUJi2uSZZjPLuWUEficrZSSkX15ZtLZ3fMcVcH+H/+7hiy7Bmw58y1kT4SjE8
PDZZYyuIYgr8PNb5MpecFvJrDq0=
=1LAs
-END PGP SIGNATURE-



Re: set italian language in LaTeX export

2024-02-19 Thread Luca Ferrari
O> You must load the babel package with the AUTO option:
>
> #+language:it
> #+LaTeX_Header: \usepackage[AUTO]{babel}
>

Thanks, this solved the problem. Out of curiosity, why is not org-mode
adding it automatically whenever a #+language setting is present?
I'm just curious because it seems that, as an example, open-office
exporting understands the language.

Thanks,
Luca



Re: Disable time messages from org-persist

2024-02-19 Thread Ihor Radchenko
Colin Baxter  writes:

> Ho do I disable messages from org-persist telling me how long it took to
> write to gc-lock.eld? For example,
>
> --8<---cut here---start->8---
> org-persist: Writing to "~/path/to/org-persist/gc-lock.eld" took 3.08 sec
> --8<---cut here---end--->8---
>
> I find them a distraction and the information is of no use to me.

You can set `org-persist--report-time' to nil.

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



Disable time messages from org-persist

2024-02-19 Thread Colin Baxter
Ho do I disable messages from org-persist telling me how long it took to
write to gc-lock.eld? For example,

--8<---cut here---start->8---
org-persist: Writing to "~/path/to/org-persist/gc-lock.eld" took 3.08 sec
--8<---cut here---end--->8---

I find them a distraction and the information is of no use to me.

Colin Baxter.




Re: [patch] Add two new header args to LaTeX block

2024-02-19 Thread Juan Manuel Macías
Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>>> new header arguments.
>>
>> org-create-formula-image inserts LaTeX code:
>
> `org-create-formula-image' will be obsoleted after Timothy merges his
> latex preview branch. If the new implementation turns out to be not
> flexible enough, we can always refactor it further to meet ob-latex
> needs.

In that case, I think this patch could be considered canceled.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía





Re: [PATCH] org-babel-demarcate-block: split using element API

2024-02-19 Thread gerard . vermeulen




On 19.02.2024 10:46, Ihor Radchenko wrote:

Ihor Radchenko  writes:


gerard.vermeu...@posteo.net writes:

I think that I have improved my region marking code by using 
""

in the temp-text as a start. Then, I only have to find where to set
mark,
and eventually exchange point and mark.


Still failing on my side (when running tests non-interactively from
command line). To fix the problem, please use the approach from
`test-org-list/indent-item':

(transient-mark-mode 1)
(push-mark (point) t t)

Instead of (set-mark-command nil)


Gerard, may I know if you had a chance to look into my comments?


I think that I have addressed this particular comment.

However, I am confused by your comments concerning this example
#+begin_src emacs-lisp
  '(1 2 3)
  '(1 2 3)
#+end_src
since it breaks my patch as well as main in the sense that such examples
can generate three blocks with invalid code.
I think there is in general no way to protect a user against bad 
selections

for splitting by demarcation.

Secondly, I see (saw) sometimes Org emitting warnings with backtraces
starting from my patch.  I think the warning may be due either to a 
mistake

on my side or a bug in Org, but I am not sure.

Regards -- Gerard







Re: [BUG] org :extend property bugfix does not work [9.7 (9.7-??-388ba5b @ /home/st/.config/emacs/.local/straight/build-30.0.50/org/)]

2024-02-19 Thread Ihor Radchenko
StrawberryTea  writes:

> In the following Org file which I have copypasted verbatim, the current
> workaround for bug#65896 made in
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=793cdbea68ae9f6eb4270315df6ff3419c3d8c20
> does not work...
>
> Copy-pasted Org mode file:
>...

It would help if you provided a reproducer that demonstrates the problem
starting from emacs -Q. Otherwise, it is very hard to debug the problem
- by default, Org mode does not use :extend faces in the provided
example file.

See https://orgmode.org/manual/Feedback.html#Feedback

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



Re: footnotes & #+STARTUP:

2024-02-19 Thread Ihor Radchenko
Sharon Kimble  writes:

> For various reasons I've recently changed my theme from a home-made one to 
> 'naquadah' which seems to have some problem in that it forces all footnotes 
> into the bottom of the file. How can I revert it back to my wanted inline, of 
> this
>   format `[fn:3]` and then just above the next heading `[fn:3] lorem ipso 
> ductem.` I've tried setting this `#+startup: fninline` but it only allows 
> this `[fn:450:Blind Io]`.

There is no way that /theme/ changes how Org mode inserts footnotes.
If that is the case, such theme is doing what it is not supposed to do.

What is more likely is that you accidentally changed
`org-footnote-section' value.

> Second question, is it possible to 'nest' startups like below but into just 
> one line, please?
>
> =
> #+startup: showeverything
> #+startup: fninline
> #+startup: fnadjust
> #+startup: noinlineimages
> =

#+startup: showeverything fninline fnadjust noinlineimages

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



Re: [FR] org-num-mode inverse defaults

2024-02-19 Thread Ihor Radchenko
Maske  writes:

> My config, not working yet, everything is numbered with org-num-mode:
>
> (setq org-num-skip-unnumbered 't)
>
> (setq org-use-property-inheritance '("UNNUMBERED"))
>
> (setq org-global-properties '(("DIR" . "data/") ("UNNUMBERED" . "t")))

Note that you need development version of Org mode for this.
On my side, your settings appear to work.

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



Re: [BUG] Org parser error Invalid search bound (wrong side of point) [9.7 (9.7-??-7a6bb0904 @ /Users/dougheadley/.config/emacs/.local/straight/build-29.2/org/)]

2024-02-19 Thread Ihor Radchenko
Doug Headley via "General discussions about Org-mode."
 writes:

> using org-ai seemed to cause this bug.  I wouldn't have recieved this 
> error otherwise.
>
> Never filed a bug report before.  Please ignore if this seems incomplete.

Thanks for reporting!
We have seen similar bugs reported for Org mode 9.6.X versions, but not
on main (9.7-pre).
May you please double check that you are using the latest main branch of
Org mode? version 9.7 is fishy - current development branch of Org mode
uses "9.7-pre" as version.

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



Re: [patch] Add two new header args to LaTeX block

2024-02-19 Thread Ihor Radchenko
Juan Manuel Macías  writes:

>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>> new header arguments.
>
> org-create-formula-image inserts LaTeX code:

`org-create-formula-image' will be obsoleted after Timothy merges his
latex preview branch. If the new implementation turns out to be not
flexible enough, we can always refactor it further to meet ob-latex
needs.

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



Re: set italian language in LaTeX export

2024-02-19 Thread Juan Manuel Macías
Luca Ferrari writes:

> #+language: it
>
> and I correctly got in the LaTeX buffer something like:
>
> pdflang={Italian}}
>
> but not something like:
>
> \usepackage[italian]{babel}

You must load the babel package with the AUTO option:

#+language:it
#+LaTeX_Header: \usepackage[AUTO]{babel}

(see 'LaTeX header and sectioning structure' in the Org Manual)

Best regards,

Juan Manuel

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía




Re: [BUG] Prompt appears in async shell results

2024-02-19 Thread Ihor Radchenko
Matt  writes:

> - Split prompt filtering and input echoing into two filters
>   + this seems to imply a =-hook= or =-functions= type implementation

Not necessarily. You may just split the filter into (1) prompt
remover; (2) body remover. The filter does not need to interact with
comint buffer and may simply be provided a regexp/string to be removed.
Then, the caller will be responsible to supply prompt regexp/body.

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



Re: dynamic blocks orgmode manpage

2024-02-19 Thread Ihor Radchenko
chris  writes:

> Now, after running =C-c C-c= on the line below, trying =M-x org-dynamic-block-
> insert-dblock= will result in the error: =funcall-interactively: Wrong type 
> argument: commandp, org-dblock-write:block-update-time=.
>
> #+begin_src emacs-lisp
>   (org-dynamic-block-define "block update time" #'org-dblock-write:block-
> update-time)
> #+end_src

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

Note that function provided in `org-dynamic-block-define' must accept
zero arguments. It is generally not the same function with
org-dblock-write:foo.

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



set italian language in LaTeX export

2024-02-19 Thread Luca Ferrari
Hi all,
this has to be trivial, but it is not working on my system (Emacs
28.2, Org 9.5.5): I set in my document
#+language: it

and I correctly got in the LaTeX buffer something like:

pdflang={Italian}}

but not something like:

\usepackage[italian]{babel}

and therefore the generation of the PDF uses English hyphenation, not
the correct italian one.
On my system I've installed the package texlive-lang-italian and if I
add the babel package line above by hand, I'm able to produce the
italianized PDF.
What am I missing here?

Thanks,
Luca



Re: detangling with babel :var header entries

2024-02-19 Thread Fraga, Eric
On Saturday, 17 Feb 2024 at 16:18, Ihor Radchenko wrote:
> I also have no idea. I'm afraid that detangling can only be used in
> simple cases as it is implemented now.

I had the feeling this would be the case.  No worries.  Thank you.

-- 
: Eric S Fraga, with org release_9.6.18-1158-g8e2ed4 in Emacs 30.0.50


Re: [PATCH] org-babel-demarcate-block: split using element API

2024-02-19 Thread Ihor Radchenko
Ihor Radchenko  writes:

> gerard.vermeu...@posteo.net writes:
>
>>> I think that I have improved my region marking code by using ""
>>> in the temp-text as a start. Then, I only have to find where to set 
>>> mark,
>>> and eventually exchange point and mark.
>
> Still failing on my side (when running tests non-interactively from
> command line). To fix the problem, please use the approach from
> `test-org-list/indent-item':
>
>   (transient-mark-mode 1)
>   (push-mark (point) t t)
>
> Instead of (set-mark-command nil)

Gerard, may I know if you had a chance to look into my comments?

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



Re: [BUG] beamer export

2024-02-19 Thread Ihor Radchenko
Leo Butler  writes:

>> What about not adding BEAMER_FRAME, but instead adding org-lint checker
>> that will detect when frame text contains the problematic \end{orgframe}?
>
> Ok, thanks for your feedback. I have modified the patch along the lines
> you suggested. It is attached.

Thanks!
It looks like you left over some parts from the previous patch version.

> (org-beamer--format-frame): Introduce the new property, :BEAMER_FRAME.

... like this.

> (org-beamer--frame-environments): New variable and function.  The
> variable holds a list of names of frame environments found while
> formatting frames.  The function generates the LaTeX code to define
> each new frame environment.
> (org-beamer-template): Add a call to `org-beamer--frame-environments'
> to insert the environment definitions into the beamer document.

And since we only have a single alternative environment in this version
of the patch, `org-beamer--frame-environments' does not appear to be
necessary.

> +(defcustom org-beamer-frame-environment "orgframe"
> +  "Name of the beamer frame environment."
> +  :group 'org-export-beamer
> +  :type '(string :tag "Beamer frame"))

It would be nice to provide a mode detailed explanation about the
purpose of this custom option.

> +(defun org-lint-beamer-frame (ast)
> +  "Check for occurrences of begin or end frame."
> +  (org-with-point-at ast
> +(goto-char (point-min))
> +(let (result)
> +  (while (re-search-forward
> +  (concat "\\(begin\\|end\\){" org-beamer-frame-environment 
> "}") nil t)
> +(push (list (match-beginning 0) "Beamer frame name may cause error 
> when exporting.") result))
> +  result)))

... and to link this org-lint warning to the
`org-beamer-frame-environment' docstring.

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



Re: Radio links work only in small numbers

2024-02-19 Thread Ihor Radchenko
Rudolf Adamkovič  writes:

> All [[link]]s in my notes perfectly match LEVEL-1 headings, so I figured
> that I may as well ask Org to make links for me.  So, I replaced all the
> ~4000 headings in my notes with radio <<>>.  However, Org now
> errors out with "Regular expression too big".
>
> Does anyone know how to overcome this limitation?  Or, perhaps someone
> has a patch in works that fixes it?  If so, please let me know!

May you try the attached patch?
>From e01f5a56fff7b3a4c9ad016802a4da6a01053e22 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Mon, 19 Feb 2024 12:19:34 +0300
Subject: [PATCH] Work around regexp size limitation for large number of link
 targets
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ol.el (org-target-link-regexp-limit): New constant defining
maximum regexp limit where `org-target-link-regexp' is still safe to
use without triggering "Regexp too long" error.
(org-target-link-regexps): New variable holding a series of shorter
regexps to be used instead of too long single
`org-target-link-regexp'.
(org--re-list-search-forward): New function like `re-search-forward',
but accepting a list of regexps.
(org--re-list-looking-at): New function like `looking-at', but
accepting a list of regexps.
(org-update-radio-target-regexp): When `org-target-link-regexp' is too
long, set `org-target-link-regexps', partitioning the link target list
into smaller regexps.
* lisp/org-element.el (org-element-link-parser):
(org-element--object-lex):
* lisp/org.el (org-activate-target-links): Use
`org--re-list-search-forward' and `org--re-list-looking-at' when
`org-target-link-regexps' is non-nil.
* testing/lisp/test-org-element.el (test-org-element/link-parser): Add
tests.

Reported-by: Rudolf Adamkovič 
Link: https://list.orgmode.org/orgmode/m2lenax5m6@me.com/
---
 lisp/ol.el   | 68 ++--
 lisp/org-element.el  | 16 ++--
 lisp/org.el  |  4 +-
 testing/lisp/test-org-element.el | 17 
 4 files changed, 97 insertions(+), 8 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index a680c43f3..6842fb8fe 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -52,6 +52,7 @@ (declare-function org-before-first-heading-p "org" ())
 (declare-function org-do-occur "org" (regexp  cleanup))
 (declare-function org-element-at-point "org-element" ( pom cached-only))
 (declare-function org-element-cache-refresh "org-element" (pos))
+(declare-function org-element-cache-reset "org-element" ( all no-persistence))
 (declare-function org-element-context "org-element" ( element))
 (declare-function org-element-lineage "org-element-ast" (datum  types with-self))
 (declare-function org-element-link-parser "org-element" ())
@@ -532,6 +533,13 @@ (defconst org-radio-target-regexp (format "<%s>" org-target-regexp)
 
 (defvar-local org-target-link-regexp nil
   "Regular expression matching radio targets in plain text.")
+(defconst org-target-link-regexp-limit (ash 2 15)
+  "Maximum allowed length of regexp.
+See MAX_BUF_SIZE in src/regex-emacs.c")
+(defvar-local org-target-link-regexps nil
+  "List of regular expressions matching radio targets in plain text.
+This list is non-nil, when a single regexp would be too long to match
+all the possible targets, exceeding Emacs' regexp length limit.")
 
 (defvar org-link-types-re nil
   "Matches a link that has a url-like prefix like \"http:\".")
@@ -2078,6 +2086,34 @@ (defun org-insert-link-global ()
   (org-load-modules-maybe)
   (org-run-like-in-org-mode 'org-insert-link))
 
+(defun org--re-list-search-forward (regexp-list  bound noerror count)
+  "Like `re-search-forward', but REGEXP-LIST is a list of regexps.
+BOUND, NOERROR, and COUNT are passed to `re-search-forward'."
+  (let (result (min-found most-positive-fixnum)
+   (pos-found nil)
+   (min-found-data nil)
+   (tail regexp-list))
+(while tail
+  (setq result (save-excursion (re-search-forward (pop tail) bound t count)))
+  (when (and result (< result min-found))
+(setq min-found result
+  pos-found (match-end 0)
+  min-found-data (match-data
+(if (= most-positive-fixnum min-found)
+(pcase noerror
+  (`t nil)
+  (_ (re-search-forward (car regexp-list) bound noerror count)))
+  (set-match-data min-found-data)
+  (goto-char pos-found
+
+(defun org--re-list-looking-at (regexp-list  inhibit-modify)
+  "Like `looking-at', but REGEXP-LIST is a list of regexps.
+INHIBIT-MODIFY is passed to `looking-at'."
+  (catch :found
+(while regexp-list
+  (when (looking-at (pop regexp-list) inhibit-modify)
+(throw :found t)
+
 ;;;###autoload
 (defun org-update-radio-target-regexp ()
   "Find all radio targets in this file and update the regular expression.
@@ -2115,6 +2151,30 @@ (defun org-update-radio-target-regexp ()
 			targets
 			"\\|")
 		   

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

2024-02-19 Thread Ihor Radchenko
Bruno Barbier  writes:

> Hi Matt, Jack, Ihor,
>
> Sorry for the late reply.  Cleaning the code took me longer than
> expected.

Thanks for the code!
It is a lot more that I expected.
I have many questions ;)

> The new API itself is more about how to wait for and display one block
> result.  So, it's not really aware of sessions.

I think that it is important to think about sessions. For non-sessions,
we may execute the code in parallel, disregarding already running
execution. In contrast, for sessions, we need to maintain some queue and
wait until previous execution finishes before running next (if multiple
session blocks are executed in quick succession).

It may also be necessary to provide an UI listing the queued and running
execution. Users should be able to stop "stale" processes if they are
defunc (consider infinite loop).

>> Also interesting, I think it's worth exploring/testing this overlay idea
>> out. Does that mean that output is asynchronously printing into the Org
>> buffer? It sounds cool but I wonder if it might cause problems while
>> trying to edit another part of the buffer.
>
> Currently, I've limited the progress feedback to fit on one line to
> avoid anoying vertical display jumps.  When the computation is
> successful, the result is inserted as usual, and, that may be annoying;
> when it updates a previous result of the same height, it's ok.  Else, we
> could fold it to stay on one line too (using the overlay), until the
> user explicitly request to see it.

Let's not worry about "jumps" yet. It is a minor issue that can be
easily solved.

What is more important is when users, for example, remove the whole
subtree containing the place where the execution result is to be
inserted. Or when users perform edits at or around that place where the
result is to be inserted. Or consider subtree with pending result
refiled elsewhere (different file or different place in the same file);
or archived.

Or consider user running an src block, quickly editing it, and then
running again. What should we do then? Should we stop the first running
process?

> So, here we go.  You'll find attach a set of patchs.  It works for me with
> Emacsc 30.50 and 9.7-pre (from today).

I have several general questions:

- what if append/prepend to result asynchronously?
- what if we replace the result, call async evaluation two times, and they 
arrive in opposite order (first called is calculated after the second)?
- on failure, Org babel sometimes uses ~org-babel-eval-error-notify~. How will 
it interact with asynchronous evaluation? What if we have multiple 
simultaneously arriving error notifications?
  Example: try running
  #+begin_src bash
  idontexist
  #+end_src

> I didn't check yet that the code and the commits follow all the
> guidelines.  This is just a preliminary version for feedbacks.
> Corrections/critiques are welcome, but don't check the details until I
> check them myself.
> So, I decided to rewrite the whole thing, taking code from the
> synchronous case (following `org-babel-python-evaluate-session').  I
> also created a package that contains all the functions that should be
> reusable for any language.  The patch [1] adds some generic functions to
> help dealing with asynchronicity (process, comint, etc.). The patch [2]
> shows a new possible way to execute python code blocks, both
> synchronously and asynchronously, with or without sessions.  You should
> just need to open [3] and follow what's written there, and execute the
> existing bash and python code blocks.

Note that we already have a WIP an asynchronous API in the works.
Check out `org-async-call' in
https://code.tecosaur.net/tec/org-mode/src/branch/dev/lisp/org-macs.el#L377
If possible, we should reuse it.

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



Re: Warn about shell-expansion in the docstring of org-latex-to-html-convert-command

2024-02-19 Thread Ihor Radchenko
Martin Edström  writes:

> Tests passed (14 SKIPPED), compiled fine.  I've made no prior
> contributions and this changes 5 lines. I'm ok if you want to rephrase
> it in any way.

Applied onto main, with amendments.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a8443f2c7
Thanks for your contribution!

You are now listed as one of the Org mode contributors:
https://git.sr.ht/~bzg/worg/commit/53d1e6e3

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