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

[Michael]

Oh-- and pass `processing-type' to `org-create-formula-image' 
explicitly.


--
Michael 

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

[Michael]

Ihor Radchenko  writes:


Michael  writes:


Should we perhaps have different variables for preview & Org
source block evaluation?


Likely yes.

In fact, ob-latex is making use of 
`org-preview-latex-process-alist'
only in a single cond branch in `org-babel-execute:latex' - when 
we have

:file foo.png

However, that branch assumes that 
`org-preview-latex-default-process' is
'dvipng (the default value). If one changes it to, say dvisvgm, 
the

generated image will not be a .png image:

(setq org-preview-latex-default-process 'dvisvgm)

#+begin_src latex :results file link :file test.png
x^2
#+end_src

#+RESULTS:
[[attachment:test.png]]

^ This is actually an svg image, renamed to "test.png".

So, it makes sense for `org-babel-execute:latex' to override
`org-preview-latex-default-process' temporarily, to something 
actually

generating .png file.


Sorry-- got sidetracked by something else. I see what you
mean. OK, so the proposal is: change the ".png" branch in
`org-babel-execute:latex' to override `org-preview-process-alist'
with something that will:

 - actually produce a PNG formatted file
 - by default, run latex more than once, tho this could of
 - course be customized

--
Michael 

Re: Better support admonitions blocks

[Adam Porter]

Hi Ihor, JD, et al,

On 4/4/24 12:04, Ihor Radchenko wrote:

JD Smith  writes:


Pandoc recently added read/write support
 for "admonitions",
which are a GFM construct
 already
supported by other org-exporters, and on GH in markdown.  This
refcard

references an org #{begin,end}_{note,warning,tip,caution,important}
syntax which pandoc now follows (though it does not support the
extra admonitions like danger/error/etc.).

It would be nice to add org support for these 5 admonition blocks
to the C-c C-, org block structure templates, and perhaps allow
block face styling for these as well (ala org-src-block-faces).


CCing Adam. We recently discussed "highlight" blocks in the context
of WORG publishing.


Thanks.


I do not see much problem adding such blocks, although I am not sure
if we want them by default.


I would tend to agree that they probably shouldn't be part of Org's
default configuration (at least, not yet--if they were to become very
widespread in usage, then maybe we could reconsider).

What we may do is to implement something akin link's :export and 
:active-func parameters to allow custom fontification and export. 
(... and add a new :structure-template parameter to auto-add them to 
structure templates)


Then, we can add optional support for all the proposed blocks that
will define how to insert, export, and fontify them.


That would seem good to me.

As far as Worg goes, I'd be in favor of having them available on Worg by 
default; they should be useful for writing documentation.


Thanks,
Adam

Re: [PATCH] lisp/org-element.el: Add repeater-deadline support to org-element

[Morgan Smith]

Hello,

Thanks for the review!

See two patches attached.  One for org and one for worg.  Tests still
pass on my end.

Ihor Radchenko  writes:

> Please also add etc/ORG-NEWS entry - it is org-element API change.

Done

> In addition to changes in Org git, you also need to update
> https://orgmode.org/worg/org-syntax.html#Timestamps and
> https://orgmode.org/worg/dev/org-element-api.html(the page source is at 
> https://git.sr.ht/~bzg/worg)

Done.  Sort of.  My change in org-syntax.org now implies that a repeater
must come before a delay.  I don't know what syntax to use that doesn't
make that implication.  Although I don't see the harm in telling people
to put the repeater first.

> This will match timestamps like <2012-03-29 Thu +1y2y>. You may instead
> use shy group \(?:...\)? around the whole /2y regexp match. (Or even
> rewrite the regexp via rx for better readability, while we are on it).

Done.  It's my first time using rx though.  I don't know if I should be
compiling it or something for performance?

> This is slightly confusing, because "deadline" has multiple meanings in
> Org. repeater-deadline-value/unit would be more readable as the variable name.

Done

>From b285023ca107f7c0fc8b89f7f636cf96bd217207 Mon Sep 17 00:00:00 2001
From: Morgan Smith 
Date: Thu, 4 Apr 2024 16:49:31 -0400
Subject: [PATCH] Document repeater deadline syntax and element api

* dev/org-element-api.org (Timestamp): Add ':repeater-deadline-unit'
and ':repeater-deadline-value'.
* org-syntax.org (Timestamps): Separate definition of repeater and
delay.  Add repeater deadline to repeater definition.
---
 dev/org-element-api.org |  5 +
 org-syntax.org  | 32 +++-
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/dev/org-element-api.org b/dev/org-element-api.org
index ffcda274..9d57238b 100644
--- a/dev/org-element-api.org
+++ b/dev/org-element-api.org
@@ -706,6 +706,11 @@ ** Timestamp
   (symbol: ~year~, ~month~, ~week~, ~day~, ~hour~ or ~nil~).
 - ~:repeater-value~ :: Value of shift, if a repeater is defined
   (integer or ~nil~).
+- ~:repeater-deadline-unit~ :: Unit of shift, if a repeater deadline
+  is defined (symbol: ~year~, ~month~, ~week~, ~day~, ~hour~ or
+  ~nil~).
+- ~:repeater-deadline-value~ :: Value of shift, if a repeater deadline
+  is defined (integer or ~nil~).
 - ~:type~ :: Type of timestamp (symbol: ~active~, ~active-range~,
   ~diary~, ~inactive~, ~inactive-range~).
 - ~:range-type~ :: Type of range (symbol: ~daterange~, ~timerange~ or
diff --git a/org-syntax.org b/org-syntax.org
index bdd372d1..cf477655 100644
--- a/org-syntax.org
+++ b/org-syntax.org
@@ -1743,13 +1743,13 @@ ** Timestamps
 Timestamps are structured according to one of the seven following patterns:
 
 #+begin_example
-<%%(SEXP)> (diary)
-  (active)
-[DATE TIME REPEATER-OR-DELAY]  (inactive)
---   (active range)
- (active range)
-[DATE TIME REPEATER-OR-DELAY]--[DATE TIME REPEATER-OR-DELAY]   (inactive range)
-[DATE TIME-TIME REPEATER-OR-DELAY] (inactive range)
+<%%(SEXP)>   (diary)
+   (active)
+[DATE TIME REPEATER DELAY]   (inactive)
+--   (active range)
+  (active range)
+[DATE TIME REPEATER DELAY]--[DATE TIME REPEATER DELAY]   (inactive range)
+[DATE TIME-TIME REPEATER DELAY]  (inactive range)
 #+end_example
 
 + SEXP :: A string consisting of any characters but =>= and =\n=.
@@ -1763,20 +1763,26 @@ ** Timestamps
 + TIME (optional) :: An instance of the pattern =H:MM= where =H=
   represents a one to two digit number (and can start with =0=), and =M=
   represents a single digit.
-+ REPEATER-OR-DELAY (optional) :: An instance of the following pattern:
++ REPEATER (optional) :: An instance of the following pattern:
   #+begin_example
 MARK VALUE UNIT
+MARK VALUE UNIT/VALUE UNIT
   #+end_example
   Where MARK, VALUE and UNIT are not separated by whitespace characters.
   - MARK :: Either the string =+= (cumulative type), =++= (catch-up type),
-or =.+= (restart type) when forming a repeater, and either =-= (all
-type) or =--= (first type) when forming a warning delay.
+or =.+= (restart type).
+  - VALUE :: A number
+  - UNIT :: Either the character =h= (hour), =d= (day), =w= (week), =m=
+(month), or =y= (year)
++ DELAY (optional) :: An instance of the following pattern:
+  #+begin_example
+MARK VALUE UNIT
+  #+end_example
+  Where MARK, VALUE and UNIT are not separated by whitespace characters.
+  - MARK :: Either  =-= (all type) or =--= (first type).
   - VALUE :: A number
   - UNIT :: Either the character =h= (hour), =d= (day), =w= (week), =m=
 (month), or =y= (year)
-
-There can be two instances of =REPEATER-OR-DELAY= in the timestamp: one
-as a 

Re: Radio links work only in small numbers

[Rudolf Adamkovič]

Ihor Radchenko  writes:

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

Thanks everyone for chiming in and fixing the problem.  I have been
unexpectedly busy lately, hence the radio silence [pun intended].

Great work!

Rudy
-- 
"The whole science is nothing more than a refinement of everyday
thinking."  --- Albert Einstein, 1879-1955

Rudolf Adamkovič  [he/him]
Studenohorská 25, 84103 Bratislava, Slovakia, European Union

Re: Has VISIBILITY property become case-sensitive?

[Richard Stanton]

Actually, it didn’t!

But now I’m not seeing the original behavior either, though I haven’t changed 
anything. Don’t spend any more time on this - I’ll report back if I learn 
anything else.

Best

Richard




> On Apr 4, 2024, at 12:42 PM, Richard Stanton  wrote:
> 
> Here’ s a very simple org file that exhibits the behavior I describe
> 
> -
> 
> #+STARTUP: overview
> 
> * Hidden
> - This should not initially appear
> - Nor this
> 
> * Visible
> :PROPERTIES:
> :VISIBILITY: content
> :END:
> - This should appear
> - And this
> 
> ———
> 
> Change the case of the word “VISIBILILTY” and the file's behavior on first 
> loading changes.
> 
> When I load this file using emacs -Q (which loads org 9.6.15), both sections 
> appear folded regardless of the case of “visibility”…! Is there some 
> configuration variable I need to set?
> 
> 
> 
> 
> 
>> On Apr 4, 2024, at 12:34 PM, Ihor Radchenko > > wrote:
>> 
>> Richard Stanton mailto:rhstan...@berkeley.edu>> 
>> writes:
>> 
>>> My org file has the header line 
>>> 
>>> #+STARTUP: overview
>>> 
>>> One section contains the properties drawer
>>> 
>>> :PROPERTIES:
>>> :Visibility: content
>>> :END:
>>> 
>>> This used to show the contents of that subtree on first loading the file, 
>>> but it no longer does. Experimentation shows that it works if I change 
>>> “Visibility” to “VISIBILITY”. Is it a deliberate change to require upper 
>>> case here? By the way, this is using org version 9.7pre
>> 
>> I am unable to reproduce.
>> Please provide more details, preferably starting from emacs -Q.
>> 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: [PATCH] org-faq.org: rename org-export-htmlize-* options to org-html-htmlize-*

[Rudolf Adamkovič]

Ihor Radchenko  writes:

While you are on it, ...

> +Normally, when you export an agenda view from within emacs, htmlize
> +will convert your face definitions to direct color css styles inlined

emacs -> Emacs (per English, and to match Org in the same sentence)
css -> CSS (per English, and to match HTML in the same sentence)

> +supply custom css styles to make these classes look any way you like.
> +To generate face definitions for a CSS file based on any faces you are
> +currently using in Emacs, you can use the following command:

css -> CSS (per English, and to match CSS in the next sentence)

Rudy
-- 
"It is far better to have a question that can't be answered than an
answer that can't be questioned."  --- Carl Sagan

Rudolf Adamkovič  [he/him]
Studenohorská 25, 84103 Bratislava, Slovakia, European Union

Re: Has VISIBILITY property become case-sensitive?

[Richard Stanton]

Here’ s a very simple org file that exhibits the behavior I describe

-

#+STARTUP: overview

* Hidden
- This should not initially appear
- Nor this

* Visible
:PROPERTIES:
:VISIBILITY: content
:END:
- This should appear
- And this

———

Change the case of the word “VISIBILILTY” and the file's behavior on first 
loading changes.

When I load this file using emacs -Q (which loads org 9.6.15), both sections 
appear folded regardless of the case of “visibility”…! Is there some 
configuration variable I need to set?





> On Apr 4, 2024, at 12:34 PM, Ihor Radchenko  wrote:
> 
> Richard Stanton mailto:rhstan...@berkeley.edu>> 
> writes:
> 
>> My org file has the header line 
>> 
>> #+STARTUP: overview
>> 
>> One section contains the properties drawer
>> 
>> :PROPERTIES:
>> :Visibility: content
>> :END:
>> 
>> This used to show the contents of that subtree on first loading the file, 
>> but it no longer does. Experimentation shows that it works if I change 
>> “Visibility” to “VISIBILITY”. Is it a deliberate change to require upper 
>> case here? By the way, this is using org version 9.7pre
> 
> I am unable to reproduce.
> Please provide more details, preferably starting from emacs -Q.
> 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: Has VISIBILITY property become case-sensitive?

[Ihor Radchenko]

Richard Stanton  writes:

> My org file has the header line 
>
> #+STARTUP: overview
>
> One section contains the properties drawer
>
> :PROPERTIES:
> :Visibility: content
> :END:
>
> This used to show the contents of that subtree on first loading the file, but 
> it no longer does. Experimentation shows that it works if I change 
> “Visibility” to “VISIBILITY”. Is it a deliberate change to require upper case 
> here? By the way, this is using org version 9.7pre

I am unable to reproduce.
Please provide more details, preferably starting from emacs -Q.
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: [BUG] Org export fails on $k$-ary

[Ihor Radchenko]

Jens Lechtenboerger  writes:

> I would expect this to be exported to HTML and LaTeX correctly:
> "A $k$-ary function has $k$ arguments"
> 
> In 12.5.1 LaTeX fragments, this use of a hyphen is documented:
> "To avoid conflicts with currency specifications, single ‘$’
> characters are only recognized as math delimiters if the enclosed text
> contains at most two line breaks, is directly attached to the ‘$’
> characters with no whitespace in between, and if the closing ‘$’ is
> followed by whitespace, punctuation or a dash."
>
> However, the HTML export result contains
> "A $k$-ary function has \(k\) arguments",
> which is not rendered correctly.  The first two dollar signs should
> be replaced as well.
>
> The LaTeX result contains "A \$k\$-ary ...", which produces literal
> dollar signs, not math mode.

This is expected. The manual is not accurate here (and has been fixed on
development version of Org mode).
See 
https://list.orgmode.org/orgmode/f0597d96-a287-2c48-7897-6b8737c95...@posteo.eu/

> In contrast, "A \(k\)-ary..." works.

This is also expected. Note that the latter syntax is preferred. We do
not recommend $k$ because it has edge cases like you encountered.

Canceled.

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

Has VISIBILITY property become case-sensitive?

[Richard Stanton]

My org file has the header line 

#+STARTUP: overview

One section contains the properties drawer

:PROPERTIES:
:Visibility: content
:END:

This used to show the contents of that subtree on first loading the file, but 
it no longer does. Experimentation shows that it works if I change “Visibility” 
to “VISIBILITY”. Is it a deliberate change to require upper case here? By the 
way, this is using org version 9.7pre

Best,

Richard Stanton

Re: How to export a single subtree but include document preamble?

[Scott Randby]

On 4/4/24 14:11, Richard Stanton wrote:
Thanks for the suggestion!

It would still be nice (i.e., you wouldn’t have to do this for every section 
you ever want to export) to have a way of specifying a line that gets executed 
for EVERY (say) LaTeX export. Or else an option to do something like include 
everything in the file before the first section header.




That would be a nice feature, but I also like using the 'PROPERTIES' drawer 
because it enables me to have very fine control over the export of a subtree. A 
typical drawer I use looks like this:

:PROPERTIES:
:EXPORT_TITLE: *Subtree Title*
:EXPORT_FILE_NAME: Exported-Subtree
:EXPORT_LATEX_HEADER_EXTRA: \input{latex-preamble.tex} 
\hypersetup{pdftitle={Subtree Title},pdfauthor={Scott 
Randby},pdfsubject={},pdfkeywords={},pdfproducer={Emacs 
Org},pdfcreator={pdflatex}} 
\hypersetup{colorlinks=true,urlcolor=blue,linkcolor=blue} %\pagestyle{empty} % 
Turn page numbering off
:EXPORT_OPTIONS: h:4 author:nil email:nil date:nil creator:nil timestamp:nil 
tags:nil num:0 toc:nil
:END:

Scott

Re: How to export a single subtree but include document preamble?

[Richard Stanton]

On Apr 4, 2024, at 11:11 AM, Richard Stanton  wrote:
> 
>> I don't know if this does what you want, but I use a ‘PROPERTIES’ drawer 
>> right below the subtree's headline and in that drawer, I put the following 
>> code:
>> 
>> :EXPORT_LATEX_HEADER_EXTRA: \input{latex-preamble.tex}
>> 
>> Scott Randby
> 
> Thanks for the suggestion! 
> 
> It would still be nice (i.e., you wouldn’t have to do this for every section 
> you ever want to export) to have a way of specifying a line that gets 
> executed for EVERY (say) LaTeX export. Or else an option to do something like 
> include everything in the file before the first section header.

That capability does (if you’re careful) seem to exist. In my case, I just had 
to replace

#+include: setup.org 

with 

#+setupfile: setup.org

and now exporting includes the macro definitions in setup.org 
 even when I’m only exporting a subtree.

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

[Sławomir Grochowski]

Ihor Radchenko  writes:

> Do not forget to add :package-version. 

Thank you for bringing it to my attention.

Patch in attachment.

>From eb71166693065534be9effdc28aea54bb24e64d2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C5=82awomir=20Grochowski?= 
Date: Sat, 16 Mar 2024 13:29:53 +0100
Subject: [PATCH] lisp/org-colview.el: Add defcustom
 `org-columns-checkbox-allowed-values'

* lisp/org-colview.el Add defcustom `org-columns-checkbox-allowed-values'.
(org-columns-next-allowed-value): Introduce variable `org-columns-checkbox-allowed-values'.

This would allow to use more than two states ("[ ]", "[X]") in
columns with SUMMARY-TYPE that use checkbox ("X", "X/", "X%").
For example you can add an intermediate state ("[-]").
Or empty state ("") to remove checkbox.

* etc/ORG-NEWS New option ~org-columns-checkbox-states~
---
 etc/ORG-NEWS| 7 +++
 lisp/org-colview.el | 8 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ca73f06e7..72caf073a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1753,6 +1753,13 @@ following properties: ~:hook~, ~:prepare-finalize~,
 prior to their global counterparts for the selected template.
 
 ** New options
+*** New option ~org-columns-checkbox-allowed-values~
+
+This would allow to use more than two states ("[ ]", "[X]") in
+columns with SUMMARY-TYPE that use checkbox ("X", "X/", "X%").
+For example you can add an intermediate state ("[-]").
+Or empty state ("") to remove checkbox.
+
 *** A new option for custom setting ~org-refile-use-outline-path~ to show document title in refile targets
 
 Setting ~org-refile-use-outline-path~ to ~'title~ will show title
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index d71c84a76..5545c5691 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -59,6 +59,12 @@
 
 ;;; Configuration
 
+(defcustom org-columns-checkbox-allowed-values '("[ ]" "[X]")
+  "Allowed values for columns with SUMMARY-TYPE that use checkbox."
+  :group 'checkbox
+  :package-version '(Org . "9.6")
+  :type '(repeat string))
+
 (defcustom org-columns-modify-value-for-display-function nil
   "Function that modifies values for display in column view.
 For example, it can be used to cut out a certain part from a time stamp.
@@ -737,7 +743,7 @@ an integer, select that value."
 	  (let ((all
 		 (or (org-property-get-allowed-values pom key)
 		 (pcase (nth column org-columns-current-fmt-compiled)
-		   (`(,_ ,_ ,_ ,(or "X" "X/" "X%") ,_) '("[ ]" "[X]")))
+		   (`(,_ ,_ ,_ ,(or "X" "X/" "X%") ,_) org-columns-checkbox-allowed-values))
 		 (org-colview-construct-allowed-dates value
 	(if previous (reverse all) all
 (when (equal key "ITEM") (error "Cannot edit item headline from here"))
-- 
2.30.2



Regards,
-- 
Slawomir Grochowski

Re: How to export a single subtree but include document preamble?

[Richard Stanton]

> I don't know if this does what you want, but I use a ‘PROPERTIES’ drawer 
> right below the subtree's headline and in that drawer, I put the following 
> code:
> 
> :EXPORT_LATEX_HEADER_EXTRA: \input{latex-preamble.tex}
> 
> Scott Randby

Thanks for the suggestion! 

It would still be nice (i.e., you wouldn’t have to do this for every section 
you ever want to export) to have a way of specifying a line that gets executed 
for EVERY (say) LaTeX export. Or else an option to do something like include 
everything in the file before the first section header.

[BUG] Org export fails on $k$-ary

[Jens Lechtenboerger]

Dear all,

I would expect this to be exported to HTML and LaTeX correctly:
"A $k$-ary function has $k$ arguments"

In 12.5.1 LaTeX fragments, this use of a hyphen is documented:
"To avoid conflicts with currency specifications, single ‘$’
characters are only recognized as math delimiters if the enclosed text
contains at most two line breaks, is directly attached to the ‘$’
characters with no whitespace in between, and if the closing ‘$’ is
followed by whitespace, punctuation or a dash."

However, the HTML export result contains
"A $k$-ary function has \(k\) arguments",
which is not rendered correctly.  The first two dollar signs should
be replaced as well.

The LaTeX result contains "A \$k\$-ary ...", which produces literal
dollar signs, not math mode.

In contrast, "A \(k\)-ary..." works.

This happens with Org mode version 9.6.15 and with
9.7-pre (release_9.6.24-1336-gc8d133 @ ...).

Recipe:
emacs -Q
(add-to-list 'load-path "~/src/org-mode/lisp")
Then export an Org buffer/file with the above line:
C-c C-e h h
C-c C-e l l

Best wishes,
Jens


smime.p7s
Description: S/MIME cryptographic signature

Re: Better support admonitions blocks

[Ihor Radchenko]

JD Smith  writes:

> Pandoc recently added read/write support 
>  for "admonitions", which are a 
> GFM construct  already 
> supported by other org-exporters, and on GH in markdown.  This refcard 
> 
>  references an org #{begin,end}_{note,warning,tip,caution,important} syntax 
> which pandoc now follows (though it does not support the extra admonitions 
> like danger/error/etc.). 
>
> It would be nice to add org support for these 5 admonition blocks to the C-c 
> C-, org block structure templates, and perhaps allow block face styling for 
> these as well (ala org-src-block-faces).

CCing Adam. We recently discussed "highlight" blocks in the context of
WORG publishing.

I do not see much problem adding such blocks, although I am not sure if
we want them by default.

What we may do is to implement something akin link's :export and
:active-func parameters to allow custom fontification and export.
(... and add a new :structure-template parameter to auto-add them to
structure templates)

Then, we can add optional support for all the proposed blocks that will
define how to insert, export, and fontify them.

-- 
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-element.el: Add repeater-deadline support to org-element

[Ihor Radchenko]

Morgan Smith  writes:

> I would like to add some features to org-habit (something I have tried
> unsuccessfully in the past).  Before I do that, I would like to switch
> org-habit over to the org-element api.  Before I do that, I would like to
> extend org-element to support the org-habit syntax.
>
> Let me know what you think!  All the tests pass on my machine.

This is a welcome addition. Thanks!

Please also add etc/ORG-NEWS entry - it is org-element API change.

In addition to changes in Org git, you also need to update
https://orgmode.org/worg/org-syntax.html#Timestamps and
https://orgmode.org/worg/dev/org-element-api.html
(the page source is at https://git.sr.ht/~bzg/worg)

> +   (string-match
> +
> "\\([.+]?\\+\\)\\([0-9]+\\)\\([hdwmy]\\)/?\\([0-9]+\\)?\\([hdwmy]\\)?"

This will match timestamps like <2012-03-29 Thu +1y2y>. You may instead
use shy group \(?:...\)? around the whole /2y regexp match. (Or even
rewrite the regexp via rx for better readability, while we are on it).

> + (let ((deadline-value (org-element-property 
> :repeater-deadline-value timestamp))
> +   (deadline-unit (org-element-property 
> :repeater-deadline-unit timestamp)))

This is slightly confusing, because "deadline" has multiple meanings in
Org. repeater-deadline-value/unit would be more readable as the variable name.

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

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

[Bruno Barbier]

Rudolf Adamkovič  writes:

>
> +1 for the full name.
>
> Searching 'M-x' for 'region' gives 229 results on my Emacs, so there is
> a precedent.  In fact, when I first read the name 'reglock', I took
> 'reg' for *not* a region, but register or registry, precisely because
> Emacs consistently spells the word out in full.
>

Thanks for your input.

Note that "reglock" is the current technical name, an implementation
detail, and for developer only.  The only current command using that
term (that shows up using M-x) is a debugging internal command
(org-pending--describe-reglock-at-point).

I'm thinking about using just "lock" but I'll keep using "reglock" for
now, as it's easier to search/replace, until the public API is
finalized.

Bruno

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

[Bruno Barbier]

Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>> I've pushed an update that should address most of your comments.
>
> Thanks!
>
>> I've found a better name: I'm now calling it a "lock".  So I renamed
>> "PENREG" into "REGLOCK" as "region lock".  The structure is now
>> `org-pending-reglock'.
>
> I slightly dislike short names and would prefer region-lock, but not a
> big deal - it is just my personal style preference.

It's more about being one word than being short, and being a new and
opaque word.  REGLOCK is a new technical term; it's definition is the
cl-defstruct.  For normal use, this is just a black box to pass
around.

I'll probably switch to using just "lock".



>> I've renamed org-pending-ti-send-update to org-pending-send-update
>> (now that the task control is gone, the prefix becomes useless).
>
> I have a further request on interaction with penreg objects.
> I feel that it is not ideal that overlays associated with penreg objects
> cannot be fully controlled by the callers.

I'm trying to limit the public API surface.  I don't think we should
leak that we are currently using a mix of overlays and text
properties.


> In particular, I'd like to see some way to
>
> 1. Create penreg object without locking the region, so that scheduled-at
>time is not set immediately and status overlay is not displayed.
>Then, `org-pending-send-update' could send :schedule signal to
>perform actual lock.

Using the term "region" was confusing, sorry.  That's why I switched
to region "lock".  I don't think there is a use to create a lock that
doesn't lock.

Also, that might be tricky to implement: `org-pending-send-update' is
called asynchronously, from the user point of view.  Having regions
that suddenly become locked, independently of what the user is
currently doing (if we implement the :schedule message), might be
difficult.

What use do you have in mind ?


> 2. Act on the outcome overlays - there is currently no way to remove
>them using penreg object.

I've added a funcion `org-pending-delete-outcome-marks' to manually
delete outcome marks that are in a given region.

Else, everything is handled automatically. Once the outcome is known,
the reglock is dead (not live-p).  org-pending may leave outcome marks
about the outcomes (outcome marks are optional).  The outcome marks
automatically disappear if the user remove the section, or, if a new
lock is created for the same region.


>Maybe :cancel signal? Canceled penreg
>objects can then be garbage-collected from the manager.

Cancel is handled by sending a failure message (see
 `org-pending-cancel').  It's customizable using the reglock field
 ~org-pending-reglock-user-cancel-function~, which can decide what to
 do (like kill a process) and which can send a better outcome.
 Standard 'cancel' leaves a failure outcome mark.
 
I've added garbage collections of useless reglocks (success or
failure): see `org-pending--mgr-garbage-collect'.



> Also, the top-level commentary is getting incomplete and out-of-sync at
> this point. May you work towards more detailed top-level description of
> the library?

Sorry. I tried hard to keep it in sync with all the modifications.

I found it too much work, and, possibly overwhelming for the reader,
to explain everything in the top-level "Commentary" section.

That's why I deleted everything that wasn't mandatory to understand
the core features.

Everything should be documented as elisp documentation strings,
following the documentation of `org-pending' and
`org-pending-send-update', and, from code comments.


> May you work towards more detailed top-level description of
> the library?
> This will make your ideas more explicit and make life
> easier for me during the further review (now, I have to guess what you
> meant by some parts of the code).

Sorry, and thank you again for your time.

I tried to improve the overall documentation.  I hope it's going to be
easier for you, and others.


>>> HANLDER will be another object we may expose via something like
>>> (org-pending-handler ( on-success-function on-cancel-function on-await 
>>> on-insert-logs) ...)
>>> Then, PENREG will call appropriate handler function as needed.
>>
>> As the task-control is now gone:
>>   - get/await is gone,
>>   - cancel is now a hook/function of REGLOCK,
>>   - insert-details is now a hook/function too of REGLOCK.
>>> ...
>>> Yes. Lexical context is implicit and harder to debug, while storing
>>> necessary data explicitly in the struct slots is more robust as we are
>>> very clear which context is intended to be captured.
>>
>> Done.
>
> Is there any reason why you hide the extra information behind :-alist
> filed? Why not directly adding extra fields with proper documentation?

To hide them, indeed :)

The API for 'get-status and 'get-live-p are
`org-pending-reglock-status' and `org-pending-reglock-live-p' (they
are read-only).  The API for the new `useless-p' is
`org-pending-reglock-useless-p' (it's read-only 

Re: [FR] 'org-columns-next-allowed-value' for 'summary-checkbox'es functions should have 'intermediate state' '[-]'

[Ihor Radchenko]

Sławomir Grochowski  writes:

> After thinking about I have found a better name:
> ...
> What do you think? 

Looks reasonable.

> (defcustom org-columns-checkbox-allowed-values '("[ ]" "[X]")
>   "Allowed values for column with SUMMARY-TYPE that use checkbox."
>   :group 'checkbox
>   :type '(repeat string))

Do not forget to add :package-version.

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

Re: [PATCH] doc/misc/org.org: Corrected info mixup.

[Ihor Radchenko]

Lee Thompson  writes:

> This is my first contribution guys please be patient if I've got
> something wrong. Let me know if the changelog needs more info.

Applied, onto bugfix, with minor amendments to the commit message.
I removed the "." at the end of the commit summary and removed ";" - we
do not usually use this Emacs convention. I also adapted the patch to
the Org git repository (it was originally against Emacs git repository).
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9895ed396

Thanks for your contribution!
You are now listed as one of the Org mode contributors.
https://git.sr.ht/~bzg/worg/commit/47b175ff

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

Better support admonitions blocks

[JD Smith]

Pandoc recently added read/write support 
 for "admonitions", which are a GFM 
construct  already 
supported by other org-exporters, and on GH in markdown.  This refcard 

 references an org #{begin,end}_{note,warning,tip,caution,important} syntax 
which pandoc now follows (though it does not support the extra admonitions like 
danger/error/etc.). 

It would be nice to add org support for these 5 admonition blocks to the C-c 
C-, org block structure templates, and perhaps allow block face styling for 
these as well (ala org-src-block-faces).

Re: [PATCH] org-faq.org: rename org-export-htmlize-* options to org-html-htmlize-*

[Ihor Radchenko]

Ihor Radchenko  writes:

> dongdigua  writes:
>
>> sorry, my email client wrapped the lines
>
> Thanks!
> I looked into this again, and I can see that the FAQ entry is dubious.
> ...
> So, we need a much more significant rewrite to make this FAQ entry up to
> date.

See the attached alternative version of the patch.

>From 3d6e938c09f896c9c55575b318829d2ef7d1c9ea Mon Sep 17 00:00:00 2001
Message-ID: <3d6e938c09f896c9c55575b318829d2ef7d1c9ea.1712229941.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Thu, 4 Apr 2024 14:22:01 +0300
Subject: [PATCH] org-faq.org (How can I preserve faces...): Update answer

* org-faq.org (How can I preserve faces when I export an agenda from
the command line?): Fix the answer, making sure that the instructions
actually work on the latest Org mode.

Link: https://list.orgmode.org/orgmode/ps2p216mb113830307ee638a1ff044f55a0...@ps2p216mb1138.korp216.prod.outlook.com/
---
 org-faq.org | 51 +--
 1 file changed, 29 insertions(+), 22 deletions(-)

diff --git a/org-faq.org b/org-faq.org
index 3674165c..f2b7d510 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -3643,41 +3643,48 @@ ** How can I preserve faces when I export an agenda from the command line?
 #+index: Export!Agenda
 #+index: Export!Faces
 
-Normally, when you export an org file or an agenda view from within
-emacs, htmlize will convert your face definitions to direct color css
-styles inlined into each == object, resulting in an HTML output
-that preserves the general look of your Org buffers and agenda views.
+Normally, when you export an agenda view from within emacs, htmlize
+will convert your face definitions to direct color css styles inlined
+into each == object, resulting in an HTML output that preserves
+the general look of your Org buffers and agenda views.
 
 Let's say you generate an export from the command line, such as the
 following:
 
-: emacs -batch -l ~/.emacs -eval '(org-batch-agenda "e")'
-
-or
-
-: emacs -batch -l ~/.emacs -eval '(org-publish-all)'
+: emacs -batch -l ~/.emacs.d/init.el \
+: -eval '(progn \
+: (org-agenda nil "a") \
+: (org-agenda-write "~/agenda.html"))'
 
 In such an instance, the exported HTML will contain only very basic
 color styles. The reason is that when Emacs is run in batch mode, it
 does not have a display and therefore only rudimentary face
 definitions.  If you'd like to use more complex styles, you'll have to
-make sure that the export process only assigns classes instead of
-direct color values.  This can be done by binding the variable
-=org-export-htmlize-output-style= to =css= for the duration of the
-export, for example with
-
-: emacs -batch -l ~/.emacs
-:   -eval '(let ((org-export-htmlize-generate-css (quote css)))
-:(org-batch-agenda "e"))'
+supply custom css styles to make these classes look any way you like.
+To generate face definitions for a CSS file based on any faces you are
+currently using in Emacs, you can use the following command:
 
-Then you can use a style file to make these classes look any way you
-like.  To generate face definitions for a CSS file based on any faces
-you are currently using in Emacs, you can use the following command:
+#+begin_src emacs-lisp
+(defun org-html-htmlize-generate-css-for-agenda ()
+  "Create the CSS for all font definitions in the current Emacs session.
+Unlike `org-html-htmlize-generate-css', do not prepend
+`org-html-htmlize-font-prefix' to face names."
+  (interactive)
+  (require 'ox-html)
+  (let ((org-html-htmlize-font-prefix ""))
+(org-html-htmlize-generate-css)))
+#+end_src
 
-: M-x org-export-htmlize-generate-css RET
+: M-x org-html-htmlize-generate-css-for-agenda RET
 
 This will generate a =...= section, the content of
-which you can add to your style file.
+which you can manually copy to your style file:
+
+: emacs -batch -l ~/.emacs.d/init.el \
+: -eval '(let ((org-agenda-export-html-style \
+:   "")) \
+: (org-agenda nil "a") \
+: (org-agenda-write "~/agenda.html"))'
 
 ** How can I avoid dark color background when exporting agenda to ps format?
:PROPERTIES:
-- 
2.44.0


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

Re: Inactive timestamps show up in agenda

[Michael Maurer]

On Thu, 4 Apr 2024 at 13:01, Ihor Radchenko  wrote:
>
> Michael Maurer  writes:
>
> > Both <2024-04-04 Do> and [2024-04-04 Do] show up in Agenda-View.
> > Google couldn't really help me on that, and I'm thinking maybe there's
> > a flag I set to include every timestamp in Agenda? I don't know.
> >
> > For reference, the entries look like this:
> > * TEST
> > <2024-04-04 Do>
> > [2024-04-04 Do]
> >
> > shows as
> >
> > Thu   4 Apr 2024
> >  TEST
> >  [ TEST
> >
> > Yes, there's no closing square bracket.
>
> Check your customization for `org-agenda-include-inactive-timestamps'.
>

Yes, that was it. Thank you!

Re: Inactive timestamps show up in agenda

[Ihor Radchenko]

Michael Maurer  writes:

> Both <2024-04-04 Do> and [2024-04-04 Do] show up in Agenda-View.
> Google couldn't really help me on that, and I'm thinking maybe there's
> a flag I set to include every timestamp in Agenda? I don't know.
>
> For reference, the entries look like this:
> * TEST
> <2024-04-04 Do>
> [2024-04-04 Do]
>
> shows as
>
> Thu   4 Apr 2024
>  TEST
>  [ TEST
>
> Yes, there's no closing square bracket.

Check your customization for `org-agenda-include-inactive-timestamps'.

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

Inactive timestamps show up in agenda

[Michael Maurer]

Both <2024-04-04 Do> and [2024-04-04 Do] show up in Agenda-View.
Google couldn't really help me on that, and I'm thinking maybe there's
a flag I set to include every timestamp in Agenda? I don't know.

For reference, the entries look like this:
* TEST
<2024-04-04 Do>
[2024-04-04 Do]

shows as

Thu   4 Apr 2024
 TEST
 [ TEST

Yes, there's no closing square bracket.