lucasvreis / org-mode-hs Goto Github PK

It's not clear to me what the behavior should be, given that Org mode itself seems confusing when exporting cross references to HTML.

For instance, Org will substitute links to internal references with a counter for most elements, but with \eqref for equations. We shouldn't do that since it's dependent on export. The Id of InternalTarget should be used for \eqref or something else on export. Still proper numbering for equations is too complicated. For other elements you can reference anything with #+name but this counter is only updated in the presence of #+caption. I will have to figure out how numbering for <<targets>> works.

Hi @lucasvreis, to be honest, I coudn't figure out in a decent amount of time how to implement a function like:

f :: OrgDocument -> IO LByteString
f :: OrgObject -> IO LByteString

I guess it's something with renderNodeOrError but I'm not good with monad transformation and I also don't understand how to get an OrgDocument/OrgObject to a OndimNode.

Could you give me a hint?

Use https://github.com/EmaApps/ema + the ema-org https://github.com/lucasvreis/organon library for a simple "live preview" command.

I tried the commands in the Installation from source and get this on the cabal install step:

fatal: Could not parse object '5fef2d328b5c15b9feec7ca0dd71d2d403c39941'.

Same error when I cd into org-parser and try cabal build.

Looks like it comes from an outdated commit in the cabal.project file:

source-repository-package
  type: git
  location: https://github.com/lucasvreis/unionmount.git
  tag: 5fef2d328b5c15b9feec7ca0dd71d2d403c39941

What's the best way to resolve this? Just use the latest commit from the unionmount repo?

After doing that I get some dependency errors including lvar and base.

Annotate the character position of elements and objects in the AST (like Org does). I'm constantly reminded of this since I think this would be extremely useful. Some applications:

• Paragraph-accurate "synctex" in organon (perhaps even split AST into words like pandoc does)
• Support for org-remark (marginalia) annotations via the templates
• Support for Org line-number links (not a priority, I don't like this sort of link)

Just a questions, is there a simple way to export the org AST or even just OrgObject to any human readable format (like org, markdown, html) without org-exporters and ondim?

Because the project I'm using your library relies on GHC 9.6 and ondim doesn't seem to compile there.

ondim> /tmp/stack-432982cf9e5df8dc/ondim-0.1.0.0/src/Ondim/Loading.hs:87:27: error: [GHC-83865]
ondim>     • Couldn't match type: (FilePath, Maybe FilePath)
ondim>                      with: [Char]
ondim>       Expected: [GHC.IsList.Item (Set ((Int, FilePath), FilePath))]
ondim>         Actual: [((Int, FilePath), (FilePath, Maybe FilePath))]
ondim>     • In the first argument of ‘fromList’, namely
ondim>         ‘(zip (zip [1 .. ] (fst <$> places)) places)’
ondim>       In the expression:
ondim>         fromList (zip (zip [1 .. ] (fst <$> places)) places)
ondim>       In an equation for ‘sources’:
ondim>           sources = fromList (zip (zip [1 .. ] (fst <$> places)) places)
ondim>    |
ondim> 87 |   let sources = fromList (zip (zip [1 ..] (fst <$> places)) places)

Basically do this:
https://orgmode.org/manual/Property-Syntax.html

It should be fairly simple to parse Org export blocks as templates to be interpreted by Ondim.

To separate them from ordinary blocks they could use custom languages like ondim-html and ondim-pandoc, this way they won't interfere with emacs' org exporters either.

Edit: perhaps it's better to use source blocks with :exports none attribute, with the advantage that org-mode would do syntax highlighting by default and we could use custom attributes.

Pandoc is considering adapting its types to be polymorphic over Inline and Block (jgm/pandoc-types#99, jgm/pandoc-types#98). This is very interesting as it may allow other libraries to extend the Pandoc AST. It would be nice if org-parser could drop part of its AST and use an extended version of Pandoc. That would contribute to a more unified package ecosystem and facilitate conversion between the libraries.

Unfortunately, I think most types & constructors in Org.Types would have to remain anyway, or be turned into patterns, else we lose the "org-element alikeness and expressivity".

One interesting example is uniorg in the context of unified. I will have a look at how uniorg reuses the types of unified, but JS is much more flexible in this aspect.

With #6, this is becoming more than just a parser. org-mode and orgmode and already taken in Hackage. Some ideas:

• org-hs
• Just org?
• Leave it as it is :(

https://github.com/lucasvreis/org-parser/blob/master/SPEC.org#export-snippets

The described problem should be resolved in https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=96529e933b445dce52e4e904695f1d538c3e0e7f

The provided example is not an @html export snippet because snippet is an object and cannot span over multiple paragraph elements.

Hi! I'm trying to build the library by following the instructions in the README.

Version information:

➤ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.7

➤ cabal --version
cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library

Installed via ghcup on Arch Linux. These are the errors I get:

Errors

When first compiling, an error appears in org-exporter/src/Org/Exporters/Pandoc.hs. To try to resolve this I just commented out the line.

src/Org/Exporters/Pandoc.hs:30:16: error:
    Not in scope: data constructor ‘P.Null’
    Perhaps you meant ‘P.Cell’ (imported from Text.Pandoc.Definition)
    Module ‘Text.Pandoc.Definition’ does not export ‘Null’.
   |
30 |       nullEl = P.Null
   |                ^^^^^^
Error: cabal: Failed to build org-exporters-0.1 (which is required by exe:horg

then after commenting out the offending line, the issue seems to be taken care of, but another error appears in org-cli:

app/org-cli.hs:81:40: error:
    • Couldn't match expected type ‘Text.Pandoc.Format.FlavoredFormat’
                  with actual type ‘Text’
    • In the first argument of ‘TP.getWriter’, namely ‘fmt’
      In a stmt of a 'do' block: (w, ext) <- TP.getWriter fmt
      In the first argument of ‘TP.runIOorExplode’, namely
        ‘do (w, ext) <- TP.getWriter fmt
            tpl <- TP.compileDefaultTemplate fmt
            utpl <- case tplo of
                      Nothing -> pure Nothing
                      Just tfp -> do ...
            let tpl' = fromMaybe tpl utpl
                wopt = ...
            ....’
   |
81 |               (w, ext) <- TP.getWriter fmt
   |                                        ^^^

The problem seems to be related to pandoc in both cases. If there's any other information you need then please let me know!

Move them to a new module, Transforms, and keep them modular. What can be done outside the parser should be detached.

The list includes:

• #11
• orgStateMacros
• orgStateInternalTargets
• orgStateKnownAnchors
• processSpecialStrings
• documentFootnotes, orgStateFootnotes: remove the field from OrgDocument
• orgStateKeywords, documentKeywords: remove the field too
• orgStateExcludeTags, orgStateExcludeTagsChanged
• orgStateSrcLineNumber