Re: Bug: Changed behaviour of org-at-timestamp-p after recent change
Anders Johansson writes:
> Hi,
> I noticed that this commit:
> b1a570b3b org-agenda: Fix regression when diary sexp timestamps are ignored
>
> made a call like (org-at-timestamp-p 'agenda) match against the regexp
> `org-element--timestamp-regexp`. However, this regexp doesn’t have the
> match groups setup as the others (`org-ts-regexp3` and `org-ts-regexp2`) so
> the last part of the docstring for org-at-timestamp-p doesn’t hold anymore
> (that the timestamp parts should now be put in match groups).
Confirmed.
Can you try the attached patch?
Also, unless I miss something, docstring was not fully obeyed even in
the past. Consider the following timestamp:
<2022-04-15 Fri 11:40>
I ran the following code with point at the timestamp:
(progn (org-at-timestamp-p ) (mapcar #'substring-no-properties (list
(match-string 0) (match-string 1) (match-string 2) (match-string 3)
(match-string 4) (match-string 5) (match-string 6) (match-string 7
The output is:
("<2022-04-15 Fri 11:40>" "2022-04-15 Fri 11:40" "2022" "04" "15" "Fri" "
11:40" "11" "40")
There are two extra groups (group 1 and group 6), presumably due to
earlier changes in org-ts-regexp1.
> I was using this in some code of mine, but I also realize that this doesn’t
> feel all that clean anyway. I am not sure if this is used elsewhere in org
> though.
I am currently working on an alternative concept of analyzing arbitrary
org element components. Instead of named groups, I plan to provide named
match groups:
(progn (org-element-match 'timestamp) (org-element-match-data))
((:minute-start 314 316)
(:hour-start 311 313)
(:day-start 304 306)
(:month-start 301 303)
(:year-start 296 300)
(:date-start 296 316)
(:timestamp-start 295 317)
(:end-marker 316 317)
(:begin-marker 295 296)
(:full 295 317)
(:full-no-blank 295 317)
(:full-no-affiliated 295 317))
The current WIP implementation is in
https://github.com/yantar92/org/blob/feature/org-font-lock-element/lisp/org-element-match.el
The match groups set by org-at-timestamp-p are currently being used by
the following functions: org-mouse-delete-timestamp,
org-follow-timestamp-link, org-time-stamp, org-toggle-timestamp-type
However, all but one of them are only using group 0 and
org-follow-timestamp-link is using group 1 as currently set by
org-at-timestamp-p against the docstring.
Best,
Ihor
>From d9a5cb8b7d7b12aca389331f4817130420d2d744 Mon Sep 17 00:00:00 2001
Message-Id:
From: Ihor Radchenko
Date: Fri, 15 Apr 2022 15:05:39 +0800
Subject: [PATCH] org-at-timestamp-p: Fix invalid regexp groups for 'agenda
scope
* lisp/org.el (org-at-timestamp-p): Make sure that match groups follow
the docstring in `agenda' scope. Update docstring explaining return
values for sexp timestamps.
Reported in https://orgmode.org/list/cakjdto8bqdbw5n6prfnqratjm2daebdcpjj0njwcd4fmhsj...@mail.gmail.com
---
lisp/org.el | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 3cc8a5036..b736a3824 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15248,20 +15248,24 @@ (defun org-at-timestamp-p (&optional extended)
When at a timestamp, return the position of the point as a symbol
among `bracket', `after', `year', `month', `hour', `minute',
`day' or a number of character from the last know part of the
-time stamp.
+time stamp. If diary sexp timestamps, any point inside the timestamp
+is considered `day' (i.e. only `bracket', `day', and `after' return
+values are possible).
When matching, the match groups are the following:
- group 1: year
- group 2: month
- group 3: day number
- group 4: day name
+ group 1: year, if any
+ group 2: month, if any
+ group 3: day number, if any
+ group 4: day name, if any
group 5: hours, if any
group 6: minutes, if any"
- (let* ((regexp (if extended
- (if (eq extended 'agenda)
- org-element--timestamp-regexp
- org-ts-regexp3)
- org-ts-regexp2))
+ (let* ((regexp
+ (if extended
+ (if (eq extended 'agenda)
+ (rx (or (regexp org-ts-regexp3)
+ (regexp org-element--timestamp-regexp)))
+ org-ts-regexp3)
+org-ts-regexp2))
(pos (point))
(match?
(let ((boundaries (org-in-regexp regexp)))
--
2.35.1
Re: Patch: Fix typo in org-manual
"Cody Harris" writes: > I was reading the docs and saw some what looks like some errant > keystrokes in the manual, so here's a patch =] Thanks! Applied to main as a0755ebcc. Best, Ihor Applied.
[PATCH] CONTRIBUTE: Link WORG page when explaining commit message format
Karl Fogel writes: > So, naturally, after I read that item, I assumed that I was ready > to write the commit message, since I already knew Emacs's > guidelines. Thanks for the detailed explanation! Attaching tentative patch with clarification. Best, Ihor >From cd5e965d079aa7a3ac842e8ea3ea5762e2d80985 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Fri, 15 Apr 2022 17:29:47 +0800 Subject: [PATCH] CONTRIBUTE: Link WORG page when explaining commit message format * CONTRIBUTE (Main contribution rules): Link relevant WORG contribute page section with extra conventions for our commit message guidelines. See https://orgmode.org/list/87r16896gh@red-bean.com --- CONTRIBUTE | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTE b/CONTRIBUTE index 94d471a0f..f8a81515e 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -55,8 +55,11 @@ Org maintenance is detailed on Worg: see [[https://orgmode.org/worg/org-maintena the [[https://www.gnu.org/philosophy/kind-communication.en.html][GNU Kind Communications Guidelines]]. - Org mode no longer uses ChangeLog entries to document changes. - Instead, special commit messages are used, as described in the - `CONTRIBUTE' file in the main Emacs repository. + Instead, special commit messages are used. The commit message + format generally follows Emacs conventions, as described in the + `CONTRIBUTE' file in the main Emacs repository. Several more + Org-specific conventions are described in + [[https://orgmode.org/worg/org-contribute.html#commit-messages][worg/org-contribute#commit-messages]]. - Among other things, Org mode is widely appreciated because of its simplicity, cleanness and consistency. We should try to preserve -- 2.35.1
AW: ox-html: exporting LaTeX-environments
Dear Thibault, dear list,
thanks for your fast answer, Thibault! I am happy to have convinced you of
dropping the extra \n's. The patch you addressed works fine for the asterisk
issue: Only those environments get an extra asterisk which are in
org-latex-math-environments-re. Nonetheless, I think we should make that
variable more user-friendly by not requiring one huge regexp but a list of
environment names like ("foo" "bar" "baz").
Unfortunately, the patch does not have any impact on the numbering problem. I
guess we actually need org-html--latex-environments-leave-unlabelled to get
this running. I just wanna give two examples why it is not useful to lable
every environment.
1. Imagine you do not need links to your equations and use the \tag command in
your equation environment to get the right equation numbers within the svg.
This looks nicer anyway because the font is the same and the formatting is
perfect. If we did not have org-html--latex-environments-leave-unlabelled,
there would be both the line number within the equation and, below it, another
in-text-line-number on a new line. Same goes for the figure-environment which
provides its own caption. In general, everything that has its own counter
within the svg should not receive extra equation numbers.
2. There are some environments you do not want labelled. Imagine you compile a
table summarizing the most important formulas of your post. This is not an
equation and it should not be numbered, but it is. Below the table then is a
number which looks awful.
Since I am in the position of setting up a blog just now, I can only stress
this variable is needed. I wish I could help you with the code more than I have
done with my suggestions. But maybe some one else on the list has an idea?
Best Regards,
Vitus
Von: Thibault Marin [thibault.ma...@gmx.com]
Gesendet: Dienstag, 12. April 2022 07:15
An: Vitus Schäfftlein
Cc: emacs-orgmode@gnu.org
Betreff: Re: ox-html: exporting LaTeX-environments
Hi Vitus, list.
My memory is quite fuzzy on this and I won't have a chance to take a
deep look until later, but I will try to share the information I have.
On Mon, 11 Apr 2022 19:38:13 + (9 hours, 37 minutes, 37 seconds ago), Vitus
Schäfftlein wrote:
Dear org-mode mailing list,
[...]
3. Any LaTeX environment name foo is changed to foo* (except it already ends
with an
asterisk). For example, \begin{tabular} is changed to \begin{tabular*}; same
for
\end{tabular}. But tabular* differs from tabular in needing an extra
width-argument, so
the export won’t work properly.
I had submitted a patch trying to address this
(https://list.orgmode.org/87h7ok3qi2.fsf@dell-desktop.WORKGROUP/, I have
attached a new version rebased on main to this message). It never made
it in and I failed to follow-up. This patch (or something similar)
could help with this issue. It basically only adds the star for math
environments (using org-html--math-environment-p)
[...]
Now the newline commands \n before and after %s are exported as whitespace.
Just replacing
\n%s\n by %s (that is, leaving the newlines out) solves the problem. HTML
ignores newlines
anyway.
This seems to work better indeed; the \n's were just cosmetic.
[...]
1 Create a new variable ox-html-latex-environments-no-number of the form
("foo"
"bar" "baz" ...), which contains all environments that should not receive
equation
numbers.
I don't know whether org-html--math-environment-p (as used in the
attached patch) is sufficient to determine whether we need to add a star
to the environment or if we need another variable (in my use cases,
testing for a match environment is sufficient but it may not be the case
in general).
[...]
I don’t know how to express in elisp what is in brackets, though. Does this
make sense to you? I
am a beginner with elisp, so I can only state the ideas I have but not
implement them (yet).
This can be made to work if there is a consensus that we want to add a
ox-html-latex-environments-no-number variable (I can try to help with
that if needed, even though my elisp isn't great)
[...]
(let ((formula-link
(org-html-format-latex
(org-html--unlabel-latex-environment latex-frag)
processing-type info)))
The patch should address that, I would be curious to see if you
encounter additional problematic cases after applying it.
Thanks for resurrecting this and for your help detecting and fixing the issues.
Best,
thibault
Re: [PATCH] CONTRIBUTE: Link WORG page when explaining commit message format
> On Fri, 15 Apr 2022 17:33:33 +0800, Ihor Radchenko > said: Ihor> - Org mode no longer uses ChangeLog entries to document changes. Ihor> - Instead, special commit messages are used, as described in the Ihor> - `CONTRIBUTE' file in the main Emacs repository. Ihor> + Instead, special commit messages are used. The commit message Ihor> + format generally follows Emacs conventions, as described in the Ihor> + `CONTRIBUTE' file in the main Emacs repository. Several more Ihor> + Org-specific conventions are described in Ihor> + [[https://orgmode.org/worg/org-contribute.html#commit-messages][worg/org-contribute#commit-messages]]. It might be good to mention `magit-generate-changelog' there as an easy way to produce the ChangeLog format entry (it doesnʼt require you to iterate over the diff hunks, and you can call it from the magit commit buffer). Robert --
link error when file missing
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.
I have a link in a text file that looks as follows, in fundamental mode:
5. Contracts: [[docview:~/Documents/Wheaton_condo/landscaping/from
Mark/2019/ALM_landscape_contract_Fall_2018.pdf::1][Landscape]],
[[docview:~/Documents/Wheaton_condo/landscaping/from
Mark/2018/ALM_snow_management_contract_Fall_2018.pdf::1][Snow]]
The path is deliberately wrong in the first link--in order to demonstrate the
error that results. The year "2019" there should be "2018" and then in that
case the link works properly (when the file is set to org-mode); the result of
using the proper link is that the document is shown in a docview buffer.
As is, there is an error thrown & below is the backtrace for it (after
appropriate use of "toggle-debug-on-error")
Debugger entered--Lisp error: (wrong-type-argument listp t)
image-mode-winprops(nil)
image-mode-window-put(page 0 nil)
doc-view-goto-page(1)
org-docview-open("~/Documents/Wheaton_condo/landscaping/from Mark/20..." nil)
org-link-open((link (:type "docview" :path
"~/Documents/Wheaton_condo/landscaping/from Mark/20..." :format bracket
:raw-link "docview:~/Documents/Wheaton_condo/landscaping/from..." :application
nil :search-option nil :begin 1000 :end 1115 :contents-begin 1104 :contents-end
1113 :post-blank 0 :parent (paragraph (:begin 989 :end 1234 :contents-begin 989
:contents-end 1234 :post-blank 0 :post-affiliated 989 :parent (item (:bullet
"5. " :begin 986 :end 1235 :contents-begin 989 :contents-end 1234 :checkbox nil
:counter nil :structure (... ... ... ... ... ... ... ...) :pre-blank 0
:post-blank 1 :post-affiliated 986 :tag nil :parent (plain-list ...))) nil)
(cond ((not type) (user-error "No link found")) ((memq type '(comment
comment-block node-property keyword)) (call-interactively
#'org-open-at-point-global)) ((memq type '(headline inlinetask))
(org-match-line org-complex-heading-regexp) (let ((tags-beg (match-beginning
5)) (tags-end (match-end 5))) (if (and tags-beg (>= (point) tags-beg) (<
(point) tags-end)) (org-tags-view arg (save-excursion (let* (... ...)
(buffer-substring ... ... (let* ((val (org-offer-links-in-entry ... ...
arg))) (if (consp val) (let* (...) (if ... ... ...)) nil) ((or (eq type
'footnote-reference) (and (eq type 'footnote-definition) (save-excursion
(skip-chars-forward " \11") (let ((begin ...)) (if begin (< ... begin) (= ...
...)) (org-footnote-action)) ((and (eq type 'planning) (org-in-regexp
org-ts-regexp-both nil t)) (org-follow-timestamp-link)) ((and (eq type 'clock)
value (>= (point) (org-element-property :begin value)) (<= (point)
(org-element-property :end value))) (org-follow-timestamp-link)) ((eq type
'src-block) (org-babel-open-src-block-result)) ((>= (point) (save-excursion
(goto-char (org-element-property :end context)) (skip-chars-backward " \11")
(point))) (user-error "No link found")) ((eq type 'inline-src-block)
(org-babel-open-src-block-result)) ((eq type 'timestamp)
(org-follow-timestamp-link)) ((eq type 'link) (org-link-open context arg))
((memq type '(citation citation-reference)) (org-cite-follow context arg)) (t
(user-error "No link found")))
(let* ((context (org-element-lineage (org-element-context) '(citation
citation-reference clock comment comment-block footnote-definition
footnote-reference headline inline-src-block inlinetask keyword link
node-property planning src-block timestamp) t)) (type (org-element-type
context)) (value (org-element-property :value context))) (cond ((not type)
(user-error "No link found")) ((memq type '(comment comment-block node-property
keyword)) (call-interactively #'org-open-at-point-global)) ((memq type
'(headline inlinetask)) (org-match-line org-complex-heading-regexp) (let
((tags-beg (match-beginning 5)) (tags-end (match-end 5))) (if (and tags-beg (>=
(point) tags-beg) (< (point) tags-end)) (org-tags-view arg (save-excursion
(let* ... ...))) (let* ((val ...)) (if (consp val) (let* ... ...) nil) ((or
(eq type 'footnote-reference) (and (eq type 'footnote-definition)
(save-excursion (skip-chars-forward " \11") (let (...) (if begin ... ...)
(org-footnote-action)) ((and (eq type 'planning) (org-in-regexp
org-ts-regexp-both nil t)) (org-follow-timestamp-link)) ((and (eq type 'clock)
value (>= (point) (org-element-property :begin value)) (<= (point)
(org-element-property :end value))) (org-follow-timestamp-link)) ((eq type
'src-block) (org-babel-open-src-block-result)) ((>= (point) (save-excursion
(goto-char (org-element-property :end context)) (skip-chars-backward " \11")
(point))) (user-error "No link found")) ((eq type 'inline-src-block)
(org-babel-open-src-block-result)
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
On 15/04/2022 05:46, Paul Eggert wrote: On 4/14/22 06:19, Max Nikulin wrote: date-time + "America/Los_Angeles" input should not be reduced to timezone offset in the output. It depends on the application. For some applications (e.g., generating "Date:" lines in email), it is entirely correct to output a timestamp like "14 Apr 2022 15:16:04 -0700", thus losing the fact that the timestamp was generated with TZ="America/Los_Angeles". However if you are storing future events bound to wall time then namely time zone identifier should have precedence. A new rule may be issued between scheduling event and the time it will happen. It is terrible feeling when it is necessary to guess if a web site stores TZ offset or its identifier and in the latter case whether its administrators updated tzinfo. It is better to store location of event since a time zone may be split and time transition may apply only to a part of the original zone. Actually I meant another case. Some representation is got for a time moment and it is necessary to get local time for another time moment. Time zone identifier or an object with internal representation allow to get correct offset for second moment of time. It should be possible to specify whether a function call is isolated conversion or further calculations will follow. Zone internal object or identifier is important for calculation of other date-time values based on the origin value. Again, that depends on the application. It's typically wrong to store an old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because there is no standard for what "Europe/Lisbon" means. If you update your copy of TZDB, or interpret such a timestamp on another computer, that can change the interpretation of such a timestamp. In this particular case, a change in TZDB release 2021b altered the interpretation of this old timestamp because we discovered that DST was observed in 1950 in Portugal. Just identifier may be ambiguous around DST transition. So timezone abbreviations are ambiguous per se but when identifiers are known they may be still necessary to resolve uncertainties for backward time shifts. At certain moment the Olson DB started to use "+04" abbreviations instead of letters for transitions unrelated to daylight saving time. If you want to keep the TZDB identifier for advice about how to interpret dates relative to a timestamp, that's fine. But you should keep the UT offset in addition to the TZDB identifier, if you want your app to be fully accurate and useful. For example, you should store "1950-07-01 00:00:00 + Europe/Lisbon" for a timestamp generated by TZDB release 2021a, so that when you interpret the timestamp in release 2021b you'll have an idea of what you're dealing with. And WET/WEST gets another bit of info in addition to numerical offset. I hope, they may work without explicitly providing time zone offset to the input that anyway requires additional calculations. It doesn't require additional calculations on the Emacs Lisp user's part. All you need to do is save the UT offset, and use it later. There's so little overhead to this that it's not worth worrying about. I do not remember if it is possible at all to obtain using libc the period of constant time offset, when time shift value is valid. Sometimes it is necessary to recalculate offset. ±n hours may mean ±n*3600 seconds or time with same minutes and seconds values but hours value is changed by n even if a 30 min DST transition happens in between. Sorry, I don't understand what this sentence is intended to mean. Let's consider Australia/Lord_Howe with 30min backward DST shift at 2022-04-03 02:00. 8 hours from 2022-04-02 22:00 may mean 2022-04-03 06:00 for duration of the night shift (8:30 instead of usual 8:00). Some technological process requiring precisely 8 hours finishes at 05:30 in such case. So it is not equivalent to add 8 hours or 480 minutes. In the former case it is more convenient to increment particular field and adjust the result if it coincides with ambiguity/impossible range. In the latter case it is better to increment timestamp as seconds since the epoch and back to time fields (leaving aside leap seconds). `parse-time-string' has another set of problems. Sure, but that was just an example. You can write your own date parser. The point is that when you save a localtime timestamp, you should save its UT offset too, in whatever notation is appropriate. You wrote that "2021-01-31 23:30:00 +0300" is parsed correctly. My opinion is that when time zone is known to be Africa/Juba (system-wide setting, environment variable, or an argument of the parsing function) then "2021-01-31 23:30:00 CAT" and "2021-01-31 23:30:00 EAT" should be parsed correctly (and localized date-time formats should be parsed as well). For transitions without DST change there is no conventional text representation. UTC offset is another fea
Re: [PATCH] CONTRIBUTE: Link WORG page when explaining commit message format
On 15 Apr 2022, Robert Pluim wrote: On Fri, 15 Apr 2022 17:33:33 +0800, Ihor Radchenko said: Ihor> - Org mode no longer uses ChangeLog entries to document changes. Ihor> - Instead, special commit messages are used, as described in the Ihor> - `CONTRIBUTE' file in the main Emacs repository. Ihor> + Instead, special commit messages are used. The commit message Ihor> + format generally follows Emacs conventions, as described in the Ihor> + `CONTRIBUTE' file in the main Emacs repository. Several more Ihor> + Org-specific conventions are described in Ihor> + [[https://orgmode.org/worg/org-contribute.html#commit-messages][worg/org-contribute#commit-messages]]. It might be good to mention `magit-generate-changelog' there as an easy way to produce the ChangeLog format entry (it doesnʼt require you to iterate over the diff hunks, and you can call it from the magit commit buffer). I really like the patch, Ihor -- it's already a big improvement! (I haven't tested Robert's suggestion of `magit-generate-changelog', but it seems like a reasonable hint to include, given Magit's popularity.) Best regards, -Karl
Re: What's the flow for adding info: links in Org documents?
On Wed, Apr 13, 2022 at 7:38 AM Max Nikulin wrote: > > On 13/04/2022 01:26, Kaushal Modi wrote: > > On Mon, Apr 11, 2022 at 10:57 AM Max Nikulin wrote: > > > >> There are a some problems with info links outside of Emacs: > >> - Export to PDF > > > > Yeah, I recently realized that I will need to add custom support for > > exporting info: links using ox-hugo. I made a small blog post out of > > this learning: https://scripter.co/linking-and-exporting-org-info-links/. > > I would prefer > info "(org) Top" > to > Org Info: Top > since the former may be pasted to M-x : or to shell command prompt. And > the link target ideally should be https://orgmode.org/manual/index.html > Unfortunately there is no way to customize mapping of documents. > > >> - Links to single page manuals as the result of export to HTML. E.g. > >> Emacs manual is really huge > > > > I did not understand this. The HTML exports convert an Info node to a > > hyperlink of the same manual page online. > > For export to html produces the following link: > https://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Browse_002dURL > I think, a better variant is > https://www.gnu.org/software/emacs/manual/html_node/emacs/Browse_002dURL.html > even though for the Org manual I often prefer single-page HTML version. Thanks for your feedback! I absorbed almost all of it into ox-hugo and wrote about it in a followup blog post: https://scripter.co/improving-ox-hugo-exported-org-info-links/. You'll see the update info: link examples on that post.
[PATCH] org-element-export-snippet-parser: Fix snippets without ending @@
There is an edge case when parsing export snippets:
@@html:fo aksjdaksjd ajs d
askdjas aksj daj sao@@
Our current parser recognises the opening "@@html:" as a standalone
snippet.
Unless I misunderstand something, it is not intentional.
The fix is attached.
Nicolas, unless you have any objections, I will install the attached
patch to bugfix.
Best,
Ihor
>From c866dcc8e593da2fca2611b100b4ab3ea9641e03 Mon Sep 17 00:00:00 2001
Message-Id:
From: Ihor Radchenko
Date: Sat, 16 Apr 2022 13:08:57 +0800
Subject: [PATCH] org-element-export-snippet-parser: Fix snippets without
ending @@
* lisp/org-element.el (org-element-export-snippet-parser): Do not
recognise snippets without closing @@ as empty "@@backend:" snippets.
Example:
@@html:fo aksjdaksjd ajs d
askdjas aksj daj sao@@
Reported in
https://github.com/lucasvreis/org-parser/blob/master/SPEC.org#export-snippets
---
lisp/org-element.el | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 9db1406b3..661902e04 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2980,8 +2980,9 @@ (defun org-element-export-snippet-parser ()
(when (and (looking-at "@@\\([-A-Za-z0-9]+\\):")
(setq contents-end
(save-match-data (goto-char (match-end 0))
- (re-search-forward "@@" nil t)
- (match-beginning 0
+(when
+ (re-search-forward "@@" nil t)
+ (match-beginning 0)
(let* ((begin (match-beginning 0))
(back-end (match-string-no-properties 1))
(value (buffer-substring-no-properties
--
2.35.1
Parsed buffer without patch:
Note (export-snippet (:back-end "html" :value "@@html:" :begin 1 :end 8
:post-blank 0 :parent #2))
(org-data
(:begin 1 :contents-begin 1 :contents-end 52 :end 52 :robust-begin 3
:robust-end 50 :post-blank 0 :post-affiliated 1 :path "/tmp/bug.org" :mode
org-data :CATEGORY "bug" :granularity nil)
(section
(:begin 1 :end 52 :contents-begin 1 :contents-end 52 :robust-begin 1
:robust-end 50 :post-blank 0 :post-affiliated 1 :mode first-section
:granularity nil :parent #0)
(paragraph
(:begin 1 :end 29 :contents-begin 1 :contents-end 28 :post-blank 1
:post-affiliated 1 :mode top-comment :granularity nil :parent #1)
(export-snippet
(:back-end "html" :value "@@html:" :begin 1 :end 8 :post-blank 0 :parent
#2))
#("fo aksjdaksjd ajs d\n" 0 20
(:parent #2)))
(paragraph
(:begin 29 :end 52 :contents-begin 29 :contents-end 52 :post-blank 0
:post-affiliated 29 :mode nil :granularity nil :parent #1)
#("askdjas aksj daj sao@@\n" 0 23
(:parent #2)
With patch:
(org-data
(:begin 1 :contents-begin 1 :contents-end 52 :end 52 :robust-begin 3
:robust-end 50 :post-blank 0 :post-affiliated 1 :path "/tmp/bug.org" :mode
org-data :CATEGORY "bug" :granularity nil)
(section
(:begin 1 :end 52 :contents-begin 1 :contents-end 52 :robust-begin 1
:robust-end 50 :post-blank 0 :post-affiliated 1 :mode first-section
:granularity nil :parent #0)
(paragraph
(:begin 1 :end 29 :contents-begin 1 :contents-end 28 :post-blank 1
:post-affiliated 1 :mode top-comment :granularity nil :parent #1)
#("@@html:fo aksjdaksjd ajs d\n" 0 27
(:parent #2)))
(paragraph
(:begin 29 :end 52 :contents-begin 29 :contents-end 52 :post-blank 0
:post-affiliated 29 :mode nil :granularity nil :parent #1)
#("askdjas aksj daj sao@@\n" 0 23
(:parent #2)
