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

[Morgan Smith]

* lisp/org-element.el (org-element-timestamp-parser,
org-element-timestamp-interpreter): Add support for repeater
deadlines.  Adds two new properties: ':repeater-deadline-value' and
':repeater-deadline-unit'.

* testing/lisp/test-org-element.el (test-org-element/timestamp-parser,
test-org-element/timestamp-interpreter): Test support for repeater
deadlines.
---

Hello!

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.

Thanks,

Morgan

 lisp/org-element.el  | 58 +---
 testing/lisp/test-org-element.el | 38 +++--
 2 files changed, 74 insertions(+), 22 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index f4eec1695..8d3b8ce44 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4288,12 +4288,13 @@ Assume point is at the target."
   "Parse time stamp at point, if any.
 
 When at a time stamp, return a new syntax node of `timestamp' type
-containing `:type', `:range-type', `:raw-value', `:year-start', `:month-start',
-`:day-start', `:hour-start', `:minute-start', `:year-end',
-`:month-end', `:day-end', `:hour-end', `:minute-end',
+containing `:type', `:range-type', `:raw-value', `:year-start',
+`:month-start', `:day-start', `:hour-start', `:minute-start',
+`:year-end', `:month-end', `:day-end', `:hour-end', `:minute-end',
 `:repeater-type', `:repeater-value', `:repeater-unit',
-`:warning-type', `:warning-value', `:warning-unit', `:begin', `:end'
-and `:post-blank' properties.  Otherwise, return nil.
+`:repeater-deadline-value', `:repeater-deadline-unit', `:warning-type',
+`:warning-value', `:warning-unit', `:begin', `:end' and `:post-blank'
+properties.  Otherwise, return nil.
 
 Assume point is at the beginning of the timestamp."
   (when (looking-at-p org-element--timestamp-regexp)
@@ -4326,20 +4327,28 @@ Assume point is at the beginning of the timestamp."
   (date-end 'daterange)
   (time-range 'timerange)
   (t nil)))
-(repeater-props
- (and (not diaryp)
-  (string-match "\\([.+]?\\+\\)\\([0-9]+\\)\\([hdwmy]\\)"
-raw-value)
-  (list
-   :repeater-type
-   (let ((type (match-string 1 raw-value)))
- (cond ((equal "++" type) 'catch-up)
-   ((equal ".+" type) 'restart)
-   (t 'cumulate)))
-   :repeater-value (string-to-number (match-string 2 
raw-value))
-   :repeater-unit
-   (pcase (string-to-char (match-string 3 raw-value))
- (?h 'hour) (?d 'day) (?w 'week) (?m 'month) (_ 'year)
+ (repeater-props
+  (and (not diaryp)
+   (string-match
+
"\\([.+]?\\+\\)\\([0-9]+\\)\\([hdwmy]\\)/?\\([0-9]+\\)?\\([hdwmy]\\)?"
+raw-value)
+   (nconc
+(list
+ :repeater-type
+ (let ((type (match-string 1 raw-value)))
+   (cond ((equal "++" type) 'catch-up)
+ ((equal ".+" type) 'restart)
+ (t 'cumulate)))
+ :repeater-value (string-to-number (match-string 2 
raw-value))
+ :repeater-unit
+ (pcase (string-to-char (match-string 3 raw-value))
+   (?h 'hour) (?d 'day) (?w 'week) (?m 'month) (_ 'year)))
+(when (and (match-string 4 raw-value) (match-string 5 
raw-value))
+  (list
+   :repeater-deadline-value (string-to-number 
(match-string 4 raw-value))
+   :repeater-deadline-unit
+   (pcase (string-to-char (match-string 5 raw-value))
+ (?h 'hour) (?d 'day) (?w 'week) (?m 'month) (_ 
'year)))
 (warning-props
  (and (not diaryp)
   (string-match "\\(-\\)?-\\([0-9]+\\)\\([hdwmy]\\)" raw-value)
@@ -4407,7 +4416,16 @@ Assume point is at the beginning of the timestamp."
 (let ((val (org-element-property :repeater-value 
timestamp)))
   (and val (number-to-string val)))
 (pcase (org-element-property :repeater-unit timestamp)
-  (`hour "h") (`day "d") (`week "w") (`month "m") (`year 
"y"
+  (`hour "h") (`day "d") (`week "w") (`month "m") (`year 
"y"))
+ (let ((deadline-value (org-element-property 
:repeater-deadline-value timestamp))
+   (dea

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

[Scott Randby]

On 4/3/24 15:00, Richard H. Stanton wrote:

I just tried to export a single subtree from an org document to a PDF file:

1) Type  C-c C-e [org-export-dispatch]
2) C-s to narrow to subtree
3) l -> o to export to PDF via LaTeX

However, instead of exporting the portion of the file I want, I get the error 
message

Undefined Org macro: newline; aborting

That macro is defined in a setup file that is #+included at the top of the 
file, so exporting the entire file works fine.

I assume the problem is that when I export only one subtree, the setup file is 
not #+included, and I can see it sort of makes sense, but it would be nice if 
there were an option to include one or more lines from the preamble when 
exporting just a subtree, since otherwise exporting a subtree doesn’t actually 
work! Is there a simple way to do this?



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

How to export a single subtree but include document preamble?

[Richard H. Stanton]

I just tried to export a single subtree from an org document to a PDF file:

1) Type  C-c C-e [org-export-dispatch]
2) C-s to narrow to subtree
3) l -> o to export to PDF via LaTeX

However, instead of exporting the portion of the file I want, I get the error 
message

Undefined Org macro: newline; aborting

That macro is defined in a setup file that is #+included at the top of the 
file, so exporting the entire file works fine.

I assume the problem is that when I export only one subtree, the setup file is 
not #+included, and I can see it sort of makes sense, but it would be nice if 
there were an option to include one or more lines from the preamble when 
exporting just a subtree, since otherwise exporting a subtree doesn’t actually 
work! Is there a simple way to do this?

Thanks.

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

[Sławomir Grochowski]

Ihor Radchenko  writes:

> It is not very clear when this feature is useful. May you provide a
> small example as a part of the news entry and also
> `org-columns-checkbox-states' docstring?

Yes. You are right. Thank you.
After thinking about I have found a better name:

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

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

What do you think? 

-- 
Slawomir Grochowski

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

[Lee Thompson]

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

>From 61e18c9e26f6bdbaaff785969881624f9a1c7068 Mon Sep 17 00:00:00 2001
From: Lee Thompson 
Date: Wed, 3 Apr 2024 16:20:15 +0100
Subject: [PATCH] ; * doc/misc/org.org (Header and sectioning structure):
 Corrected info mixup.

TINYCHANGE
---
 doc/misc/org.org | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/misc/org.org b/doc/misc/org.org
index 05ab5b36ca0..cb126ffb257 100644
--- a/doc/misc/org.org
+++ b/doc/misc/org.org
@@ -14328,8 +14328,8 @@ tables, to HTML.
 
 #+vindex: org-md-headline-style
 Based on ~org-md-headline-style~, Markdown export can generate
-headlines of both /atx/ and /setext/ types.  /atx/ limits headline
-levels to two whereas /setext/ limits headline levels to six.  Beyond
+headlines of both /atx/ and /setext/ types.  /setext/ limits headline
+levels to two whereas /atx/ limits headline levels to six.  Beyond
 these limits, the export back-end converts headlines to lists.  To set
 a limit to a level before the absolute limit (see [[*Export Settings]]).
 
-- 
2.34.1

Re: 'Markdown Export' Info Wrong?

[Ihor Radchenko]

Lee Thompson  writes:

> I noticed when browsing the info manual for Markdown Export options this
> line concerning headline styles seems to be wrong:
>
>> Header and sectioning structure
>> ---
>> 
>> Based on ‘org-md-headline-style’, Markdown export can generate headlines
>> of both _atx_ and _setext_ types.  _atx_ limits headline levels to two
>> whereas _setext_ limits headline levels to six.  Beyond these limits,
>> the export back-end converts headlines to lists.  To set a limit to a
>> level before the absolute limit (see *note Export Settings::).
>
> Should this not be the other way round? ATX headlines being repeated
> hashes limited to 6 levels and Setext headlines being underlined with
> equals for top-level then dashes for second-level.

Looks like you are right.

> Is this a quick change I could make myself and contribute?

Yes. See https://orgmode.org/worg/org-contribute.html#first-patch

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

'Markdown Export' Info Wrong?

[Lee Thompson]

Hi all,

I noticed when browsing the info manual for Markdown Export options this
line concerning headline styles seems to be wrong:

> Header and sectioning structure
> ---
> 
> Based on ‘org-md-headline-style’, Markdown export can generate headlines
> of both _atx_ and _setext_ types.  _atx_ limits headline levels to two
> whereas _setext_ limits headline levels to six.  Beyond these limits,
> the export back-end converts headlines to lists.  To set a limit to a
> level before the absolute limit (see *note Export Settings::).

Should this not be the other way round? ATX headlines being repeated
hashes limited to 6 levels and Setext headlines being underlined with
equals for top-level then dashes for second-level.

Is this a quick change I could make myself and contribute?

Re: Support for whitespace prefix for :noweb-prefix

[Fraga, Eric]

Ah, okay.  Thank you.
-- 
: Eric S Fraga, with org release_9.6.23-1314-g945046 in Emacs 30.0.50

Re: Support for whitespace prefix for :noweb-prefix

[Ihor Radchenko]

"Fraga, Eric"  writes:

> So it's a combination of no prefix in such a case and the indentation
> according to major mode.  For me, the latter is not an issue but the
> former is.
>
> (but not really an issue for me as I make sure I only have noweb
> references on lines where such a replacement will not cause any
> problems...)

You can just use :noweb-prefix no. It is already a part of Org.
What we are discussing is adding more functionality to this new
parameter.

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

Re: [PATCH] Add support for tables in Calc src block :var

[Fraga, Eric]

On Saturday, 30 Mar 2024 at 18:34, Visuwesh wrote:
>> Specifically, I would love to make reference to calc variables,
>> especially those defined using embedded calc, in org tables.
>
> Can you please provide a minimal example for me to play around with?  I
> realise I would like something like this too [*] but I don't know
> concretely what this would/should look like.

So, embedded calc processes expressions in any buffer, including org
mode, which might look like this:

x := 3

y := 5

z := 3 x - y => 4

where, in this case, the value of z has been determined by calc and the
answer given after the => in the line.  The beauty of embedded calc is
you can change the value of x and the subsequent expressions will be
updated automatically (well, with C-x * u).

I would then love to be able to have a table that would allow me to
include the value of any variable, e.g. z above, something like

| var | value |
|-+---|
| x   | 3 |
| z   | 4 |

where the values in the second column are obtained by querying Calc.

-- 
: Eric S Fraga, with org release_9.6.23-1314-g945046 in Emacs 30.0.50

Re: Support for whitespace prefix for :noweb-prefix

[Fraga, Eric]

On Friday, 29 Mar 2024 at 09:43, Ihor Radchenko wrote:
> Doerthous  writes:
>> #+begin_src elisp
>> (let ((a 0)
>> (let ((b 1))
>>`(,a ,b))
>> #+end_src
>>
>> ~(let (~ is the prefix of <>.
>>
>> I thought we can replace just the prefix in current code[1]  with
>> ~(setq prefix (replace-regexp-in-string "[^ \t]" " " prefix))~ ?
>
> I see.
> So, you want a custom prefix before the expanded noweb reference lines.

Not only that; at the moment, the prefix is defined by the text that
comes before the noweb reference and hence why the "(let (" is repeated
on the second line in the code block above.

So it's a combination of no prefix in such a case and the indentation
according to major mode.  For me, the latter is not an issue but the
former is.

(but not really an issue for me as I make sure I only have noweb
references on lines where such a replacement will not cause any
problems...)

-- 
: Eric S Fraga, with org release_9.6.23-1314-g945046 in Emacs 30.0.50

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Ihor Radchenko]

Samuel Wales  writes:

> not following this.
>
> but it amused me:
> ...

This is not the final version we settled upon.
https://orgmode.org/worg/org-maintenance.html now has

The assignment process does not always go quickly; occasionally it
may get stuck or overlooked at the FSF. If there is no response to
the contributor from FSF within a month[2], the maintainers can ask
the contributor to follow up with the FSF, CCing the Org
maintainers.

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

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Ihor Radchenko]

Adam Porter  writes:

> 1.  Having to use separate BEGIN and END macros is less convenient than 
> more Lispy constructs, like a macro call with a string argument.  But I 
> guess, to wrap Org elements, like a TODO heading or inline task, it 
> would be necessary.  A macro call with the text as an argument wouldn't 
> be a task in Org syntax, which would make it less useful outside of 
> rendered HTML.

Not for inlinetasks. For everything but heading, we can actually use
special blocks.

For headings, there is also :HTML_HEADLINE_CLASS property.

> 2.  Those macros, or one much like them, could be useful for the use 
> case of centering text to stand out, as discussed in the other thread.

Yes, but they are currently rather plain (other than having an image):

.org-info-box {
clear:both;
margin-left:auto;
margin-right:auto;
padding:0.7em;
}
.org-info-box img {
float:left;
margin:0em 0.5em 0em 0em;
}
.org-info-box p {
margin:0em;
padding:0em;
}

Wondering if we should add some background.

> 3.  For cases that don't potentially involve wrapping Org elements, 
> having a simple macro with the text as its argument might be preferable 
> to having separate BEGIN and END macros.  I wonder if we could have 
> non-begin-end equivalents of the begin-and-end macros listed there.

.org-info-box is certainly not suitable for inline highlights.
Do we need such highlights though? Isn't the classic
italic/bold/underline enough?

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

Re: [PATCH] org-manual: Document Org Plot option "timeind"

[Ihor Radchenko]

Morgan Smith  writes:

> * doc/org-manual.org (Plot options): Document "timeind".  Also fix the
> formatting for a couple other entries.

Thanks!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3e61311c7

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

Re: [PATCH] lisp/ox-html.el: Add avif support for html export inline images

[Ihor Radchenko]

Adam Porter  writes:

> I noticed what appears to be a typo in this commit: 
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1be2f9693
>
>
> +*** =.avif= images are not recognized in ~org-html-inline-image-rules~
>^
>
> Unless I misunderstand something, I guess it's supposed to say "now 
> recognized."  :)

Argh! Again.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f6876d73b

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

[DISCUSSION] Sorting strings in Org mode vs. system locale (was: test-org-table/sort-lines: Failing test on macOS)

[Ihor Radchenko]

Max Nikulin  writes:

>> This sounds like something to be adapted to Emacs upstream.
>> I suggested to change `string-collate-lessp' fallback behaviour to use
>> `downcase' when IGNORE-CASE is non-nil. See my last message in
>> bug#59275.
>
> I do not share Eli's position "all or nothing". I prefer graceful 
> degradation and best result achievable with reasonable efforts.

> However either the reason is performance or correctness, both variants 
> are against modification of `string-collate-lessp'. I still think that 
> Org will benefit from a compatibility wrapper with `downcase'.

Unless we have user complaints with real-world use-cases, I am leaning
towards keeping things consistent with Emacs. Including Emacs-wide
fallback for `string-collate-lessp'. This will make our life easier.

Maintaining an Org-specific fallback will (1) cost maintenance time; (2)
may confuse users used to global Emacs behaviour; (3) has no clear
benefit other than our theoretical discussion.

> The only additional consideration is that compare function should be 
> configurable. If a user access same files from Linux and macOS then it 
> may be really annoying to get different order of entries in agenda. For 
> most of Linux users it is better to use more smart 
> `string-collate-lessp'. Some care is required to sort entries obtained 
> from multiple buffers in predictable environment (locale, case 
> conversion table).

I agree. We can introduce a new customization -
`org-string-sort-function' that will be used across Org mode to sort
user text.

It would be even better to allow smart sort function that depends on
document #+language, but I do not see an easy way to implement such
feature - `string-collate-lessp' does accept LOCALE argument, but I have
no idea how to link #+LANGUAGE to locale deterministically.

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