Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals

[Ihor Radchenko]

Max Nikulin  writes:

> It seems I completely failed trying to express my idea.
>
> Instead of extending Org grammar (syntax), I suggest to change behavior 
> of source blocks during export. In addition to current :results options, 
> "ast" may be added. Its effect is that instead of adding text to export 
> buffer that is parsed as Org markup, it causes insertion of a branch of 
> syntax tree into original parse results. I admit, during export it may 
> be necessary to iterate over source blocks one more time at a later stage.

So, do I understand it correctly that you are _not_ suggesting the AST
format _instead_ of the discussed inline blocks?

> Such source blocks should return "Org Syntax Tree", a simplified variant 
> of org-element. It allows to change implementation details and e.g. to 
> use vectors instead of lists for attributes in org-element. A converter 
> from Org Syntax Tree to org-element should be implemented.

Doesn't it effectively mean that we need to introduce yet another Org
element syntax---"Simplified AST"?

> Certainly such format may be used directly as src_ost{(code (:class var) 
> "language")} inline snippets or as
>
> #+begin_src ost
>(code nil ("libtree-{sitter}-"
>   (code (:class var) "\"language\"")
>   "."
>   (code (:class var) "ext")))
> #+end_src
>
> block-level elements. However I expect that it is the last resort option 
> when there is no way to express desired construct in some other way.

I can foresee issues when we insert, say, code object in place of
paragraph element. The consequences might be drastic. Unless we just
allow users to shoot their own leg.

> I think, more convenient org-babel backends may be created to parse 
> TeX-like (texinfo-like) or SGML-like (XML-like) syntax into Org Syntax 
> Tree hierarchy. The essential idea is that outside of source blocks 
> usual lightweight markup is used. Source blocks however have just a few 
> special characters ([\{}], [@{}], or [&<>], etc.) to reduce issues with 
> escaping for regular text or verbatim-like commands.

This is not a bad idea, but I feel like it is getting a bit too far from
the syntax discussion herein. You might open a new thread about
importing foreign syntax into Org.

>>>   (code nil ("libtree-{sitter}-"
>>>  (code (:class var) "\"language\"")
>>>  "."
>>>  (code (:class var) "ext")))
>> 
>> This is not much different from @name[nil]{} idea, but
>> more verbose.
>>
>  > Also, more importantly, I strongly dislike the need to wrap the text
>  > into "". You will have to escape \". And it will force third-party
>  > parsers to re-implement Elisp sexp reader.
>
> By this example I was trying to show how to express @var, @samp, @file 
> without introducing of new custom objects. I do not see any problem with 
> verbosity of such format, it may be used for really special cases only, 
> while some more convenient markup is used for more simple cases.

I was comparing the inline block vs. your AST proposal. If the AST idea
is complementary, I see no issue.

>>> If there was some syntax for object attributes then simple cases would
>>> be like
>>>
>>>   [[attr:(:class var)]]~language~
>> 
>> I do not like this idea. It will require non-trivial changes in Org
>> parser and fontification.
>> 
>> Using dedicated object properties or at least inheriting properties from
>> :parent is the style we employ more commonly across the code:
>> 
>> @var{language}
>> or
>> @code[:class var]{language}
>> or
>> @attr[:class var]{~language~}
>
> I do not mind to have some "span" object to assign attributes to its 
> direct children. I used link-like prefix object just because a proof of 
> concept may be tried with no changes in Org. It does not require support 
> of nested objects. There is no existing syntax for such "span" objects, 
> but perhaps it is not necessary and source blocks should be used instead 
> for special needs.

The problem is that instead of supporting nested objects we will have to
support "previous object changing the meaning of subsequent", which is
more fundamental change.

I envision the new inline blocks to allow assigning attributes to
children. These new inline blocks must not have issues with nesting by
design.

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

Re: A function to perform Org related searches in several places

[Ihor Radchenko]

Juan Manuel Macías  writes:

> For my personal use I have written a function which performs Org related
> searches in different places. The list of places is expandable, but so
> far I found them useful: this mailing list, the Org Manual (via org-ql),
> the Git log and the Org Reddit. The idea was that everything would be
> done without leaving Emacs confort, so the results from the internet are
> returned in EWW.
>
> Before entering the search term, it defaults to the word at point or the
> marked region.

I am using helm source for similar purposes.
The advantage is displaying live results.
I use Info search + helm-org-ql + live git query + notmuch query for the
mailing list.

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

Re: [PATCH] Three documentation patches

[Stefan Kangas]

Ihor Radchenko  writes:

> The patches look good, but I am unable to apply them onto current main:

Hmm, strange.  I've rebased on top of current main, and I'm resending
the resulting patches here.  I hope they work better.
From ffd00c1272dd876f64c9ef930d19988b6da5c2a3 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 2 Oct 2022 21:54:20 +0200
Subject: [PATCH 1/3] Add crossreference to org-stuck-projects docstring

* lisp/org-agenda.el (org-stuck-projects): Add Info manual reference
to docstring.
---
 lisp/org-agenda.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index e5df768ff..5b8133e81 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -614,13 +614,17 @@ you can then use it to define a custom command."
   '("+LEVEL=2/-DONE" ("TODO" "NEXT" "NEXTACTION") nil "")
   "How to identify stuck projects.
 This is a list of four items:
+
 1. A tags/todo/property matcher string that is used to identify a project.
-   See the manual for a description of tag and property searches.
-   The entire tree below a headline matched by this is considered one project.
+   See Info node `(org) Matching tags and properties' for a
+   description of tag and property searches.  The entire tree
+   below a headline matched by this is considered one project.
+
 2. A list of TODO keywords identifying non-stuck projects.
If the project subtree contains any headline with one of these todo
keywords, the project is considered to be not stuck.  If you specify
\"*\" as a keyword, any TODO keyword will mark the project unstuck.
+
 3. A list of tags identifying non-stuck projects.
If the project subtree contains any headline with one of these tags,
the project is considered to be not stuck.  If you specify \"*\" as
@@ -628,6 +632,7 @@ This is a list of four items:
the explicit presence of a tag somewhere in the subtree, inherited
tags do not count here.  If inherited tags make a project not stuck,
use \"-TAG\" in the tags part of the matcher under (1.) above.
+
 4. An arbitrary regular expression matching non-stuck projects.
 
 If the project turns out to be not stuck, search continues also in the
-- 
2.30.2

From d0c890d14382d3b4d1c0259f76f2478a0d1700ae Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 2 Oct 2022 21:54:27 +0200
Subject: [PATCH 2/3] Improve documentation of org-agenda-skip-*

* doc/org-manual.org (Special Agenda Views): Improve indexing.
* lisp/org-agenda.el (org-agenda-skip-function)
(org-agenda-skip-entry-if, org-agenda-skip-subtree-if): Expand
docstrings.
(org-agenda-skip-if): Doc fix; clarify wording.
---
 doc/org-manual.org |  2 ++
 lisp/org-agenda.el | 33 +++--
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index a20c8e50b..ddba84cab 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21345,6 +21345,8 @@ meaningful string suitable for the agenda view.
 
 #+vindex: org-odd-levels-only
 #+vindex: org-agenda-skip-function
+#+findex: org-agenda-skip-entry-if
+#+findex: org-agenda-skip-subtree-if
 Search for entries with a limit set on levels for the custom search.
 This is a general approach to creating custom searches in Org.  To
 include all levels, use =LEVEL>0=[fn:: Note that, for
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 5b8133e81..cadf5ffb8 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4204,12 +4204,19 @@ to t."
 If this function returns nil, the current match should not be skipped.
 Otherwise, the function must return a position from where the search
 should be continued.
-This may also be a Lisp form, it will be evaluated.
-Never set this variable using `setq' or so, because then it will apply
-to all future agenda commands.  If you do want a global skipping condition,
-use the option `org-agenda-skip-function-global' instead.
-The correct usage for `org-agenda-skip-function' is to bind it with
-`let' to scope it dynamically into the agenda-constructing command.
+
+This may also be a Lisp form that will be evaluated.  Useful
+forms include `org-agenda-skip-entry-if' and
+`org-agenda-skip-subtree-if'.  See the Info node `(org) Special
+Agenda Views' for more details and examples.
+
+Never set this variable using `setq' or similar, because then it
+will apply to all future agenda commands.  If you want a global
+skipping condition, use the option `org-agenda-skip-function-global'
+instead.
+
+The correct way to use `org-agenda-skip-function' is to bind it with `let'
+to scope it dynamically into the agenda-constructing command.
 A good way to set it is through options in `org-agenda-custom-commands'.")
 
 (defun org-agenda-skip ( element)
@@ -5122,12 +5129,18 @@ bind it in the options section.")
 
 (defun org-agenda-skip-entry-if ( conditions)
   "Skip entry if any of CONDITIONS is true.
-See `org-agenda-skip-if' for details."
+See `org-agenda-skip-if' for 

Re: [PATCH] Three documentation patches

[Ihor Radchenko]

Stefan Kangas  writes:

> Please find attached three separate documentation patches.

Thanks!
The patches look good, but I am unable to apply them onto current main:

128 git … am --3way -- /tmp/0002-Improve-documentation-of-org-agenda-skip.patch
Applying: Improve documentation of org-agenda-skip-*
error: sha1 information is lacking or useless (lisp/org-agenda.el).
error: could not build fake ancestor
Patch failed at 0001 Improve documentation of org-agenda-skip-*
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

Re: Some links in online manual do not work

[Ihor Radchenko]

Tim Landscheidt  writes:

>> This looks like the nginx case issue again.
>
>> I've looked at this and there does not seem to be any 'clean' way to fix
>> this which also doesn't have significant processing overhead or a
>> maintenance burden.
>
>> I wonder if it would be worthwhile adding an option to HTML export which
>> would force all link targets and exported filenames to lower case,
>> thereby avoiding issues on platforms and with web servers which have
>> different positions wrt case sensitivity?
>
> Is the nginx configuration/webserver setup documented some-
> where?

AFAIK, our nginx configs are not public, but Bastien may privately share
them if you are willing to help.

CCing Bastien.

-- 
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-agenda.el: Fix filter preset problem for sticky agenda

[Liu Hui]

Ihor Radchenko  writes:

>> +(defvar org-agenda-filters-preset nil
>> +  "Preset of filters, which becomes buffer-local in org-agenda buffers.")
>
> Can you detail the value format in the docstring?
> It would also be useful to mention `org-agenda-local-vars'. Otherwise,
> the reader might be confused how `defvar' is buffer-local.

Done.

> Also, may you create a test for the reported bug in
> testing/lisp/test-org-agenda.el?

Done.

When writing the test, I find the original patch only addresses the
case where an entry contains multiple commands. Now the udpated patch
can address the case containing one command by changing another global
symbol property to per-buffer text property.

>From 718cb5258a407d8a51eb4a5bac3d0c8025a3f198 Mon Sep 17 00:00:00 2001
From: Liu Hui 
Date: Tue, 4 Oct 2022 11:12:41 +0800
Subject: [PATCH] Fix filter preset problem for sticky agenda

* lisp/org-agenda.el (org-agenda-local-vars):
(org-agenda-filters-preset): Add a new variable
`org-agenda-filters-preset' for storing per-buffer filter presets.
(org-agenda):
(org-agenda-filter-any):
(org-agenda-prepare):
(org-agenda-finalize):
(org-agenda-redo):
(org-agenda-filter-by-tag):
(org-agenda-filter-make-matcher):
(org-agenda-set-mode-name):
(org-agenda-reapply-filters): Use `org-agenda-filters-preset' for
getting and setting per-buffer filter presets, rather than modifying
the global symbol property. Change `org-lprops' from symbol property
to per-buffer text property. Delete unused `last-args' symbol
property.
* testing/lisp/test-org-agenda.el (test-org-agenda/sticky-agenda-filter-preset):
(test-org-agenda/redo-setting): add tests.
---
 lisp/org-agenda.el  | 108 +++-
 testing/lisp/test-org-agenda.el |  60 ++
 2 files changed, 109 insertions(+), 59 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index e5df768ff..c303aead1 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2276,6 +2276,7 @@ When nil, `q' will kill the single agenda buffer."
 org-agenda-top-headline-filter
 org-agenda-regexp-filter
 org-agenda-effort-filter
+org-agenda-filters-preset
 org-agenda-markers
 org-agenda-last-search-view-search-was-boolean
 org-agenda-last-indirect-buffer
@@ -2929,10 +2930,6 @@ Pressing `<' twice means to restrict to the current subtree or region
 	(setq org-agenda-restrict nil)
 	(move-marker org-agenda-restrict-begin nil)
 	(move-marker org-agenda-restrict-end nil))
-  ;; Delete old local properties
-  (put 'org-agenda-redo-command 'org-lprops nil)
-  ;; Delete previously set last-arguments
-  (put 'org-agenda-redo-command 'last-args nil)
   ;; Remember where this call originated
   (setq org-agenda-last-dispatch-buffer (current-buffer))
   (unless org-keys
@@ -2981,7 +2978,6 @@ Pressing `<' twice means to restrict to the current subtree or region
 		(setq org-agenda-buffer-name
 		  (or (and (stringp org-match) (format "*Org Agenda(%s:%s)*" org-keys org-match))
 			  (format "*Org Agenda(%s)*" org-keys
-	  (put 'org-agenda-redo-command 'org-lprops lprops)
 	  (cl-progv
 	  (mapcar #'car lprops)
 	  (mapcar (lambda (binding) (eval (cadr binding) t)) lprops)
@@ -3016,7 +3012,10 @@ Pressing `<' twice means to restrict to the current subtree or region
 		   (funcall type org-match))
 		  ;; FIXME: Will signal an error since it's not `functionp'!
 		  ((pred fboundp) (funcall type org-match))
-		  (_ (user-error "Invalid custom agenda command type %s" type)
+		  (_ (user-error "Invalid custom agenda command type %s" type
+  (let ((inhibit-read-only t))
+	(add-text-properties (point-min) (point-max)
+			 `(org-lprops ,lprops
 	  (org-agenda-run-series (nth 1 entry) (cddr entry
((equal org-keys "C")
 	(setq org-agenda-custom-commands org-agenda-custom-commands-orig)
@@ -3808,6 +3807,10 @@ the entire agenda view.  In a block agenda, it will not work reliably to
 define a filter for one of the individual blocks.  You need to set it in
 the global options and expect it to be applied to the entire view.")
 
+(defvar org-agenda-filters-preset nil
+  "Alist of filter types and associated preset of filters.
+This variable is local in org-agenda buffers. See `org-agenda-local-vars'.")
+
 (defconst org-agenda-filter-variables
   '((category . org-agenda-category-filter)
 (tag . org-agenda-tag-filter)
@@ -3818,7 +3821,7 @@ the global options and expect it to be applied to the entire view.")
   "Is any filter active?"
   (cl-some (lambda (x)
 	 (or (symbol-value (cdr x))
-		 (get :preset-filter x)))
+ (assoc-default (car x) org-agenda-filters-preset)))
 	   org-agenda-filter-variables))
 
 (defvar org-agenda-category-filter-preset nil
@@ -3927,10 +3930,6 @@ FILTER-ALIST is an alist of filters we need to apply when
 			(cat . ,org-agenda-category-filter))
 (if (org-agenda-use-sticky-p)
 	(progn

Re: [BUG] org-timer-start doesn't seem to take the timer string at point [9.5.5 (release_9.5.5 @ z:/emacs-i686/share/emacs/28.2/lisp/org/)]

[Ihor Radchenko]

Ypo  writes:

> Sorry for my delayed answer. But I don't see it either :/
>
> "The prompt will default to a timer string at
> +  point (if any),"
>
> I can't see it well related to the C-u prefix. For example why the "(if 
> any)"? It should be unnecessary, since it is the previous explained 
> general case.

I feel that you missed the context by reading only the diff in the commit.
The full text in the manual after applying the patch reads like:

- {{{kbd(C-c C-x 0)}}} (~org-timer-start~) ::

  #+kindex: C-c C-x 0
  #+findex: org-timer-start
  Start or reset the relative timer.  By default, the timer is set
  to 0.  When called with a {{{kbd(C-u)}}} prefix, prompt the user for
  a starting offset.  The prompt will default to a timer string at
  point (if any), providing a convenient way to restart taking notes
  after a break in the process.  When called with a double prefix
  argument {{{kbd(C-u C-u)}}}, change all timer strings in the active
  region by a certain amount.  This can be used to fix timer strings
  if the timer was not started at exactly the right moment.



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

Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals

[Ihor Radchenko]

"Rick Lupton"  writes:

> I wonder if you have seen Pollen’s approach to this? 
> https://docs.racket-lang.org/pollen/pollen-command-syntax.html

Thanks for the interesting reference!
After skimming through the syntax described in the link, I feel like
most of the features are already present in Org syntax or being
discussed here.

> There are two separate ideas used there which seemed related to this 
> discussion. I’m not sure if they are useful in the org context.  
>
> 1. The use of a special character (◊ by default) which introduces a 
> command/inline special block. I don’t know if this would be worth considering 
> as an alternative to @ (which also seems reasonable) to avoid ambiguity with 
> other syntax. As the link above discusses it’s harder to type but there are 
> solutions. 

I do understand the idea behind ◊, but it is the design decision we
would need to make before creating Org syntax. At this point, we are not
going to change the Org syntax concepts just for having the nice
feature. There is no point to solve the escaping problem just for a
single new Org syntax element and not changing the rest of the syntax. 

So, I'd prefer to keep "@" or other symbol we already use in the
existing Org elements/objects.

For escaping @ inside, we already have zero-width, an alternative idea
with special \-- entity, and we can introduce \atsymbol entity that
exports and displays as "@".

> 2. Making it easy to define custom functions that produce org syntax. A bit 
> like perhaps Max's suggestion to use source blocks, but instead of writing 
> AST-like structure directly in the document where you want it, you can call a 
> previously defined function to build it. This is similar to org macros but 
> I’m not sure if they are so flexible as a lisp function. There is also the 
> option to choose between passing arguments as lisp (in [ ]) or as markup (in 
> { })

We already have named code blocks to call arbitrary code in arbitrary
programming language and produce arbitrary results, including Org
markup. On export. I do not think that we should allow runtime markup
calculations on-the-fly due to performance reasons.

Also, Org macros do allow arbitrary elisp:

   As a special case, Org parses any replacement text starting with
‘(eval’ as an Emacs Lisp expression and evaluates it accordingly.
Within such templates, arguments become strings.  Thus, the following
macro


 #+MACRO: gnustamp (eval (concat "GNU/" (capitalize $1)))

turns ‘{{{gnustamp(linux)}}}’ into ‘GNU/Linux’ during export.

Max's idea about AST structure is just an extra fallback to produce
really tricky cases. And since it is going to be an src block result,
all the features for src blocks will apply, including calling arbitrary
code (not just Elisp). I do not see this idea as being a part of normal
usage, just really weird border cases. (At least, it is my
understanding. Max may chime in with more clarifications).

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

Re: [PATCH 1/1] Allow returning empty list from post-processing block

[Ihor Radchenko]

Jonas Bernoulli  writes:

> * lisp/ob-ref.el (org-babel-ref-resolve): When the result an empty
> list, then treat it as a list, not as the symbol nil.
> * testing/lisp/test-ob.el (test-ob/return-empty-list-from-post-block):
> Add new test.
> * etc/ORG-NEWS (Post-processing code blocks can return an empty list):
> Document change in behavior.

Thanks for the patch!
LGTM in general.

>  
> +(ert-deftest test-ob/return-empty-list-from-post-block ()

Re: test location. Should probably be around
`test-ob/elisp-in-header-arguments'.

Also, I'd slightly prefer to have a more general test name like
test-ob/post-header-argument. We may add more cases inside later.

I have no comments wrt the code in the commit.

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

Re: [BUG] org-beamer :BEAMER_ACT: ignored on columns

[Ihor Radchenko]

"Fraga, Eric"  writes:

> On Wednesday,  5 Oct 2022 at 06:38, reza wrote:
>> But the overlay specification is missing on the second column and I
>> guess this is a bug?
>
> Maybe a bug or more simply a missing feature.  On line 552 of
> ox-beamer.el, we add options but there is no equivalent for adding
> actions to the column definition.
>
> The attached patch adds action processing but I've only tested it
> minimally (busy with teaching unfortunately).

Thanks for the patch anyway!

>;; Start a "columns" environment when explicitly requested or
>;; when there is no previous headline or the previous
>;; headline do not have a BEAMER_column property.
> @@ -546,10 +551,11 @@ used as a communication channel."
> (if (not (equal environment "columns")) "\\begin{columns}\n"
>(format "\\begin{columns}%s\n" options)))
>   (when column-width
> -   (format "\\begin{column}%s{%s}\n"
> +   (format "\\begin{column}%s%s{%s}\n"
>  ;; One can specify placement for column only when
>  ;; HEADLINE stands for a column on its own.
>  (if (equal environment "column") options "")
> +(if (equal environment "column") actions "")

Is there any reason why you only allow actions for "column" environment
specifically? What about other environments?

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

Re: [PATCH] DOCT integration: template specific hooks [9.5.5 (9.5.5-g003cc7 @ /home/n/.emacs.d/elpaca/builds/org/)]

[Ihor Radchenko]

No Wayman  writes:

> The attached patch is the first step toward integrating DOCT[1] 
> syntax into Org mode.

Thanks! This is most welcome.

> It adds property options to org-capture-templates which make it 
> easier to run template-specific hooks.
> ...
> Contrast the above with the following syntax enabled by the 
> attached patch: 
> 
> #+begin_src emacs-lisp :lexical t
> (let ((org-capture-templates
>'(("t" "test" plain (file "/tmp/test.org")
> "test %?"
> :hook ((lambda () (insert "mode-hook\n")))
> :before-finalize ((lambda () (insert 
> "before-finalize\n")))
> ;; Only a message because this happens outside the 
> context
> ;; of the capture buffer.
> :after-finalize ((lambda () (message "after-finalize")))
> :prepare-finalize ((lambda () (insert 
> "prepare-finalize\n")))
>   (org-capture nil "t"))
> #+end_src
> 
> These template-specific hook functions run prior to their global 
> counterparts.

LGTM.
 
> Ihor, an implementation note: I have not used `run-hooks' with 
> these because they have no associated symbol.
> The functions are lists stored directly on `org-capture-plist'.

Then, please add an appropriate comment in the code.

> See attached patch.
>
> From 780194a5af6a8a6c7fbb602e834dcbec78016070 Mon Sep 17 00:00:00 2001
> From: Nicholas Vollmer 
> Date: Tue, 27 Sep 2022 05:44:33 -0400
> Subject: [PATCH] org-capture: Add template hook properties
>
> * lisp/org-capture.el (org-capture-templates): Document template hook 
> properties.
> (org-capture-finalize): execute :prepare/:before/:after-finalize functions.
Nitpick: Execute

> (org-capture-place-template): execute :hook functions.

> * doc/org-manual.org Document template hook properties.

You also need to add an appropriate ORG-NEWS entry.

> +  - ~:hook~ ::
> +
> +A function or list of functions run before `org-capture-mode-hook'
> +when the template is selected.

You did not mention the number of arguments passed to the functions.

> + - ~:prepare-finalize~ ::
> +
> +A function or list of functions run before 
> `org-capture-prepare-finalize-hook'
> +when the template is selected.
> +
> + - ~:before-finalize~ ::
> +
> +A function or list of functions run before 
> `org-capture-before-finalize-hook'
> +when the template is selected.
> +
> + - ~:after-finalize~ ::
> +
> +A function or list of functions run before 
> `org-capture-after-finalize-hook'
> +when the template is selected.

In the above, please use the quoting consistently. This is an Org file,
so do not use `symbol'. Instead, use ~symbol', as documented in
doc/Documentation_Standards.org

>   :no-saveDo not save the target file after finishing the capture.
>  
> + :hook   A function or list of functions run before
> + `org-capture-mode-hook' when the template is selected.
> +
> + :prepare-finalize   A function or list of functions run before
> + `org-capture-prepare-finalize-hook'
> + when the template is selected.
> +
> + :before-finalizeA function or list of functions run before
> + `org-capture-before-finalize-hook'
> + when the template is selected.
> +
> + :after-finalize A function or list of functions run before
> + `org-capture-after-finalize-hook'
> + when the template is selected.

Again, the number of arguments passed to the hooks should be documented.

>  
> +(defun org-capture--run-template-functions (keyword  local)
> +  "Run template's KEYWORD functions.
> +If LOCAL is non-nil use the buffer-local value of `org-capture-plist'."

It is unclear what "KEYWORD functions" refers to.

> +  (let ((value (org-capture-get keyword local)))
> +(if (functionp value)
> +(funcall value)
> +  (mapc #'funcall value

The reasoning why not `run-hooks' might be commented here.

>  
> +;; Do not use the local arg to `org-capture-get' here.
> +;; The buffer-local value has been stored on `org-capture-plist'.

Did you mean "... local arg to `org-capture--run-template-function'"?

> +(org-capture--run-template-functions :after-finalize)
>  (run-hooks 'org-capture-after-finalize-hook)
>  ;; Special cases
>  (cond
> @@ -1147,6 +1175,7 @@ may have been stored before."
>  (`item (org-capture-place-item))
>  (`checkitem (org-capture-place-item)))
>(setq-local org-capture-current-plist org-capture-plist)
> +  (org-capture--run-template-functions :hook t)
>(org-capture-mode 1))

Here and above, it would be a bit more clear to use something like
'local instead of t argument.

Also, please add some tests into testing/lisp/test-org-capture.el.

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

Re: Planning links to tasks

[Eduardo Suarez Santana]

Org sample fixed:

BEGIN ORG SAMPLE

...
* Planning
** Planned tasks
- [[#task4][My task 4 header]]
  - [[#task5][My task 5 header]]
  - [[#task1][My task 1 header]]
- [[#task2][My task 2 header]]
  - [[#task7][My task 7 header]]
- [[#task6][My task 6 header]]
  - [[#task3][My task 3 header]]
** Unplanned tasks
- [[#task8][My task 8 header]]
- [[#task9][My task 9 header]]

END ORG SAMPLE

Re: [HELP] Fwd: Org format as a new standard source format for GNU manuals

[Rick Lupton]

Hi Ihor and all,

I wonder if you have seen Pollen’s approach to this? 
https://docs.racket-lang.org/pollen/pollen-command-syntax.html

There are two separate ideas used there which seemed related to this 
discussion. I’m not sure if they are useful in the org context.  

1. The use of a special character (◊ by default) which introduces a 
command/inline special block. I don’t know if this would be worth considering 
as an alternative to @ (which also seems reasonable) to avoid ambiguity with 
other syntax. As the link above discusses it’s harder to type but there are 
solutions. 

2. Making it easy to define custom functions that produce org syntax. A bit 
like perhaps Max's suggestion to use source blocks, but instead of writing 
AST-like structure directly in the document where you want it, you can call a 
previously defined function to build it. This is similar to org macros but I’m 
not sure if they are so flexible as a lisp function. There is also the option 
to choose between passing arguments as lisp (in [ ]) or as markup (in { })

On Tue, 4 Oct 2022, at 9:28 PM, Juan Manuel Macías wrote:
> Ihor Radchenko writes:
>
>> If I were to choose an alternative symbol other than "_", I'd choose
>> "@":
>>
>> @name{}
>> @name{{> @name[:key value ...]{}
>>
>> 1. It is similar to Texinfo
>> 2. It does not clash with TeX
>> 3. We already use @ in the inline export snippets.
>
> I like the "@" alternative a lot. And I agree with all three points. It is
> also compact without losing clarity, and does not give the feeling of a
> blank space before, as in the case of "_".
>
> Best regards,
>
> Juan Manuel

[PATCH] Three documentation patches

[Stefan Kangas]

Please find attached three separate documentation patches.
From 269faa44ec18bb63c61ecba4cb232ceb0e46cd10 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 2 Oct 2022 21:54:20 +0200
Subject: [PATCH 1/3] Add crossreference to org-stuck-projects docstring

* lisp/org-agenda.el (org-stuck-projects): Add Info manual reference
to docstring.
---
 lisp/org-agenda.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index b608bdd29..612407c0a 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -614,13 +614,17 @@ you can then use it to define a custom command."
   '("+LEVEL=2/-DONE" ("TODO" "NEXT" "NEXTACTION") nil "")
   "How to identify stuck projects.
 This is a list of four items:
+
 1. A tags/todo/property matcher string that is used to identify a project.
-   See the manual for a description of tag and property searches.
-   The entire tree below a headline matched by this is considered one project.
+   See Info node `(org) Matching tags and properties' for a
+   description of tag and property searches.  The entire tree
+   below a headline matched by this is considered one project.
+
 2. A list of TODO keywords identifying non-stuck projects.
If the project subtree contains any headline with one of these todo
keywords, the project is considered to be not stuck.  If you specify
\"*\" as a keyword, any TODO keyword will mark the project unstuck.
+
 3. A list of tags identifying non-stuck projects.
If the project subtree contains any headline with one of these tags,
the project is considered to be not stuck.  If you specify \"*\" as
@@ -628,6 +632,7 @@ This is a list of four items:
the explicit presence of a tag somewhere in the subtree, inherited
tags do not count here.  If inherited tags make a project not stuck,
use \"-TAG\" in the tags part of the matcher under (1.) above.
+
 4. An arbitrary regular expression matching non-stuck projects.
 
 If the project turns out to be not stuck, search continues also in the
-- 
2.30.2

From f0af8f8e68e3953455c7ef5d08651da39ef86a01 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Sun, 2 Oct 2022 21:54:27 +0200
Subject: [PATCH 2/3] Improve documentation of org-agenda-skip-*

* doc/org-manual.org (Special Agenda Views): Improve indexing.
* lisp/org-agenda.el (org-agenda-skip-function)
(org-agenda-skip-entry-if, org-agenda-skip-subtree-if): Expand
docstrings.
(org-agenda-skip-if): Doc fix; clarify wording.
---
 doc/org-manual.org |  2 ++
 lisp/org-agenda.el | 33 +++--
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index d249f32d6..5de4f93c7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21159,6 +21159,8 @@ meaningful string suitable for the agenda view.
 
 #+vindex: org-odd-levels-only
 #+vindex: org-agenda-skip-function
+#+findex: org-agenda-skip-entry-if
+#+findex: org-agenda-skip-subtree-if
 Search for entries with a limit set on levels for the custom search.
 This is a general approach to creating custom searches in Org.  To
 include all levels, use =LEVEL>0=[fn:161].  Then to selectively pick
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 612407c0a..9189bbafb 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4203,12 +4203,19 @@ to t."
 If this function returns nil, the current match should not be skipped.
 Otherwise, the function must return a position from where the search
 should be continued.
-This may also be a Lisp form, it will be evaluated.
-Never set this variable using `setq' or so, because then it will apply
-to all future agenda commands.  If you do want a global skipping condition,
-use the option `org-agenda-skip-function-global' instead.
-The correct usage for `org-agenda-skip-function' is to bind it with
-`let' to scope it dynamically into the agenda-constructing command.
+
+This may also be a Lisp form that will be evaluated.  Useful
+forms include `org-agenda-skip-entry-if' and
+`org-agenda-skip-subtree-if'.  See the Info node `(org) Special
+Agenda Views' for more details and examples.
+
+Never set this variable using `setq' or similar, because then it
+will apply to all future agenda commands.  If you want a global
+skipping condition, use the option `org-agenda-skip-function-global'
+instead.
+
+The correct way to use `org-agenda-skip-function' is to bind it with `let'
+to scope it dynamically into the agenda-constructing command.
 A good way to set it is through options in `org-agenda-custom-commands'.")
 
 (defun org-agenda-skip ( element)
@@ -5121,12 +5128,18 @@ bind it in the options section.")
 
 (defun org-agenda-skip-entry-if ( conditions)
   "Skip entry if any of CONDITIONS is true.
-See `org-agenda-skip-if' for details."
+See `org-agenda-skip-if' for details about CONDITIONS.
+
+This function can be put into `org-agenda-skip-function' for the
+duration of a command."
   (org-agenda-skip-if nil 

Re: Some links in online manual do not work

[Tim Landscheidt]

Tim Cross  wrote:

>> at https://orgmode.org/manual/HTML-Export.html, the links
>> for the first five (5) and the last two (2) subsections
>> work, the links for:

>> - "Headlines in HTML export"
>>   (https://orgmode.org/manual/Headlines-in-HTML-export.html)
>> - "Links in HTML export"
>>   (https://orgmode.org/manual/Links-in-HTML-export.html)
>> - "Tables in HTML export"
>>   (https://orgmode.org/manual/Tables-in-HTML-export.html)
>> - "Images in HTML export"
>>   (https://orgmode.org/manual/Images-in-HTML-export.html)
>> - "Math formatting in HTML export"
>>   (https://orgmode.org/manual/Math-formatting-in-HTML-export.html)
>> - "Text areas in HTML export"
>>   (https://orgmode.org/manual/Text-areas-in-HTML-export.html)

>> however all return "301 Moved Permanently", pointing back to
>> "HTML-Export.html".

>> The fact that all failing links are named
>> "Something-in-HTML-export.html" might suggest an issue with
>> the webserver configuration.

> This looks like the nginx case issue again.

> I've looked at this and there does not seem to be any 'clean' way to fix
> this which also doesn't have significant processing overhead or a
> maintenance burden.

> I wonder if it would be worthwhile adding an option to HTML export which
> would force all link targets and exported filenames to lower case,
> thereby avoiding issues on platforms and with web servers which have
> different positions wrt case sensitivity?

Is the nginx configuration/webserver setup documented some-
where?

Tim

[PATCH 0/1] Allow returning empty list from post-processing block

[Jonas Bernoulli]

Here's my patch, including a test and a news entry.

I didn't know where to put the test so I just put it at the beginning.
It should probably be moved.

Jonas Bernoulli (1):
  Allow returning empty list from post-processing block

 etc/ORG-NEWS|  6 ++
 lisp/ob-ref.el  |  2 +-
 testing/lisp/test-ob.el | 24 
 3 files changed, 31 insertions(+), 1 deletion(-)

-- 
2.37.3

[PATCH 1/1] Allow returning empty list from post-processing block

[Jonas Bernoulli]

* lisp/ob-ref.el (org-babel-ref-resolve): When the result an empty
list, then treat it as a list, not as the symbol nil.
* testing/lisp/test-ob.el (test-ob/return-empty-list-from-post-block):
Add new test.
* etc/ORG-NEWS (Post-processing code blocks can return an empty list):
Document change in behavior.
---
 etc/ORG-NEWS|  6 ++
 lisp/ob-ref.el  |  2 +-
 testing/lisp/test-ob.el | 24 
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4728528f8..74095d101 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -425,6 +425,12 @@ The new variable name is =org-plantuml-args=.  It now 
applies to both
 jar PlantUML file and executable.
 
 ** Miscellaneous
+*** Post-processing code blocks can return an empty list
+
+When the result of a regular code block is nil, then that was already
+treated as an empty list.  Now that is also the case for code blocks
+that post-process the result of another block.
+
 *** Styles are customizable in ~biblatex~ citation processor
 
 It is now possible to add new styles or modify old ones in ~biblatex~
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index b79e47900..2b4a16aea 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -199,7 +199,7 @@ (defun org-babel-ref-resolve (ref)
(org-babel-execute-src-block nil info params
 (error "Reference `%s' not found in this buffer" ref
 (cond
- ((symbolp result) (format "%S" result))
+ ((and result (symbolp result)) (format "%S" result))
  ((and index (listp result))
   (org-babel-ref-index-list index result))
  (t result)
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 99912fe63..8d1548fe1 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -26,6 +26,30 @@ (require 'ob-ref)
 (require 'org-table)
 (eval-and-compile (require 'cl-lib))
 
+(ert-deftest test-ob/return-empty-list-from-post-block ()
+  "When the result of a post-processing source block is an empty
+list, then it should be treated as such; not as the symbol nil."
+  (should
+   (let ((default-directory temporary-file-directory))
+ (org-test-with-temp-text
+ "
+#+name: addheader
+#+header: :var rows=\"\"
+#+begin_src elisp :hlines yes
+  '()
+#+end_src
+#+header: :post addheader(*this*)
+#+begin_src emacs-lisp :results table
+#+end_src
+#+RESULTS:
+: nil"
+   (org-babel-execute-src-block)
+   (goto-char (1- (point-max)))
+   (equal (buffer-substring-no-properties
+   (line-beginning-position)
+   (line-end-position))
+  "#+RESULTS:")
+
 (ert-deftest test-ob/indented-cached-org-bracket-link ()
   "When the result of a source block is a cached indented link it
 should still return the link."
-- 
2.37.3

Re: [BUG] org-timer-start doesn't seem to take the timer string at point [9.5.5 (release_9.5.5 @ z:/emacs-i686/share/emacs/28.2/lisp/org/)]

[Ypo]

Sorry for my delayed answer. But I don't see it either :/

"The prompt will default to a timer string at
+  point (if any),"

I can't see it well related to the C-u prefix. For example why the "(if 
any)"? It should be unnecessary, since it is the previous explained 
general case.


Best regards


El 03/10/2022 a las 4:57, Ihor Radchenko escribió:

Ypo  writes:


Oh! Thanks

I didn't understand. Maybe this would be more understandable?:


   When called with a ‘C-u’ prefix, prompt the user for a starting
  offset or, if there is a timer string at point, this is taken as the
  default, ...

Or:


   When called with a ‘C-u’ prefix, there are 2 options: prompt the user for a 
starting
  offset.  Or, if there is a timer string at point, this is taken as the
  default, ...

Your versions still feel a bit confusing.
What about the attached patch?

Re: Numbered footnotes in the manual interfere with diff (was: Dates in headlines)

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>>> https://orgmode.org/manual/Handling-Links.html#FOOT28
>>
>> Unless I miss something, this footnote is plain wrong. The timestamps
>> are not removed. At least not when I run M-x org-store-link on a
>> headline with timestamp with emacs -Q.
>
> I think we should just remove this footnote.

Done on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5adde9f3fed4e0d1003860002f21c827276f1d19

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

A function to perform Org related searches in several places

[Juan Manuel Macías]

Hi all,

For my personal use I have written a function which performs Org related
searches in different places. The list of places is expandable, but so
far I found them useful: this mailing list, the Org Manual (via org-ql),
the Git log and the Org Reddit. The idea was that everything would be
done without leaving Emacs confort, so the results from the internet are
returned in EWW.

Before entering the search term, it defaults to the word at point or the
marked region.

The function has two versions. The first version does not depend on any
external packages to display the options. The second version includes a
simple hydra. The hydra version has the advantage that you can have the
hydra buffer open and continue running more searches on the same term. I
don’t know if it’s very orthodox to include the definition of the hydra
inside the function (I would say no, I don’t know), but I couldn’t think
of another way to pass the argument to the different heads of the hydra…

It’s homemade and improvable code, but I’m attaching it here in an Org
document, in case someone finds it useful :-).

Best regards,

Juan Manuel



function.org
Description: Lotus Organizer

Re: [BUG] org-beamer :BEAMER_ACT: ignored on columns

[Fraga, Eric]

On Wednesday,  5 Oct 2022 at 06:38, reza wrote:
> But the overlay specification is missing on the second column and I
> guess this is a bug?

Maybe a bug or more simply a missing feature.  On line 552 of
ox-beamer.el, we add options but there is no equivalent for adding
actions to the column definition.

The attached patch adds action processing but I've only tested it
minimally (busy with teaching unfortunately).

-- 
: Eric S Fraga, with org release_9.5.5-851-ge9781f in Emacs 29.0.50
From 6668760b3be48610dddb03f20c5291760c11b8bf Mon Sep 17 00:00:00 2001
From: Eric S Fraga 
Date: Wed, 5 Oct 2022 09:15:05 +0100
Subject: [PATCH] lisp/ox-beamer.el: Add BEAMER_ACT to column definition

* ox-beamer.el (org-beamer--format-block): Process BEAMER_ACT if given
for column block.
---
 lisp/ox-beamer.el | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 51684448d..1d84aae6e 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -512,6 +512,11 @@ used as a communication channel."
 	 (options (if raw-options
 		  (org-beamer--normalize-argument raw-options 'option)
 		""))
+ ;; also process actions
+	 (raw-actions (org-element-property :BEAMER_ACT headline))
+	 (actions (if raw-actions
+	  (org-beamer--normalize-argument raw-actions 'action)
+	""))
 	 ;; Start a "columns" environment when explicitly requested or
 	 ;; when there is no previous headline or the previous
 	 ;; headline do not have a BEAMER_column property.
@@ -546,10 +551,11 @@ used as a communication channel."
(if (not (equal environment "columns")) "\\begin{columns}\n"
 	 (format "\\begin{columns}%s\n" options)))
  (when column-width
-   (format "\\begin{column}%s{%s}\n"
+   (format "\\begin{column}%s%s{%s}\n"
 	   ;; One can specify placement for column only when
 	   ;; HEADLINE stands for a column on its own.
 	   (if (equal environment "column") options "")
+	   (if (equal environment "column") actions "")
 	   (format "%s\\columnwidth" column-width)))
  ;; Block's opening string.
  (when (nth 2 env-format)
-- 
2.30.2

Re: Explicit page breaks

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>
>> May we introduce a new standard macro {{{page-break(backend)}}}
>> that will expand to an appropriate
>> @@backend:> ?
>
> The macro seems like a good idea. The only (minor) inconvenience that I
> see, if I have understood it correctly, is in the case of LaTeX, where
> there are several commands that do different things: \pagebreak,
> \clearpage, \newpage, etc.
>
> Since \pagebreak is a more low-level command (introduces a hard break),
> it could be left as the default command \clearpage, which starts a new
> page and ends the old one. I don't know...
>
> By the way, in LaTeX there is also the opposite of \pagebreak:
> \nopagebreak, with a mandatory level from 1 to 4. I see this type of
> commands more useful for defining new LaTeX commands than for inserting
> them directly into the document.

Hmm... Then I am wondering about the utility of page break macro outside
odt export.

> And, in any case, I think this page break topic is most useful
> especially for odt, which only has a hard break (and also splits the
> paragraph in two if added inside the paragraph). For LaTeX, after all,
> putting things like @@latex:\pagrebreak[2]@@ doesn't involve much
> verbosity.
>
> Anyway, the opendocument schema is completely arcane to me. I have taken
> a look at the Org Manual and it says that this snippet adds a page break
> in odt export:
>
> #+odt:
>
> But I have tried:
>
> foo
>
> #+odt:
>
> bar
>
> and the document is not exported with the page break. I don't know if
> I'm missing something. But as i said, XML is beyond me :-).

I missed this part of the manual.
If adding page break is this easy, I am not sure if we really need to
bother with macro.

The only thing might be adding the PageBreak style into
etc/styles/OrgOdtStyles.xml, which you likely missed. (see *Hint* in the
manual).

Or we may also add {{{odt-page-break}}} macro for odt specifically.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] org-table: deleting columns not always actualise the formulas. [9.4.6 (release_9.4.6-541-g52b097 @ /home/oub/emacs/site-lisp/packages/org/)]

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>> But as you can see @3$17 only gets changed to @3$16 but not to @3$8 as
>> it should be.

> Thanks for reporting, and sorry for the late reply.
> Fixed on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ceb99b86006f9a10a772860c72dd473cb15a72aa

Thanks! Better late than never. 


-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 


smime.p7s
Description: S/MIME cryptographic signature

Re: Support for tagging (special) blocks

[Ihor Radchenko]

Sébastien Miquel  writes:

> Hi,
>
> Ihor Radchenko writes:
>> Thanks for the clarification!
>> I did not mean to reduce the font size in affiliated keywords.
>> I was referring to replacing the display of affiliated keywords:
>>
>> #+name: A classic
>> #+tag: easy
>>
>> will be displayed by Emacs as
>>
>> #+... A classic :easy:
>>
>> The underlying text will not be changed.
>> The hidden parts will be revealed upon cursor entering the affiliated
>> keywords.
>
> Perhaps something like
> #+... name: A classic tag: easy
> might be used for any kind of keyword. That'd be quite the trick.

> It would certainly improve the situation when an element has several
> keywords, but I'm not sure how common that is.
>
> I'll look into implementing such #+name and #+tag keywords, when I
> have the time.

Escaping might be an issue.
Another approach could be following out headline format
#+name: Title :tag1:tag2:

In any case, I am not too concerned about the semantics at this point.

In order to implement tag support in named blocks, you will need to add
it to many places in Org, like parser, export, babel, user commands,
etc. It is not trivial. And do not forget about backwards compatibility
and, for example, third-party export backends.

> On an unrelated note, how is your work on revamping org's
> fontification going, if I may ask ? I had had a look at your repo, but
> since adapting my configuration would have required some effort I did
> not try it.

The latest progress is a bit of discussion on parser-based font-lock
keywords in emacs-devel. See
https://yhetil.org/emacs-devel/87wn9srn9n.fsf@localhost/

The code status still requires some decisions to be made about code
design of the parser. In particular, the current (albeit working)
implementation will make it difficult to apply arbitrary fontification
order for parent/child elements. Like in
https://orgmode.org/list/m2mtdp2cwo@ntnu.no

And I need to write tests, add faces to all possible elements/objects,
and re-factor the code into shorter function.

I have not had much time to work in these lately because of the upcoming
Org release.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] lisp/org-agenda.el: Fix filter preset problem for sticky agenda

[Bastien Guerry]

Hi Ihor and Liu,

Ihor Radchenko  writes:

>>  I have signed the FSF
>> copyright assignment paper.
>
> Bastien, could you please confirm the FSF records?

I do confirm, I updated https://orgmode.org/worg/contributors.html

Liu, thanks in advance for contributing to Org!

Best,

-- 
 Bastien

Re: Post-process table without changing result for empty table(/list)

[Ihor Radchenko]

Jonas Bernoulli  writes:

>>> In the long run you might want to consider not turning any symbols
>>> into strings, at least not when the "regular" block as well as the
>>> post-processing block both use elisp.
>>
>> This may be tricky. Introducing any kind of special case will make the
>> code fragile. We should better make things as generic as possible.
>
> By "special case", do you mean "just for elisp", or "if both use the
> same language, whatever that might be"?  IMO it would be best if as much
> information were preserved between the two code blocks, and when they
> use the same language, that should be "all of it", or nearly.

Either way. It's not like I am against the idea. Rather (1) afraid to
over-complicate the already complex babel code; (2) afraid to break
something non-trivial.

If we do it, I'd prefer same language / same language. Basically, as
generic as possible approach that will be easier to maintain.

> If they use the same language that might be fairly easy to do (bypass
> the code that previously prevented it), but of course it would be
> preferable if all type information were preserved between any two block.
>
> But that would be harder, which is why I would suggest to first/only do
> it if the same language is used by both blocks.  The actual suggestion
> to do it only if both block use elisp, was more about first trying it
> with the language we are most familiar with.  I wasn't trying to imply
> it should only be done for that language.  Of course, if initially only
> doing for elisp actually makes it harder, then doing it for all
> languages at once, would be preferable.

I do no like to make things elisp-specific, unless you can fit it into
ob-emacs-lisp.el. For more generic things, we also need to be careful
and not break anything.

> Speaking of other languages, when I investigated the above issue, I
> tried whether the issue was maybe limited to post-processing blocks that
> use elisp.  So I also tried doing it using python, but it turned out
> that that had the same issue, and additionally there was a somewhat
> related, python specific, bug:
>
> `org-babel-script-escape' doesn't handle an empty python list correctly:
>   "['a']" => ("a")
> but
>   "[]"=> []
> I.e., an empty python list is turned into an empty lisp vector instead
> of an empty lisp list.  At least for python, (> (length str) 2) should
> probably be changed to use >=.

Patches welcome. But please change the subject in the email containing
the patch for easier tracking.

> ---
>
> And while reproducing that issue just now, I ran into an additional,
> unrelated issue.  I didn't have python installed and when I tried to
> evaluate a python block directly, that resulted in an error as expected.
> However, when I evaluated a elisp block, which uses a post-processing
> block that uses python, that failed silently.

It would help if you can provide a reproducer. Also in a branched
thread.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

[BUG] org-beamer :BEAMER_ACT: ignored on columns

[reza]

Hi List

I have the following MWE:

   * A section

   ** A Frame

   *** A left column
  :PROPERTIES:
  :BEAMER_COL: 0.48
  :END:

   *** A right column
  :PROPERTIES:
  :BEAMER_COL: 0.48
  :BEAMER_ACT: <2->
  :END:


And I would expect the following tex output:


   \section{A section}

   \begin{frame}{A Frame}

   \begin{columns}
   \begin{column}{0.48\columnwidth}
   \end{column}

   \begin{column}<2->{0.48\columnwidth}
   \end{column}
   \end{columns}

   \end{frame}

But the overlay specification is missing on the second column and I 
guess this is a bug?


OpenPGP_0xC375C6AF05125C52.asc
Description: application/pgp-keys


OpenPGP_signature
Description: PGP signature

Re: emacs really slow when inserting a new source code block

[Luca Ferrari]

On Thu, Sep 29, 2022 at 4:19 PM Ihor Radchenko  wrote:
> Or you can bisect the config to hunt for less obvious issues using
> https://github.com/Malabarba/elisp-bug-hunter
>

I'm preparing a new machine right now, so I will plug into the emacs
configuration one bit ata time and see when the problem manifests.
I will report back.
Thanks,
Luca