Capture notes should have a preview mode

[gitonthescene]

I think it would be nice to have a "View document" option for captured notes as well. For one this might be a good place to find clickable versions of links that have been added.

[gitonthescene]

One possibility is to have clicking on the row go to editing the captured note only when in edit mode and have it go to preview mode if not editing.

I'm happy to take a whack at doing this if it seems reasonable to people.

[gitonthescene]

I still think that "View document" for captured notes is a good idea, since my notes often include links and it's nice to be able to click on them before I've had a chance to sync them, but I think I may have misunderstood the intent of edit mode in the iOS ecosystem. I think abstractly my last suggestion makes sense, but after some research it doesn't seem idiomatic.

Perhaps instead we could have a click-hold menu like the outline page which offers a View Document option.

[dive]

I had a crazy idea to embed organice as an engine to preview notes/documents.

[webframp]

I had a crazy idea to embed organice as an engine to preview notes/documents.

Not too crazy of an idea actually if it could be done in a way that harmonizes the UX.

Organice is a neat project. Very material-UI feeling.

[gitonthescene]

Orgnice also has a way to start a clock which is something else I was going to suggest, but maybe the suggestion here is just to use the renderer.

Also, this particular issue is about adding preview mode for capture notes rather than how the rendering is actually done. I assume we'd want a consistent renderer. Maybe changing the renderer for preview mode should be a separate issue, since we could probably attack both in parallel.

[gitonthescene]

Short term, I was thinking something along these lines, where you only descend into editing if you're in editing mode. I think this feels a little more consistent.

I'll see if I can get the captured note to render the same way that Outline notes do.

[gitonthescene]

My read from the code is that OrgFileParser reads in the entire file as a string and from there on doesn't use the fact that this string came from a file (except possible for handing org file specific syntax like FILETAGS). We could refactor this code to generate nodes from strings, and use this to generate a string from a captured note to render with OutlineView.

As a separate project we could swap out this org file parsing with something else, like organice, though my sense is that it's more geared toward editing org files than rendering. Aren't we after something more like the html exporter?

It's tough to tell from the site, but I wonder if organice isn't built on top of this org -> AST parser. Perhaps that's what we're really after here. It's written in JavaScript, but we can probably use JavaScriptCore to run it.

[gitonthescene]

An alternative is to make a dummy file with the concatenation of all the capture notes. And use that to render. I still think you'd need to refactor the grabbing of the "file" source, maybe by passing in a handler.

[gitonthescene]

Actually, it might be worth asking whether it's worth using the orga AST as the basis for the data model. Initial experiments show it to be fairly quick and looking at the code, it seems pretty extensive. I made a repo out of the playground I used to test.

D'oh! I just noticed there's also a swift-orga in native Swift, though it doesn't seem as active as the orga parser itself.

[webframp]

Not opposed to replacing or refactoring the org parsing and data models.

I would prefer that we keep any new library dependencies we take on to be Swift instead of objc if possible, but don’t have to be too strict about it

[gitonthescene]

I think there's a good chance we can retire quite a bit of objc if this works. I'll do some more research. Have a look at the playground code I posted above if you have a chance.

[gitonthescene]

Let me hash out my idea here...

With some small changes to the orga parser, we can (with javascript) go back and forth between an org document and a complete Abstract Syntax Tree for the document.

It's easier to extract information out of the Abstract Syntax Tree than manually parsing out interesting bits from the original document. For instance we can easily find all the top level headings, pull out the heading types and/or tags or find all the subheadings of a given heading.

Also, since we can render trees as org documents, we can do the same for subtrees. So if we have a handle on a given node in the AST, we can render just that node. If we edit that rendered text, we can parse that text into a new subtree and splice that back into the full AST in place of the original subtree.

Moreover, there is support for rendering orga AST trees as html. We could use this for the Outline View.

Granted that most of this tree handling/manipulating is going on in javascript, but hopefully this description makes it clear that you can pretty much black box it and be ignorant of the details.

Having these functions be black boxes has other advantages in that they can be developed independently of the full app. So if someone wanted to render the html with some virtual-dom functionality to open and close drawers for example, that can be done completely using the orga parser and html renderer and should work as a drop in replacement for what we'd be using.

One thing I don't know much about is how the licensing affects us. It looks like orga has been distributed with the MIT license. Will that cause problems?