Use new org-parser, remove Pandoc dependency and update ema

[luavreis]

The org-parser library is WIP and is available here: https://gitlab.com/lucasvreis/org-parser. I will move it to github once it's finished.

[srid]

Your org-parser is interesting. What do you think of the similar https://github.com/fosskers/org-mode ?

[luavreis]

@srid I am aware of it, but last time I checked it was less accurate and overall less feature complete than Pandoc's. It seems more focused on task management (so it parses things like timestamps and agenda stuff that pandoc doesn't).

org-parser is being based on the draft of the Org syntax you can find here: https://orgmode.org/worg/dev/org-syntax-edited.html, and also on the very tested pandoc parser. The overall structure of the code is similar to pandoc, and it has similar tooling like Walk and citeproc... and looking at the support table in fossker's org-mode it seems that mine already parses more things now.

[luavreis]

Oops! Apparently GitHub automatically closes pull requests with different histories. I'm now rewriting the whole thing and also using the multisite Ema branch. @srid I'm finally testing it, and it's awesome!! It will take a while to finish the port, though.

[srid]

@lucasvreis It is nice to see https://github.com/srid/ema/pull/81 already being used. :-) I think that PR's API has become stable enough; mostly what's left is to improve on generics deriving ergonomics and then documentation.

HeistSite looks to be pretty neat. I should use some of your ideas ...

https://github.com/lucasvreis/abacateiro/blob/e6760e78803e6bacb33a5c50ad176b01f4529977/src/Render.hs#L60-L85

[srid]

I need to take a deeper look, but one thing that is not clear to me is why you are storing HeistState in SiteArg instead of directly in RouteModel. An LVar is also not strictly required if the heist state is stored directly in the model (Ema uses it internally, so the user doesn't have to).

I added SiteArg mainly to be able to pass things from the environment, like CLI arguments or 'settings'. The intuition behind EmaSite is that it is more like a function (pipeline) than a mere typeclass:

[world] --> SiteArg --> siteInput --> Dynamic model --[R, model]--> siteOutput --> [site]

EDIT: The whole watchDir should normally be inside siteInput, which would avoid having to use an LVar and store it in SiteArg. See https://github.com/srid/ema/blob/53bd5bfeeac56a4cb363a2bb7ba82f5e5c0bdd77/src/Ema/Example/Ex03_Store.hs#L100

[luavreis]

Thanks! I'm very new to Haskell (started messing with it in ~August last year) so don't take what I write very seriously. My motivation for using SiteArg there is because I wanted to have only a single process watching the Heist template folder for changes when I compose multiple sites, and the subsites get notified of changes and update their WithHeist models. But this is what my non-CS mind thought was "right", I have no idea if it makes more sense to have each subsite watch the template folder on their on. And I'm also considering not watching the template folder anyway. You suggest having each site watch the folder, right? (let me figure out what emanote does...)

[srid]

Can you point out where multiple sites are used in your org-parser branch? As far as I can tell there is only one route (thus one site). The main entry is also running one site.

I wanted to have only a single process watching the Heist template folder for changes when I compose multiple sites

Yea, this is a legit use case in general. One that I've come across on my private site as well. There, I had two sub-sites wanting to monitor the same directory (but different file patterns); and it was sub-optimal to run fsnotify twice when you can do it once, and share it with sub-sites. I haven't solved that problem, yet. More generally the question becomes: how can one site's model use another site's model? I need to think about this more.

Considering all these use cases are helpful in coming up with a good design for Ema 1.0. If you have any specific thoughts let me know. Your SiteArg trick is one possible solution to this problem; I'll have to play with it more.

[srid]

If the composition is done using a top-level route (as opposed to using MultiRoute), then doing it in Applicative lift would be another way (unless I'm missing something here):

https://github.com/srid/ema/blob/10dbf098263ef8df642de114abbc04752aaa0416/src/Ema/Example/Ex04_Multi.hs#L44-L46

(Though the composition becomes no longer polymorphic, as you have to use the model update functions manually on the second model)

[luavreis]

Can you point out where multiple sites are used in your org-parser branch? As far as I can tell there is only one route (thus one site). The main entry is also running one site.

No multiple sites in the branch yet, just my first experiment from yesterday afternoon :) but the plan is to allow using multiple org-roam folders if one wants to.