From 210d0ffbdeafeef524ce1c1a739f98e897569e88 Mon Sep 17 00:00:00 2001 Message-Id: <210d0ffbdeafeef524ce1c1a739f98e897569e88.1669442423.git.yantar92@posteo.net> In-Reply-To: References: From: Ihor Radchenko Date: Sat, 26 Nov 2022 13:59:35 +0800 Subject: [PATCH 3/4] * dev/org-syntax.org: Remove change summary section --- dev/org-syntax.org | 59 ---------------------------------------------- 1 file changed, 59 deletions(-) diff --git a/dev/org-syntax.org b/dev/org-syntax.org index e07564cd..0e4b436b 100644 --- a/dev/org-syntax.org +++ b/dev/org-syntax.org @@ -1618,65 +1618,6 @@ * Footnotes #+latex: \appendix * Appendix -** Summary of changes compared to the current =org-syntax= document -:PROPERTIES: -:CUSTOM_ID: Changes -:END: - -+ Rename "Headlines" -> "Headings", since while both forms are - currently used in the docs a change to consistently use the latter - seems imminent if delayed by (what looks like) an ongoing wait for - Bastien's final say -+ Describe patterns with consistent phrasing, "Xs are structured - according to the following pattern:" -+ Describe string patterns with consistent phrasing,"a string - constituted of" (and other forms) -> "a string consisting of" -+ Describe components of a pattern using description lists -+ Use verbatim objects for verbatim text over quotes -+ Change the way inlinetasks are described -+ Add =CONTENTS= component to the Item structure -+ Some whitespace/capitalisation changes -+ (Lots of) miscellaneous wording changes for clarity -+ Fix some minor errors (like referencing a variable which was removed - 7y ago, or saying that switches in source block headers should be - separated by blank lines) -+ Change the babel call element syntax description to the more detailed form - found in the manual -+ Change the inline babel call object syntax description to be - consistent with the babel call element syntax. This does not - precisely match the parser behaviour, but matches a very slight - subset. The previous description in some parts matched a superset - of the parser behaviour, and in other places a subset. -+ Change "Greater Elements" / "Elements" to "Greater Elements"/ - "Lesser Elements" -+ Put all Elements under the new level-1 heading "Elements" -+ Separate list definition into four sub-definitions -+ Add a "Terminology and conventions" section -+ Mention ~plain-text~ objects (see src_elisp{(org-element-type - "text")}) for the sake of consistency (When something can "contain - an object" it can contain unformatted text. Without naming - ~plain-text~ as an object this is a bit funky). -+ Specify that whitespace in plain text is semantically - collapsed/equivalent to a single space. It is worth noting that this - is not indicated by =org-element='s parsing, which grabs all the - whitespace as-is. However, this feels like something which is done - for performance reasons, instead of a deliberate choice to make - whitespace significant, and there are a few things which reinforce - this view - - =ox-ascii=, the only export backend to a format which doesn't itself - collapse whitespace when interpreted, re-fills paragraphs and - collapses whitespace. - - We have a line break object. If =\n= was significant in plain text - this would be unnecessary. - - ~org-fill-paragraph~ collapses whitespace - - Lastly, this is well-established sensible behaviour in every other - plaintext format that I can think of (HTML, LaTeX, Markdown, reST, - etc.). -+ Added bunch of examples -+ Probably a few bits and pieces that have slipped my mind. - -#+latex: \newpage - ** Org Entities :PROPERTIES: :CUSTOM_ID: Entities_List -- 2.35.1