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

Support lists #13

Open
jjlee opened this issue Oct 13, 2019 · 4 comments
Open

Support lists #13

jjlee opened this issue Oct 13, 2019 · 4 comments

Comments

@jjlee
Copy link
Contributor

jjlee commented Oct 13, 2019

Thanks for your recent work on orgparse, it looks promising.

It would be great if orgparse supported lists like this:

- one
- two
- three

I was able to port my code over from org-export-json to orgparse by parsing out the items from node.body myself, but I probably did a bad job of it, and that's exactly the sort of core org syntax thing that I'd love to be able to rely on orgparse for.

@karlicoss
Copy link
Owner

related: #12
I'll think about it over the weekend!

@neilyio
Copy link

neilyio commented Dec 1, 2019

I second this! I often use orgmode un-ordered lists to take quick notes below a heading. Trying now to load these through orgparse, and I'm going to have to manually split them on newlines.

Great work on the package so far, I hope it can keep growing.

@MorphicResonance
Copy link

Lists support would be great. It is low level structural thing of org body/drawer. By the way extracting of user drawers would be great also.

@buhtz
Copy link
Contributor

buhtz commented Apr 27, 2022

Mhm... While developing hyperorg using orgparse I understand orgparse not as a parser for org content. For me it is more a parser for metadata in org-files (e.g. the PROPERTIES section and the subtree structure, the filename).

I am not involved in the development of orgparse but I wonder if it would be a good idea to implement parsing of org content like paragraphs, lists, links, tables, etc. Maybe this is to much and would bind to much ressources in developing and maintaining. Maybe it would be a better idea to separate such a content parser into its own project and take care of good interoperability between that project and orgparse.

Currently I parse such (but currently not all) org-content-elements myself within my hyperorg project.

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

5 participants