Re: [BUG] src and example blocks do not properly escape headings [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[note meta]

hi,

I think you might use a comma.

See here https://orgmode.org/worg/org-syntax.html#Blocks

Lines beginning with an asterisk or #+ must be quoted by a comma (,*, ,#+).

Zhen


Vladimir Nikishkin  于2023年9月13日周三 11:59写道：

> Hello, everyone,
>
> My MWE is the following:
>
> ```
> Hello, preamble.
>
> * Heading one
>
> body one
>
> #+begin_src org
> * heading 2
> #+end_src
>
> #+begin_example
> * heading 3
> #+end_example
>
> #+begin_verbatim
> * heading 4
> #+end_verbatim
>
>
> ```
>
> Clearly, "heading 2", "heading 3", and of course, "heading 4" should not
> be considered headings of the original document. However, here they are
> treated as normal headings, in particular, they are not just breaking
> the folding logic, they are even breaking the detection of begin_*/end_*
> blocks.
>
> I have a feeling that this was not the case in the past...?
>
> Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-slackware-linux-gnu, GTK+
> Version 3.24.31, cairo version 1.16.0)
>  of 2023-07-31
> Package: Org mode version 9.6.6 (release_9.6.6 @
> /usr/share/emacs/30.0.50/lisp/org/)
> --
> Your sincerely,
> Vladimir Nikishkin (MiEr, lockywolf)
> (Laptop)
>
>

[BUG] src and example blocks do not properly escape headings [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Vladimir Nikishkin]

Hello, everyone,

My MWE is the following:

```
Hello, preamble.

* Heading one

body one

#+begin_src org
* heading 2
#+end_src

#+begin_example
* heading 3
#+end_example

#+begin_verbatim
* heading 4
#+end_verbatim


```

Clearly, "heading 2", "heading 3", and of course, "heading 4" should not
be considered headings of the original document. However, here they are
treated as normal headings, in particular, they are not just breaking
the folding logic, they are even breaking the detection of begin_*/end_*
blocks.

I have a feeling that this was not the case in the past...?

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-slackware-linux-gnu, GTK+ Version 
3.24.31, cairo version 1.16.0)
 of 2023-07-31
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/usr/share/emacs/30.0.50/lisp/org/)
-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

[PATCH] ob-maxima.el, etc. (was Re: [MAINTENANCE] On how much we can expose internals into defcustom)

[Leo Butler]

On Thu, Sep 07 2023, Ihor Radchenko  wrote:

> `org-babel-execute:maxima' relies on certain output that maxima
> produces. Removing --very-quiet will make the assumptions in the code no
> longer valid. Worse - it might happen that in the absence of --very-quiet
> `org-babel-execute:maxima' (or its future code) will work _almost_
> correctly, with problems going unnoticed to the user.
>
> If we want to support use-case when --very-quiet is absent, we need to
> explicitly change `org-babel-execute:maxima' to account for it,
> maintaining this support forever.
>
> Either way, it will be an extra maintenance burden, which must be
> justified.
>
> The baseline is - we cannot put the burden of wrongly changing
> customization onto the user. Because the user may or may not notice
> them problem, especially when it is subtle and requires good knowledge
> of the Elisp code in ob-maxima.
>
> Of course, the above statement is not 100% strict. If you describe cases
> when customization is necessary for certain valid use cases, we may
> still put in such dangerous customization with all the appropriate
> warnings in the docstring. But it should be justified.
>
>>> So, leaving essential settings customizeable is not necessarily a good idea.
>>
>> I understand your hesitation about full-blown customization using
>> `defcustom'. However, I would still like to have more dials to turn.
>>
>> Perhaps we could add header arguments to get the desired customization?
>
> Header arguments are generally better, because they provide more
> fine-grained control compared to global customization.
>
>> E.g.
>>
>> - :batch :: Control how the Maxima source is evaluated by Maxima.
>>   1. Default. If nil or no, then use batchload with the --very-quiet
>>  command-line flag.
>>   2. If t or yes, then use batch with the --quiet command-line flag;
>
> Is there a place where I can see the differences between batch and batchload?
>
>> - :plot-engine :: Set the plotting package.
>>   1. Default. If nil or no, the use `plot';
>>   2. If `draw', then use `draw'.
>
> Sounds reasonable.
>
>> - Similarly, we could do something like ob-R.el does, and construct the
>>   graphics instructions using some additional header arguments and
>>   grovelling the terminal from the filename (see
>>   org-babel-R-construct-graphics-device-call).
>>
>> My sense is that this would be more in keeping with how other ob-*.el
>> packages do things.
>
> Yes.

Attached is a patch that tries to address some of Ihor's concerns. I
have added two header arguments for maxima src blocks:

- :graphics-pkg lets the user choose the graphics package to use;

- :batch lets the user choose which source-code loader Maxima will use.

I have also moved two defaults, that were embedded in the code, to
`defvar' forms.

I have added tests in test-ob-maxima.el and in ob-maxima-test.org to
demonstrate the use of these header arguments.

Leo


diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
index d1d7c7424..ab166bfd4 100644
--- a/lisp/ob-maxima.el
+++ b/lisp/ob-maxima.el
@@ -48,29 +48,44 @@
   :group 'org-babel
   :type 'string)
 
+(defvar org-babel-maxima-command-arguments
+  "--very-quiet"
+  "A string containing the command-line arguments used when calling the Maxima executable. See `org-babel-maxima-command', `org-babel-maxima-batch/load' and `org-babel-execute:maxima'.")
+
+(defvar org-babel-maxima-graphic-package-options
+  '((plot . "(set_plot_option ('[gnuplot_term, %s]), set_plot_option ('[gnuplot_out_file, %S]))$")
+(draw . "(load(draw), set_draw_defaults(terminal='%s,file_name=%S))$"))
+  "An alist, each element of the form (PACKAGE-NAME . FORMAT-STRING). The format string contains the Maxima code to set the graphic file terminal and name. It must contain `%s' to set the terminal and `%S' to set the filename. The default package is `plot'. See `org-babel-maxima-expand'.")
+
+(defvar org-babel-maxima-default-epilogue
+  "gnuplot_close ()$"
+  "A string with the final Maxima code executed. See `org-babel-maxima-expand'.")
+
 (defun org-babel-maxima-expand (body params)
   "Expand a block of Maxima code according to its header arguments."
-  (let ((vars (org-babel--get-vars params))
-	(epilogue (cdr (assq :epilogue params)))
-	(prologue (cdr (assq :prologue params
+  (let* ((vars (org-babel--get-vars params))
+ (graphic-file (ignore-errors (org-babel-graphical-output-file params)))
+	 (epilogue (cdr (assq :epilogue params)))
+	 (prologue (cdr (assq :prologue params
 (mapconcat 'identity
-	   (list
-		;; Any code from the specified prologue at the start.
-		prologue
-		;; graphic output
-		(let ((graphic-file (ignore-errors (org-babel-graphical-output-file params
-		  (if graphic-file
-		  (format
-		   "set_plot_option ([gnuplot_term, png]); set_plot_option ([gnuplot_out_file, %S]);"
-		   graphic-file)
-		""))
-		;; variables
-		(mapconcat 'org-babel-maxima-var-to-maxima vars "\n")
-		;; body
-		body
-		;; Any code from the 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Juan Manuel Macías]

Max Nikulin writes:

>>> Every piece of code accessing this public constant must implement
>>> fallback from e.g. "de-ch" (or de_CH) to "de". Or to "en" for an
>>> unsupported language.
>> Not necessarily. I mostly thought about some unconventional code
>> that
>> uses the constant for some reason unexpected to us. We do not want to
>> break that.
>
> My point is that direct usage of `org-latex-language-alist' should be
> discouraged.

I understand that org-latex-language-alist is a temporary patch waiting
for something better, and is very dependent on
org-latex-guess-babel-language and
org-latex-guess-polyglossia-language[1], two functions that (IMHO)
should be made obsolete in the future. Keep in mind that the old
org-latex-babel-language-alist was more focused on the old babel ldf
files, which is a limited number of languages. Polyglossia also has a
rather limited number of supported languages. The ini files system is
more extensive and more flexible. One can even define new "virtual"
languages using \babelprovide, or write new custom ini files. With this
scenario a closed list like org-latex-language-alist doesn't make much
sense. I actually think that there would be no need for any ad hoc list
of this type for latex, and everything should be delegated to a global
language name translation system like the one Ihor is developing. I
think that would be the first stone to build native Org multilingual
support.

[1] I think also that in this function there was an unhappy decision:
using a syntax that is not from polyglossia but from babel leaves the
user with little freedom of action, since polyglossia has more 'keyval'
options, not only language variants. For example, this (real polyglossia
code):

\usepackage{polyglossia}
\setmainlanguage{spanish}
\setotherlanguage[numerals=arabic]{chinese}

cannot be translated from (fake polyglossia code):

#+language: es
#+LaTeX_Header: \usepackage[chinese,AUTO]{polyglossia}

--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Preventing inadvertent global modifications

[Max Nikulin]

Hi,

Yesterday, when I was going to commit changes after editing several 
headings in different places of an Org file, I was surprised by huge 
diff with hundreds of chunks. Tags spread across the whole file were 
adjusted by one or tow spaces. Probably I just accidentally hit C-u 
before setting a tag to a new heading by C-c C-q. Of course, I did not 
noticed it immediately. I managed to create a commit with real changes 
without noise due to tags realignment. However I would like to prevent 
similar issues in future.


I can add a prompt for a particular argument of a function by

(defun nm-safe-org-set-tags-command ( arg)
  "Call `org-set-tags-command' requiring to confirm
realigning of all tags."
  (interactive "P")
  (cond
   ((and (equal '(4) arg) (not (yes-or-no-p "Realign all tags? "
   (t (call-interactively #'org-set-tags-command

(add-hook 'org-mode-hook
  (lambda ()
	(define-key org-mode-map (kbd "C-c C-q") 
#'nm-safe-org-set-tags-command)))


The function can be made a bit smarter by adding minimal file size 
threshold.


However almost certainly there are more function "destructive" in a 
similar way. Is there a more general approach to make commands safer in 
respect to global modifications?

Re: [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6)

[Max Nikulin]

On 12/09/2023 16:05, Ihor Radchenko wrote:

Max Nikulin writes:


Every piece of code accessing this public constant must implement
fallback from e.g. "de-ch" (or de_CH) to "de". Or to "en" for an
unsupported language.


Not necessarily. I mostly thought about some unconventional code that
uses the constant for some reason unexpected to us. We do not want to
break that.


My point is that direct usage of `org-latex-language-alist' should be 
discouraged.



This languange-region identifiers may be written in different way
(dash/underscore, case), but they are used specify POSIX locale LANG,
LC_* and extensions like LANGUAGE, so in some cases human friendly names
may be less convenient.


Sorry, but I do not follow you about the downsides of "human friendly" names.


I am not against them for the "#+language" keyword (however I am unsure 
concerning e.g. human variant for de_IT). In the code I would prefer 
ll_RR locale identifiers as a widely accepted practice.



Though I am not sure if we can easily handle tricky
cases like weird installation directory for TeXLive or MikTeX.


kpsewhich babel-de.ini


which may not be in the PATH.


From my point of view it is a call to trouble. E.g. I have no idea how 
to determine if LuaLaTeX is installed. Notice that in Debian the 
executable file is provided by


texlive-latex-base: /usr/bin/lualatex

while actually texlive-luatex must be installed to make lualatex usable. 
Unsure if there is a better way than


kpsewhich -engine luahbtex lualatex.fmt

and I am not sure that this particular command is reliable enough.

Moreover kpsewhich may help to detect if some packages are available for 
export or a fallback to less advanced ones should be used instead.



/usr/share/texlive/texmf-dist/tex/generic/babel/locale/de/babel-de.ini


which is not true on Guix, or when installed under /opt via make install.


It is the exact reason to use kpsewhich. Besides install paths it 
respects TEXMF environment variables that may additional user-specific 
directories to search path.



I did not mean the conventional distros that follow conventional naming
schemes, but the edge cases - I see no point adding automation just to
fight various non-standard user installations later. It will not make
maintenance any easier.


I am considering generating of some locale data on a developer machine 
that has all necessary packages installed. In general I am against 
storing of autogenerated files in git, but in this case it may have sense.

ICalendar export

[Henrik Frisk]

hi,

I've had an iCal export setup working fine for several years. I have an
org-agenda-custom-commands defined with:

(org-agenda-start-day "2022-09-01")
(org-agenda-span 120) ;; number of days
(org-agenda-include-diary nil))

Recently (not sure when) the ics output came out malformed and a newline is
omitted between the end of one event and the beginning of another:

END:VEVENT
BEGIN:VEVENT

is now

END:VEVENTBEGIN:VEVENT

I can't figure out wha the pattern is, for some events the output is
correct.

This is on Org mode version 9.7-pre release_9.6.8-719-gf299fb and emacs 29.1

best,
/Henrik

Re: [BUG] PRIORITIES does not accept multi-byte unicode characters [9.6.9 (N/A @ /gnu/store/3rxpvdkn907pb1ccm2yl3ffyaz02k7d1-emacs-org-9.6.9/share/emacs/site-lisp/org-9.6.9/)]

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> Hi, I tried to hack a UI together to have simple marking of entries with
> priorities and found that multi-byte priorities do not work.
>
> To reproduce: Set priorities as
>
> #+PRIORITIES:   
>
> Then go on a headline and press S-up.
>
> Expected: The lowest priority is selected: [#]
>
> Actual: Only the first byte of the lowest priority is selected: [#]

Try M-x describe-char on any of these emojis.
Org mode relies on `string-to-char' to extract the priority char and
(insert (string-to-char "")) ;=> 

So, it is a problem with Emacs. You may report it with M-x report-emacs-bug

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

[BUG] PRIORITIES does not accept multi-byte unicode characters [9.6.9 (N/A @ /gnu/store/3rxpvdkn907pb1ccm2yl3ffyaz02k7d1-emacs-org-9.6.9/share/emacs/site-lisp/org-9.6.9/)]

[Dr. Arne Babenhauserheide]

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.


Hi, I tried to hack a UI together to have simple marking of entries with
priorities and found that multi-byte priorities do not work.

To reproduce: Set priorities as

#+PRIORITIES:   

Then go on a headline and press S-up.

Expected: The lowest priority is selected: [#]

Actual: Only the first byte of the lowest priority is selected: [#]

I understand full well that I am not using this as indended, but I think
nonetheless that this is a bug, because it would likely also break for
at least some Japanese letters.

Best wishes,
Arne

Emacs  : GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, 
cairo version 1.16.0)
Package: Org mode version 9.6.9 (N/A @ 
/gnu/store/3rxpvdkn907pb1ccm2yl3ffyaz02k7d1-emacs-org-9.6.9/share/emacs/site-lisp/org-9.6.9/)
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: Some Issues I Encountered While Developing Metanote

[Ihor Radchenko]

[ Adding Org mailing list back to CC. Please use "Reply All" or "Wide
  reply" to keep the discussion public ]

note meta  writes:

> Ihor Radchenko  于2023年9月12日周二 16:15写道：
>>
>> ...
>> Are you sure that you meant
>>
>> #+begin
>> #+end:
>>
>> Maybe
>>
>> #+begin:
>> #+end:
>> ?
>>
>> Either way, there is no dynamic block in both cases - dynamic blocks
>> must have non-empty NAME. See
>> https://orgmode.org/worg/org-syntax.html#Dynamic_Blocks
>>
> Indeed, according to the org mode syntax documentation, neither of
> these examples should be a Dynamic block.
>
> #+begin (here is a space)
> #+end:
>
> I double-checked, and from the output of the org mode parser, it
> indeed get parsed as a Dynamic block, this is the output:

Not on the latest Org.
I was also not able to reproduce using built-in Org versions in Emacs
29, 28, and 27. In Emacs 26, I can reproduce.

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

Re: [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6)

[Ihor Radchenko]

Max Nikulin  writes:

>> It is already a public constant. And I see no strong reason to change
>> this (strong enough to justify breaking change).
>
> Every piece of code accessing this public constant must implement 
> fallback from e.g. "de-ch" (or de_CH) to "de". Or to "en" for an 
> unsupported language. To achieve consistent behavior it is better to 
> provide a helper function.

Not necessarily. I mostly thought about some unconventional code that
uses the constant for some reason unexpected to us. We do not want to
break that.

Helper function is certainly a good idea. I did plan for it.

>>> I have a hope that properties may be generated from CLDR data, LaTeX
>>> babel .ini files, etc. However it should be possible to override
>>> specific properties.
>> 
>> For context, I plan to provide a global language-identifier alist that
>> will link human-readable language names to abbreviations like "de",
>> "de-de", etc.
>
> This languange-region identifiers may be written in different way 
> (dash/underscore, case), but they are used specify POSIX locale LANG, 
> LC_* and extensions like LANGUAGE, so in some cases human friendly names 
> may be less convenient.

Sorry, but I do not follow you about the downsides of "human friendly" names.

>> Though I am not sure if we can easily handle tricky
>> cases like weird installation directory for TeXLive or MikTeX.
>
> kpsewhich babel-de.ini

which may not be in the PATH.

> /usr/share/texlive/texmf-dist/tex/generic/babel/locale/de/babel-de.ini

which is not true on Guix, or when installed under /opt via make install.

I did not mean the conventional distros that follow conventional naming
schemes, but the edge cases - I see no point adding automation just to
fight various non-standard user installations later. It will not make
maintenance any easier.

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

bbb:OrgMeetup for Asia-Pacific time zones (was: #2 [[bbb:OrgMeetup]] on Wed, Sep 13, 19:00 UTC+3)

[Ihor Radchenko]

Corwin Brust  writes:

> On Mon, Sep 11, 2023 at 3:39 AM Ihor Radchenko  wrote:
>>
>> Tshiung Han See  writes:
>>
>> > I would’ve liked to join, but that’s 1am (Malaysian time).
>>
>> Currently, the time is decided simply by my own availability.
>> [snip]
>> But someone needs to volunteer.
>>
>
> I can host US/Central evening hours, so any start-time from about 5pm
> until about 10pm my time (10p-3a UTC), give we are talking exclusively
> about "school nights" :)

Thanks for the offer!
This might work, although maybe not on working days.
10pm UTC will be 8am Singapore time - not the best choice for a weekday.

Tshiung, what do you think about such timing?
Others who would prefer the proposed timing - please chime in, so that
we have some idea about who is willing to attend the alternative
schedule.

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

Re: Some Issues I Encountered While Developing Metanote

[Ihor Radchenko]

note meta  writes:

> I'm a big fan of org mode. A few years ago, I couldn't find an app that
> supported org mode on my phone, so I created one myself. I hope that
> through my app, I can introduce org mode to more people, even those who are
> not familiar with Emacs. I also hope to make some contributions to org mode.

Contributions benefiting both you and Org mode are certainly welcome.

> Additionally, is it possible to include Metanote in the 'Tools that work
> with Org' section at https://orgmode.org/tools.html ?  Metanote website is
> https://metanote-dev.github.io/.

Unfortunately, we cannot recommend Metanote on
https://orgmode.org/tools.html page.

This page, unlike WORG wiki, is the official GNU Org mode web-page.

We, as a GNU project, are obliged to follow FSF guidelines, including
https://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration
that explicitly prohibit recommending non-Libre software.

Metanote is a closed source, non-Libre software and thus cannot be
recommended by us officially.

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

Re: Some Issues I Encountered While Developing Metanote

[Ihor Radchenko]

note meta  writes:

> 3. About Pre-blank
>
>The first blank line in a Greater Element is parsed as a paragraph.
> However, this behavior is inconsistent in Items and Footnote definitions.
> In Items and Footnote definitions, a blank line is parsed as a Pre-blank.
> In Footnote definitions, especially, this blank line appears only once
> because having more than one would break the Footnote definitions.
>
> #+begin_example
> [fn:a]
>
> bbb
> #+end_example

Not just items and footnotes, but also headings.

AFAIK, the original motivations to separate :pre-blank from contents was
to avoid problems during export to LaTeX, where blank lines can
sometimes break document structure because blank lines serve as
paragraph separators.

In practice, it does not matter much though - ox-latex cleans up blank
lines in paragraphs.

The only place where :pre-blank is actually utilized is headings.

That said, removing :pre-blank will be a breaking change in the parser.
And I do not see any clear practical benefit dropping it.
So, we should probably leave the current idiosyncrasy for items,
footnote-definitions, and headlines as is.

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

[BUG] org-element-paragraph-separate is not accurate when detecting table.el tables (was: Some Issues I Encountered While Developing Metanote)

[Ihor Radchenko]

note meta  writes:

> 2. About Paragraph
>
>#+begin_example
> +--+
> +--+
> +this is a paragraph+
> +this is a paragraph+
>#+end_example
>
> There should be only one paragraph above, but it's parsed as two:
>
> (org-data nil (section (:begin 1 :end 55 :contents-begin 1 :contents-end 55
> :post-blank 0 :post-affiliated 1 :parent #0) (paragraph (:begin 1 :end 6
> :contents-begin 1 :contents-end 6 :post-blank 0 :post-affiliated 1 :parent
> #1)) (paragraph (:begin 6 :end 55 :contents-begin 6 :contents-end 55
> :post-blank 0 :post-affiliated 6 :parent #1

Confirmed.
`org-element-paragraph-separate', which is used to determine paragraph
boundaries incorrectly detects the above +--+ as table.el table
boundary. It matches

^[ \t]*\+\(?:-+\+)+[ \t]*$

while the actual criteria to match table.el tables is much more complex:

   ;; There is no strict definition of a table.el
   ;; table.  Try to prevent false positive while being
   ;; quick.
   (let ((rule-regexp
  (rx (zero-or-more (any " \t"))
  "+"
  (one-or-more (one-or-more "-") "+")
  (zero-or-more (any " \t"))
  eol))
 (non-table.el-line
  (rx bol
  (zero-or-more (any " \t"))
  (or eol (not (any "+| \t")
 (next (line-beginning-position 2)))
 ;; Start with a full rule.
 (and
  (looking-at-p rule-regexp)
  (< next limit) ;no room for a table.el table
  (save-excursion
(end-of-line)
(cond
 ;; Must end with a full rule.
 ((not (re-search-forward non-table.el-line limit 'move))
  (if (bolp) (forward-line -1) (forward-line 0))
  (looking-at-p rule-regexp))
 ;; Ignore pseudo-tables with a single
 ;; rule.
 ((= next (line-beginning-position))
  nil)
 ;; Must end with a full rule.
 (t
  (forward-line -1)
  (looking-at-p rule-regexp))

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

Re: Some Issues I Encountered While Developing Metanote

[Ihor Radchenko]

note meta  writes:

> 1. Dynamic Block Parsing Issue
>
>#+begin_example
> #+begin
> #+end:
>#+end_example
>
>The above is a Dynamic Block, and the parsed syntax tree is:
>
>(org-data nil (section (:begin 1 :end 17 :contents-begin 1 :contents-end
> 17 :post-blank 0 :post-affiliated 1 :parent #0) (dynamic-block (:begin 1
> :end 17 :block-name nil :arguments nil :contents-begin nil :contents-end
> nil :post-blank 0 :post-affiliated 1 :parent #1

Are you sure that you meant

#+begin
#+end:

Maybe

#+begin:
#+end:
?

Either way, there is no dynamic block in both cases - dynamic blocks
must have non-empty NAME. See
https://orgmode.org/worg/org-syntax.html#Dynamic_Blocks

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