[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.]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

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

Your bug report will be posted to the Org mailing list.

Hello,

Below are the steps to replicate the issue:

Start emacs by running "emacs --no-init".

Set the org-startup-numerated variable to true with the command (setq
org-startup-numerated t).

Create a new file named tmp.org and insert the following content:



- H
$\alpha$




To view the latex equation, place the cursor on the equation and press
the shortcut C-c C-x C-l to run org-latex-preview.  This will display
the latex preview.

Press C-c C-x C-l again to remove the latex preview and receive the
warning:



■ Warning (org-element-cache): org-element--cache: Org parser error in 
tmp.org::11. Resetting.
The error was: (error "Invalid search bound (wrong side of point)")
Backtrace: nil
Please report this issue to the Org mode mailing list using M-x 
org-submit-bug-report.



Running C-c C-x C-l again will not trigger the warning.  However, the
warning reappears whenever a new latex preview is generated.

For example, changing $\alpha$ to $\beta$ and generating a latex preview
using C-c C-x C-l and removing preview using C-c C-x C-l will again
result in this warning.



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

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
 org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change
  org-cycle-display-inline-images)
 org-startup-numerated t
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all append
local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-persist-directory "/tmp/org-persist-Wop8rB"
 org-fold-core-isearch-open-function 'org-fold--isearch-reveal
 org-latex-format-inlinetask-function 
'org-latex-format-inlinetask-default-function
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow org-eww-open :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)

Re: [FR] :noweb-wrap header arg

[Amy Grinn]

Ihor Radchenko  writes:

> Amy Grinn  writes:
>
>> +(insert raw)
>> +(goto-char (point-min))
>> +(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.

Re: [BUG] Customizing org-emphasis-alist does not work as expected [9.6.15 (release_9.6.15 @ d:/emacs_home/program/emacs/share/emacs/29.2/lisp/org/)]

[Ihor Radchenko]

Max Nikulin  writes:

>> I have updated the docstring to explain this.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=42cdf2a90
>
> Have you decided to discard another variant that warns users?
>
> Ihor Radchenko… [PATCH v5] org.el: Warning for unsupported markers in 
> `org-set-emphasis-alist' Thu, 02 Feb 2023 10:53:20 +. 
> https://list.orgmode.org/87r0v8pcdb.fsf@localhost

In that thread, the decision has been made to obsolete
`org-emphasis-alist'. However, I postponed its implementation until
after the new font-lock engine.

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

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

[Morgan Smith]

Hello!

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.

>From 3c3d7abed25cafb2be1096ca079a0e8be907c644 Mon Sep 17 00:00:00 2001
From: Morgan Smith 
Date: Thu, 11 Apr 2024 12:23:21 -0400
Subject: [PATCH 1/2] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx

---
 lisp/org-clock.el | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 65a54579a..5ef987ab8 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2008,9 +2008,23 @@ each headline in the time range with point at the headline.  Headlines for
 which HEADLINE-FILTER returns nil are excluded from the clock summation.
 PROPNAME lets you set a custom text property instead of :org-clock-minutes."
   (with-silent-modifications
-(let* ((re (concat "^\\(\\*+\\)[ \t]\\|^[ \t]*"
-		   org-clock-string
-		   "[ \t]*\\(?:\\(\\[.*?\\]\\)-+\\(\\[.*?\\]\\)\\|=>[ \t]+\\([0-9]+\\):\\([0-9]+\\)\\)"))
+(let* ((re (rx line-start
+   (or
+(group (regexp org-outline-regexp))
+(seq (* blank)
+ (literal org-clock-string)
+ (* blank)
+ (or
+  (seq
+   (group "[" (* (not "]")) "]")
+   (+ "-")
+   (group "[" (* (not "]")) "]"))
+  (seq
+   "=>"
+   (+ blank)
+   (group (+ digit))
+   ":"
+   (group (+ digit
 	   (lmax 30)
 	   (ltimes (make-vector lmax 0))
 	   (level 0)
-- 
2.41.0

>From e5298920568e4c5a34589640f11edfa09a98d0d1 Mon Sep 17 00:00:00 2001
From: Morgan Smith 
Date: Thu, 11 Apr 2024 12:51:18 -0400
Subject: [PATCH 2/2] Test clock times without timestamps

* testing/lisp/test-org-clock.el (test-org-clock/clocktable/insert):
Add a clock time that does not include timestamps.
---
 testing/lisp/test-org-clock.el | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/testing/lisp/test-org-clock.el b/testing/lisp/test-org-clock.el
index 44c62e7bc..be8acb529 100644
--- a/testing/lisp/test-org-clock.el
+++ b/testing/lisp/test-org-clock.el
@@ -345,13 +345,12 @@ CLOCK: [2022-11-03 %s 06:00]--[2022-11-03 %s 06:01] =>  0:01
(equal
 "| Headline | Time   |
 |--+|
-| *Total time* | *1:00* |
+| *Total time* | *2:00* |
 |--+|
-| H1   | 1:00   |"
+| H1   | 2:00   |"
 (org-test-with-temp-text "* H1\n"
-  (insert (org-test-clock-create-clock ". 1:00" ". 2:00"))
-
-  (goto-line 2)
+  (insert (org-test-clock-create-clock ". 1:00" ". 2:00")
+  "CLOCK: => 1:00\n")
   (require 'org-clock)
   (org-dynamic-block-insert-dblock "clocktable")
 
-- 
2.41.0

Re: [BUG] Customizing org-emphasis-alist does not work as expected [9.6.15 (release_9.6.15 @ d:/emacs_home/program/emacs/share/emacs/29.2/lisp/org/)]

[Max Nikulin]

On 10/04/2024 15:19, Ihor Radchenko wrote:

Chang Xiaoduan writes:


I am trying to customizing `org-emphasis-alist` so that ` can replace ~ as
the code marker. I use the following code in my configuration file:


Custom markup markers are not supported.
This customization is only useful to change the existing markup faces.

I have updated the docstring to explain this.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=42cdf2a90


Have you decided to discard another variant that warns users?

Ihor Radchenko… [PATCH v5] org.el: Warning for unsupported markers in 
`org-set-emphasis-alist' Thu, 02 Feb 2023 10:53:20 +. 
https://list.orgmode.org/87r0v8pcdb.fsf@localhost

Re: [Q] startup hook: How do I detect if the current buffer has been opened programmatically?

[Max Nikulin]

On 09/04/2024 00:31, Rudi C wrote:
I want to automatically preview all LaTeX fragments if the buffer was 
opened by the user


Be careful and limit automatic preview to files you created yourself. 
Doing so for an arbitrary file downloaded from net might cause huge 
amount of garbage files in /tmp.


Emacs-29.3 includes a fix for CVE-2024-30204 that is specific for email 
attachment inline preview. When a regular file is opened, weird LaTeX 
code inside still may be executed. There is no general way to determine 
if specific file should be treated as trusted.

[no subject]

[Ihor Radchenko]

Sébastien Gendre  writes:

> When I try to execute a block of PlantUML in an Org document, I get an
> error message:
>
> "org-babel-execute-src-block: No org-babel-execute function for plantuml!"
> ...
> (add-to-list
>  'org-babel-load-languages
>  '(plantuml . t))

Just use (require 'ob-plantuml).

To use `org-babel-load-languages', you should either set it before
loading Org mode or run `org-babel-do-load-languages' manually, as
described in "16.9 Languages" section of the manual.

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

Re: none

[Fraga, Eric]

On Thursday, 11 Apr 2024 at 16:43, Sébastien Gendre wrote:
> When I try to execute a block of PlantUML in an Org document, I get an
> error message:
> [...]
> (setq plantuml-default-exec-mode 'executable)
> (setq org-plantuml-exec-mode 'plantuml)

I don't have either of these setq lines but I do have:

(setq org-plantuml-jar-path (expand-file-name 
"/usr/share/plantuml/plantuml.jar"))

I'm not sure what those settings you have defined are meant to do.

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

[no subject]

[Sébastien Gendre]

Hello,

When I try to execute a block of PlantUML in an Org document, I get an
error message:

"org-babel-execute-src-block: No org-babel-execute function for plantuml!"




I have configured Org mode to enable execution of plantUML source block
by adding this in my init.el:

(setq plantuml-default-exec-mode 'executable)
(setq org-plantuml-exec-mode 'plantuml)
(add-to-list
 'org-babel-load-languages
 '(plantuml . t))




Here is an example of PlantUML block:
#+begin_src plantuml :file ./images/FPGA/DCC/
  @startuml
  robust "Signal DCC" as DCC_sign
  DCC_sign has +U,0,-U

  @DCC_sign
  0 is +U
  +58 is -U
  +58 is +U
  +100 is -U
  +100 is +U
  +100 is -U
  +100 is +U
  +58 is -U
  +58 is +U
  +100 is -U
  +100 is +U
  +58 is -U
  +58 is +U
  +58 is -U
  +58 is +U
  +100 is -U
  +100 is +U

  @enduml
#+end_src

My version of Org-mode is: 9.6.15


What did I miss ?

Re: org-clone-subtree-with-time-shift with reverse order

[Ihor Radchenko]

Christian Barthel  writes:

> I'd like to suggest adding a new prefix arg i.e.
> `C-u C-u org-clone-subtree-with-item-shift' to reverse
> the order of newly created / cloned siblings.  Would
> that be of interest for other orgmode users?

May you explain your use case a bit more?

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

> First of all, I would like to change (defalias) the function name
> org-babel-noweb-wrap to org-babel-noweb-make-regexp. I think this in
> more in line with other functions which create regular expressions.

+1
You may even use obsolete alias (add it to lisp/org-compat.el)

> Second, the command org-babel-tangle-clean is not able to determine
> which noweb syntax is being used in any tangled source file because the
> header arguments are not tangled along with the source code.
>
> My proposal is to add an additional warning to this command, stating:
>
> """
> Warning, this command removes any lines containing constructs which
> resemble Org file links or noweb references.  It also cannot determine
> which noweb syntax is being used for any given source file, if
> :noweb-wrap was specified in the original Org file.
> """

Makes sense.
Ideally, this function should try to follow the link and lookup code
block headers, but it is already short of doing this. Improving
`org-babel-tangle-clean' is out of scope of your patch.

> +(defun org-babel-get-noweb-wrap ( info)
> +  "Retrieve a description the :noweb-wrap header arg from INFO.
> +
> +The description will be in the form of a list of two of strings
> +for the start and end of a reference.  INFO can be the result of
> +`org-babel-get-src-block-info' otherwise this function will parse
> +info at point."
> +  (unless info
> +(setq info (org-babel-get-src-block-info 'no-eval)))
> +  (when-let ((raw (cdr (assq :noweb-wrap (nth 2 info)
> +(let (result)
> +  (with-temp-buffer

Please, avoid creating throwaway buffers and work with strings instead.
Creating buffers (even temporary buffers) may be costly for some users
who heavily customized buffer hooks.

> +(insert raw)
> +(goto-char (point-min))
> +(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.

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

Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>> The latest added to the branch are Maxim's proposals (and code) for
>> backend control. See this thread:
>>
>> https://list.orgmode.org/?t=20240321102752
>>
>> And this other thread, continuation of the previous one:
>>
>> https://list.orgmode.org/877ciavnwo.fsf...@posteo.net/
>
> I have seen these two branches and my comments account for them.

Ok. Although I will try to answer all your comments in detail [if it's
okay, I can start a new thread called "inline-special-block: general
discussion"] I can anticipate that I would be in favor of removing
global attributes (:smallcaps, :lang, :color). At first I didn't think
it was a bad idea to have certain «pre-cooked» attributes. But later I
realized that the implementation of each backend where it makes sense to
apply these attributes is unnecessarily complicated. Furthermore, the
very flexibility of the new object allows the same goal to be achieved.

Well, next week I will continue commenting. I will try to stay up to
date with everything that is being discussed here. By the way, if
someone wants to collaborate on the branch, I can add them as a
contributor (I'm afraid it is necessary to have a GitLab account, if
I'm not mistaken).

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

[Ihor Radchenko]

Alexander Adolf  writes:

> it seems that the time summing behaviour of columnview dynamic blocks is
> different for CLOCKSUM than for EFFORT columns with respect to how the
> contributions from sub-headlines are handled. When summing up CLOCKSUM
> columns, a parent headline can have its own clocked time, which gets
> added to the sum of its sub-items' clocked times to produce its CLOCKSUM
> value. When summing up EFFORT columns, any effort a parent headline may
> have been manually assigned gets overwritten with the sum of its
> sub-items' efforts, however. In the example at the end of this message,
> compare the results for tasks A and D. If you change the effort for
> either task B or C, and then update the dynamic block, the EFFORT in the
> property drawer of task A will get overwritten with the new sum of B's
> and C's efforts.
>
> I'd have two questions regarding this:
>
> Does anyone recall the rationale for this different behaviour?

The "default" behaviour is to store summary of all the child property
value in each parent.

For example, starting from

#+COLUMNS: %ITEM%EFFORT{:}
* 1
:PROPERTIES:
:EFFORT:   0:00
:END:
** 1.1
:PROPERTIES:
:EFFORT:   0:20
:END:
** 1.2
:PROPERTIES:
:EFFORT:   0:20
:END:

after generating column view, you will get

* 1
:PROPERTIES:
:EFFORT:   0:40
:END:
...

This is, however, not possible for CLOCKSUM because clocksum is not an
actual property, but a "special" one - it is derived from logbook data.
That's why its behavior is different.

In fact, CLOCKSUM property does not support custom summaries.

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

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

> See two patches attached again.  All tests pass on my computer.

Thanks!
Applied, onto main, with amendments (see the attached diffs).
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=66e307b41
https://git.sr.ht/~bzg/worg/commit/f1486f42

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 2b418cd3c..e61bd6988 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -516,7 +516,9 @@ and returns an appropriate timestamp string.
 
 ~org-element-timestamp-parser~ now adds =:repeater-deadline-value= and
 =:repeater-deadline-unit= properties to each timestamp object that has
-a repeater deadline.
+a repeater deadline.  For example, in =<2012-03-29 Thu ++1y/2y>=, =2y=
+is the repeater deadline with a value of =2= and unit of =y=.  See
+"5.3.3 Tracking your habits" section in the manual.
 
 Possible values for =:repeater-deadline-value=: ~positive integer~, ~nil~.
 
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 49a312694..e7561f16f 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4331,13 +4331,13 @@ (defun org-element-timestamp-parser ()
   (and (not diaryp)
(string-match
 (rx
- (group (or "+" "++" ".+"))
- (group (+ digit))
- (group (or "h" "d" "w" "m" "y"))
- (\?
+ (group-n 1 (or "+" "++" ".+"))
+ (group-n 2 (+ digit))
+ (group-n 3 (any "hdwmy"))
+ (optional
   "/"
-  (group (+ digit))
-  (group (or "h" "d" "w" "m" "y"
+  (group-n 4 (+ digit))
+  (group-n 5 (any "hdwmy"
 raw-value)
(nconc
 (list
@@ -4427,17 +4427,15 @@ (defun org-element-timestamp-interpreter (timestamp _)
 	   (and val (number-to-string val)))
 	 (pcase (org-element-property :repeater-unit timestamp)
 	   (`hour "h") (`day "d") (`week "w") (`month "m") (`year "y"))
- (let ((repeater-deadline-value
-(org-element-property :repeater-deadline-value timestamp))
-   (repeater-deadline-unit
-(org-element-property :repeater-deadline-unit timestamp)))
-   (if (and repeater-deadline-value repeater-deadline-unit)
-   (concat
-"/"
-(number-to-string repeater-deadline-value)
-(pcase repeater-deadline-unit
-  (`hour "h") (`day "d") (`week "w") (`month "m") (`year "y")))
- ""
+ (when-let ((repeater-deadline-value
+ (org-element-property :repeater-deadline-value timestamp))
+(repeater-deadline-unit
+ (org-element-property :repeater-deadline-unit timestamp)))
+   (concat
+"/"
+(number-to-string repeater-deadline-value)
+(pcase repeater-deadline-unit
+  (`hour "h") (`day "d") (`week "w") (`month "m") (`year "y"))
(range-type (org-element-property :range-type timestamp))
(warning-string
 	(concat
diff --git a/org-syntax.org b/org-syntax.org
index c8eb7f77..70a46dcf 100644
--- a/org-syntax.org
+++ b/org-syntax.org
@@ -1776,8 +1776,8 @@ ** 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 a single REPEATER and/or an
-  instance of a single DELAY in any order.
++ REPEATER-OR-DELAY (optional) :: An instance of a single =REPEATER= and/or an
+  instance of a single =DELAY= in any order.
 + REPEATER (optional) :: An instance of the following pattern:
   #+begin_example
 MARK VALUE UNIT
@@ -1786,18 +1786,18 @@ ** Timestamps
   Where MARK, VALUE and UNIT are not separated by whitespace characters.
   - MARK :: Either the string =+= (cumulative type), =++= (catch-up type),
 or =.+= (restart type).
-  - VALUE :: A number
+  - VALUE :: A number.
   - UNIT :: Either the character =h= (hour), =d= (day), =w= (week), =m=
-(month), or =y= (year)
+(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
+  - VALUE :: A number.
   - UNIT :: Either the character =h= (hour), =d= (day), =w= (week), =m=
-(month), or =y= (year)
+

Re: Verbatim content (inline-special-block)

[Ihor Radchenko]

Max Nikulin  writes:

>> - We should be able to define special markup for code, where the
>>   contents is not parsed. Something like
>> 
>>   @code{ unlike =code=, we can have leading and trailing spaces }
>>   @code{ @foo{is not interpreted inside}}
>
> I think, it should be controlled by some optional parameter like
>
>  @kbd[:verbatim t]{ unlike =code=, ... }

I do not like this idea - this will make the attribute list a part of
the Org markup spec, which I would like to avoid if possible:

1. External parsers would be forced to understand the attribute syntax,
   which will complicate Org markup spec.
2. Our own parser may have to account for attribute inheritance while
   parsing, which will complicate the parser too much.

The question remains how to define custom verbatim markup, of course.

It may be enough to have @kbd{@code{...}} - it is not like Texinfo has a
concept of truly verbatim text like in Org.

Alternatively, we may allow two classes of inline markup:
@foo{parsed *text* inside}
and
@foo={verbatim *text* inside}/@foo~{verbatim *text* inside}

This way, instead of @code{}, we should use @code~{...} or even
@~{...}/@={...} (mnemonics for ~...~ and =...=)

> Certainly parsing of normal Org markup should be suppressed,
> however I am less sure concerning @markup{}. In the following example 
> text inside @param{} may be emphasized:
>
>  @code{def calculate(@param{expr}, @param{env})}
>
> "@" inside such object may be escaped as @{@}. An alternatively is a 
> parameter like :parse that can have values like "markup", "custom", 
> "verbatim". This case "verbatim" disabled parsing of @objects().

AFAIU, you are referring to how Texinfo handles its @code{...} command,
where other texinfo commands are allowed, which is _conceptually_
different from how Org handles the verbatim/code - as a general rule,
all the "code" in Org mode syntax is taken verbatim (with the only
exception of src blocks where we have no choice).

Also, the reason why Texinfo users do @param in @code is the lack of
automatic syntax highlighting, unlike in Org mode.

I think that Org mode's equivalent of Texinfo @code should be either

1. inline src block
2. if direct markup is unavoidable, use something like
   @fixedwidth{@code{def calculate(}@param{expr}@code{, }@param{env}@code{)}}
   Most of the @code{..} can be safely dropped. It is just to illustrate
   the idea that we still parse the contents.

   In practice, things like
   *def* calculate(expr, env) "foo\alpha"
   will become
   @fixedwidth{*def@code{*} calculate(@param{expr}, @param{env}) 
"foo@code{\}alpha"}
   or
   @fixedwidth{\star{}def* calculate(@param{expr}, @param{env}) "foo\@@{}alpha"}

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

Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Juan Manuel Macías  writes:

> The latest added to the branch are Maxim's proposals (and code) for
> backend control. See this thread:
>
> https://list.orgmode.org/?t=20240321102752
>
> And this other thread, continuation of the previous one:
>
> https://list.orgmode.org/877ciavnwo.fsf...@posteo.net/

I have seen these two branches and my comments account for them.

-- 
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: ...))

[Ihor Radchenko]

Bruno Barbier  writes:

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

Let me rephrase my concern - I do not like that after reglock is no
longer live (got success/failure signal), there is no way to clean up the
visual hints associated with this particular reglock.

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

I was mostly confused about linkage between "visual hints" in buffer and
how they are connected with reglock object. You may discard this
comment of mine.

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

I do not like this.
I'd like the Elisp program that creates the reglock to be able to
clean up any visual hints associated with it. A function doing it for a
given region cannot do this AFAIU.

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

Note that this function is not documented anywhere other than in reglock
class documentation. In general, I am confused about your overall design
of the user interaction with the locks.

The updated top commentary explains well how Elisp programs can send
data to the locks, but it does not say anything about how Elisp programs
can receive the data.

Also, I'd like to see more information in the top commentary about what
are the "visual hints" displayed to the user and how to configure them.
  
>> 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.

I agree, but I'd like to see the core concepts explained on top:
1. How to create region lock (done)
2. What the region lock does (prohibit modifications, done)
3. How the lock is presented to the user and how to control the presentation 
(not done)
4. What can user do with the lock and how it is reflected in Elisp level (not 
done)
5. What can Elisp do with the lock (done)

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

Yes! Thanks!

>> 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 too).

We usually "hide" fields by declaring them private.
Hiding them from the type docs is not a good idea because it defeats the
purpose of type documentation in general.

> The fields anchor-ovl, region-ovl, on-outcome, set-status and
> creation-point are the dump of the closure context, so that
> 

Link to the repository (Re: inline-special-block: part2)

[Max Nikulin]

On 11/04/2024 17:49, Max Nikulin wrote:
I think, it is better to create a new thread to discuss next bunch of 
questions related to the inline special block feature.


I have realized that I forgot to add the link for those who wish to try 
the new feature in action:


Juan Manuel Macías. Experimental public branch for inline special 
blocks. Fri, 01 Mar 2024 20:34:35 +.

https:list.orgmode.org/87wmql6690@posteo.net


Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:

Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 02/03/2024 03:34, Juan Manuel Macías wrote:

Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:




Next part of this thread:

Max Nikulin. inline-special-block: part2. Thu, 11 Apr 2024 17:49:40 +0700.
https://list.orgmode.org/0f1351e2-cb5e-4b65-9faf-c6e78f15c...@gmail.com

Previous discussion:

Juan Manuel Macías. [proof of concept] inline language blocks. Tue, 20 
Feb 2024 20:35:04 +.

https://list.orgmode.org/87msrudgcn@posteo.net

Verbatim content (inline-special-block)

[Max Nikulin]

Ihor Radchenko. Re: Experimental public branch for inline special
blocks. Tue, 09 Apr 2024 08:52:38 +.
https://list.orgmode.org/875xwqj4tl.fsf@localhost


- We should be able to define special markup for code, where the
  contents is not parsed. Something like

  @code{ unlike =code=, we can have leading and trailing spaces }
  @code{ @foo{is not interpreted inside}}


I think, it should be controlled by some optional parameter like

@kbd[:verbatim t]{ unlike =code=, ... }

Certainly parsing of normal Org markup should be suppressed,
however I am less sure concerning @markup{}. In the following example 
text inside @param{} may be emphasized:


@code{def calculate(@param{expr}, @param{env})}

"@" inside such object may be escaped as @{@}. An alternatively is a 
parameter like :parse that can have values like "markup", "custom", 
"verbatim". This case "verbatim" disabled parsing of @objects().

inline-special-block: part2

[Max Nikulin]

I think, it is better to create a new thread to discuss next bunch of 
questions related to the inline special block feature.


Previous thread is rather huge:

Juan Manuel Macías. Experimental public branch for inline special 
blocks. Fri, 01 Mar 2024 20:34:35 +.

https:list.orgmode.org/87wmql6690@posteo.net

In particular it contains detailed overview

Ihor Radchenko. Re: Experimental public branch for inline special 
blocks. Tue, 09 Apr 2024 08:52:38 +.

https://list.orgmode.org/875xwqj4tl.fsf@localhost

An earlier closely related thread:

Juan Manuel Macías. [proof of concept] inline language blocks. Tue, 20 
Feb 2024 20:35:04 +.

https://list.orgmode.org/87msrudgcn@posteo.net

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

[Sławomir Grochowski]

Philip Kaludercic  writes:

> I tried out using your `org-columns-help-quick-sections' variable, but
> it seems that `where-is' didn't find all the commands you wanted:

> Are commands like `org-columns-move-up' part of the next release of Org?
> I am using whatever is currently on master.

Yes this function was added recently. It's on Org master 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org-colview.el#n997
But not on Emacs repo. 

-- 
Slawomir Grochowski

Re: Update contact info

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien, may you check which name is used in the FSF records?

I've taken this offlist.

-- 
 Bastien Guerry

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 tried out using your `org-columns-help-quick-sections' variable, but
it seems that `where-is' didn't find all the commands you wanted:

--8<---cut here---start->8---
Move column & rowAdd & delete columnEdit column   Edit 
values  View Misc.
M-  move column left   M-S- add column < narrow  e   
edit value   c show content   C-c C-o open link
M- move column right  M-S-  delete column  > widen   a   
edit allowed value   o show overview  g   redo
s attributes  n   
next allowed value   v show value q   quit
  p   
previous allowed value
  C-c C-c 
toggle checkbox or quit
  C-c C-t 
change TODO state
--8<---cut here---end--->8---

(some of the descriptions are pretty long, are they not?)

Are commands like `org-columns-move-up' part of the next release of Org?
I am using whatever is currently on master.

-- 
Philip Kaludercic on peregrine

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

[Philip Kaludercic]

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.

-- 
Philip Kaludercic on peregrine