Re: How does =org-md-item= produce the correct indentation for nested lists?

[Rohit Patnaik]

Hello,

Yes, that clarifies things quite a bit. I thought that the contents of the list
item only included that specific item, when in reality it includes the item and
all sub-lists.

Thanks,
Rohit

Re: PATCH allow explicit style= in #+cite_export: biblatex

[Pedro Andres Aranda Gutierrez]

Sorry... I was not right... You are right. I'll take a look at it again.
/PA

On Sun, 14 Apr 2024 at 07:22, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> Hi,
>
> Maybe not... because style= is a keyword for the biblatex package, while
> bibstyle or citestyle aren't.
>
> Best, /PA
>
> On Sat, 13 Apr 2024 at 16:32, Ihor Radchenko  wrote:
>
>> Pedro Andres Aranda Gutierrez  writes:
>>
>> > HI,
>> > Attached is a small patch to allow explicitly adding style= in the
>> biblatex export options, to increase consistency with
>> > Customisation variables.
>>
>> Thanks!
>>
>> >  (style-options
>> >   (cond
>> >((null style) nil)
>> > +  ;; allow the user to include "style=" anywhere in the style
>> options
>> > +  ((string-match "\\(^s\\|,s\\)tyle=" style) (list style))
>> >((not (string-match "/" style)) (list (concat "style="
>> style)))
>> >(t
>> > (list (concat "bibstyle=" (substring style nil
>> (match-beginning 0)))
>>
>> If we allow style=..., may as well allow bibstyle= and citestyle=.
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>>
>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: PATCH allow explicit style= in #+cite_export: biblatex

[Pedro Andres Aranda Gutierrez]

Hi,

Maybe not... because style= is a keyword for the biblatex package, while
bibstyle or citestyle aren't.

Best, /PA

On Sat, 13 Apr 2024 at 16:32, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > HI,
> > Attached is a small patch to allow explicitly adding style= in the
> biblatex export options, to increase consistency with
> > Customisation variables.
>
> Thanks!
>
> >  (style-options
> >   (cond
> >((null style) nil)
> > +  ;; allow the user to include "style=" anywhere in the style
> options
> > +  ((string-match "\\(^s\\|,s\\)tyle=" style) (list style))
> >((not (string-match "/" style)) (list (concat "style="
> style)))
> >(t
> > (list (concat "bibstyle=" (substring style nil
> (match-beginning 0)))
>
> If we allow style=..., may as well allow bibstyle= and citestyle=.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: [BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]

[Björn Bidar]

Ihor Radchenko  writes:

> Björn Bidar  writes:
>
>> The bug also seems to affect `org-attach`.
>
> Fixed, on main. Alongside with other similar places.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=78e9dd0c4

I noticed after the change that captured links are not picked up.

E.g.:
1. I capture a link using org-protocol
2. Switch to the org-buffer
3. C-c C-l
4. RET  <- frame closes however links isn't inserted into the target org-buffer 

Re: [BUG] Org parser error when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]

[General discussions about Org-mode.]

> Then, it looks like a duplicate of
> https://list.orgmode.org/orgmode/caedgbw4gmfmpt4-w6edrh7poapd5drarbtusfulrq7vbvtu...@mail.gmail.com/
>
> There is no bug on the latest development version of Org mode (main).

Sure!  
Thank you for pointing it out and helping with the resolution.

--
Anush Veeranala

Re: How does =org-md-item= produce the correct indentation for nested lists?

[Ihor Radchenko]

"Rohit Patnaik"  writes:

> #+BEGIN_SRC elisp
> (concat bullet
> ...
> (and contents
>(org-trim (replace-regexp-in-string "^" "" contents
> #+END_SRC
>
> and I'm wondering why it's adding indentation in front of the bullet. 
> Naively, I
> would expect the result of this snippet, for an unordered list to be something
> like:
>
> =-[item contents]=
>
> That is, it concatenate the bullet, then three spaces (4 - length of bullet),
> then another four spaces, then the contents of the item. Instead, what I see 
> is
> a four-space indent, followed by the bullet and its padding, followed by the
> item contents:
>
> =-   [item contents]=
>
> This is the correct result, but I don't see how the code from ox-md.el 
> produces
> that result.

The code makes use of the CONTENTS.

If you have nested lists

- item
  - sub-item
- sub-sub-item

"sub-sub-item" transcoder will receive CONTENTS="sub-sub-item" and return

-   sub-sub-item

then, "sub-item" transcoder will receive CONTENTS="sub-item" + output of
nested transcoder -

CONTENTS=

sub-item
-   sub-sub-item

and add 4 spaces to each line, except first:

-   sub-item
-   sub-sub-item

then, item transcoder will receive the result of the two nested
transcoders:

CONTENTS=

item
-   sub-item
-   sub-sub-item

yielding

-   item
-   sub-item
-   sub-sub-item

Hope, it clarifies things.

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

Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx

[Morgan Smith]

Ihor Radchenko  writes:

> So, in the message I linked, Nicolas (the major Org mode contributor)
> was not right. I hence need to fix the parser and update Org syntax
> page. This includes fixing `org-element-clock-line-re' to account for
> CLOCK: => 1:00 syntax.

Cool.  I guess ping this thread when that's done so I can give you
another version of the patch.  Or if you'd like help with that stuff let
me know.  I'm here to help.

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Ihor Radchenko]

Alexander Adolf  writes:

>> In any case, making column views more flexible is welcome.
>> [...]
>
>  Lure me into contributing a patch? fair enough; I might just as well
> give that a try. I presume I'd get some support here on this list?
> And/or on IRC (e.g. libera.chat#org-mode)?

Yup. You are free to ask questions on the mailing list.
You may also try to ask questions in IRC or Matrix:
- https://web.libera.chat/#org-mode
- https://matrix.to/#/%23org-mode:matrix.org
Or even live, during online meetup:
- 
https://list.orgmode.org/18ed37bf7da.110d936ff448640.1616496967933735...@excalamus.com/T/#t

See https://orgmode.org/worg/org-contribute.html for more instructions.

> I have signed FSF copyright assignment for all of Emacs, so I guess
> nothing would need to be done at the paperwork level?

Org mode is a part of Emacs. So, your copyright assignment for Emacs is
enough.

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

Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx

[Ihor Radchenko]

Morgan Smith  writes:

>>> -  (goto-line 2)
>>> +  (insert (org-test-clock-create-clock ". 1:00" ". 2:00")
>>> +  "CLOCK: => 1:00\n")
>>
>> This is not a valid clock format. Matching such lines is a bug.
>> See https://list.orgmode.org/orgmode/87wpkkhafc.fsf@saiph.selenimh/
>
> Let me preface this defense with the fact that I don't like this format
> and I don't think we should support it.  Rewriting `org-clock-sum' would
> be much easier if we drop support for it.  However, I do believe we
> currently support it.
>
> First of all, it currently does work.
>
> Accord to the "Version 4.78" release notes as found on worg, this is
> valid.
>
> ```
>- You may specify clocking times by hand (i.e. without
>  clocking in and out) using this syntax.
>
>  : CLOCK: => 2:00
>
>  Thanks to Scott Jaderholm for this proposal.
> ```

This is convincing. I did not know that this format is explicitly
mentioned in the news.

Our general rule is that we do not drop existing features in Org mode
except extraordinary circumstances:
https://bzg.fr/en/the-software-maintainers-pledge/
Especially when they are documented.

So, in the message I linked, Nicolas (the major Org mode contributor)
was not right. I hence need to fix the parser and update Org syntax
page. This includes fixing `org-element-clock-line-re' to account for
CLOCK: => 1:00 syntax.

Luckily, it does not look like we are going to break the existing
external exporter packages as long as they are using ox.el API -
`org-export-translate' works just fine with missing timestamps.

> Also last time I went to rewrite `org-clock-sum' you said
> (https://list.orgmode.org/orgmode/87bkg7xbxo.fsf@localhost/):
>
> ```
> Further, you dropped the
>
>((match-end 4)
> ;; A naked time.
>
> branch of the code, which accounts for CLOCK: => HH:MM lines that are not 
> clock elements.
> ```

Yup. Although I did not see Nicolas' message that time. My judgment was
simply based on looking at the code and seeing that CLOCK: => HH:MM
matching was clearly intentional.

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

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Alexander Adolf]

Ihor Radchenko  writes:

> Alexander Adolf  writes:
>
>>> In fact, CLOCKSUM property does not support custom summaries.
>>
>> ???
>
> AFAIU, you cannot do %CLOCKSUM{max}.

Ah, I see; that's what you meant.

>> [...]
>> Thus, from my point of view, having a :formatter for the columnview
>> dblock would be quite fabulous. 濾
>
> This will not prevent the property values from being changed by column
> view.

Correct. But I don't see that as a problem, as this has been the
behaviour of effort properties since - always.

> In any case, making column views more flexible is welcome.
> [...]

 Lure me into contributing a patch? fair enough; I might just as well
give that a try. I presume I'd get some support here on this list?
And/or on IRC (e.g. libera.chat#org-mode)?

I have signed FSF copyright assignment for all of Emacs, so I guess
nothing would need to be done at the paperwork level?


Cheers,

  --alexander

Re: [BUG] Org parser error when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Anush V  writes:

> Thanks for outlining your steps.  I’ve added an additional step
> (5). Here's the updated sequence:
> ...
> 5. M-: (setq org-startup-numerated t)

Then, it looks like a duplicate of
https://list.orgmode.org/orgmode/caedgbw4gmfmpt4-w6edrh7poapd5drarbtusfulrq7vbvtu...@mail.gmail.com/

There is no bug on the latest development version of Org mode (main).

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

Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx

[Morgan Smith]

Ihor Radchenko  writes:

>> * testing/lisp/test-org-clock.el (test-org-clock/clocktable/insert):
>> Add a clock time that does not include timestamps.
>> ...
>> -
>> -  (goto-line 2)
>> +  (insert (org-test-clock-create-clock ". 1:00" ". 2:00")
>> +  "CLOCK: => 1:00\n")
>
> This is not a valid clock format. Matching such lines is a bug.
> See https://list.orgmode.org/orgmode/87wpkkhafc.fsf@saiph.selenimh/

Let me preface this defense with the fact that I don't like this format
and I don't think we should support it.  Rewriting `org-clock-sum' would
be much easier if we drop support for it.  However, I do believe we
currently support it.

First of all, it currently does work.

Accord to the "Version 4.78" release notes as found on worg, this is
valid.

```
   - You may specify clocking times by hand (i.e. without
 clocking in and out) using this syntax.

 : CLOCK: => 2:00

 Thanks to Scott Jaderholm for this proposal.
```

Also last time I went to rewrite `org-clock-sum' you said
(https://list.orgmode.org/orgmode/87bkg7xbxo.fsf@localhost/):

```
Further, you dropped the

 ((match-end 4)
  ;; A naked time.

branch of the code, which accounts for CLOCK: => HH:MM lines that are not clock 
elements.
```

Re: [BUG] Org parser error when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]

[General discussions about Org-mode.]

> I did the following:
>
> 1. Save your file to /tmp/
> 2. rm -rf /tmp/ltximg
> 3. emacs-29 --version
> GNU Emacs 29.3
> Copyright (C) 2024 Free Software Foundation, Inc.
>
> 4. emacs-29 -Q
> 5. C-x C-f /tmp/tmp.org 
> 6. C-n
> 7. C-c C-x C-l
> 8. C-c C-x C-l
> 9. I do not observe any warnings


Thanks for outlining your steps.  I’ve added an additional step
(5). Here's the updated sequence:

1. Save your file to /tmp/
2. rm -rf /tmp/ltximg
3. emacs-29 --version
GNU Emacs 29.3
Copyright (C) 2024 Free Software Foundation, Inc.

4. emacs-29 -Q


5. M-: (setq org-startup-numerated t)


6. C-x C-f /tmp/tmp.org 
7. C-n
8. C-c C-x C-l
9. C-c C-x C-l
10. I observe warning

--
Anush Veeranala

Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx

[Ihor Radchenko]

Morgan Smith  writes:

> See two attached patches.  All tests pass on my computer.
>
> Every once in a while I feel obligated to go back to org-clock-sum to
> try and optimize it.  I have a file with 8 clocktables in it and it
> takes forever to update.  This time I decided instead of trying to
> optimize, I'm just going to try and understand.
>
> The regex has been altered slightly.
>
> 1. Instead of using "[ \t]", I decided to use [[:blank:]].  No real
> reason.  I just think it's easier to read and maybe slightly more
> correct?
>
> 2. For the timestamps, instead of ".*?" (using a non-greedy ".*") I
> decided to use "[^]]*" (accept everything except "]").  I did this simply
> because I'm not used to using non-greedy regex's.  Maybe this way
> performs better?  I didn't test that.
>
> 3. I used the variable `org-outline-regexp' but that doesn't actually
> change the regex.

Thanks for the patch!
I think that a better approach would be re-using the parser constant
`org-element-clock-line-re'. 

> * testing/lisp/test-org-clock.el (test-org-clock/clocktable/insert):
> Add a clock time that does not include timestamps.
> ...
> -
> -  (goto-line 2)
> +  (insert (org-test-clock-create-clock ". 1:00" ". 2:00")
> +  "CLOCK: => 1:00\n")

This is not a valid clock format. Matching such lines is a bug.
See https://list.orgmode.org/orgmode/87wpkkhafc.fsf@saiph.selenimh/

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

Re: PATCH allow explicit style= in #+cite_export: biblatex

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> HI,
> Attached is a small patch to allow explicitly adding style= in the biblatex 
> export options, to increase consistency with 
> Customisation variables.

Thanks!

>  (style-options
>   (cond
>((null style) nil)
> +  ;; allow the user to include "style=" anywhere in the style options
> +  ((string-match "\\(^s\\|,s\\)tyle=" style) (list style))
>((not (string-match "/" style)) (list (concat "style=" style)))
>(t
> (list (concat "bibstyle=" (substring style nil (match-beginning 
> 0)))

If we allow style=..., may as well allow bibstyle= and citestyle=.

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

Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM

[Ihor Radchenko]

Alexander Adolf  writes:

>> In fact, CLOCKSUM property does not support custom summaries.
>
> ???

AFAIU, you cannot do %CLOCKSUM{max}.

>>> Is there any way to change the summation behaviour for either or both
>>> column types?
>>
>> It is currently hard-coded. (Although, it is not too hard add some kind
>> of switch).
>> [...]
>
> I think that instead of a switch, I would prefer the columnview dblock
> to get a :formatter added. Knowing how the values have been computed in
> the dblock's write function, I can re-calculate whatever data I need in
> the formatter.
>
> I am already using this approach successfully with the clocktable dblock
> to generate invoices for me.
>
> Compared to a new switch, it would seem to me that adding a :formatter
> to the columnview dblock has several advantages:
>
> - it would likely be a smaller code change;
>
> - instead of implementing a single, new behaviour (activated by switch)
>   it would give users the flexibility to implement any new behaviour
>   they might want (user-supplied :formatter function).
>
>
> Thus, from my point of view, having a :formatter for the columnview
> dblock would be quite fabulous. 濾

This will not prevent the property values from being changed by column
view.

In any case, making column views more flexible is welcome.

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

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Protesilaos Stavrou  writes:

> With regard to the disambiguation scheme, I am playing around with
> various scenaria to see how Org HTML export behaves. Using the
> following:
> ...
> This is test 2  role="doc-backlink">1
> ...
> This is test 3  role="doc-backlink">1
>
> Notice that the 100 in the ID is not incremented further. I guess this
> is something that can be worked on but, again, I think it is separate
> from the issue of using the label for the ID and HREF.
>
> Any thoughts?

Duplicate IDs are against HTML spec:
https://softwareengineering.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really

So, this is a bug.

>>> Though I should have clarified my intent earlier: the idea is to use the
>>> label as a fixed reference to the footnote, so that the link does not
>>> change between exports. This is the same principle as what we do with
>>> links to headings that have a CUSTOM_ID.
>>>
>>> As such, the anchor text can still be the way it is now as an
>>> automatically generated number sequence (^1, ^2, etc.), but the HTML
>>> "id" and "href" values will be constructed based on the label of the
>>> footnote, NOT its number in the sequence.

See the attached tentative patch.
>From 446bfc8c8afb5b2e09d0e0acf7b136b9f0780f5a Mon Sep 17 00:00:00 2001
Message-ID: <446bfc8c8afb5b2e09d0e0acf7b136b9f0780f5a.1713016519.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sat, 13 Apr 2024 16:53:48 +0300
Subject: [PATCH] ox-html: Use non-number footnote names as link anchors

* lisp/ox-html.el (org-html-footnote-section):
* lisp/ox-html.el (org-html-footnote-reference): When footnote has a
non-number name, build link anchors using this name.
* etc/ORG-NEWS (=ox-html=: When exporting footnotes with custom
non-number names, the names are used as link anchors): Announce the
change.

Link: https://orgmode.org/list/875xwngiwx@protesilaos.com
---
 etc/ORG-NEWS|  8 +
 lisp/ox-html.el | 77 +
 2 files changed, 53 insertions(+), 32 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index e61bd6988..1b7040815 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,14 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** Important announcements and breaking changes
+*** =ox-html=: When exporting footnotes with custom non-number names, the names are used as link anchors
+
+Previously, link anchors for footnote references and footnote
+definitions were based on the footnote number: =fn.1=, =fnr.15=, etc.
+
+Now, when the footnote has a non-number name, it is used as an anchor:
+=fn.name=, =fnr.name=.
+
 *** Underline syntax now takes priority over subscript when both are applicable
 
 Previously, Org mode interpreted =(_text_)= as subscript.
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 0471a573b..1262da1aa 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1873,36 +1873,42 @@ (defun org-html-footnote-section (info)
   (pcase (org-export-collect-footnote-definitions info)
 (`nil nil)
 (definitions
+ (format
+  (plist-get info :html-footnotes-section)
+  (org-html--translate "Footnotes" info)
   (format
-   (plist-get info :html-footnotes-section)
-   (org-html--translate "Footnotes" info)
-   (format
-	"\n%s\n"
-	(mapconcat
-	 (lambda (definition)
-	   (pcase definition
-	 (`(,n ,_ ,def)
-	  ;; `org-export-collect-footnote-definitions' can return
-	  ;; two kinds of footnote definitions: inline and blocks.
-	  ;; Since this should not make any difference in the HTML
-	  ;; output, we wrap the inline definitions within
-	  ;; a "footpara" class paragraph.
-	  (let ((inline? (not (org-element-map def org-element-all-elements
-#'identity nil t)))
-		(anchor (org-html--anchor
-			 (format "fn.%d" n)
-			 n
-			 (format " class=\"footnum\" href=\"#fnr.%d\" role=\"doc-backlink\"" n)
-			 info))
-		(contents (org-trim (org-export-data def info
-		(format "%s %s\n"
-			(format (plist-get info :html-footnote-format) anchor)
-			(format "%s"
-(if (not inline?) contents
-  (format "%s"
-	  contents
-	 definitions
-	 "\n"))
+   "\n%s\n"
+   (mapconcat
+	(lambda (definition)
+	  (pcase definition
+	(`(,n ,label ,def)
+ ;; Do not assign number labels as they appear in Org mode
+ ;; - the footnotes are re-numbered by
+ ;; `org-export-get-footnote-number'.  If the label is not
+ ;; a number, keep it.
+ (when (equal label (number-to-string (string-to-number label)))
+   (setq label nil))
+	 ;; `org-export-collect-footnote-definitions' can return
+	 ;; two kinds of footnote definitions: inline and blocks.
+	 ;; Since this should not make any difference in the HTML
+	 ;; output, we wrap the inline definitions within
+	 ;; a "footpara" class 

Re: [BUG] A custom org-num-format-function causes org-latex-preview warn when it called. [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Garid Zorigoo  writes:

> * To Reproduce
>
> 1. Change the org-num-format-function as written above
> 2. (In org-file) Turn-on ~org-num-mode~
> 3. (In org-file) On any equation, change it.
> 4. run ~org-latex-preview~ to preview the equation image.
> 5, run ~org-latex-preview~ go back to text mode. (here warning comes)
> (If warning doesn't appear try from step 3 again)
> (When org-num-mode turned off, it doesn't produce warning)
>
>$\alpha$

Thanks for reporting!
I was able to reproduce using the provided steps using the built-in Org
mode version and using the latest stable Org mode version.
However, I am unable to reproduce using the latest development Org mode
version.

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

Re: [FR] :noweb-wrap header arg

[Ihor Radchenko]

Amy Grinn  writes:

>>> +(while (< (point) (point-max))
>>> +  (unless (looking-at " *\"\\([^\"]+\\)\" *")
>>> +(looking-at " *\\([^ ]+\\)"))
>>
>> May you please explain the rationale behind this regexp? AFAIU, it
>> implies that you want to allow whitespace characters inside :noweb-wrap
>> boundaries. But I do not think that we need to complicate things so much.
>
> That is exactly what I was going for.  I thought about the ways this
> could be used and the most general-purpose, non-syntax-breaking,
> easily-recognizable way I could think of was to use the language's
> line-comment construct followed by the standard << >> characters.
>
> # <>
> ;; <>
> // <>
>
> I can see how it might be harder to maintain to allow whitespace in the
> noweb-wrap header arg.  I could create a separate org-parse-arg-list
> function to ease that burden somewhat.  My opinion is that having the
> option to use the examples above is preferable to using non-standard
> wrappers, from a third-person point-of-view.

Makes sense. Also, see a similar idea being discussed in
https://list.orgmode.org/orgmode/87o7jlzxgn.fsf@localhost/

I recommend the following:

If the value starts from ", use Elisp's `read':
   |"# <<" ">>"
   (read (current-buffer)) ; => "# <<"
   otherwise, consider read until the first whitespace.
   |#<<; >>;
   (re-search-forward (rx (1+ (not whitespace
   #<<;|
   
However, there may be edge cases like

"<< >>"
"<< >>
<< << >>
<< "asd" >>

-- 
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 when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Anush V  writes:

>> Thanks for reporting!
>> I tried to follow your steps, but I am unable to reproduce the problem.
>> May you please attach the exact problematic Org file, so that we can
>> make sure that we do the same thing?
>
> Thanks for the prompt response.
>
> Please find the attached file tmp.org.
>
> Please ensure that the LaTeX preview image for the equation ($\alpha$)
> is not in the directory specified by org-preview-latex-image-directory.
> This warning appears when you generate a preview image that is not
> already present in the directory specified by
> org-preview-latex-image-directory.  I should have clarified this in the
> initial email.  Apologies for any confusion.

I did the following:

1. Save your file to /tmp/
2. rm -rf /tmp/ltximg
3. emacs-29 --version
GNU Emacs 29.3
Copyright (C) 2024 Free Software Foundation, Inc.

4. emacs-29 -Q
5. C-x C-f /tmp/tmp.org 
6. C-n
7. C-c C-x C-l
8. C-c C-x C-l
9. I do not observe any warnings

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

Re: (error "Listing directory failed but ‘access-file’ worked")

[Ihor Radchenko]

Edgar Lux  writes:

> I got this in an Org file:
>
> #+begin_src org
> [[file:Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg]]
> [[file:Figures/Ti19-g(w, eta={0.1,}, R=1e-3).png]]
> #+end_src
>
> The files exist, and can be viewed in image-mode (tested with src_bash{emacs 
> -q}).
> With =C-c C-o= src_emacs-lisp{(org-open-at-point)}, the result is:
>
> #+begin_example
> Debugger entered--Lisp error: (error "Listing directory failed but 
> ‘access-file’ worked")
> ...
>   dired("Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg")
> ...
>   org-link-open-as-file("Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg" nil)

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

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

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Philip Kaludercic]

Philip Kaludercic  writes:

> Sławomir Grochowski  writes:
>
>> Thank you Philip for the explanation and preparing the code snippet. 
>>
>> So what are the next steps?
>> Can you merge your patch?
>
> If this is everything, I can push the change.  But I'll test it first.

I have pushed the changes to master.

-- 
Philip Kaludercic on peregrine

[BUG] A custom org-num-format-function causes org-latex-preview warn when it called. [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Garid Zorigoo]

* What I'm experiencing:
A custom ~org-num-format-function~ causes ~org-latex-preview~ warn when it
is called.

* Exact "Warning" I'm getting.
⛔ Warning (org-element-cache): org-element--cache: Org parser error in
ask.org::648. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
nil

* Info about when this Warning comes:
- Warning comes up when equation change from "previewed-state (image)" back
to "text-state"
- Warning only comes when the equation is changed.

* Setup (the custom ~org-num-format-function~)
#+begin_src elisp
(defun my/org-num-format (numbering)
(concat
 (number-to-string (car numbering)) "." (mapconcat (lambda (x) (format
"%02d" x)) (cdr numbering) ".") " "))

(setq org-num-format-function #'my/org-num-format)
#+end_src

#+RESULTS:
: my/org-num-format

* To Reproduce

1. Change the org-num-format-function as written above
2. (In org-file) Turn-on ~org-num-mode~
3. (In org-file) On any equation, change it.
4. run ~org-latex-preview~ to preview the equation image.
5, run ~org-latex-preview~ go back to text mode. (here warning comes)
(If warning doesn't appear try from step 3 again)
(When org-num-mode turned off, it doesn't produce warning)

   $\alpha$


Emacs  : GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0)
Package: Org mode version 9.6.15 (release_9.6.15 @
/usr/share/emacs/29.3/lisp/org/)

PATCH allow explicit style= in #+cite_export: biblatex

[Pedro Andres Aranda Gutierrez]

HI,
Attached is a small patch to allow explicitly adding style= in the biblatex 
export options, to increase consistency with 
Customisation variables.

Best, /PA



0001-Allow-style-in-cite_export.patch
Description: Binary data