Organon
Known Issues 😳
- Putting
id
attributes on backlink elements don’t work consistently. For instance, plain list items are not wrapped by an element. Perhaps I should add aTarget
inline element to the AST instead, and rework the backlink preview functionality to be more similar to what it was before (without fancy buggy portals). - Portal stuff is terrible and should probably be ditched altogether. Transclusion can probably work via
walk.query
expansions. - Attachment figures do not get recognized as figures. Related to AST Annotations.
- Anchor links to the same file but to a part with a different ID do not work.
-
organon-follow-mode
gets confused with headings with the same title.
Editor integration
Robust page following
Observations:
- Since headings already have anchors, it’s easy to use AST annotations to reimplement the current following feature but without the issue when there are headings with the same title.
-
Element-wise following requires some thinking, but it should end with something more robust.
Idea: if the start position is stored in AST and
Sync heading folds
Custom metadata
Use ondim? pageExp
could be available inside it, could be used to store stuff like todo states!
Precise backlinks
Basically: heading-level, element-level and inline-level backlinks.
We already store all the necessary information to provide this.
Also: more general forms of backlinks. For instance, timestamps and citations should be considered links.
Just a note, only forward links are stored, and this really what we should store. Backlinks are then queried from the DB via the links-to
thing.
Metadata files
Generated pages
Pages generated by metadata queries.
Cli
Cache the rendering functions
CLI command to clear cache
Runs the generator once without writing output, clear what is not used.
Querying
If done right, querying can generalize a bunch of patterns you find in a static site. For instance, creating a list of posts with a given tag or creating a list of tags.
[0/1]
Syntax
[0/1]
Syntax
The basic idea here is using affiliated keywords, more specifically backend key/value pairs, and bind expansions providing the query results in the context of its children.
[0/1]
Keyword querying with :wrapped
[0/1]
Keyword querying with :wrapped
Parse org key-value pairs
Org-formatted queries
We could even have a pure Org preprocessor
syntax (note: in fact, the
expansion would happen during rendering inside Ondim
).
This would require more changes to org-hs
:
- Expansion syntax for objects (and perhaps elements), e.g. using
{{{macros}}}
for inlines (and something else for elements).
Creating tables:
#+attr_query: :from notes :where (in "games" tags)
| Name | Time Played | Length | Rating |
|---------------+-----------------------+------------------+------------------|
| {{{q:title}}} | {{{q:m:time-played}}} | {{{q:m:length}}} | {{{q:m:rating}}} |
Or a list:
#+attr_query: :from notes :where (in "games" tags) :where (or (in "moba" tags) (in "crpg" tags))
- {{{note:link}}}
In principle, the output of all examples above could be generated in Org
beforehand with lisp, by using src
blocks. But the advantage here is that they
are updated automatically every time the page renders.
\mathrm{\LaTeX} support
Parallel compilation
- Note taken on
This will likely be superseded by the parallel map expansion I plan to put on Organon per se.
The way things are set up now , the \LaTeX rendering is done during the document rendering (from Org AST to HTML, via Ondim). This has some advantages:
- There is no need to encode the output in the AST, which can be limiting — as a result, it is easy to customize how the figure is laid out in HTML via templates;
- It fits better in the
expansion \iff plugin
metaphor I’m aiming for Organon; - Fragments are rendered lazily, just before they are shown in the browser page;
- It is more general in that it could more easily be made to work with input types other than Org AST.
But doing so introduced a performance problem, namely that Ondim rendering is not easily paralellizable because the monad carries a state. The proper way to reimplement that is via what I would call a session expansion
.
Session expansions
The basic idea is: we have a organon:latex-session
expansion which binds organon:render-latex
inside.