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

Can’t parse trivial .org file #68

Open
tokuchan opened this issue Aug 17, 2019 · 11 comments
Open

Can’t parse trivial .org file #68

tokuchan opened this issue Aug 17, 2019 · 11 comments

Comments

@tokuchan
Copy link

I created a file with a single word, “foo” in it, named foo.org. When I attempted to access it with orgweb I was told it couldn’t parse.

@tokuchan
Copy link
Author

I just tried it with an empty file, same result.

@munen
Copy link
Contributor

munen commented Aug 17, 2019

@tokuchan I have done a little work on the parser, so I can tell you from memory what's the issue. What's "trivial" and what is not is itself not trivial^^

org-web expects a file to start with either these keywords #+TODO, #+TYP_TODO or with a header (indicated by a *).

I have opened a separete issue two weeks ago that's going in a similar direction: #55

@tokuchan
Copy link
Author

tokuchan commented Aug 18, 2019 via email

@munen
Copy link
Contributor

munen commented Aug 18, 2019 via email

@DanielDe
Copy link
Owner

Hey @tokuchan, thanks for the report! org-web was largely built around my own particular use cases, which is one monolithic org file. Adding support for creating new files has been a rather commonly requested feature, however. Is that your use case here?

@andersjohansson
Copy link
Contributor

As I mentioned in #71, org allows content before the first headline, so opening such a file should ideally be supported by org-web. I think many people stumble on the complex syntax of org, which has no real formal definition except the elisp-implementation (even though this "draft" page on worg seems to document it well).
Many people have attempted to write more or less complete parsers as well, for example: https://www.reddit.com/r/orgmode/comments/7wjmwr/orga_the_ultimate_orgmode_parser_in_javascript/

Would there be a point of using something like this in org-web? Otherwise I guess it’s a quite pragmatic solution to parse the basics, and then allow free-text editing of other things in the sections. In my understanding, org-web isn’t supposed to enable all org mode workflows, but is mainly aimed towards the planning functionality.

@DanielDe
Copy link
Owner

I looked into that parser but had already done so much work on my own by that point that I opted not to use it. One day it might make sense to swap it in, though.

My philosophy behind org-web has always been a sort of progressive enhancement. That is, I've wanted to allow editing the raw headers as plain text, but progressively over time support more org features natively (like TODOs, checklists, timestamps, etc). I think I just missed this case of allowing text before a header like this.

@alanbernstein
Copy link

I noticed that text content before the first * section (valid org-mode content, as far as I know) is not available in the web app. It looks like that is a subset of this issue, is that right?

@DanielDe
Copy link
Owner

Ah, yep, that is probably contained in this issue. I didn't realize you could put valid org-mode content before the first header.

@tokuchan
Copy link
Author

Definitely! After all, one has to be able to define things like properties and todo keywords. Speaking of which, how much work would it take to become able to parse custom todo keywords?

@DanielDe
Copy link
Owner

Ah I think I misunderstood what "valid content" was in this context. org-web actually already does support custom todo keywords, @tokuchan!

In the help file (Settings icon in the top right corner > Help), check out the third header under Actions > Todos (https://github.com/DanielDe/org-web/blob/master/sample.org#L2 and https://github.com/DanielDe/org-web/blob/master/sample.org#L18)

andersjohansson added a commit to andersjohansson/org-web that referenced this issue Oct 28, 2019
Store and restore settings (#+ lines) and content lines (other lines)
before the first headline in the file.

The settings and content are invisible and can’t be edited but are read in by the
parser and saved when exported again

Fixes DanielDe#55.
Partial fix for DanielDe#68.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants