Re: Radio links work only in small numbers

[Noboru Ota]

Ihor Radchenko  writes:

> org-target-link-regexp does not matter in this case. For this long
> regexps I introduced a new variable org-target-link-regexps that
> contains a list of shorter regexps. This list is used instead of
> org-target-link-regexp.

Ah! Thank you.

If it is valid to compare (length org-target-link-regexps) and 2048, at
least for a rough indication, I have these:

- 33 for  5000 terms
- 76 for 1 terms

It seems we should not worry about hitting the limit in normal personal
uses.

– nobiot

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

[gerard . vermeulen]

On 29.02.2024 12:56, Ihor Radchenko wrote:

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


That includes `org-babel-demarcate-block' splitting with the patch.

I do not understand why it works and why I never see the user-error
re-signalled by `org-babel-edit-prep:sql' (even as demoted message).


[...]

I have reduced my version of `org-babel-demarcate-block' to a minimal
function to locate the bug stemming from edit-prep signaling an
user-error or not.  In case edit-prep signals an user-error the call
chain `org-indent-block', `org-indent-region', `org-element-at-point'
triggers an infinite list of warnings (major mode is Python when run
on the test block).
#+begin_src emacs-lisp -n :results silent
(defun oeap-test ()
  "Test `org-element-at-point': call with point at block."
  (interactive)
  (let* ((info (org-babel-get-src-block-info 'noeval))
 (start (org-babel-where-is-src-block-head))
 (body (and start (match-string 5
(if (and info start)
(let* ((copy (org-element-copy (org-element-at-point)))
   (before (org-element-begin copy))
   (beyond (org-element-end copy)))
  (org-element-put-property copy :value body)
  (delete-region before beyond)
  (insert (org-element-interpret-data copy))
  (org-babel-previous-src-block 1)
  (message "Mode derived from: %S" (derived-mode-p 'org-mode))
  ;; Triggers list of warnings and condition-case is no 
solution:

  (org-indent-block)
#+end_src
Working edit-prep:
#+begin_src emacs-lisp -n :results silent
(defun harm-full-edit-prep (_info)
  (user-error "Harm-FULL edit-prep"))

(defun org-babel-edit-prep:python (info)
  (condition-case nil
  (harm-full-edit-prep info)
(t nil)))

(message "Working edit-prep:python")
#+end_src
Failing edit-prep:
#+begin_src emacs-lisp -n :results silent
(defun harm-full-edit-prep (_info)
  (user-error "Harm-FULL edit-prep"))

(defun org-babel-edit-prep:python (info)
  (harm-full-edit-prep info))

(message "Failing edit-prep:python")
#+end_src
Test block:
#+begin_src python -i -n :results silent
11
22
#+end_src
I do not like to put extra constraints on edit-prep functions. Maybe,
it is better to cancel the patch.

Regards -- Gerard

Re: Radio links work only in small numbers

[Ihor Radchenko]

Noboru Ota  writes:

> - MAX_BUF_SIZE in src/regex-emacs.c is, if I understand the comment
>   around it correctly, 2^15 bytes = 32768 bytes.
>
> - `org-target-link-regexp-limit` is 2^11 bytes = 2048 bytes (?).
>
> - For my 5000 terms, (length org-target-link-regexp) => 103603 (what's
>   the unit of measure?)
>
> - (string-bytes org-target-link-regexp) => 103603, the same number.

org-target-link-regexp does not matter in this case. For this long
regexps I introduced a new variable org-target-link-regexps that
contains a list of shorter regexps. This list is used instead of
org-target-link-regexp.

> - If I evaluate the following to try to get a compiled length of the
>   regexp, 88785.

By "compiled", I did not mean byte-compiled. Regexp compilation is a
completely different beast. It is performed by Emacs C internals,
converting string regexp into representation used by regexp matching
code. This compiled representation is not exposed to Elisp.

If you want to learn more about regexp matching theory and
implementation, you may check
https://blog.burntsushi.net/regex-internals/

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

[Noboru Ota]

Ihor Radchenko  writes:
> Thanks for testing!
> Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=341a01a07
> Fixed.

You're very welcome. This is amazing. Thank you so much. I have rebased
the source to the latest main and also tested with 10,000 dummy entries.
The target links still work!

> See the docstring of `org-target-link-regexp-limit'. The hard limit is
> MAX_BUF_SIZE in src/regex-emacs.c, but that's after the regexp is
> compiled (AFAIU). So, the real limit is smaller and may depend on
> regexp complexity.

Thank you for the detail.

I do not need to understand all the technical detail here, but for
future reference and if you have the time, let me ask this -- please try
not to waste your time answering.

- MAX_BUF_SIZE in src/regex-emacs.c is, if I understand the comment
  around it correctly, 2^15 bytes = 32768 bytes.

- `org-target-link-regexp-limit` is 2^11 bytes = 2048 bytes (?).

- For my 5000 terms, (length org-target-link-regexp) => 103603 (what's
  the unit of measure?)

- (string-bytes org-target-link-regexp) => 103603, the same number.

- If I evaluate the following to try to get a compiled length of the
  regexp, 88785.

(let ((regexp org-target-link-regexp))
(with-temp-file "org-target-link-regexp"
  (insert regexp)))
(byte-compile-file "org-target-link-regexp")
(file-attribute-size (file-attributes "org-target-link-regexp.elc"))

- For 1 dummy terms, (length org-target-link-regexp) => 228848.

The numbers I get seem to be much greater than 2048 (bytes?) and 32768
bytes

My test with 10,000 terms is more than sufficient to cover my needs, so
please do not feel obliged to answer this technical part -- someone else
might want to jump in to help :)

– nobiot

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Max Nikulin writes:

>> Anyway, I think your example only makes sense in HTML, or at least I
>> can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
>> passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
>> does seem sensible to me that someone would want to change the tags.
>> Maybe with a :html-tag, or something like that.
>
> Consider a document aimed to be exported to different formats. It is
> unlikely that names of commands, elements, classes, etc. match for all
> of them.

It makes sense, although I have never encountered a case like this.
Usually (and returning to the example of the large special blocks), if
in org I put something like:

#+begin_foo
...
#+end_foo

I try to ensure that there is a "foo" environment in LaTeX, a "foo" class
in html or a "foo" style in odt (now I don't remember if the odt exporter
produces paragraph styles from special blocks. I don't think so).

In any case, on second thought, maybe someone wants to reuse a LaTeX
preamble, css style sheets or any odt templates. I see no problem, then,
in there being attributes like :latex-command, :html-tag, :odt-style 
:html-attribute,
etc., which override the default values.

>> As for :latex-command, if I understand it correctly, I don't quite see
>> how useful this could be:
>> &foo[:latex-command bar]{text} == LaTeX ==> \bar{text}
>> when it is simpler to put:
>> &bar{text}
>
> Command may require additional arguments and it should be convenient
> to define shortcuts to the same command with different arguments:
>
> &la{text} => \foreignlanguage{latin}{text}
> &es{text} => \foreinglanguage{spanish}{text}

With the current implementation:

#+options: inline-special-block-aliases:(("bar" :prelatex [bar]) ("baz" 
:prelatex [baz]))

&foo[@bar@]{lorem ipsum} ==> \foo[bar]{lorem ipsum}
&foo[@baz@]{lorem ipsum} ==> \foo[baz]{lorem ipsum}

Your example is less verbose, but with this implementation you can do 
combinations, it's
more granular, I think:

&foo[@bar@ :smallcaps t]{lorem ipsum} ==> {\scshape\foo[bar]{lorem ipsum}}
&foo[@baz@ :lang it]{lorem ipsum} ==> \foo[baz]{\foreignlanguage{italian}{lorem 
ipsum}}

I think this is quite flexible and leaves a great deal of freedom to the user.

>> The same thing happens with the anonymous variant:
>> &_[:latex-command foo]{text} == LaTeX ==> \foo{text}
>> which is identical to putting &foo{text}
>> The anonymous variant would be equivalent in LaTeX to a
>> \begingroup...\endgroup, or rather to {...}. One could add all the
>> commands one wants within the group simply with :prelatex:
>> &_[:prelatex \foo\bar\vaz\blah{}]{text}
>> ==> {\foo\bar\vaz\blah{}text}
>
> The idea is to not add \begingroup and \endgroup if LaTeX command is
> specified (or to control it by a dedicated attribute). Again, consider
> a document suitable for multiple export formats.

Indeed, if the :latex-command attr is implemented should work in both
variants. In such a way, perhaps:

&_[:latex-command foo]{lorem} ==> \foo{lorem}

> I think, flexibility in respect to underlying
> commands/classes/elements allows to minimize changes in documents
> later. Sometimes it is necessary to switch to another LaTeX package,
> CSS framework, etc. It allows usage semantic names within Org
> documents despite they may be exported to the same command.
>
>> In any case, I think that my implementation leaves open the possibility
>> of extending it with everything you mentioned, or anything else.
>
> The question is proper balance of built-in features, flexibility,
> implementation complexity. It would be unfortunate if most of users
> will have to create custom backends even for basic documents.

We can continue the discussion when I publish my experimental branch and
share the link. I'm a little late because I want to make some
corrections to the code first.

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

Re: [proof of concept] inline language blocks

[Max Nikulin]

On 29/02/2024 17:41, Juan Manuel Macías wrote:

Max Nikulin writes:


I do not try to dispute \foo and class="foo" as default behavior. I
suggest to implement possibility to override default behavior of
&foo{text} to \bar{text} and text. The same is applicable
for anonymous objects

  &_[:latex_command bar :html_element bar]{text}


Maxim, I insist that I follow the logic of the "large" special blocks.


Export of special blocks may be extended as well.


Anyway, I think your example only makes sense in HTML, or at least I
can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
does seem sensible to me that someone would want to change the tags.
Maybe with a :html-tag, or something like that.


Consider a document aimed to be exported to different formats. It is 
unlikely that names of commands, elements, classes, etc. match for all 
of them.



As for :latex-command, if I understand it correctly, I don't quite see
how useful this could be:

&foo[:latex-command bar]{text} == LaTeX ==> \bar{text}

when it is simpler to put:

&bar{text}


Command may require additional arguments and it should be convenient to 
define shortcuts to the same command with different arguments:


&la{text} => \foreignlanguage{latin}{text}
&es{text} => \foreinglanguage{spanish}{text}


The same thing happens with the anonymous variant:

&_[:latex-command foo]{text} == LaTeX ==> \foo{text}

which is identical to putting &foo{text}

The anonymous variant would be equivalent in LaTeX to a
\begingroup...\endgroup, or rather to {...}. One could add all the
commands one wants within the group simply with :prelatex:

&_[:prelatex \foo\bar\vaz\blah{}]{text}

==> {\foo\bar\vaz\blah{}text}


The idea is to not add \begingroup and \endgroup if LaTeX command is 
specified (or to control it by a dedicated attribute). Again, consider a 
document suitable for multiple export formats.


I think, flexibility in respect to underlying commands/classes/elements 
allows to minimize changes in documents later. Sometimes it is necessary 
to switch to another LaTeX package, CSS framework, etc. It allows usage 
semantic names within Org documents despite they may be exported to the 
same command.



In any case, I think that my implementation leaves open the possibility
of extending it with everything you mentioned, or anything else.


The question is proper balance of built-in features, flexibility, 
implementation complexity. It would be unfortunate if most of users will 
have to create custom backends even for basic documents.

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

[Ihor Radchenko]

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

> That includes `org-babel-demarcate-block' splitting with the patch.
>
> I do not understand why it works and why I never see the user-error
> re-signalled by `org-babel-edit-prep:sql' (even as demoted message).

Because `org-babel-edit-prep:sql' does not signal anything. It simply
returns a string:

In
(condition-case nil
(sql-set-product product)
  (user-error "Cannot set `sql-product' in Org Src edit buffer"))

(user-error ) means "If we encounter user-error, do ".
That code is certainly misleading.

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

Re: Setting org-odd-levels-only causes [/] and [%] count incorrectly

[Ihor Radchenko]

"E.L.K."  writes:

> I recently encountered this bug.
>
> If org-odd-levels-only set to true, this is how [/] is being counted (i.e.
> if I press C-c C-c on them):
>
>> * test
>> *** first [2/3]
>> * DONE first 1
>> *** second [1/2]
>> * DONE second one
>> * TODO second two

Thanks for reporting!
Fixed, on bugfix, and on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=864857657
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6ef015457

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

Re: emacs-orgmode@gnu.org Subject: Org mode version 9.7-pre (9.7-pre-n/a-g356072; org-table-to-lisp breaks table alignment when using links

[Ihor Radchenko]

Kostadin Ninev  writes:

> After installing latest org from git, table alignment is broken for 
> me in tables where some of the cells contain links for example:
>
>
> | a| b |
> |--+---|
> | [[c][c]] | d |
>
>
> Shows like this:
>
>
> | a| b |
> |--+---|
> | c | d |

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=731d16f9e

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

[Ihor Radchenko]

Noboru Ota  writes:

>> You need Www.
>> The attached version of the patch should work for 5000-terms.org.
>
> Thank you, Ihor. With your advice, I have managed to apply the patch. It
> works for 5000 terms! Thank you.

Thanks for testing!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=341a01a07
Fixed.

> Some observations:
>
> - Running `org-update-radio-target-regexp` takes about 15 seconds for the
>   file[1].

This is expected. By splitting radio target regexp into multiple
regexps, we increase the number of regexp search invocations. Regexp
search is relatively costly in Emacs.

>> (I had to scale down the maximum allowed regexp size; apparently,
>> the number from C sources was not small enough).
>
> Do you have any indication on how many would be maximum?

See the docstring of `org-target-link-regexp-limit'.
The hard limit is MAX_BUF_SIZE in src/regex-emacs.c, but that's after
the regexp is compiled (AFAIU). So, the real limit is smaller and may
depend on regexp complexity.

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

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Max Nikulin writes:

>> the user should expect something like &foo{...} to produce \foo{...} or
>> ..., etc. The only difference is that there would
>> be an anonymous variant &_{...}.
>
> I do not try to dispute \foo and class="foo" as default behavior. I
> suggest to implement possibility to override default behavior of
> &foo{text} to \bar{text} and text. The same is applicable
> for anonymous objects
>
>  &_[:latex_command bar :html_element bar]{text}

Maxim, I insist that I follow the logic of the "large" special blocks.

Anyway, I think your example only makes sense in HTML, or at least I
can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
does seem sensible to me that someone would want to change the tags.
Maybe with a :html-tag, or something like that.

As for :latex-command, if I understand it correctly, I don't quite see
how useful this could be:

&foo[:latex-command bar]{text} == LaTeX ==> \bar{text}

when it is simpler to put:

&bar{text}

The same thing happens with the anonymous variant:

&_[:latex-command foo]{text} == LaTeX ==> \foo{text}

which is identical to putting &foo{text}

The anonymous variant would be equivalent in LaTeX to a
\begingroup...\endgroup, or rather to {...}. One could add all the
commands one wants within the group simply with :prelatex:

&_[:prelatex \foo\bar\vaz\blah{}]{text}

==> {\foo\bar\vaz\blah{}text}

I'm not opposed to your ideas, I just can't find a use case for it. In
LaTeX, I mean. In the case of HTML I find it useful, indeed, to have
more control over the tags: , , etc.

In any case, I think that my implementation leaves open the possibility
of extending it with everything you mentioned, or anything else. 


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

Re: [PATCH] ob-tangle: Add flag to optionally remove files before writing

[Ihor Radchenko]

Olivier Lischer  writes:

>> Please, let me know if you want to change anything.
>> Also, if you can, please test my patch with your use-case.
>
> I tried it and it works for me.
> Thank you for your patience.

Thanks for testing!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dd4d05a15

I also added you to the contributor list.
https://git.sr.ht/~bzg/worg/commit/7752b51b

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

Re: bizarre: checkbox in properties, counting does not work with subheadings

[Ihor Radchenko]

Ihor Radchenko  writes:

> With the attached patch, the result would be the following:

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ac1ed2bf8
Fixed.

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

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

[gerard . vermeulen]

On 28.02.2024 12:54, Ihor Radchenko wrote:

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


You may wrap `org-indent-block' into `condition-case' to catch
user-errors.


The caveat is not a real constraint, since Org has limited support for
source block editing in an Org mode buffer when an
`org-babel-edit-prep:' function signals an user-error.

I show that in the attached no-user-errors-in-edit-prep.org.


I studied the existing Org handling of various errors related to src
edit buffers and it seems that we tend to ignore them in a number of
scenarios. In particular, when major mode fails to load for any reason,
Org mode does not even throw an error, but simply displays a warning.

So, I think that we can similarly ignore errors in edit-prep function,
demoting them to messages.

(In addition, it does not look like electric-indent-mode triggered in
your example file by pressing  handles errors gracefully either -
yet another reason not to throw errors in `org-indent-*' functions)

Does it make sense?


Your reply helped me to read the Org Babel code from a different view
point.  I re-discovered that `org-babel-edit-prep:sql' handles all
issues gracefully while trying the block below:
#+begin_src sql :engine wrong
a
b
#+end_src
That includes `org-babel-demarcate-block' splitting with the patch.

I do not understand why it works and why I never see the user-error
re-signalled by `org-babel-edit-prep:sql' (even as demoted message).

After writing `org-babel-edit-prep:python' like:
#+begin_src emacs-lisp -n :results silent
(defun harm-full-edit-prep (_info)
  (user-error "Harm-FULL edit-prep"))

(defun org-babel-edit-prep:python (info)
  "Imitate `org-babel-edit-prep:sql'."
  (condition-case nil
  (harm-full-edit-prep info)
(user-error "Why is this harm-LESS in `org-babel-edit-prep:sql'?")))
#+end_src
and trying it on the block below:
#+begin_src python -i -n :results silent
11
22
#+end_src
I see that this `org-babel-edit-prep:python' handles all issues like
`org-babel-edit-prep:sql' (and it does not matter whether
`electric-indent-mode' is disabled or enabled).

I conclude (contrary to the previous commit message in the patch):

In case functions called by an `org-babel-edit-prep:' function
raise an user-error, this `org-babel-edit-prep:' function should
re-signal the user-error like `org-babel-edit-prep:sql' does.

Attached you'll find the patch with an updated commit message.

Regards -- Gerard


0001-org-babel-demarcate-block-split-using-element-API.patch
Description: Binary data

Re: Things got very slow: profiler output

[Bruno Barbier]

Bruno Barbier  writes:

> Hi William,
>
> William Denton  writes:
>
>> I rebuilt Org and Emacs from the development trees and something is wrong, 
>> because some Org files I use regularly have become incredibly slow to use.  
>> I rarely use the profiler and don't know what to make of what it says, but I 
>> opened a file and ran it while I moved around and expanded and collapsed 
>> some headings for a minute or so.  (It was so slow that it took me a minute 
>> to do what would usually take me a few seconds.)  I'll paste the results 
>> below.  Does that say anything useful?  There is a little LaTeX in the file 
>> but not much.
>>
>> Any help on interpreting this would be welcome.  I can try reverting to an 
>> earlier Git commit tomorrow.
>>
>> Bill
>>
>>  Samples%   Function
>>73203  70% - redisplay_internal (C function)
>>71496  68%  - jit-lock-function
>>71488  68%   - jit-lock-fontify-now
>>71472  68%- jit-lock--run-functions
>>71472  68% - #
>>71472  68%  - font-lock-fontify-region
>>71468  68%   - font-lock-default-fontify-region
>>71436  68%- font-lock-fontify-keywords-region
>>71124  68% - org-do-latex-and-related
>>71124  68%re-search-forward
>>  228   0% + org-activate-folds
>>   16   0% + org-fontify-meta-lines-and-blocks
>>   12   0% + org-activate-footnote-links
>>8   0%   org-activate-dates
>>8   0% + org-activate-links
>>4   0%   org-do-emphasis-faces
>>4   0%   org-fontify-drawers
>>4   0%   org-raise-scripts
>>   28   0%+ font-lock-unfontify-region
>>4   0%+ font-lock-extend-region-wholelines
>>4   0%  text-property-any
>>30951  29% + command-execute
>>   ...
>
> Did you customize org-latex-and-related-regexp ?  Is it still slow if you set
> this to nil (which is apparently the default value) ?
>
> If not, telling which version of Org, that you were using before, might help.

Oops, sorry, the customization option is:

org-highlight-latex-and-related

(the other value is computed by Org)

You may try to change that option org-highlight-latex-and-related to see
if it helps.


Bruno

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

Re: Things got very slow: profiler output

[Ihor Radchenko]

Bruno Barbier  writes:

> Did you customize org-latex-and-related-regexp ?  Is it still slow if you set
> this to nil (which is apparently the default value) ?

org-latex-and-related-regexp is not a customization. It is an internal
variable. The relevant customization is org-highlight-latex-and-related.

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

Re: Question about cite_export basic

[Ihor Radchenko]

Ihor Radchenko  writes:

> Parsing itself is not that hard, actually. We just need to follow
> http://www.bibtex.org/SpecialSymbols/. However, it will be better if the
> parsing is done on bibtex.el side.

Not so easy. http://www.bibtex.org/SpecialSymbols/ is not accurate and
there is no formal (and full) description of Bibtex format anywhere.

> If bibtex.el maintainer refuses to implement the request, we will just
> do the parsing on Org side.

bibitex.el maintainer don't think that fine parsing is within bibtex.el
scope.
I implemented an approximate parser on Org side instead.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d2df9624c

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

Re: Things got very slow: profiler output

[Bruno Barbier]

Hi William,

William Denton  writes:

> I rebuilt Org and Emacs from the development trees and something is wrong, 
> because some Org files I use regularly have become incredibly slow to use.  I 
> rarely use the profiler and don't know what to make of what it says, but I 
> opened a file and ran it while I moved around and expanded and collapsed some 
> headings for a minute or so.  (It was so slow that it took me a minute to do 
> what would usually take me a few seconds.)  I'll paste the results below.  
> Does that say anything useful?  There is a little LaTeX in the file but not 
> much.
>
> Any help on interpreting this would be welcome.  I can try reverting to an 
> earlier Git commit tomorrow.
>
> Bill
>
>  Samples%   Function
>73203  70% - redisplay_internal (C function)
>71496  68%  - jit-lock-function
>71488  68%   - jit-lock-fontify-now
>71472  68%- jit-lock--run-functions
>71472  68% - #
>71472  68%  - font-lock-fontify-region
>71468  68%   - font-lock-default-fontify-region
>71436  68%- font-lock-fontify-keywords-region
>71124  68% - org-do-latex-and-related
>71124  68%re-search-forward
>  228   0% + org-activate-folds
>   16   0% + org-fontify-meta-lines-and-blocks
>   12   0% + org-activate-footnote-links
>8   0%   org-activate-dates
>8   0% + org-activate-links
>4   0%   org-do-emphasis-faces
>4   0%   org-fontify-drawers
>4   0%   org-raise-scripts
>   28   0%+ font-lock-unfontify-region
>4   0%+ font-lock-extend-region-wholelines
>4   0%  text-property-any
>30951  29% + command-execute
>   ...

Did you customize org-latex-and-related-regexp ?  Is it still slow if you set
this to nil (which is apparently the default value) ?

If not, telling which version of Org, that you were using before, might help.


Bruno


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

Setting org-odd-levels-only causes [/] and [%] count incorrectly

[E.L.K.]

Hello!

I recently encountered this bug.

If org-odd-levels-only set to true, this is how [/] is being counted (i.e.
if I press C-c C-c on them):

> * test
> *** first [2/3]
> * DONE first 1
> *** second [1/2]
> * DONE second one
> * TODO second two

This is "minimal config" to reproduce it with emacs -Q -l minimal-config.el:

> (setq-default org-odd-levels-only t)

Emacs version: GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.40, cairo version 1.18.0)

Org versions tested (as per org-version function):
- Org mode version 9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)
- Org mode version 9.6.20 ( @ /home/elk/.emacs.d/elpa/org-9.6.20/)

Thanks,
best regards,
Alexey