Re: Incorrect quantity of en-spaces
> This appears to be a special case, not documented on org-syntax page. Sounds good, thanks! -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: Comments following not-really-affiliated keywords are becoming paragraphs
Thanks! -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Incorrect quantity of en-spaces
The org-mode syntax document describes entities as:
> \NAME POST
> \NAME{}
> Where NAME and POST are not separated by a whitespace character.
and POST is defined as:
> Either the end of line or a non-alphabetic character.
So using the test document:
```
\_ Foo
```
(a backslash, underscore, three spaces, and then the word Foo)
I would expect to get only 2 en-spaces but I am getting 3. Looking at
org-entities, an underscore with 2 spaces gets 2 en-spaces, whereas an
underscore with 3 spaces gets 3 en-spaces, but if we match all 3 spaces as NAME
then POST becomes invalid because "F" is neither the end of the line nor a
non-alphabetic character, so we can only match the first two spaces as NAME.
emacs version: 29.1
org-mode version: 9bbc21df84d507e568a3ebd17e105cdb9e163784 (latest in git)
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
Re: Clock becomes a paragraph by prefixing with not-really-affiliated-keyword
Thanks! -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Clock becomes a paragraph by prefixing with not-really-affiliated-keyword
This test document correctly parses as a clock: ``` CLOCK: [2023-04-21 Fri 19:43] ``` This test document incorrectly parses as a paragraph: ``` #+NAME: foo CLOCK: [2023-04-21 Fri 19:43] ``` -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: Keyword becoming a paragraph based on optval
> Note that _affiliated keyword_ has an optional form of Ah, that was what I was missing, thanks! -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Keyword becoming a paragraph based on optval
Emacs version: 29.1 Org-mode version: f3de4c3e041e0ea825b5b512dc0db37c78b7909e (latest in git) This test document parses as a keyword: ``` #+CAPTION[*foo*]: baz ``` but this test document parses as a paragraph: ``` #+CAPTION[*foo* bar]: baz ``` -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Comments following not-really-affiliated keywords are becoming paragraphs
Emacs version: 29.1 Org-mode version: e1569918cc94253650781e83a09695739c93352f (latest in git) Test document: ``` #+CAPTION: foo # bar ``` This parses as a paragraph with the caption of foo and the body of "# bar" when it should parse as a regular keyword followed by a comment. Relevant org-syntax[1] bit: > a keyword with the same KEY as an affiliated keyword may occur so long as it > is not immediately preceding a valid element that can be affiliated. For > example, an instance of #+caption: hi followed by a blank line will be parsed > as a keyword, not an affiliated keyword. [1] https://orgmode.org/worg/org-syntax.html#Keywords -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Org-mode starting with 37d6bde27 errors out parsing org-mode/testing/examples/pub/a.org
Steps to reproduce:
1. Build emacs 29.1
2. Build org-mode with revision 37d6bde27fe228cdadcb5cdaa09287872a508777
3. Run the following:
```
emacs -q --no-site-file --no-splash --batch --eval "(progn
(require 'org)
(setq vc-handled-backends nil)
(find-file-read-only \"org-mode/testing/examples/pub/a.org\")
(org-mode)
(message \"%s\" (pp-to-string (org-element-parse-buffer)))
)"
```
I've attached a Dockerfile that reproduces the issue. Just throw that in a
directory and run `docker build -t temp .` to see it fail. Change the `ARG
ORG_VERSION=` line to `ac108a3ac1b332bf27ff2984a9cf26af3744185d` to see it
succeed.
Error message:
```
File mode specification error: (void-function org-export--list-bound-variables)
Error: void-function (org-export--list-bound-variables)
mapbacktrace(#f(compiled-function (evald func args flags) #))
debug-early-backtrace()
debug-early(error (void-function org-export--list-bound-variables))
org-export--list-bound-variables()
org-element--generate-copy-script(# :copy-unreadable
do-not-check :drop-visibility t :drop-narrowing t :drop-contents t :drop-locals
nil)
org-element-copy-buffer(:to-buffer # :drop-visibility t
:drop-narrowing t :drop-contents t :drop-locals nil)
org-element-parse-secondary-string("<2014-03-04 Tue>" (bold citation code
entity export-snippet inline-babel-call inline-src-block italic line-break
latex-fragment link macro radio-target statistics-cookie strike-through
subscript superscript target timestamp underline verbatim))
org-macro--find-date()
org-macro--collect-macros()
org-macro-initialize-templates()
org-mode()
(progn (require 'org) (setq vc-handled-backends nil) (find-file-read-only
"/input/home/talexander/git/org-mode/testing/examples/pub/a.org") (org-mode)
(message "%s" (pp-to-string (org-element-parse-buffer
command-line-1(("--no-splash" "--eval" "(progn\n (require 'org)\n
(setq vc-handled-backends nil)\n (find-file-read-only
\"/input/home/talexander/git/org-mode/testing/examples/pub/a.org\")\n
(org-mode)\n (message \"%s\" (pp-to-string
(org-element-parse-buffer)))\n)"))
command-line()
normal-top-level()
Symbol’s function definition is void: org-export--list-bound-variables
```
--
Tom Alexander
pgp: https://fizz.buzz/pgp.asc
Dockerfile
Description: Binary data
Document-level properties incorrect and/or missing based on preceding blank lines and/or comments
Emacs version: Emacs 29.1 Org-mode version: e1569918cc94253650781e83a09695739c93352f (latest in git) The org-mode syntax document[1] says that property drawers can exist in the zeroth section with the format: ``` BEGINNING-OF-FILE BLANK-LINES COMMENT PROPERTYDRAWER ``` Using this test document: ``` :PROPERTIES: :FOO:bar :END: ``` I correctly get the foo property in the top-level org-data ``` (org-data (:standard-properties [1 1 1 33 33 0 nil org-data nil nil nil 32 33 nil # nil nil nil] :path nil :FOO "bar" :CATEGORY nil) ``` But now there are two separate issues: ### Issue 1 Putting a comment before it makes the value for the foo property incorrect (seems to be grabbing an earlier string slice): ``` # baz :PROPERTIES: :FOO:bar :END: ``` ``` (org-data (:standard-properties [1 1 1 39 39 0 nil org-data nil nil nil 38 39 nil # nil nil nil] :path nil :FOO "O: " :CATEGORY nil) ``` Interestingly, looking farther down the AST, the value for foo is properly set in the node-property, just not the org-data: ``` (node-property (:standard-properties [20 20 nil nil 33 0 nil node-property nil nil nil nil nil nil # nil nil #2] :key "FOO" :value "bar")) ``` ### Issue 2 Putting any blank lines before it makes the foo property not appear in org-data at all ``` :PROPERTIES: :FOO:bar :END: ``` ``` (org-data (:standard-properties [1 1 2 34 34 0 nil org-data nil nil nil 4 34 nil # nil nil nil] :path nil :CATEGORY nil) ``` Looking farther down the AST it seems the property-drawer became a regular drawer [1] https://orgmode.org/worg/org-syntax.html#Property_Drawers -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: Inconsistent text markup handling when double-nesting markers
> Fixed, on main. Thanks! -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: COUNTER-SET for alphabetical ordered lists ignored for utf-8 exporter
Thanks! > We aim to reduce config-dependent Org syntax in the long term. Thats wonderful news! Sometimes this stuff can really surprise you. For example, the structure of the document created by running `echo "1. foo\n 1.bar\n1.baz\n\t1.lorem"` changes based on the user's **tab-width**!! If tab-width is less than 8 then this is: ```text 1. foo 1. bar 1. baz 2. lorem ``` If tab-width is 8 then this is: ```text 1. foo 1. bar 1. baz 2. lorem ``` and if tab-width is greater than 8 this is: ```text 1. foo 1. bar 1. baz 1. lorem ``` Absolute madness! I always considered tab-width to be a personal aesthetic choice and not something that would functionally change how documents other people wrote will be parsed. Idk if its been discussed, but personally if I were given dictatorship over org-mode I would take all of these emacs variables that are defined outside of the document, and instead of having them influence org-mode directly, I would *only* use them to pre-populate values for in-buffer settings templates. For example, if a user had set `org-odd-levels-only` then I wouldn't have that impact ANY existing document they open, but if they open a new document then I would have it auto-insert `#+STARTUP: odd` at the top of the fresh document. Otherwise it seems like org-mode is unsuitable for multi-person collaboration without dictating the contents of everyone's `.emacs` file. -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Inconsistent text markup handling when double-nesting markers
I used the following test document: ``` __foo__ **foo** ``` I'd expect the two to behave the same but the first one parses as: ``` (paragraph "_" (subscript "foo") "__" ) ``` Whereas the second parses as: ``` (paragraph (bold (bold "foo" ) ) ) ``` This pattern happens in worg at [2] Looking at the description for text markup in the syntax document[1], I don't see any reason the first wouldn't be parsed as an underline: 1. PRE: valid because it is the beginning of a line 2. MARKER: valid underscore 3. CONTENTS: valid. Series of objects from standard set includes both subscript and text markup, so regardless of how we parse the interior, its valid. Also cannot begin or end with whitespace but there is no whitespace in the CONTENTS. 4. MARKER: valid underscore 5. POST: Only valid if we extend the underline to the 2nd underscore so it ends at the end of the line. But the 2nd line shows us that having copies of the marker inside the CONTENTS is fine so I see two possible expected parses of the CONTENTS: 4a. (underline "foo") 4b. ((subscript "foo") (plain-text "_")) I also ran the following test document to further prove that having copies of the marker inside the CONTENTS is fine: ``` *foo*bar* ``` which parses as (bold "foo*bar") So the only way the top line would fail to parse as an underline is if it matched the first closing underscore as closing the underline, but that would be invalid because underscore is not a valid POST character and invalid copies of the closing marker are ignored as proven by both "**foo**" and "*foo*bar*". [1] https://orgmode.org/worg/org-syntax.html#Emphasis_Markers [2] https://git.sr.ht/~bzg/worg/tree/ba6cda890f200d428a5d68e819eef15b5306055f/org-contrib/babel/intro.org#L117 -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: Clarify that REST is not supported on the start TIME in a time-range timestamp.
> As for the problem with REST you raised, I am inclined to remove it from > syntax doc for the time being - it only creates more confusion, > unfortunately. Makes sense, thanks. Is there anything we do to mark patches as rejected? I removed [PATCH] from the subject line. -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: Lesser blocks allowing unescaped lines
Thank you! Makes sense. -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: [PATCH] Clarify that REST is not supported on the start TIME in a time-range timestamp.
Potentially related, org-mode is accepting this malformed timestamp from[1]: ``` <2016-02-14 Sun ++y> ``` The org-mode documentation[2] only includes REST with TIME, defining TIME as "H:MMREST". The above does not have any TIME but it accepts the timestamp anyway: ``` (timestamp :type active :range-type nil :raw-value "<2016-02-14 Sun ++y>" :year-start 2016 :month-start 2 :day-start 14 :hour-start nil :minute-start nil :year-end 2016 :month-end 2 :day-end 14 :hour-end nil :minute-end nil ) ``` Perhaps that grammar is wrong and REST needs to be separated from TIME? [1] https://github.com/howardabrams/pdx-emacs-hackers/blob/bfb7bd640fdf0ce3def21f9fc591ed35d776b26d/workshops/org-mode-gtd-feature-demo.org#L183 [2] https://orgmode.org/worg/org-syntax.html#Timestamps -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
[PATCH] Clarify that REST is not supported on the start TIME in a time-range timestamp.
If REST is included in the first TIME on a time-range timestamp then the entire timestamp becomes a single range-less timestamp. To test I used the following test document: ``` [1970-01-01 Thu 8:15-13:15foo] [1970-01-01 Thu 8:15foo-13:15] ``` The first line parses as a timerange from 8:15-13:15. The second line parses as a single timestamp at 8:15. -- Tom Alexander pgp: https://fizz.buzz/pgp.asc From b1114e983d961d48e1d837b8d2ad209a976a5417 Mon Sep 17 00:00:00 2001 From: Tom Alexander Date: Mon, 2 Oct 2023 17:35:28 -0400 Subject: [PATCH] * org-syntax.org (Timestamps): Clarify that REST is not supported on the start TIME in a time-range timestamp. If REST is included in the first TIME on a time-range timestamp then the entire timestamp becomes a single range-less timestamp. To test I used the following test document: ``` [1970-01-01 Thu 8:15-13:15foo] [1970-01-01 Thu 8:15foo-13:15] ``` The first line parses as a timerange from 8:15-13:15. The second line parses as a single timestamp at 8:15. --- org-syntax.org | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/org-syntax.org b/org-syntax.org index c2061431..0c326ba8 100644 --- a/org-syntax.org +++ b/org-syntax.org @@ -1686,9 +1686,10 @@ -MM-DD DAYNAME - DAYNAME (optional) :: A string consisting of non-whitespace characters except =+=, =-=, =]=, =>=, a digit, or =\n=. + TIME (optional) :: An instance of the pattern =H:MMREST= where =H= - represents a one to two digit number (and can start with =0=), and =M= - represents a single digit. =REST= can contain anything but =\n= or - closing bracket. + represents a one to two digit number (and can start with =0=), and + =M= represents a single digit. =REST= can contain anything but =\n= + or closing bracket. =REST= cannot exist on the start TIME in a + time-range timestamp (the patterns with =TIME-TIME=). + REPEATER-OR-DELAY (optional) :: An instance of the following pattern: #+begin_example MARK VALUE UNIT -- 2.42.0
Re: Extra paragraphs incorrectly spawning when ":end:" appears.
Hmm thanks, that makes sense. I guess a post-processing step to merge adjacent paragraphs wouldn't work either since that wouldn't stitch together objects like the bold in this test document without re-parsing the entire paragraph: ``` foo *bar :end: baz* ``` oh well 路 -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: Extra paragraphs incorrectly spawning when ":end:" appears.
Same problem occurs with this sample document: ``` foo #+BEGIN: bar baz ``` which parses as: ``` (section (paragraph "foo\n") (paragraph "#+BEGIN: bar\nbaz\n) ) ``` again, no blank lines and no non-paragraph elements but the single paragraph got split in two. -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Extra paragraphs incorrectly spawning when ":end:" appears.
This test document has 1 paragraph: ``` foo bar baz ``` which parses as: ``` (section (paragraph "foo\nbar\nbaz\n") ) ``` This test document should have 1 paragraph but org-mode is parsing it as 2: ``` foo :end: baz ``` which parses as: ``` (section (paragraph "foo\n") (paragraph ":end:\nbaz\n") ) ``` The paragraph documentation[1] states that: > Empty lines and other elements end paragraphs. But the document contains no empty lines and we can see in the output that it only contains paragraphs. [1] https://orgmode.org/worg/org-syntax.html#Paragraphs -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Lesser blocks allowing unescaped lines
This happens in worg at: https://git.sr.ht/~bzg/worg/tree/ba6cda890f200d428a5d68e819eef15b5306055f/exporters/ox-docstrings.org#L2490 The documentation for lesser blocks[1] states: > Lines beginning with an asterisk or `#+` must be quoted by a comma (`,*`, > `,#+`). However, the following test document parses as a lesser block despite containing a line starting with an unescaped #+: ``` #+CATEGORY: foo #+begin_src text #+CATEGORY: bar #+end_src ``` which parses as: ``` (org-data (:standard-properties [1 1 1 60 60 0 nil org-data nil nil nil 3 60 nil # nil nil nil] :path nil :CATEGORY "foo") (section (:standard-properties [1 1 1 60 60 0 nil first-section nil nil nil 1 60 nil # nil nil #0]) (keyword (:standard-properties [1 1 nil nil 17 0 nil top-comment nil nil nil nil nil nil # nil nil #1] :key "CATEGORY" :value "foo")) (src-block (:standard-properties [17 17 nil nil 60 0 nil nil nil nil nil nil nil nil # nil nil #1] :language "text" :switches nil :parameters nil :number-lines nil :preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value "#+CATEGORY: bar\n" ``` whereas I would expect this to be ``` (section (keyword :key "CATEGORY" :value "foo") (paragraph "#+begin_src text") (keyword :key "CATEGORY" :value "bar") (paragraph "#+end_src") ) ``` This test document shows that lines with an unescaped "*" do break up the lesser block: ``` * foo #+begin_src text * bar #+end_src ``` [1] https://orgmode.org/worg/org-syntax.html#Blocks -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
COUNTER-SET for alphabetical ordered lists ignored for utf-8 exporter
It seems that COUNTER-SET[1] is not being honored when exporting to utf-8 for alphabetical lists even though it is honored for numeric lists. When exporting to html, COUNTER-SET is honored for both. Test document: ``` # An ordered list starting at 3 1. [@3] foo # An ordered list starting at 1 m. bar # An ordered list starting at 11 m. [@k] baz ``` Launching emacs with: (Setting org-list-allow-alphabetical is necessary or else the alphabetical lists will become paragraphs) ``` emacs -q --eval '(setq org-list-allow-alphabetical t)' /tmp/test.org ``` When exporting to html you get (edited to remove whitespace for clarity): ``` foo bar baz ``` But when exporting to utf-8 you get: (whitespace removed again) ``` 3. foo m. bar m. baz ``` Whereas I would expect: (whitespace removed again) ``` 3. foo m. bar k. baz ``` On a slightly related note: it seems the COUNTER-SET[1] allows single-letter values even when org-list-allow-alphabetical is nil. I don't think that is going to hurt anyone but I figured I should mention it in case its a bug (test doc: `1. [@k] foo` is a plain list starting at 11 even when org-list-allow-alphabetical is nil). [1] https://orgmode.org/worg/org-syntax.html#Items Emacs 29.1, Org-mode version 9.7-pre (release_9.6.8-781-gc70354) -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: Subscript with parenthesis
> Not true. I tried > > b^(*asd*) and bold inside superscript does get parsed. Ah thanks for double-checking! You're right, that is getting parsed. Not sure what test document I was using to make me think objects didn't work inside the parenthesis. -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: [PATCH] Add backslash to list of POST characters for text markup
Thanks! -- Tom Alexander pgp: https://fizz.buzz/pgp.asc On Fri, Sep 22, 2023, at 5:29 AM, Ihor Radchenko wrote: > "Tom Alexander" writes: > >> Backslash appears to be supported. To test I used the following test >> document: >> ``` >> foo ~bar~\& baz >> ``` > > Thanks! > You are right. > Applied, onto master, with minor amendments to the commit message. > https://git.sr.ht/~bzg/worg/commit/ba6cda89 > > -- > Ihor Radchenko // yantar92, > 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>
[PATCH] Add backslash to list of POST characters for text markup
Backslash appears to be supported. To test I used the following test document: ``` foo ~bar~\& baz ``` This happens in a document in worg: https://git.sr.ht/~bzg/worg/tree/ae64e1a54185232d4ebdcab174d8d4319ffd564d/org-release-notes.org#L The ampersand was chosen for the test document since that is not a supported POST character, to make sure backslash was not simply escaping the next character. In the documentation I wrote out the word "backslash" in parenthesis to disambiguate between backslash and escaping the following comma. Patch is attached. -- Tom Alexander pgp: https://fizz.buzz/pgp.ascFrom 098434680b5e3942acc00684a47389f2cdab6208 Mon Sep 17 00:00:00 2001 From: Tom Alexander Date: Thu, 21 Sep 2023 21:14:33 -0400 Subject: [PATCH] Add backslash to list of POST characters for text markup. Backslash appears to be supported. To test I used the following test document: ``` foo ~bar~\& baz ``` The ampersand was chosen since that is not a supported POST character, to make sure backslash was not simply escaping the next character. In the documentation I wrote out the word "backslash" in parenthesis to disambiguate between backslash and escaping the following comma. --- org-syntax.org | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/org-syntax.org b/org-syntax.org index c5299741..8f0f9b0c 100644 --- a/org-syntax.org +++ b/org-syntax.org @@ -249,9 +249,9 @@ discarded. This also applies to single-line elements. :This paragraph will not contain :a long sequence of spaces before "a". -: +: :This paragraph does not have leading spaces according to the parser. -: +: :#+begin_src emacs-lisp : (+ 1 2) :#+end_src @@ -1742,7 +1742,7 @@ whitespace characters. verbatim) or a series of objects from the standard set. In both cases, CONTENTS may not begin or end with whitespace. + [[#Special_Tokens][POST]] :: Either a whitespace character, =-=, =.=, =,=, =;=, =:=, =!=, =?=, ='=, =)=, =}=, - =[=, ="=, or the end of a line. + =[=, ="=, =\= (backslash), or the end of a line. *Examples* -- 2.42.0
Consecutive plain list items of different types
The org-mode documentation[1] states for plain lists that: > List types are mutually exclusive at the same level of indentation, if both > types are present consecutively then they parse as separate lists. first a minor nit-pick that "both" is probably not the correct word here since there are 3 types of lists, not two (unordered, ordered, and descriptive). I'd go with "multiple" instead IMO. but more importantly, based on that description I would expect the following test document to parse into three separate plain lists, but it parses as a single plain list with 3 items: ``` 1. foo - bar - lorem :: ipsum ``` [1] https://orgmode.org/worg/org-syntax.html#Plain_Lists -- Tom Alexander pgp: https://fizz.buzz/pgp.asc
Re: Subscript with parenthesis
Some additional things I'm noticing: - when using parenthesis, :use-brackets-p is nil, so they're not equivalent to curly braces. - it does not support objects inside the parenthesis, just plain text, which again means they're not equivalent to braces. - it, however, seems to require that the parenthesis are balanced because this test document does NOT contain a subscript: ``` foo_(b(ar) ``` which is closer to the curly braces requirement since that seems to be the only part of the subscript/superscript documentation that mentions needing balance. -- Tom Alexander
Subscript with parenthesis
The org-mode documentation[1] states that the SCRIPT portion of the subscript/superscript is either an asterisk, the standard set of objects wrapped in balanced curly braces, or an optional sign followed by "Either the empty string, or a string consisting of any number of alphanumeric characters, commas, backslashes, and dots" But I'm seeing the following test document parse as containing a subscript despite using parenthesis which I do not think matches any of the above criteria: ``` foo_(bar) ``` [1] https://orgmode.org/worg/org-syntax.html#Subscript_and_Superscript -- Tom Alexander
Re: Fixed width areas not allowing tab after leading colon.
Thanks! -- Tom Alexander On Sun, Sep 17, 2023, at 5:48 AM, Ihor Radchenko wrote: > "Tom Alexander" writes: > >> The documentation for fixed width areas states: A “fixed-width line” starts >> with a colon character (:) and either a whitespace character or the >> immediate end of the line. >> ... >> Fixed-width area documentation: >> https://orgmode.org/worg/org-syntax.html#Fixed_Width_Areas > > org-syntax.html is not accurate here. The parser only allows ": " (colon > followed by space) and no other variant. > > Fixed, on master. > https://git.sr.ht/~bzg/worg/commit/a42f57ac > >> This happens in a document in worg: >> https://git.sr.ht/~bzg/worg/tree/74e80b0f7600801b1d1594542602394c085cc2f9/item/org-contrib/org-bom.org#L499 > > Fixed, on master. > https://git.sr.ht/~bzg/worg/commit/0c8d5679 > > -- > Ihor Radchenko // yantar92, > 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] Re: Description list with " :: " in the tag.
Sorry for the delay, I've been busy in the IRLs. I've updated the patch to reflect that the parser grabs the text before the last " :: " and then parses it as objects. The new patch is attached. -- Tom Alexander On Thu, Sep 14, 2023, at 7:24 AM, Ihor Radchenko wrote: > "Tom Alexander" writes: > >> I've written a patch (attached) with my proposed wording changes to >> the documentation, should I be starting another thread or does >> dropping it here work best? > > You can just modify subject with [PATCH], as I did. > >> ... I do not have commit access so I'd need >> someone with such authority to do the last bit. > > Sure. > >> + =TAG-TEXT= is one of more objects from the standard set so long as >> + they do not contain a newline character, until the last occurrence >> + of the substring =" :: "= (two colons surrounded by whitespace, >> + without the quotes). > > It does not fully represent what is going on - Org parser is top-down > and does not parse objects before it is done parsing the descriptive > list item. So, > > - *foo :: bar* does not actually contain bold markup > > Rather it is "* foo" tag + "bar* does not actually contain bold markup" > description. > > What happens is that the parser splits the first line of the item by the > last " :: " and only then proceeds with parsing the tag and description > using standard set of objects: > > - <> :: > > -- > Ihor Radchenko // yantar92, > 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>From c8812bf7d81dc824d8ecf2c03368f58884773ddf Mon Sep 17 00:00:00 2001 From: Tom Alexander Date: Wed, 13 Sep 2023 18:19:05 -0400 Subject: [PATCH] org-syntax.org: Fix definition of description list tags. Description lists support objects in their tags and they support the substring " :: ". --- org-syntax.org | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/org-syntax.org b/org-syntax.org index 123fc232..fc5e9a37 100644 --- a/org-syntax.org +++ b/org-syntax.org @@ -470,9 +470,10 @@ BULLET COUNTER-SET CHECK-BOX TAG CONTENTS + CHECK-BOX (optional) :: A single whitespace character, an =X= character, or a hyphen enclosed by square brackets (i.e. =[ ]=, =[X]=, or =[-]=). + TAG (optional) :: An instance of the pattern =TAG-TEXT ::= where - =TAG-TEXT= represents a string consisting of non-newline characters - that does not contain the substring ="Â ::Â "= (two colons surrounded by - whitespace, without the quotes). + =TAG-TEXT= is the text up until the last occurrence of of the + substring ="Â ::Â "= (two colons surrounded by whitespace, without the + quotes) on that line. =TAG-TEXT= is then parsed with the standard + set of objects. + CONTENTS (optional) :: A collection of zero or more elements, ending at the first instance of one of the following: - The next item. -- 2.42.0
Fixed width areas not allowing tab after leading colon.
The documentation for fixed width areas states: A “fixed-width line” starts
with a colon character (:) and either a whitespace character or the immediate
end of the line.
Using the test document:
```
:foo
```
parses as a paragraph instead of a fixed-width area:
```
(org-data
(:standard-properties
[1 1 1 7 7 0 nil org-data nil nil nil 3 7 nil # nil nil nil]
:path nil :CATEGORY nil)
(section
(:standard-properties
[1 1 1 7 7 0 nil first-section nil nil nil 1 7 nil # nil
nil #0])
(paragraph
(:standard-properties
[1 1 1 7 7 0 nil top-comment nil nil nil nil nil nil #
nil nil #1])
#(": foo\n" 0 6
(:parent #2)
```
This happens in a document in worg:
https://git.sr.ht/~bzg/worg/tree/74e80b0f7600801b1d1594542602394c085cc2f9/item/org-contrib/org-bom.org#L499
Emacs version: GNU Emacs 29.1 (build 1, x86_64-pc-linux-musl)
Org-mode version: c703541ffcc14965e3567f928de1683a1c1e33f6 (latest in git)
Fixed-width area documentation:
https://orgmode.org/worg/org-syntax.html#Fixed_Width_Areas
--
Tom Alexander
Re: Description list with " :: " in the tag.
I've written a patch (attached) with my proposed wording changes to the documentation, should I be starting another thread or does dropping it here work best? I do not have commit access so I'd need someone with such authority to do the last bit. -- Tom Alexander From 20addaa5ab7d4e9420ade1125c2a337345ecdd31 Mon Sep 17 00:00:00 2001 From: Tom Alexander Date: Wed, 13 Sep 2023 18:19:05 -0400 Subject: [PATCH] org-syntax.org: Fix definition of description list tags. Description lists support objects in their tags and they support the substring " :: ". --- org-syntax.org | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/org-syntax.org b/org-syntax.org index 123fc232..3046e26c 100644 --- a/org-syntax.org +++ b/org-syntax.org @@ -470,9 +470,10 @@ BULLET COUNTER-SET CHECK-BOX TAG CONTENTS + CHECK-BOX (optional) :: A single whitespace character, an =X= character, or a hyphen enclosed by square brackets (i.e. =[ ]=, =[X]=, or =[-]=). + TAG (optional) :: An instance of the pattern =TAG-TEXT ::= where - =TAG-TEXT= represents a string consisting of non-newline characters - that does not contain the substring ="Â ::Â "= (two colons surrounded by - whitespace, without the quotes). + =TAG-TEXT= is one of more objects from the standard set so long as + they do not contain a newline character, until the last occurrence + of the substring ="Â ::Â "= (two colons surrounded by whitespace, + without the quotes). + CONTENTS (optional) :: A collection of zero or more elements, ending at the first instance of one of the following: - The next item. -- 2.42.0
Re: Description list with " :: " in the tag.
Thanks! -- Tom Alexander On Sat, Sep 9, 2023, at 5:06 AM, Ihor Radchenko wrote: > "Tom Alexander" writes: > >> Emacs version: 29.1 >> Org-mode version: 163bafb43dcc2bc94a2c7ccaa77d3d1dd488f1af >> >> Found a conflict between the documentation and the parser behavior. The >> org-mode documentation[1] for description list items says that TAG '[...] >> does not contain the substring " :: "' >> >> Using this sample document, I have created a plain list item with a tag that >> contains that substring by wrapping it in a verbatim block: >> ``` >> - =foo :: bar= :: baz >> ``` >>(item >> ... >> ((1 0 "- " nil nil "=foo :: bar=" 23)) >> ... >> It seems that "TAG-TEXT" is not just text but it can include objects and >> those objects can include the substring " :: ". > > It is simpler. > Everything after the bullet and before the last " :: " is considered as > tag. Everything after the last " :: " is description. > Then, tag and description are parsed, allowing objects inside. > > org-syntax document is inaccurate here - it says that the _first_ " :: " > is used as tag:description delimiter, not the _last_. > > I do not see any benefit changing the current parser. So, we probably > need to update org-syntax document instead. > > -- > Ihor Radchenko // yantar92, > 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>
Description list with " :: " in the tag.
Emacs version: 29.1
Org-mode version: 163bafb43dcc2bc94a2c7ccaa77d3d1dd488f1af
Found a conflict between the documentation and the parser behavior. The
org-mode documentation[1] for description list items says that TAG '[...] does
not contain the substring " :: "'
Using this sample document, I have created a plain list item with a tag that
contains that substring by wrapping it in a verbatim block:
```
- =foo :: bar= :: baz
```
Which parses to:
```
(org-data
(:standard-properties
[1 1 1 23 23 0 nil org-data nil nil nil 3 23 nil # nil nil
nil]
:path nil :CATEGORY nil)
(section
(:standard-properties
[1 1 1 23 23 0 nil first-section nil nil nil 1 23 nil #
nil nil #0])
(plain-list
(:standard-properties
[1 1 1 23 23 0 nil top-comment nil nil nil nil nil nil #
nil
((1 0 "- " nil nil "=foo :: bar=" 23))
#1]
:type descriptive)
(item
(:standard-properties
[1 1 19 23 23 0
(:tag)
item nil nil nil nil nil nil # nil
((1 0 "- " nil nil "=foo :: bar=" 23))
#2]
:bullet "- " :checkbox nil :counter nil :pre-blank 0 :tag
((verbatim
(:standard-properties
[3 nil nil nil 15 0 nil nil nil nil nil nil nil nil #
nil nil #3]
:value "foo :: bar"
(paragraph
(:standard-properties
[19 19 19 23 23 0 nil nil nil nil nil nil nil nil # nil
nil #3])
#("baz\n" 0 4
(:parent #4)))
```
It seems that "TAG-TEXT" is not just text but it can include objects and those
objects can include the substring " :: ".
[1] https://orgmode.org/worg/org-syntax.html#Items
--
Tom Alexander
Text markup and TeX-style LaTeX fragments spanning more than three lines
The documentation for both text markup and TeX-style LaTeX fragments states that their contents (CONTENTS for text markup, BODY for TeX-style LaTeX fragments) cannot span more than three lines, but I'm not seeing such limitation for either in practice. I don't know if this is a documentation error or a parser error. Documentation text markup: https://orgmode.org/worg/org-syntax.html#Emphasis_Markers Documentation LaTeX fragments: https://orgmode.org/worg/org-syntax.html#LaTeX_Fragments Test document text markup: ``` foo *bar baz* lorem text *markup cannot span* more than *three lines. foo bar* baz foo *bar \\ baz \\ lorem \\ ipsum \\ dolar* cat ``` Test document TeX-style LaTeX fragments: ``` $foo bar baz lorem ipsum dolar$ ``` -- Tom Alexander
Re: Clarification on blank lines following list items
Thanks! -- Tom Alexander On Tue, Aug 22, 2023, at 4:26 AM, Ihor Radchenko wrote: > Ihor Radchenko writes: > >>> I am seeing dual-ownership of the post-blank in the examples below, but at >>> the same time if I put a plain-list inside a footnote definition, the >>> footnote definition ends up with sole custody of the post-blank. >> >> It is a bug in the list parser. > > Fixed, on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=53c9d91d3 > > -- > Ihor Radchenko // yantar92, > 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: Clarification on blank lines following list items
Thank you so much for explaining all of that! There is some good information there I was missing. I think the most important bit I was missing is the post-blank stuff. I was only looking at begin->end but I think digging into the post-blank is what makes this consistent. I've got 2 separate questions: 1. Is the following statement true? "Two elements can count the same character in their post-blank?" I am seeing dual-ownership of the post-blank in the examples below, but at the same time if I put a plain-list inside a footnote definition, the footnote definition ends up with sole custody of the post-blank. 2. I'm still not sure about some behavior I'm seeing. I think it would be easiest to see if we focus on exactly 1 blank line: ``` 1. bar 2. baz < this blank line here ipsum ``` In this example, the blank line gets counted in the post-blank for the plain-list but not for the item: ``` plain-list: post-blank 1 | begin 1 end 16 | contents-begin 1 contents-end 15 item: post-blank 0 | begin 1 end 8 | contents-begin 4 contents-end 8 paragraph: post-blank 0 | begin 4 end 8 | contents-begin 4 contents-end 8 item: post-blank 0 | begin 8 end 15 | contents-begin 11 contents-end 15 paragraph: post-blank 0 | begin 11 end 15 | contents-begin 11 contents-end 15 paragraph: post-blank 0 | begin 16 end 22 | contents-begin 16 contents-end 22 ``` but if we take that plain-list and nest it inside another plain-list: ``` 1. foo 1. bar 2. baz < this blank line here 2. lorem ipsum ``` The blank line gets counted as a post-blank for both the item "foo" and the item "baz": ``` plain-list: post-blank 0 | begin 1 end 38 | contents-begin 1 contents-end 38 item: post-blank 1 | begin 1 end 29 | contents-begin 4 contents-end 28 paragraph: post-blank 0 | begin 4 end 8 | contents-begin 4 contents-end 8 plain-list: post-blank 0 | begin 8 end 29 | contents-begin 8 contents-end 29 item: post-blank 0 | begin 8 end 18 | contents-begin 14 contents-end 18 paragraph: post-blank 0 | begin 14 end 18 | contents-begin 14 contents-end 18 item: post-blank 1 | begin 18 end 29 | contents-begin 24 contents-end 28 paragraph: post-blank 0 | begin 24 end 28 | contents-begin 24 contents-end 28 item: post-blank 0 | begin 29 end 38 | contents-begin 32 contents-end 38 paragraph: post-blank 0 | begin 32 end 38 | contents-begin 32 contents-end 38 paragraph: post-blank 0 | begin 38 end 44 | contents-begin 38 contents-end 44 ``` Meaning the post-blank did this movement: ``` plain-list: post-blank 0 item: post-blank 1 <---<<<-\ paragraph: post-blank 0 | plain-list: post-blank 0 >>--| item: post-blank 0 | paragraph: post-blank 0 | item: post-blank 1 <---<---/ paragraph: post-blank 0 item: post-blank 0 paragraph: post-blank 0 paragraph: post-blank 0 ``` Question ---> So why is the item "baz" gaining a post-blank instead of the inner plain-list (bar baz) keeping that post-blank? I would expect it to instead be: ``` plain-list: post-blank 0 item: post-blank 1 paragraph: post-blank 0 here -> plain-list: post-blank 1 item: post-blank 0 paragraph: post-blank 0 not here -> item: post-blank 0 paragraph: post-blank 0 item: post-blank 0 paragraph: post-blank 0 paragraph: post-blank 0 ``` I re-did both test cases using greater blocks and lesser blocks instead of paragraphs to make sure it wasn't that historical exception at the end of your email, and the post-blank behavior was exactly the same. -- Tom Alexander
Clarification on blank lines following list items
| | bar | Yes | | baz | Yes | | lorem | No| Against expectations, we did not coerce lorem to consume its trailing blank lines. What is different between "baz" and "lorem"? Well, "baz" is contained within "foo" which has a "lorem" after it, whereas "lorem" is contained within "cat" which does not have any list items after it. New theory: List items own their trailing blank lines unless they are both the final list item and not the final element of a non-final list item. | Plain List *Item* | Owns trailing blank lines | Why | |-+---+--| | cat (includes foo -> lorem) | No| Final list item and not contained in a list item | | foo (includes bar baz) | Yes | Not the final list item | | bar | Yes | Not the final list item | | baz | Yes | Final element of non-final list item | | lorem | No| Final list item and final element of final list item | *** Test case 4 So if that theory is true, then we should be able to coerce lorem to consume its trailing blank lines by adding a second item to the cat list. ``` 1. cat 1. foo 1. bar 2. baz 2. lorem 2. dog ipsum ``` | Plain List *Item* | Owns trailing blank lines | |-+---| | cat (includes foo -> lorem) | Yes | | foo (includes bar baz) | Yes | | bar | Yes | | baz | Yes | | lorem | Yes | | dog | No| For the first time our expectations were met! Enduring theory: List items own their trailing blank lines unless they are both the final list item and not the final element of a non-final list item. | Plain List *Item* | Owns trailing blank lines | Why | |-+---+--| | cat (includes foo -> lorem) | Yes | Not the final list item | | foo (includes bar baz) | Yes | Not the final list item | | bar | Yes | Not the final list item | | baz | Yes | Final element of non-final list item | | lorem | Yes | Final element of non-final list item | | dog | No| Final list item and not contained in a list item | -- Tom Alexander
Re: Export snippet matching without closing "@@"
> Thanks for reporting! > Fixed, on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e340dde63 Thanks for fixing! -- Tom Alexander
Export snippet matching without closing "@@"
I suspect this is a regression. I am using this test document:
```
@@latex:
\documentclass[margin,11pt]{res} % default is 10 pt
@@
```
and dumped the AST with M-x eval-expression (message "%s" (pp-to-string
(org-element-parse-buffer)))
When using the latest in main (commit b89bc55867d7cb809c379d371d12d409db785154,
Org mode version 9.7-pre (release_N/A-N/A-b89bc5 @
/usr/share/emacs/site-lisp/org/)) the "@@latex:" gets parsed as an export
snippet despite not having a closing "@@" (because the "@@" is in a different
paragraph).
When using the version of org-mode that shipped with emacs 29.1 (Org mode
version 9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)) the "@@latex:"
gets parsed as plaintext.
The docs seem to show that a "@@" is required as the end of an export snippet
based on the pattern "@@BACKEND:VALUE@@":
https://orgmode.org/worg/org-syntax.html#Export_Snippets
AST from org-mode in main:
```
(org-data
(:standard-properties
[1 71 1 71 0 1 nil nil nil 3 71 org-data nil nil nil nil nil #]
:path nil :CATEGORY nil)
(section
(:standard-properties
[1 71 1 71 0 1 nil nil nil 1 71 first-section nil nil #0 nil nil #])
(paragraph
(:standard-properties
[1 13 1 10 3 1 nil nil nil nil nil top-comment nil nil #1 nil nil #])
(export-snippet
(:standard-properties
[1 9 nil nil 0 nil nil nil nil nil nil nil nil nil #2 nil nil #]
:back-end "latex" :value nil))
#("\n" 0 1
(:parent #2)))
(paragraph
(:standard-properties
[13 68 13 65 3 13 nil nil nil nil nil nil nil nil #1 nil nil #])
(latex-fragment
(:standard-properties
[13 46 nil nil 1 nil nil nil nil nil nil nil nil nil #2 nil nil #]
:value "\\documentclass[margin,11pt]{res}"))
#("% default is 10 pt\n" 0 19
(:parent #2)))
(paragraph
(:standard-properties
[68 71 68 71 0 68 nil nil nil nil nil nil nil nil #1 nil nil #])
#("@@\n" 0 3
(:parent #2)
```
AST from org-mode in emacs 29.1:
```
(org-data
(:begin 1 :contents-begin 1 :contents-end 71 :end 71 :robust-begin 3
:robust-end 69 :post-blank 0 :post-affiliated 1 :path nil :mode org-data
:CATEGORY nil :granularity nil)
(section
(:begin 1 :end 71 :contents-begin 1 :contents-end 71 :robust-begin 1
:robust-end 69 :post-blank 0 :post-affiliated 1 :mode first-section
:granularity nil :parent #0)
(paragraph
(:begin 1 :end 13 :contents-begin 1 :contents-end 10 :post-blank 3
:post-affiliated 1 :mode top-comment :granularity nil :parent #1)
#("@@latex:\n" 0 9
(:parent #2)))
(paragraph
(:begin 13 :end 68 :contents-begin 13 :contents-end 65 :post-blank 3
:post-affiliated 13 :mode nil :granularity nil :parent #1)
(latex-fragment
(:value "\\documentclass[margin,11pt]{res}" :begin 13 :end 46 :post-blank 1
:parent #2))
#("% default is 10 pt\n" 0 19
(:parent #2)))
(paragraph
(:begin 68 :end 71 :contents-begin 68 :contents-end 71 :post-blank 0
:post-affiliated 68 :mode nil :granularity nil :parent #1)
#("@@\n" 0 3
(:parent #2)
```
--
Tom Alexander
Re: Seemingly inconsistent whitespace ownership
On August 11, 2023 5:20:08 AM EDT, Ihor Radchenko wrote: >"Tom Alexander" writes: > >> The org-mode documentation states: "With the exception of list items, blank >> lines belong to the preceding element with the narrowest possible scope. For >> example, if at the end of a section we have a paragraph and a blank line, >> that blank line is considered part of the paragraph." >> >> https://orgmode.org/worg/org-syntax.html#org9bc833d >> >> So I created a test org-mode document with exactly that scenario described: >> ... >> and then I ran a M-x eval-expression (message "%s" (pp-to-string >> (org-element-parse-buffer))) to see the parse tree. I'll paste the output at >> the end because its a wall of text, but analyzing it: >> ... >> Its only child is a paragraph which has a :begin at 1 and :end at 10, which >> only includes the line break at the end of "foo bar." but this is exactly >> the scenario described in the documentation (a paragraph at the end of a >> section) so I would expect the paragraph to end at 14, not 10. > >You are right and you revealed an existing inconsistency between our >incremental and recursive parsers (org-element-parse-buffer is the >recursive parser). > >Fixed, on main. >https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bfe1179dc > >Also, in addition to list items, footnote-definitions do not extend >their contents to the trailing blank lines. >I now clarified it in org-syntax document. >https://git.sr.ht/~bzg/worg/commit/3e91f5be > >-- >Ihor Radchenko // yantar92, >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> Oh neat, I didn't know there were two! I'll check that out. Thanks!
Seemingly inconsistent whitespace ownership
The org-mode documentation states: "With the exception of list items, blank
lines belong to the preceding element with the narrowest possible scope. For
example, if at the end of a section we have a paragraph and a blank line, that
blank line is considered part of the paragraph."
https://orgmode.org/worg/org-syntax.html#org9bc833d
So I created a test org-mode document with exactly that scenario described:
```
foo bar.
* Lorem
baz
* Ipsum
alpha
beta
```
and then I ran a M-x eval-expression (message "%s" (pp-to-string
(org-element-parse-buffer))) to see the parse tree. I'll paste the output at
the end because its a wall of text, but analyzing it:
The zeroth section has :begin at 1 and :end at 14, which is expected.
Its only child is a paragraph which has a :begin at 1 and :end at 10, which
only includes the line break at the end of "foo bar." but this is exactly the
scenario described in the documentation (a paragraph at the end of a section)
so I would expect the paragraph to end at 14, not 10.
The "Lorem" section is repeating the test to prove this isn't behavior unique
to the zeroth section. It behaved the same, so there is no need to go over it.
The "Ipsum" section is where I put two separate paragraphs with a bunch of
blank lines in between. This time the "alpha" paragraph goes all the way to
character 48 which means it includes ALL of the blank lines between "alpha" and
"beta".
So the "Ipsum" section proves that ":begin" to ":end" is supposed to contain
the trailing blank lines of an element.
I am using org-mode version: Org mode version 9.6.6 (release_9.6.6 @
/usr/share/emacs/29.1/lisp/org/)
And finally, that parse tree I mentioned:
```
(org-data
(:begin 1 :contents-begin 1 :contents-end 53 :end 53 :robust-begin 3
:robust-end 51 :post-blank 0 :post-affiliated 1 :path nil :mode org-data
:CATEGORY nil :granularity nil)
(section
(:begin 1 :end 14 :contents-begin 1 :contents-end 10 :robust-begin 1
:robust-end 8 :post-blank 4 :post-affiliated 1 :mode first-section :granularity
nil :parent #0)
(paragraph
(:begin 1 :end 10 :contents-begin 1 :contents-end 10 :post-blank 0
:post-affiliated 1 :mode top-comment :granularity nil :parent #1)
#("foo bar.\n" 0 9
(:parent #2
(headline
(:raw-value "Lorem" :begin 14 :end 30 :pre-blank 0 :contents-begin 22
:contents-end 26 :robust-begin nil :robust-end nil :level 1 :priority nil :tags
nil :todo-keyword nil :todo-type nil :post-blank 4 :footnote-section-p nil
:archivedp nil :commentedp nil :post-affiliated 14 :title
(#("Lorem" 0 5
(:parent #1)))
:mode nil :granularity nil :parent #0)
(section
(:begin 22 :end 30 :contents-begin 22 :contents-end 26 :robust-begin 22
:robust-end 24 :post-blank 4 :post-affiliated 22 :mode section :granularity nil
:parent #1)
(paragraph
(:begin 22 :end 26 :contents-begin 22 :contents-end 26 :post-blank 0
:post-affiliated 22 :mode planning :granularity nil :parent #2)
#("baz\n" 0 4
(:parent #3)
(headline
(:raw-value "Ipsum" :begin 30 :end 53 :pre-blank 0 :contents-begin 38
:contents-end 53 :robust-begin 40 :robust-end 51 :level 1 :priority nil :tags
nil :todo-keyword nil :todo-type nil :post-blank 0 :footnote-section-p nil
:archivedp nil :commentedp nil :post-affiliated 30 :title
(#("Ipsum" 0 5
(:parent #1)))
:mode nil :granularity nil :parent #0)
(section
(:begin 38 :end 53 :contents-begin 38 :contents-end 53 :robust-begin 38
:robust-end 51 :post-blank 0 :post-affiliated 38 :mode section :granularity nil
:parent #1)
(paragraph
(:begin 38 :end 48 :contents-begin 38 :contents-end 44 :post-blank 4
:post-affiliated 38 :mode planning :granularity nil :parent #2)
#("alpha\n" 0 6
(:parent #3)))
(paragraph
(:begin 48 :end 53 :contents-begin 48 :contents-end 53 :post-blank 0
:post-affiliated 48 :mode nil :granularity nil :parent #2)
#("beta\n" 0 5
(:parent #3))
```
--
Tom Alexander
Re: Documentation: Equal sign incorrectly listed as disallowed in plain links
Thanks for fixing all the documentation issues I submitted today! On Sat, Jul 22, 2023, at 2:58 AM, Ihor Radchenko wrote: > "Tom Alexander" writes: > >> The documentation for plain links states that PATHPLAIN is: >> >>> A string containing non-whitespace non-bracket (()[]<>=) characters, >>> optionally containing parenthesis-wrapped non-whitespace non-bracket >>> substrings up to a depth of two. The string must end with either a >>> non-punctation non-whitespace character, a forwards slash, or a >>> parenthesis-wrapped substring. >> >> but if we create an org-mode document with the following test content: >> ``` >> http://foo/bar=baz > > As you can see from the sentence, PATHPLAIN must be "non-whitespace" > "non-bracket". "=" is just a messed up verbatim markup marker. > > Fixed, on master. > https://git.sr.ht/~bzg/worg/commit/85ef10ed > > -- > Ihor Radchenko // yantar92, > 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>
Documentation: incorrect character name in line breaks
The documentation for line breaks says that PRE is: > Anything but backspace (`\`). I suspect this is supposed to say "backslash" (ascii 92) not "backspace" (ascii 8) Link to the documentation: https://orgmode.org/worg/org-syntax.html#Line_Breaks
Documentation: Equal sign incorrectly listed as disallowed in plain links
The documentation for plain links states that PATHPLAIN is:
> A string containing non-whitespace non-bracket (()[]<>=) characters,
> optionally containing parenthesis-wrapped non-whitespace non-bracket
> substrings up to a depth of two. The string must end with either a
> non-punctation non-whitespace character, a forwards slash, or a
> parenthesis-wrapped substring.
but if we create an org-mode document with the following test content:
```
http://foo/bar=baz
http://foo/bar[baz
```
and run a M-x eval-expression (message "%s" (pp-to-string
(org-element-parse-buffer)))
Then we can see that it allows the equals sign in the PATHPLAIN (output pasted
below)
Link to the documentation: https://orgmode.org/worg/org-syntax.html#org6934900
Syntax tree:
```
(org-data
(:begin 1 :contents-begin 1 :contents-end 40 :end 40 :robust-begin 3
:robust-end 38 :post-blank 0 :post-affiliated 1 :path "/tmp/test/test.org"
:mode org-data :CATEGORY "test" :granularity nil)
(section
(:begin 1 :end 40 :contents-begin 1 :contents-end 40 :robust-begin 1
:robust-end 38 :post-blank 0 :post-affiliated 1 :mode first-section
:granularity nil :parent #0)
(paragraph
(:begin 1 :end 21 :contents-begin 1 :contents-end 20 :post-blank 1
:post-affiliated 1 :mode top-comment :granularity nil :parent #1)
(link
(:type "http" :path "//foo/bar=baz" :format plain :raw-link
"http://foo/bar=baz; :application nil :search-option nil :begin 1 :end 19
:contents-begin nil :contents-end nil :post-blank 0 :parent #2))
#("\n" 0 1
(:parent #2)))
(paragraph
(:begin 21 :end 40 :contents-begin 21 :contents-end 40 :post-blank 0
:post-affiliated 21 :mode nil :granularity nil :parent #1)
(link
(:type "http" :path "//foo/bar" :format plain :raw-link "http://foo/bar;
:application nil :search-option nil :begin 21 :end 35 :contents-begin nil
:contents-end nil :post-blank 0 :parent #2))
#("[baz\n" 0 5
(:parent #2)
```
Documentation: Reference to BODY field that is not specified in the grammar
The documentation for Inline Babel Calls mentions that opening and closing square brackets must be balanced within BODY but the grammar above it only defines NAME, ARGUMENTS, HEADER1, and HEADER2. Link to the documentation: https://orgmode.org/worg/org-syntax.html#Inline_Babel_Calls
Documentation: Reference to "KEYCITES" field that is not specified in grammar
The documentation for Citations when specifying which syntactic elements have spaces between them references a "KEYCITES" syntactic element that does not appear anywhere else on the page. Link to the documentation issue: https://orgmode.org/worg/org-syntax.html#Citations
Bug: Inconsistent formatting when terminating bold inside a link [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]
uot;mailto" :follow
#[257 "\301\300\302Q!\207" ["mailto" browse-url ":"] 5
"\n\n(fn URL)"])
("https" :follow
#[257 "\301\300\302Q!\207" ["https" browse-url ":"] 5
"\n\n(fn URL)"])
("http" :follow
#[257 "\301\300\302Q!\207" ["http" browse-url ":"] 5
"\n\n(fn URL)"])
("ftp" :follow
#[257 "\301\300\302Q!\207" ["ftp" browse-url ":"] 5
"\n\n(fn URL)"])
("help" :follow org-link--open-help)
("file" :complete org-link-complete-file)
("elisp" :follow org-link--open-elisp) ("doi" :follow
org-link--open-doi))
org-latex-format-headline-function 'org-latex-format-headline-default-function
org-link-elisp-confirm-function 'yes-or-no-p
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-html-format-headline-function 'org-html-format-headline-default-function
)
--
Tom Alexander
Re: [O] O[PATCH] org-export-generic table exporting
Well thank you! I apologize for the late reply, my coursework has a hold on me, but I was getting worried when no one responded immediately :-). I think the next step would be editing the configs for generic exporting to other mediums to support the tables (which HTML would be beyond trivial with the variables I included), but I am waiting for the lords of org-mode to either approve this patch or suggest changes first. Also, I have been using this modification to handle meeting minutes for my fraternity for the past month and I have not run into a hiccup yet, so http://i.imgur.com/xzfgp.jpg . On Wed, Feb 15, 2012 at 5:55 PM, Wes Hardaker wjhns...@hardakers.netwrote: On Tue, 7 Feb 2012 23:44:42 -0500, Tom Alexander tomalexan...@paphus.com said: TA I noticed that the org-export-generic.el script had options for basic TA features like checkboxes but not for tables, which were locked into TA ascii exporting. The attached patch creates many variables to allow TA users to change the table formatting (much like how there are TA variables like :body-list-checkbox-done). I also created a generic TA exporter named mediawiki that demonstrates use of the table TA exporting. Awesome! TA This is my first post to this mailing list, and my first ever TA contribution to an open-source project so I look forward to feedback TA and be kind when you point out any sort of mailing list etiquette I TA might have broken. Well, I think you've certainly given a good first shot at a contribution! [Hopefully someone with write access will apply it soon] -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ -- Tom Alexander HS - Secretary Alpha Sigma Phi; Beta Psi Chapter Rensselaer Polytechnic Institute Class of 2013
[O] [PATCH] org-export-generic table exporting
I noticed that the org-export-generic.el script had options for basic
features like checkboxes but not for tables, which were locked into
ascii exporting. The attached patch creates many variables to allow
users to change the table formatting (much like how there are
variables like :body-list-checkbox-done). I also created a generic
exporter named mediawiki that demonstrates use of the table
exporting.
This is my first post to this mailing list, and my first ever
contribution to an open-source project so I look forward to feedback
and be kind when you point out any sort of mailing list etiquette I
might have broken.
--
Tom Alexander
HS - Secretary
Alpha Sigma Phi; Beta Psi Chapter
Rensselaer Polytechnic Institute
Class of 2013
From 6e072d97d056cb61fc7810b8b9fea43d3cf9489e Mon Sep 17 00:00:00 2001
From: Tom Alexander craftkil...@gmail.com
Date: Tue, 7 Feb 2012 20:15:29 -0500
Subject: [PATCH] Added variables for exporting tables including: -
body-table-start - body-table-end -
body-table-row-start - body-table-row-end -
body-table-cell-start - body-table-cell-end -
body-table-first-cell-start -
body-table-interior-cell-start -
body-table-interior-cell-end - body-table-last-cell-end
- body-table-hline-start - body-table-hline-end
Added a mediawiki exporter which uses the new table exporting
---
contrib/lisp/org-export-generic.el | 87 +--
1 files changed, 82 insertions(+), 5 deletions(-)
diff --git a/contrib/lisp/org-export-generic.el b/contrib/lisp/org-export-generic.el
index 436badc..9e21992 100644
--- a/contrib/lisp/org-export-generic.el
+++ b/contrib/lisp/org-export-generic.el
@@ -325,6 +325,51 @@ in this way, it will be wrapped.
:body-bullet-list-prefix (* ** *** * )
)
;;
+;; mediawiki
+;;
+(mediawiki
+ :file-suffix .txt
+ :key-binding ?m
+
+ :header-prefix
+ :header-suffix
+
+ :title-format = %s =\n
+
+ :date-export nil
+
+ :toc-exportnil
+
+ :body-header-section-numbers nil
+ :body-section-prefix \n
+
+ :body-section-header-prefix(= == ===
+ = == )
+ :body-section-header-suffix( =\n\n ==\n\n ===\n\n
+ \n\n =\n\n ==\n\n)
+
+ :body-line-export-preformated t ;; yes/no/maybe???
+ :body-line-format %s\n
+ :body-line-wrap75
+
+ :body-line-fixed-format%s\n
+
+ :body-list-format * %s\n
+ :body-number-list-format # %s\n
+
+ :body-bullet-list-prefix (* ** *** * )
+ :body-list-checkbox-todo ☐
+ :body-list-checkbox-done ☒
+ :body-table-start {|
+ :body-table-end|}
+ :body-table-cell-start |
+ :body-table-cell-end \n
+ :body-table-last-cell-end |-
+ :body-table-hline-start
+
+
+ )
+;;
;; internet-draft .xml for xml2rfc exporter
;;
(ietfid
@@ -715,7 +760,34 @@ underlined headlines. The default is 3.
(or (plist-get export-plist :body-list-checkbox-done-end) ))
(listcheckhalfend
(or (plist-get export-plist :body-list-checkbox-half-end) ))
- (bodynewline-paragraph (plist-get export-plist :body-newline-paragraph))
+ (bodytablestart
+ (or (plist-get export-plist :body-table-start) ))
+ (bodytableend
+ (or (plist-get export-plist :body-table-end) ))
+ (bodytablerowstart
+ (or (plist-get export-plist :body-table-row-start) ))
+ (bodytablerowend
+ (or (plist-get export-plist :body-table-row-end) ))
+ (bodytablecellstart
+ (or (plist-get export-plist :body-table-cell-start) ))
+ (bodytablecellend
+ (or (plist-get export-plist :body-table-cell-end) ))
+ (bodytablefirstcellstart
+ (or (plist-get export-plist :body-table-first-cell-start) ))
+ (bodytableinteriorcellstart
+ (or (plist-get export-plist :body-table-interior-cell-start) ))
+ (bodytableinteriorcellend
+ (or (plist-get export-plist :body-table-interior-cell-end) ))
+ (bodytablelastcellend
+ (or (plist-get export-plist :body-table-last-cell-end) ))
+ (bodytablehlinestart
+ (or (plist-get export-plist :body-table-hline-start) \\1))
+ (bodytablehlineend
+ (or (plist-get export-plist :body-table-hline-end) ))
+
+
+
+ (bodynewline-paragraph (plist-get export-plist :body-newline-paragraph))
(bodytextpre (plist-get export-plist :body-text-prefix))
(bodytextsuf (plist-get export-plist :body-text-suffix))
(bodylinewrap (plist-get export-plist :body-line-wrap))
@@ -1328,16 +1400,21 @@ REVERSE means to reverse the list if the plist match is a list
(setq lines (org-table-clean-before-export lines)))
;; Get rid of the vertical lines except for grouping
(let ((vl (org-colgroup-info-to-vline-list org-table
