Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite orgparser.py with a proper parser for Org-mode syntax #63

Open
2 tasks
novoid opened this issue Dec 21, 2021 · 5 comments
Open
2 tasks

Rewrite orgparser.py with a proper parser for Org-mode syntax #63

novoid opened this issue Dec 21, 2021 · 5 comments

Comments

@novoid
Copy link
Owner

novoid commented Dec 21, 2021

The initial and current parser is a naïve linear parser. It comes with some drawbacks:

  • A mandatory empty line between two different syntax elements.
  • A finite list of Org elements with a fall-back using Pandoc as a workaround (which works quite well).
  • Several (edge-cases of the) syntax elements are not handled properly like italic, URL detection, ...

With switching to a really good Org-mode (orgdown?) parser, the lazyblorg syntax possibilities as well as the maintenance could be improved.

  • Identify a proper Python parser that offers advantages over the current situation.
  • Find a way of including the many lazyblorg-specific search&replace features: tsfile-links, internal links, ...
@xeruf
Copy link
Contributor

xeruf commented Nov 21, 2022

If I understand it correctly the current parser is there to allow running some syntax-bound features.
Why not separate these functions from the export, i.e. run them first and then simply use native org mode html export?

@novoid
Copy link
Owner Author

novoid commented Nov 21, 2022

If I understand it correctly the current parser is there to allow running some syntax-bound features.

The current parser parses some lazyblorg-specific things such as support for tsfile links and so forth, yes.

Why not separate these functions from the export, i.e. run them first and then simply use native org mode html export?

Which export? There is not export involved yet. So you must have a totally different workflow in mind which I can not follow.

You suggest to use "native org mode html export". I guess you would assume to use the Elisp functionality to export single orgdown headings to separate HTML files, right? If so, this would require massive pre- (tsfile links, ...) and postprocessing (side-bar, header, footer, ...) steps as well as an efficient way of using Emacs functionality which I don't see at this point. The whole templating mechanism and all of its built-in features would not work any more.

This would most probably require the whole lazyblorg functionality moved to Elisp which is a total new rewrite which I can not accomplish due to lack of Elisp and lack of time/motivation to do so. Unfortunately, lazyblorg works perfectly fine for my now.

@xeruf
Copy link
Contributor

xeruf commented Nov 21, 2022

One can call elisp from the CLI, and I thought it is possible to add HTML templates in for export.
I was just thinking that with this lots of idiosyncracies like missing italics and required empty lines could be fixed though native emacs functionality.

@novoid
Copy link
Owner Author

novoid commented Nov 22, 2022

One can call elisp from the CLI, and I thought it is possible to add HTML templates in for export.

That's possible, yes. In my opinion only with a completely rewrite in Elisp because hundreds or thousands of Emacs invocations most certainly does not scale at all for re-building a blog. You don't have to forget that lazyblorg re-generates everyting with each invocation. It's not just build the new articles. Any new article can have massive influence on all the others such as "most frequently used tags", links, and so forth.

I was just thinking that with this lots of idiosyncracies like missing italics and required empty lines could be fixed though native emacs functionality.

It works for me without italics. Certainly good enough for not changing the architecture of the parser for it.

Although replacing the naïve parser with a "proper" one would have lots of advantages, the current one does the job with the current known limitations which is OK to me. The only thing that could happen to make me think of going into that direction is a proven OrgDown Python parser from the community so that lazyblorg is pushing the idea of OD.

@xeruf
Copy link
Contributor

xeruf commented Dec 2, 2022

See also #2

I am all for pushing OD, btw :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants