Status of syntax specification

[Gerry Agbobada]

Hello,

I found on Worg a "draft" for org syntax description : 
https://orgmode.org/worg/dev/org-syntax.html

Do you think this paper marked as draft is good enough to use as a source to 
make a parser ?  
I think it'd be nice to try to finalize this ; but I don't know who to contact 
to see how I can help
 if I know almost nothing about standards and technical writing.


Best regards,
Gerry Agbobada

Bug: Asterisk inside example is incorrectly parsed [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]

[Eric Berquist]

The asterisk inside the example block isn't escaped properly, and
appears as a header, leaving `#+begin_example` and `#+end_example` to
appear as regular text. It occurs in at least both the HTML and LaTeX
output. Here is a minimal example to reproduce the problem:

* first section

#+begin_example
* I am not supposed to be a section
#+end_example

* second section

#+begin_example
Hello, world!
#+end_example

This is using `emacs -Q`, so I've left off the current state
section. This also happens with Org commit
3c4cb7b296c78aafb0d6302a4075f1f1fa1c7e1c (`org-collect-keywords` was
causing me issues, so I'm not at HEAD).

Emacs  : GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.17.3)
 of 2020-05-17
Package: Org mode version 9.3 (release_9.3 @
/usr/share/emacs/27.0.91/lisp/org/)

Org-list: Add back fancy description list indentation

[James R Miller]

Hi all,

Was there really not a way to keep fancy description list indentation instead 
of removing it entirely? I have almost a decade of org files that use 
description lists, and it really helps have the description items called out 
from the description text. 

Is there a simple way to add this functionality back in? Perhaps as some sort 
of variable like `org-use-fancy-description-list-indentation` instead of 
throwing it out entirely? 

Here's the commit I'm referring to: 
https://code.orgmode.org/bzg/org-mode/commit/683df456a41a2b0e308bdbf746f5db0235a6058a

Thanks. 

-- 
  James Miller
  james.ryland.mil...@gmail.com

Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output

[Nick Daly]

Hi Org Maintainers,

Attached is an updated patch that makes output trimming work with
blocks that do and don't produce results.  The old patch creates a
=let: Wrong type argument: arrayp, nil= error when evaluating blocks
that don't produce output.  This necessarily incorporates yesterday's
patch.

Thanks for your time,
Nick


Multi-line function declarations with output still work fine.

#+BEGIN_SRC haskell
  :{
  chain :: (Integral a) => a -> [a]
  chain 1 = [1]
  chain n
  | even n = n:chain (n `div` 2)
  | odd n  = n:chain (n*3 + 1)
  :}
  chain 10
#+END_SRC

#+RESULTS:
| 10 | 5 | 16 | 8 | 4 | 2 | 1 |


Silent declaration-only blocks correctly evaluate silently.

#+BEGIN_SRC haskell :results silent
  :{
  flip' :: (a -> b -> c) -> (b -> a -> c)
  flip' f = \x y -> f y x
  :}
#+END_SRC


Single-line function calls also return the expected results.

#+name: flip'-hello
#+BEGIN_SRC haskell
  flip' zip [1,2,3,4,5,6] "hello"
#+END_SRC

#+RESULTS: flip'-hello
| h | 1 |
| e | 2 |
| l | 3 |
| l | 4 |
| o | 5 |
diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index bea162528..cb581fe3b 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -83,12 +83,16 @@
 			  (cdr (member org-babel-haskell-eoe
(reverse (mapcar #'org-trim raw)))
 (org-babel-reassemble-table
- (let ((result
+ (let* ((result
 (pcase result-type
   (`output (mapconcat #'identity (reverse results) "\n"))
-  (`value (car results)
+  (`value (car results
+(result
+ (if (stringp result)
+ (replace-regexp-in-string "Prelude[|>] " "" result)
+   result)))
(org-babel-result-cond (cdr (assq :result-params params))
-	 result (org-babel-script-escape result)))
+	 result (if (stringp result) (org-babel-script-escape result
  (org-babel-pick-name (cdr (assq :colname-names params))
 			  (cdr (assq :colname-names params)))
  (org-babel-pick-name (cdr (assq :rowname-names params))

[PATCH] ob-haskell: Line Continuations Mangle Block Output

[Nick Daly]

Hi Org Maintainers,

Please see the attached patch to remove "Prelude> " and "Prelude| " line
continuations from the block result output when parsing blocks that contain
multi-line function declarations.

This likely requires yesterday's patch to return value-type results from
Haskell blocks.  This patch applies cleanly against the org-mode master.

#+name: chain-ecm
#+BEGIN_SRC haskell
  :{
  chain :: (Integral a) => a -> [a]
  chain 1 = [1]
  chain n
  | even n = n:chain (n `div` 2)
  | odd n  = n:chain (n*3 + 1)
  :}
  chain 10
#+END_SRC

Results without patch:
: Prelude| Prelude| Prelude| Prelude| Prelude| Prelude| Prelude>
[10,5,16,8,4,2,1]

Results with patch:
: | 10 | 5 | 16 | 8 | 4 | 2 | 1 |

Thank you for your time,
Nick
--- lisp/ob-haskell.el
+++ lisp/ob-haskell.el
@@ -84,9 +84,11 @@
(reverse (mapcar #'org-trim raw)))
 (org-babel-reassemble-table
  (let ((result
-(pcase result-type
-  (`output (mapconcat #'identity (reverse results) "\n"))
-  (`value (car results)
+	(replace-regexp-in-string
+	 "Prelude[|>] " ""
+ (pcase result-type
+   (`output (mapconcat #'identity (reverse results) "\n"))
+   (`value (car results))
(org-babel-result-cond (cdr (assq :result-params params))
 	 result (if (stringp result) (org-babel-script-escape result
  (org-babel-pick-name (cdr (assq :colname-names params))

Diff finished.  Sun May 17 14:26:21 2020

Re: restore window configuration after org-edit-src-exit

[edgar]

Hello. I would like to request this to be pushed onto the =maint= branch 
(7684b59c7) or make it the default, please.


https://lists.gnu.org/archive/html/emacs-orgmode/2019-12/txtr_q1WmvVPH.txt

which is related to (at least) commits 7d5e931f7 and d833920de from the 
=master= branch. I have also tested by using lisp/org-src.el from the 
current =master= (9bc0cc7fb) on the =maint= branch (7684b59c7), and it 
works for me. Thanks!


-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: [PATCH] Add margin option to float for figure in ox-latex.el

[Thomas S. Dye]

Aloha Kyle,

Barring a guru's user-end customization, Rasmus's figure 
:environment attribute idea is a good one.


The LaTeX float package has a facility to create and name 
environments that are handled like figures.  A figure :environment 
attribute in Org mode would provide a straightforward and flexible 
path to transcode them.


Thanks for looking into this.

Let me know if you have questions.

All the best,
Tom

Kyle Meyer writes:


Thomas S. Dye writes:

This patch produces a LaTeX environment, marginfigure, that 
isn't

part of the standard.  AFAIK, marginfigure is defined in the
sidenotes package and separately in the tufte-latex class, 
neither
of which Org mode loads by default.  If the patch is applied, 
then
one of these packages should be added to the list of default 
LaTeX
packages so ox-latex doesn't export code it is unable to 
compile.


My takeaway from the discussion surrounding ox-tufte-latex 
several
years ago is that support for non-standard LaTeX constructs 
should
not be part of Org mode core because they complicate 
maintenance

unduly.


Thanks for your input and the helpful summary.  The stance in 
the second

paragraph sounds like a sensible one.

Given the desire to use the marginfigure environment has popped 
up a few
times, I wonder if an ox-latex guru can suggest a user-end 
customization
that would enable the use of that environment.  I suppose an 
alternative
is Rasmus's proposal of an :environment attribute for figures 
[*] that I

mentioned in a sibling thread.

[*]: https://yhetil.org/orgmode/878u31ycc5@gmx.us/



--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

Dear Nicolas Goaziou,

Apparently my previous email was again refused by your mail server (I
tried to add patch as attachment this time).

The patch is in
https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef

This patch is actually one commit ahead of the patch in the email, fixing
an issue when change function throws an error. I wrapped the call into
with-demoted-errors to avoid potential data loss on error in future.

Best,
Ihor



Ihor Radchenko  writes:

> Hi,
>
> [All the changes below are relative to commit ed0e75d24. Later commits
> make it hard to distinguish between hidden headlines and drawers. I will
> need to figure out a way to merge this branch with master. It does not
> seem to be trivial.]
>
> I have finished a seemingly stable implementation of handling changes
> inside drawer and block elements. For now, I did not bother with
> 'modification-hooks and 'insert-in-font/behind-hooks, but simply used
> before/after-change-functions.
>
> The basic idea is saving parsed org-elements before the modification
> (with :begin and :end replaced by markers) and comparing them with the 
> versions of the same elements after the modification.
> Any valid org element can be examined in such way by an arbitrary
> function (see org-track-modification-elements) [1].
>
> For now, I have implemented tracking changes in all the drawer and block
> elements. If the contents of an element is changed and the element is
> hidden, the contents remains hidden unless the change was done with
> self-insert-command. If the begin/end line of the element was changed in
> the way that the element changes the type or extends/shrinks, the
> element contents is revealed. To illustrate:
>
> Case #1 (the element content is hidden):
>
> :PROPERTIES:
> :ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
> :END:
>
> is changed to
>
> :ROPERTIES:
> :ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
> :END:
>
> Text is revealed, because we have drawer in place of property-drawer
>
> Case #2 (the element content is hidden):
>
> :ROPERTIES:
> :ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
> :END:
>
> is changed to
>
> :OPERTIES:
> :ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
> :END:
>
> The text remains hidden since it is still a drawer.
>
> Case #3: (the element content is hidden):
>
> :FOO:
> bar
> tmp
> :END:
>
> is changed to
>
> :FOO:
> bar
> :END:
> tmp
> :END:
>
> The text is revealed because the drawer contents shrank.
>
> Case #4: (the element content is hidden in both the drawers):
>
> :FOO:
> bar
> tmp
> :END:
> :BAR:
> jjd
> :END:
>
> is changed to
>
> :FOO:
> bar
> tmp
> :BAR:
> jjd
> :END:
>
> The text is revealed in both the drawers because the drawers are merged
> into a new drawer.
>
>> However, I think we can do better than that, and also fix the glitches
>> from overlays. Here are two of them. Write the following drawer:
>>
>>   :FOO:
>>   bar
>>   :END:
>>
>> fold it and delete the ":f". The overlay is still there, and you cannot
>> remove it with TAB any more. Or, with the same initial drawer, from
>> beginning of buffer, evaluate:
>>
>>   (progn (re-search-forward ":END:") (replace-match ""))
>>
>> This is no longer a drawer: you just removed its closing line. Yet, the
>> overlay is still there, and TAB is ineffective.
>
> I think the above examples cover what you described.
>
> Case #5 (the element content is hidden, point at ):
>
> :FOO:
> bar
> tmp
> :END:
>
> is changed (via self-insert-command) to
>
> :FOO:a
> bar
> tmp
> :END:
>
> The text is revealed.
>
> This last case sounds logical and might potentially replace
> org-catch-invisible-edits.
>
> 
>
> Some potential issues with the implementation:
>
> 1. org--after-element-change-function can called many times even for
> trivial operations. For example (insert "\n" ":TEST:") seems to call it
> two times already. This has two implications: (1) potential performance
> degradation; (2) org-element library may not be able to parse the
> changed element because its intermediate modified state may not match
> the element syntax. Specifically, inserting new property into
> :PROPERTIES: drawer inserts a newline at some point, which makes
> org-element-at-point think that it is not a 'property-drawer, but just
> 'drawer.
>
> For (1), I did not really do any workaround for now. One potential way
> is making use of combine-after-change-calls (info:elisp#Change Hooks).
> At least, within org source code. 
>
> For (2), I have introduced org--property-drawer-modified-re to override
> org-property-drawer-re in relevant *-change-function. This seems to work
> for property drawers. However, I am not sure if similar problem may
> happen in some border cases with ordinary drawers or blocks. 
>
> 2. I have noticed that results of org-element-at-point and
> org-element-parse-buffer are not always consistent.
> In my tests, they returned different number of empty lines after drawers
> 

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

Hi,

[All the changes below are relative to commit ed0e75d24. Later commits
make it hard to distinguish between hidden headlines and drawers. I will
need to figure out a way to merge this branch with master. It does not
seem to be trivial.]

I have finished a seemingly stable implementation of handling changes
inside drawer and block elements. For now, I did not bother with
'modification-hooks and 'insert-in-font/behind-hooks, but simply used
before/after-change-functions.

The basic idea is saving parsed org-elements before the modification
(with :begin and :end replaced by markers) and comparing them with the 
versions of the same elements after the modification.
Any valid org element can be examined in such way by an arbitrary
function (see org-track-modification-elements) [1].

For now, I have implemented tracking changes in all the drawer and block
elements. If the contents of an element is changed and the element is
hidden, the contents remains hidden unless the change was done with
self-insert-command. If the begin/end line of the element was changed in
the way that the element changes the type or extends/shrinks, the
element contents is revealed. To illustrate:

Case #1 (the element content is hidden):

:PROPERTIES:
:ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
:END:

is changed to

:ROPERTIES:
:ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
:END:

Text is revealed, because we have drawer in place of property-drawer

Case #2 (the element content is hidden):

:ROPERTIES:
:ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
:END:

is changed to

:OPERTIES:
:ID:   279e797c-f4a7-47bb-80f6-e72ac6f3ec55
:END:

The text remains hidden since it is still a drawer.

Case #3: (the element content is hidden):

:FOO:
bar
tmp
:END:

is changed to

:FOO:
bar
:END:
tmp
:END:

The text is revealed because the drawer contents shrank.

Case #4: (the element content is hidden in both the drawers):

:FOO:
bar
tmp
:END:
:BAR:
jjd
:END:

is changed to

:FOO:
bar
tmp
:BAR:
jjd
:END:

The text is revealed in both the drawers because the drawers are merged
into a new drawer.

> However, I think we can do better than that, and also fix the glitches
> from overlays. Here are two of them. Write the following drawer:
>
>   :FOO:
>   bar
>   :END:
>
> fold it and delete the ":f". The overlay is still there, and you cannot
> remove it with TAB any more. Or, with the same initial drawer, from
> beginning of buffer, evaluate:
>
>   (progn (re-search-forward ":END:") (replace-match ""))
>
> This is no longer a drawer: you just removed its closing line. Yet, the
> overlay is still there, and TAB is ineffective.

I think the above examples cover what you described.

Case #5 (the element content is hidden, point at ):

:FOO:
bar
tmp
:END:

is changed (via self-insert-command) to

:FOO:a
bar
tmp
:END:

The text is revealed.

This last case sounds logical and might potentially replace
org-catch-invisible-edits.



Some potential issues with the implementation:

1. org--after-element-change-function can called many times even for
trivial operations. For example (insert "\n" ":TEST:") seems to call it
two times already. This has two implications: (1) potential performance
degradation; (2) org-element library may not be able to parse the
changed element because its intermediate modified state may not match
the element syntax. Specifically, inserting new property into
:PROPERTIES: drawer inserts a newline at some point, which makes
org-element-at-point think that it is not a 'property-drawer, but just
'drawer.

For (1), I did not really do any workaround for now. One potential way
is making use of combine-after-change-calls (info:elisp#Change Hooks).
At least, within org source code. 

For (2), I have introduced org--property-drawer-modified-re to override
org-property-drawer-re in relevant *-change-function. This seems to work
for property drawers. However, I am not sure if similar problem may
happen in some border cases with ordinary drawers or blocks. 

2. I have noticed that results of org-element-at-point and
org-element-parse-buffer are not always consistent.
In my tests, they returned different number of empty lines after drawers
(:post-blank and :end properties). I am not sure here if I did something
wrong in the code or if it is a real issue in org-element.

For now, I simply called org-element-at-point with point at :begin
property of all the elements returned by org-element-parse buffer to
make things consistent. This indeed introduced overhead, but I do not
see other way to solve the inconsistency.

3. This implementation did not directly solve the previously observed
issue with two ellipsis displayed in folded drawer after adding hidden
text inside:

:PROPERTY: ...  -->  :PROPERTY: ...  ...

For now, I just did

(org-hide-drawer-toggle 'off)
(org-hide-drawer-toggle 'hide)

to hide the second ellipsis, but I still don't understand why it is
happening. Is it 

Re: Customizable fixed indentation column

[Panagiotis Vlantis]

Hello,

On 5/14/20 4:52 PM, Nicolas Goaziou wrote:

Hello,

Panagiotis Vlantis  writes:


This is my first time using the mailing list so please point out if
I am going about this the wrong way.

Thank you for the patch.

You are welcome.



After searching a bit, I didn't find a way to specify a custom fixed
indentation column in org sections; the current implementation
automatically aligns content at the beginning of the line when
`org-adapt-indentation' is set to nil, which I find somewhat
restrictive (e.g., in this case, one should be careful when using
lists beginning with '*' characters).

Starting list items with "*" is a terrible idea, indeed. However, it is
unlikely to break the document because list promotion commands handle
this case.

I'm not convinced the current implementation is restrictive. OOC, do you
know any text-related mode that allows indenting contents at any column?
Also please note that if your first line is indented, all indentation
below will follow.


Maybe restrictive was a bad way to put it. Nonetheless, I find being 
able to align contents at a column other than the first handy since it 
is easy to visually distinguish between staff without steadily losing 
usable space as the node level increases. This is especially noticeable 
when one follows a fixed line width layout and somehow ends up with 7 
levels deep headings (not a good practice, I know :)) I have to admit 
that I am not aware of any text-related mode with this kind of feature 
either, although such customization (i.e., adaptive vs fixed 
indentation) is rather convenient in source code editing modes (e.g., 
`cc-mode', etc).



To that end, I modified the current implementation accordingly (and
added some tests) in order to allow one to set the desired indentation
column to something other than the 0th, where section contents will be
aligned at if adaptive indentation is disabled.

I don't know if others will find this feature useful but I'll go and
include the patch here anyway. If you find this worth merging but
should be modified somehow before that, I would be happy to do so.

Instead of creating a new variable, what about overloading
`org-adapt-indentation'? If it is a whole number, use it as indentation.
`nil' becomes an alias for 0.

WDYT?


I tried out your suggestion and overloaded `org-adapt-indentation' 
instead of introducing a new variable. The corresponding patch can be 
seen below. Clearly, I am in no position to tell which implementation is 
better, although the latter feels a bit more complicated than the first. 
What is your opinion on this?




Regards,

--
Nicolas Goaziou


Best regard,

Panagiotis Vlantis




From 7e46937d1b188f913093f0ae66914803f51441e7 Mon Sep 17 00:00:00 2001
From: Panagiotis Vlantis 
Date: Sun, 17 May 2020 14:36:21 +0300
Subject: [PATCH] org: Enable selection of custom indentation column

* lisp/org.el (org-adapt-indentation): Allow integer values to specify
custom indentation column.
(org--get-expected-indentation): Properly handle case when
`org-adapt-indentation' is integer.
(org-add-planning-info): Properly indent newly added planning info when
`org-adapt-indentation' is integer.

* testing/lisp/test-org.el (test-org/get-property-block,
test-org/insert-property-drawer, test-org/indent-line,
test-org/indent-region, test-org/add-planning-info, test-org/deadline,
test-org/schedule, test-org/set-property): Modify tests depending on
indentation and add more tests.

Introduce variable and modify indentation mechanism accordingly in
order to allow the user to specify a custom indentation column (other
than zero) to be used instead of adaptive indentation.
---
 lisp/org.el  |  47 ++
 testing/lisp/test-org.el | 190 ++-
 2 files changed, 220 insertions(+), 17 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index dcd446745..487a81617 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1575,27 +1575,34 @@ lines to the buffer:
 (defcustom org-adapt-indentation t
   "Non-nil means adapt indentation to outline node level.

-When this variable is set to t, Org assumes that you write
+When this variable is non-nil, Org assumes that you write
 outlines by indenting text in each node to align with the
 headline (after the stars).

-When this variable is set to 'headline-data, only adapt the
-indentation of the data lines right below the headline, such as
-planning/clock lines and property/logbook drawers.
+In the special case this variable is set to 'headline-data,
+only adapt the indentation of the data lines right below the headline,
+such as planning/clock lines and property/logbook drawers.
+
+In the special case this variable is set to an integer value N,
+section contents will be indented to the N-th column instead,
+independently of the the corresponding outline node's level.

 The following issues are influenced by this variable:

-- The indentation is increased by one space in a demotion
-  command, and decreased by one in 

Re: [PATCH] agenda: Consider FILETAGS for archive skipping

[Dauer, Michael]

Hi,

I support George view. A working ARCHIVE tag on file level would be
consistent and very useful.

To be archived is a property of the content of a file, not of it's file
name. Having to store the file name on a variable is a complicated and poor
workaround. The file name may change. Still the content should stay
archived.

Regards,
Michael

Kyle Meyer  schrieb am So., 17. Mai 2020, 07:34:

> George Sokolsky writes:
>
> > I have .org files with  "#+FILETAGS: ARCHIVE" headers.
> >
> > I want items from these .org files to be hidden by default from results
> > of "org-agenda" -> "s Search for keywords" by default.
> >
> > This is not the case, unfortunately.
> [...]
>
> I'd guess that it's uncommon to try to set the ARCHIVE tag at the file
> level, as file-level archiving is already dealt through
> org-archive-location and friends.  These standard files can optionally
> be included with vA (or C-u M-x org-agenda-archives-mode).
>
> > *How the above could be done, please?*
>
> I don't see a built-in way to do it, though I think the patch below may
> be sufficient to provide the behavior you want.  It doesn't consider any
> of the tag inheritance variables, but that's probably okay given that
> those aren't considered for handling :ARCHIVE: subtrees either.
>
> -- >8 --
> Subject: [PATCH] agenda: Consider FILETAGS for archive skipping
>
> * lisp/org-agenda.el (org-agenda-skip): Consider skipping all entries
> in a file if org-archive-tag is set via FILETAGS.
> ---
>  lisp/org-agenda.el | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index 9c73d0d6c..8ed5e402d 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -4082,8 +4082,10 @@ (defun org-agenda-skip ()
>  (when (or
>(save-excursion (goto-char p) (looking-at comment-start-skip))
>(and org-agenda-skip-archived-trees (not
> org-agenda-archives-mode)
> -   (get-text-property p :org-archived)
> -   (org-end-of-subtree t))
> +   (or (and (get-text-property p :org-archived)
> +(org-end-of-subtree t))
> +   (and (member org-archive-tag org-file-tags)
> +(goto-char (point-max)
>(and org-agenda-skip-comment-trees
> (get-text-property p :org-comment)
> (org-end-of-subtree t))
> --
> 2.26.2
>
>
>