[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: akater
Subject: [PATCH] org-element: Hide parsers boilerplate into plist-creating macros
Date: Tue, 08 Sep 2020 17:19:16 +0000

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

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

Attachment: signature.asc
Description: PGP signature

Attachment: 0001-org-element-Hide-parsers-boilerplate-into-plist-crea.patch
Description: Hide boilerplate in org-element.el

reply via email to

[Prev in Thread] Current Thread [Next in Thread]