Re: [PATCH] org-element: Hide parsers boilerplate into plist-creating macros

[akater]

Bastien  writes:

> IIUC this is a refactoring, it does not add or remove functionalities?

Yes, just a refactoring.

A typo crept into comments and help pages, so here's an update.



signature.asc
Description: PGP signature
>From 0636f032b3c7e60221c28aeea91cce58376561dd Mon Sep 17 00:00:00 2001
From: akater 
Date: Thu, 16 Apr 2020 02:25:59 +
Subject: [PATCH] org-element: Hide parsers boilerplate into plist-creating
 macros

* lisp/org-element.el (org-prog-plist, org-let*-prog-plists) (org-let*-prog-plist): New macros.  Build plists without boilerplate.

(org-fold, org-dekeyword): New functions.  Dependencies for the above.

* lisp/org-element.el (org-element-center-block-parser)
(org-element-drawer-parser, org-element-dynamic-block-parser)
(org-element-footnote-definition-parser)
(org-element-plain-list-parser, org-element-property-drawer-parser)
(org-element-quote-block-parser, org-element-section-parser)
(org-element-special-block-parser, org-element-babel-call-parser)
(org-element-clock-parser, org-element-comment-parser)
(org-element-comment-block-parser, org-element-diary-sexp-parser)
(org-element-example-block-parser, org-element-export-block-parser)
(org-element-fixed-width-parser, org-element-horizontal-rule-parser)
(org-element-keyword-parser, org-element-latex-environment-parser)
(org-element-node-property-parser, org-element-paragraph-parser)
(org-element-planning-parser, org-element-src-block-parser)
(org-element-table-parser, org-element-table-row-parser)
(org-element-verse-block-parser, org-element-entity-parser)
(org-element-footnote-reference-parser, org-element-inline-babel-call-parser)
(org-element-inline-src-block-parser, org-element-latex-fragment-parser)
(org-element-link-parser): Use org-prog-plist to build plist

(org-element-headline-parser, org-element-inlinetask-parser)
(org-element-item-parser, org-element-timestamp-parser): Use
org-let*-prog-plist to build plist

(org-element-radio-target-parser, org-element-statistics-cookie-parser) (org-element-subscript-parser, org-element-superscript-parser) (org-element-table-cell-parser, org-element-target-parser) (org-element-underline-parser, org-element-verbatim-parser): Use
just #'list to build plist

(org-element-comment-block-parser): Fix a typo in docstring.
---
 lisp/org-element.el | 2584 +++
 lisp/org-macs.el|  259 +
 2 files changed, 1421 insertions(+), 1422 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index a693cb68d..e40f881b9 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -691,29 +691,26 @@ Assume point is at the beginning of the block."
 	   (re-search-forward "^[ \t]*#\\+END_CENTER[ \t]*$" limit t)))
 	;; Incomplete block: parse it as a paragraph.
 	(org-element-paragraph-parser limit affiliated)
-  (let ((block-end-line (match-beginning 0)))
-	(let* ((begin (car affiliated))
-	   (post-affiliated (point))
+  (list 'center-block
+	(nconc
+	 (org-prog-plist
+	   block-end-line (match-beginning 0)
+	   :begin (car affiliated)
+	   :post-affiliated (point)
 	   ;; Empty blocks have no contents.
-	   (contents-begin (progn (forward-line)
+	   :contents-begin (progn (forward-line)
   (and (< (point) block-end-line)
-	   (point
-	   (contents-end (and contents-begin block-end-line))
-	   (pos-before-blank (progn (goto-char block-end-line)
-	(forward-line)
-	(point)))
-	   (end (save-excursion
+	   (point)))
+	   :contents-end (and contents-begin block-end-line)
+	   pos-before-blank (progn (goto-char block-end-line)
+   (forward-line)
+   (point))
+	   :end (save-excursion
 		  (skip-chars-forward " \r\t\n" limit)
-		  (if (eobp) (point) (line-beginning-position)
-	  (list 'center-block
-		(nconc
-		 (list :begin begin
-		   :end end
-		   :contents-begin contents-begin
-		   :contents-end contents-end
-		   :post-blank (count-lines pos-before-blank end)
-		   :post-affiliated post-affiliated)
-		 (cdr affiliated
+		  (if (eobp) (point)
+			(line-beginning-position)))
+	   :post-blank (count-lines pos-before-blank end))
+	 (cdr affiliated))
 
 (defun org-element-center-block-interpreter (_ contents)
   "Interpret a center-block element as Org syntax.
@@ -740,32 +737,28 @@ Assume point is at beginning of drawer."
 (if (not (save-excursion (re-search-forward "^[ \t]*:END:[ \t]*$" limit t)))
 	;; Incomplete drawer: parse it as a paragraph.
 	(org-element-paragraph-parser limit affiliated)
-  (save-excursion
-	(let* ((drawer-end-line (match-beginning 0))
-	   (name (progn (looking-at org-drawer-regexp)
-			(match-string-no-properties 1)))
-	   (begin (car affiliated))
-	   (post-affiliated (point))
-	   ;; Empty drawers have no contents.
-	   (contents-begin (progn (forward-line)
-

[PATCH] org-element: Hide parsers boilerplate into plist-creating macros

[akater]

We replace some repetetive code with macro calls org-prog-plist and
org-let*-prog-plist.  The macros are not very conventional but hopefully
their docstrings are illustrative enough.  In effect, all subexpressions
of the form

:begin begin
:end end
:contents-begin contents-begin
:contents-end contents-end

and so on, are removed, together with some let* forms.

Macros expand to code that is essentially the original code, only the
order of key-value pairs in resulting plists is different.

One might argue that it is desirable to have key-value pairs plisted in
specific order, maybe somewhat unified.  A rejoinder: plists are meant
to be order-independent while those who delve into these fairly
low-level plists regularly enough to be bothered by the properties'
order, can be considered org-element experts (voluntary or not); I
believe it is only instructive to an expert to be reminded of the
structure of the algorithm that constructs plist in question, especially
if such algorithms are highly imperative.  That said, I did rearrange
some assignments to make resulting plists look a little prettier.  I
also outlined (but not implemented) a mechanism for (partially)
specifying positions, in comments.

I tested most redefined parsers with new definitions applying them to
one sample object of each kind.  Left untested (as I'm not familiar with
Org markup for the corresponding objects) are

- inlinetask-parser
- diary-sexp-parser
- horizontal-rule-parser
- planning-parser
- entity-parser
- export-snippet-parser
- latex-fragment-parser
- macro-parser
- radio-target-parser
- statistics-cookie-parser
- target-parser

Still, diff shows that only trivial subexpressions, as described above,
are discarded there.  I did check that Org(+contrib) builds with this
patch.

Minor note on org-element-inline-babel-call-parser:
org-element--parse-paired-brackets alters point.  That's why I felt it
would be more appropriate to put the corresponding binding/assignment on
top level of an explicitly imperative macro, rather than keep the
binding in a more localized let form, as extent of the operation is not
localized.



signature.asc
Description: PGP signature
>From d9d108f97917c1b55841df907510bcc89f8db406 Mon Sep 17 00:00:00 2001
From: akater 
Date: Thu, 16 Apr 2020 02:25:59 +
Subject: [PATCH] org-element: Hide parsers boilerplate into plist-creating
 macros

* lisp/org-element.el (org-prog-plist, org-let*-prog-plists) (org-let*-prog-plist): New macros.  Build plists without boilerplate.

(org-fold, org-dekeyword): New functions.  Dependencies for the above.

* lisp/org-element.el (org-element-center-block-parser)
(org-element-drawer-parser, org-element-dynamic-block-parser)
(org-element-footnote-definition-parser)
(org-element-plain-list-parser, org-element-property-drawer-parser)
(org-element-quote-block-parser, org-element-section-parser)
(org-element-special-block-parser, org-element-babel-call-parser)
(org-element-clock-parser, org-element-comment-parser)
(org-element-comment-block-parser, org-element-diary-sexp-parser)
(org-element-example-block-parser, org-element-export-block-parser)
(org-element-fixed-width-parser, org-element-horizontal-rule-parser)
(org-element-keyword-parser, org-element-latex-environment-parser)
(org-element-node-property-parser, org-element-paragraph-parser)
(org-element-planning-parser, org-element-src-block-parser)
(org-element-table-parser, org-element-table-row-parser)
(org-element-verse-block-parser, org-element-entity-parser)
(org-element-footnote-reference-parser, org-element-inline-babel-call-parser)
(org-element-inline-src-block-parser, org-element-latex-fragment-parser)
(org-element-link-parser): Use org-prog-plist to build plist

(org-element-headline-parser, org-element-inlinetask-parser)
(org-element-item-parser, org-element-timestamp-parser): Use
org-let*-prog-plist to build plist

(org-element-radio-target-parser, org-element-statistics-cookie-parser) (org-element-subscript-parser, org-element-superscript-parser) (org-element-table-cell-parser, org-element-target-parser) (org-element-underline-parser, org-element-verbatim-parser): Use
just #'list to build plist

(org-element-comment-block-parser): Fix a typo in docstring.
---
 lisp/org-element.el | 2584 +++
 lisp/org-macs.el|  259 +
 2 files changed, 1421 insertions(+), 1422 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index a693cb68d..e40f881b9 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -691,29 +691,26 @@ Assume point is at the beginning of the block."
 	   (re-search-forward "^[ \t]*#\\+END_CENTER[ \t]*$" limit t)))
 	;; Incomplete block: parse it as a paragraph.
 	(org-element-paragraph-parser limit affiliated)
-  (let ((block-end-line (match-beginning 0)))
-	(let* ((begin (car affiliated))
-	   (post-affiliated (point))
+  (list 'center-block
+	(nconc
+	 (org-prog-plist
+	   block-end-line 

Re: [PATCH] Add support for trace and error output streams in Common Lisp

[akater]

So, the overall plan that I suggest is as follows:

- Merge the patch(es) I sent.  Whether to merge documntation patch or
  not, is left for you to decide.  The text does not lie to users but it
  hints at a feature that is not available yet.  These patches will not
  break anything for anyone unless I get hit by the bus and SLIME gets
  to 2.28 without my submission merged into it.

- Once my pending submission to SLIME (and SLY, if neccessary) is
  accepted,
  
  - update the documentation if it has not been done at the previous step

  - move utilitiy function `org-babel-nsubstitute-multiple' to a more
appropriate file

  - move `require' forms (to the top of ob-lisp.el, or wherever
`org-babel-nsubstitute-multiple' went)

- Once SLIME 2.25--2.27 (the one that lacks the grab-multiple-outputs
  feature) becomes unsupported,
  
  - delete function `org-babel-execute:lisp--legacy'
  
  - rename `org-babel-execute:lisp--multiple-targets-support' to
   `org-babel-execute:lisp'
   
  - remove defalias for `org-babel-execute:lisp'

By the way, I was wrong about something: newline variable in my patch
does not refer to newlines emitted by Lisp, it's newline that Org
inserts into Org buffer.  I generally try to make it easy to allow
consistent usage of non-unix newlines in users' files.  If you are
certain that trying to support this in Emacs is not worth it, I'll
gladly stop doing it.


signature.asc
Description: PGP signature

Re: (almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer

[akater]

stardiviner  writes:

> I have some considering. Multi-block return might will cause other options 
> hard
> to handle the result block. For example ~:cache~, ~:results replace~, and use 
> result
> as source block input data. WDYT?

Probably.  I'm not a user of either :cache or :results replace but
multi-block return, if implemented, will likely require some non-trivial
work to be incorporated smoothly.

Returning just a single block by default will keep it safe for general
users.  But I do find it suspicious when some output is produced and yet
not submitted into the buffer where evaluation results are supposed to
go.  And Org seems to be able to handle this very neatly.

>> while simply hiding empty blocks, if any, for convenience.
>>
>> Note that currently, when “output” is specified, “values” is simply
>> lost, and vice versa. Implementing multi-block results would fix this
>> shortcoming too.
>>
>> However, I did not try to implement this yet.
>>
>> * Conclusion
>> How do we sync with SLIME if you're OK with this? How do we treat the
>> case of vcs Org + stable SLIME?
>
> Might on Org Mode side, add an function to detect SLIME output, or SLIME 
> version
> to make sure ~:results trace~ is usable. If not, warn user to update SLIME. 
> WDYT?

For now, I just delayed activation of the feature in Org until a certain
future SLIME version.  In my SLIME patch, it's handled more subtly,
using supplied-p optional argument, a check that can be dropped once Org
9.3 becomes unsupported.


signature.asc
Description: PGP signature

Re: [PATCH] Add support for trace and error output streams in Common Lisp

[akater]

Bastien  writes:

> Hi,
>
> akater  writes:
>
>> This patch can't be merged right away: I need to sort out the exact
>> SLIME version where the feature will be introduced. Some doc update is
>> needed, too.
>
> did you finally managed to finalize this patch?
>
> If so, can you send it to the list as an attachment?
>
> We are in feature freeze, but small enhancement on ob- and ol- files
> are acceptable if they don't break anything for the user.

Sorry for the delay.  The patch is now safe to apply.  The feature is
set to not activate until SLIME 2.28 which is likely months into the
future.  The reason for this is, I got a blessing from one of SLIME
developers but they've not responded to my PR since; I also need to test
with SLY.  Delaying activation until SLIME 2.28 looks safe enough.

There are some idiosyncrasies: I require elisp features cl-macs, cl-seq,
subr-x in the middle of ob-lispe.el, right before they are needed.  This
is mostly due to state of the patch still being uncertain.  I also
define a variable for a newline emitted by Lisp because I'm always
cautious of non-standard newlines on some platforms.  This might be
totally unnecessary.

Note also that I update the documentation in addition to ob- files.
This comes in a separate patch since the feature mentioned is not really
available yet.


signature.asc
Description: PGP signature
>From 93889d291d8b9539fb6b6950b98394c526cd96ed Mon Sep 17 00:00:00 2001
From: akater 
Date: Fri, 10 Apr 2020 02:52:21 +
Subject: [PATCH 1/2] ob-lisp.el: Add support for trace and error output
 streams

* lisp/ob-lisp.el (org-babel-execute:lisp): Support recent more
structured and featureful output from `swank:eval-and-grab-output'.

* lisp/ob-core.el (org-babel-result-cond): Acknowledge new output options.

* lisp/ob-clojure.el (ob-clojure-eval-with-slime): Support recent more
structured and featureful output from `swank:eval-and-grab-output'.

Trace and error outputs from Common Lisp are now available in
org-babel evaluation with SLIME, starting with some future version of it.
---
 lisp/ob-clojure.el | 24 +++-
 lisp/ob-core.el|  2 +
 lisp/ob-lisp.el| 98 +-
 3 files changed, 121 insertions(+), 3 deletions(-)

diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 299a326e4..da17ec948 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -213,7 +213,7 @@
  (replace-regexp-in-string "nil" "" r))
    result0)))
 
-(defun ob-clojure-eval-with-slime (expanded params)
+(defun ob-clojure-eval-with-slime--legacy (expanded params)
   "Evaluate EXPANDED code block with PARAMS using slime."
   (condition-case nil (require 'slime)
 (user-error "slime not available"))
@@ -224,6 +224,28 @@
,(buffer-substring-no-properties (point-min) (point-max)))
  (cdr (assq :package params)
 
+(defun ob-clojure-eval-with-slime--multiple-targets-support (expanded params)
+  "Evaluate EXPANDED code block with PARAMS using slime."
+  (condition-case nil (require 'slime)
+(user-error "slime not available"))
+  (with-temp-buffer
+(insert expanded)
+(let ((results-alist
+	   (slime-eval
+	`(swank:eval-and-grab-output
+	  ,(buffer-substring-no-properties (point-min) (point-max))
+	  '(common-lisp:*standard-output* common-lisp:values))
+	(cdr (assq :package params)
+  (list
+   (cdr (assoc 'common-lisp:*standard-output* results-alist #'eq))
+   (cdr (assoc 'common-lisp:values results-alist #'eq))
+
+(defalias 'ob-clojure-eval-with-slime
+  (if (and (featurep 'slime)
+   (version< slime-version "2.25"))
+  'ob-clojure-eval-with-slime--legacy
+'ob-clojure-eval-with-slime--multiple-targets-support))
+
 (defun org-babel-execute:clojure (body params)
   "Execute a block of Clojure code with Babel."
   (unless org-babel-clojure-backend
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index e798595bd..9ca3a81a8 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -3070,6 +3070,8 @@ Emacs shutdown."))
 		 (member "pp" ,params)
 		 (member "file" ,params)
 		 (and (or (member "output" ,params)
+			  (member "errors" ,params)
+			  (member "trace"  ,params)
 			  (member "raw",params)
 			  (member "org",params)
 			  (member "drawer" ,params))
diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el
index 8b126b26f..799144d2a 100644
--- a/lisp/ob-lisp.el
+++ b/lisp/ob-lisp.el
@@ -82,10 +82,14 @@ current directory string."
 	(format "(pprint %s)" body)
   body)))
 
-(defun org-babel-execute:lisp (body params)
+(defun org-babel-execute:lisp--legacy (body params)
   "Execute a block of Common Lisp code with Babel.
 BODY is the contents of the block, as a string.  PARAMS is
-a property list contai

Re: [PATCH] org-agenda.el: Complete multiple todo keywords

[akater]

Kyle Meyer  writes:

> Is akater the name you prefer
> listed on that site and in the commit message?

Yes.

I will use git-am complaint patch formatting next time; thank you for
the guidelines.


signature.asc
Description: PGP signature

Self-sufficient Org file with customised export? :eval-when?

[akater]

I'd like to write an Org file that would export to a html with fairly
significant tweaks along the way.  The rough idea is, users should be
able to run reasonaly recent vanilla emacs, (require 'ox),
(org-html-export-to-html) and get a fine-tuned html.

I also would like to move relevant Elisp to the end of the Org file
because the text is going to be read by humans, and people with(out)
certain background apparently faint too often when they see Lisp on top
of a text written in markup.

I put an emacs-lisp src block under the last unexported section, with
header arguments :exports none :results none, but it does not seem to be
evaluated on export.  I couldn't find anything relevant in Info directory.

I know that with vanilla emacs one needs to explicitly allow evaluation
of blocks but that can be considred an acceptable preamble.

It would also be great if exporting such a file would not alter the
state of Emacs session too much (wouldn't pollute hooks or add advices,
for example) but that's low priority.  For now, I just want a
self-contained customisation with minimal hassle for users to get the
export result that was intended.  What are my options?


-


If I may prematurely offer my vision: Common Lisp has special operator
eval-when which specifies when the enclosed code is to be evaluated (or
compiled).  Example:

(eval-when (:compile-toplevel) (defun f () ..))

specifies that function f should be defined during compilation only.

I believe it would be neat if Org-mode widely supported :eval-when
header argument inspired by Common Lisp's eval-when.  Usage examples
would be:

#+begin_src emacs-lisp :eval-when compile load
..
#+end_src

#+begin_src emacs-lisp :eval-when tangle
..
#+end_src

#+begin_src emacs-lisp :eval-when export
..
#+end_src

#+begin_src emacs-lisp :eval-when ()
..
#+end_src

where the last setting would be equivalent to the (now-supported)
:eval never.

In my case, I'd write a block with header arguments

:eval-when export :results none

if this feature was supported.

I'm currently working on a Common Lisp-specific feature that will
introduce :eval-when (it will be offered to a Common Lisp library
literate-lisp) so I'm interested in opinions on this as well.

Re: [PATCH] org-agenda.el: Complete multiple todo keywords

[akater]

Kyle Meyer  writes:

> Thanks for the patch.  Looks like a nice improvement to me.
>
> akater  writes:
>
>> * lisp/org-agenda.el (org-todo-list): Use completing-read-multiple
>> instead of completing-read when selecting todo keywords to filter by
>> in Agenda.
>
> This and the rest of the lines were unwrapped.  Could you wrap them ~70
> characters?  (The Org repo's .dir-locals.el sets fill-column to 70.)

>> * lisp/org-agenda.el (org-todo-list): Fix a typo in the prompt.
>
> Thanks for spotting that typo.  I think it'd be more common to append
> this description to the entry above rather than adding another
> org-todo-list entry.

Done. New patch is attached.

>> There is minor UX cost to Helm users: while candidates list used to
>> appear immediately to Helm users, now Helm users have to hit TAB to
>> see the list.
>
> Just the opinion of one Helm user, but needing to hit tab for crm-based
> completion has never bothered me too much.  But if it did, Helm allows
> specifying that certain commands should go through the built-in
> completion.
>
> Out of curiosity I tried with the latest ivy (9e0803c), and I also
> needed to hit tab before seeing anything.
>
>> This inconsistency is not present in vanilla Emacs
>> completion.
>
> I'm confused by this.  When I try with no customization (Emacs 26.3), I
> need to hit tab to see any of the candidates.

Yes; my point is, in vanilla Emacs completing-read-multiple and
completing-read behave similarly while in Helm, singleton completion
does not require hitting TAB initially but multiple-candidates
completion does.  I remember initially thinking that I broke completion
altogether when I first introduced crm here.  My confusion didn't last
long but still, I found this a little unpleasant and tried my best to
make it go.

> Looks like you stuck with "|" as the separator, which seems like a good
> idea to me.
>
>> However, it is unfortunate that string patterns are strings themselves
>> and are thus indistinguishable from strings; it would be better if crm
>> exposed separator (the string) on its own in its interface.
>
> I'm not quite sure I follow what you're suggesting with the last bit.
> Could you rephrase the point in a way that is a bit more connected with
> the code change?  This patch sticks with the same separator, so aside
> from being able to complete multiple things, there's no change in
> behavior/added restriction here, right?

Well, this likely shouldn't be in the patch either.  I removed it and
it's fine to forget about it.  The rest of the message elaborates on
this.

What type is crm-separator of? According to crm.el, its default value is
that of the constant crm-default-separator which is regex, i.e. a string
pattern.  That means crm-separator is a string pattern.  It is employed
as a string pattern in (the function) completing-read-multiple to clean
some string from unneeded whitespace.

And yet, using string pattern modelled on the default one in my patch
would break things for Helm users (besides the fact that using it would
simply make the code unnecessary cluttered).  If you substitute said
direct equivalent, activate Helm, eval

(let ((crm-separator "[ \t]*\|[ \t]*"))
  (completing-read-multiple "kwds: "
(mapcar #'list '("TODO" "DONE")) nil nil))

, press TAB C-SPC C-SPC RET | TAB C-SPC C-SPC RET, you'll get corrupted
result: TODO,DONE|TODO|DONE.  This is due to the fact that to make Helm
support non-standard crm-separator, Helm developer had to resort to a
fairly ugly hack trying to distinguish between a string pattern and an
actual separator, otherwise results like TODO,DONE|TODO|DONE would
appear in minibuffer.

The gist of the problem is, Helm needs a separator to insert into
buffer, and it now tries do detect whether crm-separator is regex or
not, only uses it as insertion material in the latter case and reverts
to the default comma otherwise.  Detection is based on string length:
https://github.com/emacs-helm/helm/commit/52e1d74f9ec6647c039012626f96596f0eb4140a
which is of course very unreliable.

This might be considered a low-quality decision in Helm but I'd say it
is natural for a user

- of multiple-candidates completion interface (such as Helm)

- that has to transform collections of candidates into strings on its
  own (this would be true for any Emacs application, I guess)

to need both the separator to search for and the separator to
intersperse a string with.

Some collection types, like this collection type “a collection of Org
todo keywords”, come bundled with specific separator-the-string.  It is
this string that I'm using in mapconcat here.  This string is a natural
part of the interface of many collections of candidates, due to
string-orientedness of everything that Emacs has to deal with, but this
sep

[PATCH] org-agenda.el: Complete multiple todo keywords

[akater]

* lisp/org-agenda.el (org-todo-list): Use completing-read-multiple instead of 
completing-read when selecting todo keywords to filter by in Agenda.

* lisp/org-agenda.el (org-todo-list): Fix a typo in the prompt.

There is minor UX cost to Helm users: while candidates list used to appear 
immediately to Helm users, now Helm users have to hit TAB to see the list.  
This inconsistency is not present in vanilla Emacs completion.  The issue had 
been discussed with experienced Helm developer who insisted that current Helm 
behaviour should not change.

We opted to use custom separator that is more natural in context.  However, it 
is unfortunate that string patterns are strings themselves and are thus 
indistinguishable from strings; it would be better if crm exposed separator 
(the string) on its own in its interface.

org-agenda.el: Complete multiple todo keywords

* lisp/org-agenda.el (org-todo-list): Use completing-read-multiple instead of completing-read when selecting todo keywords to filter by in Agenda.

* lisp/org-agenda.el (org-todo-list): Fix a typo in the prompt.

There is minor UX cost to Helm users: while candidates list used to appear immediately to Helm users, now Helm users have to hit TAB to see the list.  This inconsistency is not present in vanilla Emacs completion.  The issue had been discussed with experienced Helm developer who insisted that current Helm behaviour should not change.

We opted to use custom separator that is more natural in context.  However, it is unfortunate that string patterns are strings themselves and are thus indistinguishable from strings; it would be better if crm exposed separator (the string) on its own in its interface.


--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4790,8 +4790,12 @@
 (nth (1- arg) kwds
   (when (equal arg '(4))
 (setq org-select-this-todo-keyword
-  (completing-read "Keyword (or KWD1|K2D2|...): "
-   (mapcar #'list kwds) nil nil)))
+  (mapconcat #'identity
+ (let ((crm-separator "|"))
+   (completing-read-multiple
+"Keyword (or KWD1|KWD2|...): "
+(mapcar #'list kwds) nil nil))
+ "|")))
   (and (equal 0 arg) (setq org-select-this-todo-keyword nil))
   (org-compile-prefix-format 'todo)
   (org-set-sorting-strategy 'todo)

Re: [PATCH] Add support for trace and error output streams in Common Lisp

[akater]

To test the feature, please
- git clone https://gitlab.com/akater/org-mode.git
- checkout ob-lisp-traces-and-errors
- load lisp/ob-lisp.el and lisp/ob-core.el in a running Emacs
- M-: (defalias 'org-babel-execute:lisp 
'org-babel-execute:lisp--multiple-targets-support) RET

and also
- git clone https://github.com/akater/slime.git
- checkout grab-multiple-outputs
- load slime.el

Then start SLIME (this will load patched swank.lisp) and try examples in

https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00137.html

There is a defalias form in the patched ob-lisp.el but it refers to a future 
SLIME version .

One inconsistency with org-element parsers

[akater]

I want to make it easier for users to define custom non-inline blocks
(and operations on them). So I studied parsers in =org-element.el= and
stumbled upon the following seeming inconsistency:

Plists for =comment-block=, =example-block=, =export-block=, =src-block=
all have neither ~:contents-begin~ nor ~:contents-end~ in them, while
plists for =center-block=, =quote-block=, =verse-block= have both.

Parameters ~contents-begin~ and ~contents-end~ are defined almost
everywhere (the only exception is, =src-block= parser never defines
~contents-begin~) but are not returned in plists by four parsers
mentioned.

Should something be done about this? I'm removing some boilerplate from
the parsers and could reuse existing parameters to put them into plists
but I don't understand the semantics yet so won't necessarily be able to
add ~:contents-begin~ to src-blocks. Maybe they are simply unnecessary
in these plists?

[PATCH] Add support for trace and error output streams in Common Lisp

[akater]

This patch can't be merged right away: I need to sort out the exact
SLIME version where the feature will be introduced. Some doc update is
needed, too.

According to orgmode.org, I can link to a public repository and the
branch.
Repository: https://gitlab.com/akater/org-mode
Branch: ob-lisp-traces-and-errors

The patch can be reviewed in web browser:
https://gitlab.com/akater/org-mode/-/commit/e7dbc0b8

URI for all commits, just in case:
https://gitlab.com/akater/org-mode/-/commits/ob-lisp-traces-and-errors

This is a follow-up to the message
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00137.html
Unfortunately, I can't reply to the message directly at the moment.

I mentioned compatibility issue for users who wouldn't update SLIME and
Org simultaneously; this patch resolves the issue for users with new Org
and old SLIME.

(almost a patch) Receiving more output from a Common Lisp evaluation in Org buffer

[akater]

* Summary
I have a patch that allows to put trace output and error output into
corresponding Org buffer. Current behaviour with outputs being splitted
so that they go to different buffers (Org buffer, REPL), is arbitrary
and inconvenient. The patch ensures backwards compatibility. I thus
believe merging the patch would be a clear improvement. I use the
proposed features daily (trace, mostly). Note however that the patch
can't be merged right away; see [[Caveats]].

Contents of output streams not specified in =:results= is always emitted
to REPL buffer.

* Examples
I'll give here some examples of what's possible with the patch applied
that is not possible currently.

** Output of ~time~
#+begin_src lisp :results trace
(time 0)
#+end_src

#+RESULTS:
: Evaluation took:
:   0.000 seconds of real time
:   0.04 seconds of total run time (0.04 user, 0.00 system)
:   100.00% CPU
:   420 processor cycles
:   0 bytes consed
:   

** Traces
#+begin_src lisp :results trace :wrap example lisp
(defun memq (item list) (or (eq item (car list)) (memq item (cdr list
(trace memq)
(memq 'e '(a b c d e f))
#+end_src

#+RESULTS:
#+begin_example lisp
  0: (MEMQ E (B C D E F))
1: (MEMQ E (C D E F))
  2: (MEMQ E (D E F))
3: (MEMQ E (E F))
3: MEMQ returned T
  2: MEMQ returned T
1: MEMQ returned T
  0: MEMQ returned T
#+end_example

** Ignored errors
#+begin_src lisp :results errors :wrap example lisp
(ignore-errors (/ 1 0))
#+end_src

#+RESULTS:
#+begin_example lisp
; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/"))
; (/ 1 0)
; 
; caught STYLE-WARNING:
;   Lisp error during constant folding:
;   arithmetic error DIVISION-BY-ZERO signalled
;   Operation was (/ 1 0).
; 
; compilation unit finished
;   caught 1 STYLE-WARNING condition
#+end_example

** A combo
#+begin_src lisp :results errors trace output :wrap example lisp
(progn (time 0) (ignore-errors (/ 1 0)) (princ "wow"))
#+end_src

#+RESULTS:
#+begin_example lisp
; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/"))
; (/ 1 0)
; 
; caught STYLE-WARNING:
;   Lisp error during constant folding:
;   arithmetic error DIVISION-BY-ZERO signalled
;   Operation was (/ 1 0).
; 
; compilation unit finished
;   caught 1 STYLE-WARNING condition

Evaluation took:
  0.000 seconds of real time
  0.04 seconds of total run time (0.04 user, 0.00 system)
  100.00% CPU
  420 processor cycles
  0 bytes consed
  

wow
#+end_example

* Caveats
This improvement requires a change in SLIME code. One of SLIME
maintaners agreed to merge it but SLIME and Org would need to
synchronise their updates, and I'm not sure how to approach this.

Corresponding patch to SLIME changes the interface of
~swank:eval-and-grab-output~. As implemented,
~swank:eval-and-grab-output~ makes its users choose between values and
output by means of ~car~ and ~cadr~; preserving the compatibility by
extending the current behaviour would make its users refer to various
outputs by their positions which is a very bad idea. I employed alist
instead. However, merging will break =ob-lisp= completely for those who
use vcs Org but a stable SLIME.

The change to SLIME may also affect ~org-babel-execute:clojure~ but I
have no idea why Clojure would use SLIME and whether it actually does
use it. Anyway, I will be able to provide a patch for it that would
ensure backwards compatibility.

* Some Details
** Syntax
At least one function needs to be changed, namely
~org-babel-execute:lisp~.

We preserve the current behaviour, i.e. =:results output= behaves as it
used to. Preserving compatibility requires patching
~org-babel-result-cond~ so that it does not try to vectorise output from
=:result trace=, =:result errors=.

We could avoid this by requiring the =output= parameter all the time, so
that user would have to write something like =:results trace output= or
=:results output trace standard=. While the former is neat, the latter
is not. Also, the notion “error output stream” makes sense not only for
Common Lisp. Thus, adding =trace= and =errors= exceptional cases to
~org-babel-result-cond~ looks acceptable to me.

** (suggestion) Multi-block return
Overall, I believe it would be best to embrace full potential of Org
features and implement multi-block results as default for Common Lisp
evaluation in Org, like in the following example:

#+begin_src lisp
(progn (time 0) (ignore-errors (/ 1 0)) (princ "wow") t)
#+end_src

#+RESULTS:
#+begin_values lisp
T
#+end_values
#+begin_errors lisp
; in: LET ((*DEFAULT-PATHNAME-DEFAULTS* #P"/home/akater/"))
; (/ 1 0)
; 
; caught STYLE-WARNING:
;   Lisp error during constant folding:
;   arithmetic error DIVISION-BY-ZERO signalled
;   Operation was (/ 1 0).
; 
; compilation unit finished
;   caught 1 STYLE-WARNING condition
#+end_errors
#+begin_trace lisp
Evaluation took:
  0.000 seconds of real time
  0.03 seconds of total run time (0.03 user, 0.00 system)
  1

A possible improvement to org todo keywords completion UI

[akater]

I'd like to discuss a possible improvement to org todo keywords completion UI 
but

- it could break something as is

- it still needs some polish, or maybe some of org internals better be
altered

Proposal so far:
#+begin_src diff
--- 
/sudo:portage@localhost:/var/tmp/portage/app-editors/emacs-28.0./work/emacs/lisp/org/org-agenda.el
+++ #>
@@ -4774,8 +4774,11 @@
 (nth (1- arg) kwds
   (when (equal arg '(4))
 (setq org-select-this-todo-keyword
-  (completing-read "Keyword (or KWD1|K2D2|...): "
-   (mapcar #'list kwds) nil nil)))
+  (mapconcat #'identity
+ (completing-read-multiple
+  "Keyword (or KWD1|KWD2|...): "
+  (mapcar #'list kwds) nil nil)
+ "|")))
   (and (equal 0 arg) (setq org-select-this-todo-keyword nil))
   (org-compile-prefix-format 'todo)
   (org-set-sorting-strategy 'todo)
#+end_src

This makes it possible to mark multiple candidates with helm. In what
follows, `crm' means `complete-read-multiple'.

With org-todo-list implemented as it is now, helm user cannot select
multiple todo keywords with helm at all. User has to type keywords
explicitly, togehther with vertical bar separators.

The proposed change makes it possible to do the following C-c a T TAB
 RET and have KWD1,KWD2,...,KWDn
appear in minibuffer.

At this point, user can type another comma, hit TAB again and add more
keywords to the list. Hitting RET without adding anoter comma will
submit the keywords to org-adenga procedure, and the expected Agenda
buffer will be displayed.

There are see several issues however, relevant to inner workings of both
crm and orgmode.

The first three are likely either crm-related or helm-related; I leave
them here so that I can reference to the whole example, with its
context, from other discussions. Skipping them won't prevent you from
being able to reply meaningfully to this message.

- the neccessity to hit the initial TAB to trigger the completion is
somewhat unpleasant: new users likely won't recognise the completion
candidates are there at all. It would be more convenient and less
confusing if candidates appeared immediately.

- it would be natural for crm to allow for arbitrary separator, tailored
to particular callers; in this case it better be vertical bar rather
than comma.

- results entered so far could be safely appended with a trailing
comma. That would make it possible to trigger additional completions
with hitting just TAB each time. One does not need to remove the
trailing separator for the resulting list to be correct, or at least
this is true for org todo keywords. The downside is that the presence of
the trailing separator might confuse users, so that they'd think their
input was still incomplete but (1) I find this unlikely; (2) I guess the
trailing separator could be de-emhasized with a dimmed face (the
downside here, in turn, is that there is no such thing as dimmed face in
console). Trailing separator might also confuse users so that they'd
remove it each time before hitting RET. This is more likely, and I don't
know what to do with this.

orgmode-related questions and issues are:

- could orgmode internals be changed in such a way that this call to
completing-read-multiple could simply return a list and thus we wouldn't
have to rely on some unix-style string passing with explicit characters
as separators, doing it in a civilised manner instead?

- maybe my patch would break something as is?

- reliance on completing-read-multiple will make org-agenda require
Emacs ≥24.4 (or something similar; I'm as precise here as crm help page
is). I suspect it's not an issue but I want to make sure.

I'd like to hear feedback on orgmode-related points, and maybe hints on
where I should discuss the aforementioned crm interface issues: in helm
repository or in some emacs mailing list. Also, it is possible that
those can be mitigated with a patch for `org-agenda.el' that is more
competently made than mine, still providing the intended improvement.

[O] Some whitespace stripped from emacs-lisp value in src blocks making it unreadable in certain cases

[akater]

Consider a lisp form that, when evaluated, produces another form. I'm
used to org printing the resulting form nicely, in lisp blocks. However,
this is not the case for emacs-lisp src blocks. An example:

1. The way it should be (and is now the case) with lisp, namely sbcl:

#+begin_src lisp :results value verbatim :wrap example lisp
(macroexpand '(defun test (a b  c) "doc" nil))
#+end_src

#+RESULTS:
#+begin_example lisp
(PROGN
 (EVAL-WHEN (:COMPILE-TOPLEVEL) (SB-C:%COMPILER-DEFUN 'TEST T NIL NIL))
 (SB-IMPL::%DEFUN 'TEST
  (SB-INT:NAMED-LAMBDA TEST
  (A B  C)
"doc"
(BLOCK TEST NIL
T
#+end_example

2. The way it is now with emacs-lisp and a src block header that is
otherwise identical:

#+begin_src emacs-lisp :results value verbatim :wrap example emacs-lisp
(macroexpand
  '(use-package outline
:ensure nil
:bind
(:map outline-mode-map
  ("" . (lambda nil (interactive) (outline-up-heading 1))
#+end_src

#+RESULTS:
#+begin_example emacs-lisp
(progn (use-package-ensure-elpa 'outline '(nil) 'nil) (defvar 
use-package--warning157 #'(lambda (keyword err) (let ((msg (format "%s/%s: %s" 
'outline keyword (error-message-string err (display-warning 'use-package 
msg :error (condition-case-unless-debug err (progn (if (not (require 
'outline nil t)) (display-warning 'use-package (format "Cannot load %s" 
'outline) :error)) (bind-keys :package outline :map outline-mode-map 
("" lambda nil (interactive) (outline-up-heading 1 (error (funcall 
use-package--warning157 :catch err
#+end_example

Is there a remedy? This probably better be fixed but it could be due to
me using bleeding-edge Emacs 27 master (2019-09-10) & Org from melpa
(2019-09-09). If you don't have proper output formatting with other
versions in use, please report.


signature.asc
Description: PGP signature

Re: [O] [SOLVED] org-20181210 seems to break Column View

[Akater]

Thanks anyway.

My bad, it was due to poly-org package which I had installed
recently. It broke undo in org buffers too.


signature.asc
Description: PGP signature

[O] [Bug?] org-20181210 seems to break Column View

[Akater]

I've been using Column View for quite some time without any
issues. After today's update, C-c C-c on the BEGIN line of the dynamic
block

#+BEGIN: columnview :hlines 1 :id local :maxlevel 3

[...]

#+END:

draws the table close to the very beginning of a buffer, starting at the
11th char, cells determined by forumlas are left empty, the dynamic
block is emptied as well (so e.g. a TBLFM statement is gone).

I'm quite sure it happened in recent hours, as I perform Column View
refresh several times a day.


signature.asc
Description: PGP signature

[O] How do I debug agenda-skip-functions?

[Akater]

To quote the following 2013 message from this mailing list
http://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00841.html

> This is quite strange because I can debug skipping functions
> for tags-todo blocks, but for some reason I cannot debug skipping
> functions for agenda blocks.

I try to debug a skipping function for agenda. debug-on-entry has no
effect. debug-on-entry org-agenda-skip-eval had an effect once but I
can't reproduce it; besides, another message
http://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00854.html
from the same thread reads:

> It would be great except for the following: as soon as I use the
> debugger, my function works as intended.

so I won't feel confident I won't be hit by the same bug.

How do you debug agenda skip functions?


signature.asc
Description: PGP signature

Re: [O] Feature suggestion and code review request: org-babel-cycle-src-block-header

[Akater]

Thank you, I'll make use of 's. Not well versed in Elisp
libraries. save-excursion is certainly an improvement, too.


signature.asc
Description: PGP signature

Re: [O] superscript footnote number underlined?

[Akater]

Sharon Kimble  writes:

> How can I have the footnote number in an org-mode file, exported to
> latex and then built as a PDF file, be underlined please?

Try adding the following LaTeX directive.

#+latex_header: \renewcommand{\thefootnote}{\underline{\arabic{footnote}}}

Note: both footnote number in text and in the footnote itself will be
underlined.


signature.asc
Description: PGP signature

Re: [O] superscript footnote number underlined?

[Akater]

Sharon Kimble  writes:

> How can I have the footnote number in an org-mode file, exported to
> latex and then built as a PDF file, be underlined please?

Try adding the following LaTeX directive:

#+latex_header: \renewcommand{\thefootnote}{\underline{\arabic{footnote}}}

Note: both footnote number in text and in the footnote itself will be
underlined.


signature.asc
Description: PGP signature

[O] Feature suggestion and code review request: org-babel-cycle-src-block-header

[Akater]

insert new-header-string)
(unless we-were-before-replacement-zone
  (incf default-position-to-return-to (length new-header-string)))
(goto-char (if (<= fallback-position
   default-position-to-return-to
   (+ fallback-position (length new-header-string)))
   fallback-position
 default-position-to-return-to)

;; example for mailing list
;; Common Lisp assumed!
(defun akater/org-babel-cycle-header nil
  (interactive)  
  (org-babel-cycle-src-block-header-string
   '("lisp :tangle no :results none"   ;; type 2 above
 "lisp :tangle yes :results none"  ;; type 3 above
 "lisp :results type verbatim" ;; type 1 above
 )))
#+end_src

Ideally, I envision something along these lines (some specific choices
below don't really make sense):
#+begin_src emacs-lisp
(defcustom org-babel-standard-header-sequences-alist
  '((development-setup-1
 (lisp
  (((:tangle . "no") 
(:results . "none"))
   ((:tangle . "yes") 
(:results . "none"))
   ((:results . "type verbatim"
 (python
  (((:tangle . "no") 
(:results . "none"))
   ((:tangle . "yes") 
(:results . "none"))
   ((:results . "type output"
 )
(development-setup-2
 (C
  (((:tangle . "no") 
(:results . "none"))
   ((:tangle . "yes") 
(:results . "raw"
 (julia
  (((:tangle . "no") 
(:results . "none"))
   ((:tangle . "yes") 
(:results . "none")))
#+end_src


signature.asc
Description: PGP signature

Re: [O] Trivial bug in ox-latex

[Akater]

Nicolas Goaziou  writes:

>> When depth is -1, wholenump form evaluates to nil, and setcounter
>> command is not exported at all.
>
> I don't think it's a bug. Org doesn't pretend to support every LaTeX
> feature. Setting `org-export-with-toc', which is where DEPTH comes from,
> to -1 doesn't make much sense in an Org context, does it?

I can't answer this as I do not deal with org-export-with-toc
directly. I was setting tocdepth via
org-export-filter-options-functions, specialized explicitly to latex
backend:

#+begin_src emacs-lisp
(defun my-consistent-toc (plist backend)
  (cond 
((equal backend 'latex) 
 (plist-put plist :with-toc -1))
 ;; other backend-specific settings
  )
  plist)
(add-to-list 'org-export-filter-options-functions 'my-consistent-toc)
#+end_src

I was able to achieve the desired outcome with
#+LATEX_HEADER: \setcounter{tocdepth}{-1}

If this is not considered a bug, fine then. However, this is confusing
behaviour at best, and given the rich functionality of filter-options
and friends, I don't see why it should silently fail here.

Lots of possible settings don't make sense. In my most humble opinion,
this sort of ad hoc type-checking—preventing valid document to be
produced without any notice—doesn't feel like it fits a dynamic Lisp, or
Org-mode.


signature.asc
Description: PGP signature

[O] Trivial bug in ox-latex

[Akater]

The following snippet in ox-latex.el processes negative tocdepths
incorrectly:

#+begin_src emacs-lisp
;; Table of contents.
(let ((depth (plist-get info :with-toc)))
  (when depth
(concat (when (wholenump depth)
  (format "\\setcounter{tocdepth}{%d}\n" depth))
(plist-get info :latex-toc-command
#+end_src

When depth is -1, wholenump form evaluates to nil, and setcounter command is 
not exported at all.

See, e.g.
https://en.wikibooks.org/wiki/LaTeX/Document_Structure#Sectioning_commands
for example of a negative level use.


signature.asc
Description: PGP signature

Re: [O] How can I obtain Org via HTTPS?

[Akater]

On a related note, I'd love to use org-plus-contrib packages but there's
no https update, and I still don't understand how to check whether
packages are signed, w/ which keys, where the keys are published.
Maybe I didn't do everything I could but all the other updates on my
system have been far more transparent in that regard---even if unsigned,
I'm at least aware of this, and if signed, I know which key they are
signed with, and the key is in the keyring.


signature.asc
Description: PGP signature

Re: [O] Do not inherit unnumbered property: help needed

[Akater]

On November 18, 2017 5:18:10 PM GMT+00:00, Nicolas Goaziou 
 wrote:
> I suggest to write a parse tree filter that does that
>change to the tree.
>
I got an impression that UNNUMBERED's children get cut off prior to what user 
can do, hence writing a simple backend won't help, and I'll have to patch org 
(ox) source. Do you know for sure I'm wrong? That's what I asked for 
originally---which function is responsible for excluding unnumbered's children 
from exported entries.



signature.asc
Description: PGP signature

Re: [O] Do not inherit unnumbered property: help needed

[Akater]

On November 18, 2017 5:18:10 PM GMT+00:00, Nicolas Goaziou 
>I see. I don't think UNNUMBERED should be able to modify the structure
>of the document. I suggest to write a parse tree filter that does that
>change to the tree.
>
>Regards,

Please note: it is not UNNUMBERED that modifies the structure in my suggestion 
but rather SKIP-OUTLINE-LEVEL.



signature.asc
Description: PGP signature

Re: [O] Do not inherit unnumbered property: help needed

[Akater]

On November 17, 2017 10:09:55 PM GMT+00:00, Nicolas Goaziou 
 wrote:
>
>OOC, what is the output you expect from your initial example?
>

in LaTeX:

* section-one
blah
* unnumbered-header
:PROPERTIES:
:UNNUMBERED:
:SKIP-OUTLINE-LEVEL:
:END:
** section-two
blah
** section-three
blah
* section-four
blah

should export as

\section{section-one}
blah
\section*{unnumbered-header}
\section{section-two}
blah
\section{section-three}
blah
\section{section-four}
blah

I agree, this is structurally incorrect but will look ok, or can be made look 
ok.
This is the first time I post to mailing list from K9-mail, hopefully it goes 
to proper thread, sorry if doesn't.


signature.asc
Description: PGP signature

Re: [O] Do not inherit unnumbered property: help needed

[Akater]

Kaushal Modi  writes:

> Have you looked at org-use-property-inheritance variable
> http://orgmode.org/manual/Property-inheritance.html -- You can set that to
> a regexp that does not match UNNUMBERED.

As this page mentions, default value is nil, which means nothing would be
inherited. UNNUMBERED does not follow this rule, even though it is not
mentioned as one “for which inheritance is hard-coded” in the manual ---
as was announced in org-news,
> *** Export unnumbered headlines

> Headlines, for which the property ~UNNUMBERED~ is non-nil, are now
> exported without section numbers irrespective of their levels.  The
> property is inherited by children.
http://orgmode.org/cgit.cgi/org-mode.git/plain/etc/ORG-NEWS

See also
Org Manual > Exporting > Export Settings
which also mentions
> Set `UNNUMBERED' property to non-`nil' to disable
>  numbering of heading and subheadings entirely.
Not a single word in the manual, or in worg, on disabling this
particular kind of inheritance.

After evaluating
(setq org-use-property-inheritance "[^\\(UNNUMBERED\\)]")
children are still exported numbered. org-reload has no additional
effect. I use Org 9.1.3 (20171116 from melpa) and Emacs 25.3.1.

In case UNNUMBERED's inheritance could be turned off by a standard
procedure, my other points are meaningless. So let's first figure out if
it could.


signature.asc
Description: PGP signature

[O] Do not inherit unnumbered property: help needed

[Akater]

I have to deal with a document that has an unfortunate vague structure
which involves unnumbered headlines spanning a couple of numbered
ones. I'd like to convert the document into Org and thus effectively
need to implement a feature that would allow unnumbered property in Org
not to be inherited by children of unnumbered items in some cases.

Say, in the following toy example

#+BEGIN_SRC org
* section-one-title
blah
* the first two prime-numbered sections (duh)
:properties:
:ignore-this-outline-level: t
:unnumbered: t
:end:
** section-two-title
blah
** section-three-title
blah
* section-four-title
blah
#+END_SRC

section-three and section-four would be treated as being on the same
level as other section-x's, their children treated correspondingly.

For exporting needs, I chose to format the unnumbered headline the
same style as section-x's, only unnumbered, and have section-two and
section-three be numbered as if the unnumbered headline didn't
exist.

First,
I need to mark (?) parts of the parse tree that are children of
the unnumbered item, and are not explicitly marked unnumbered
themselves, as exportable when being passed to
org-export--collect-headline-numbering.

This is where I ask for help, as it's not clear to me how to do that.
My hypothesis so far was that org-export--prune-tree from ox.el filters
out unnumbered items but my attempts with debug-on-entry did not confirm
this. Could someone help?

Re: (?) maybe children are never marked as exportable in the first place
and the tree just does not get traversd too deep. Again, I don't yet see
which function is to be patched to let them through.

Second,
I will also need to redefine specialized functions like
org-html-section, turning
org-export-get-headline-number
into
org-export-get-deepest-numbered-parent-headline-number
and so on, but this doesn't seem to be difficult. However, if I'm
missing something and you think this could be a valuable feature, you
are welcome to share your thoughts. I'm not an experienced programmer
but hopefully I can implement this and contribute.
n(Will sign anything FSF if needed.)

I admit that the whole idea to add this to Org is questionable, and
documents structured like this better be restructured altogether. It is
likely that exported versions for some backends are not going to be
structured properly. (As far as I can see, Texinfo looks particularly
unpromising.)

Nevertheless, it is possible to at least make exported versions /look/
ok and describe possible backend-related caveats in the documentation.
I find it reasonable to keep org files structured properly, while
considering exported versions to be more of an eye candy. In my case,
the document in question is an archive entry which cannot be changed
retrospectively but me and my colleagues could still benefit from it
being tidily marked up.


signature.asc
Description: PGP signature