Support editing - Githubissues

chaorace commented 4 years ago

Currently, it seems the app only allows for viewing of org files. Are there any plans to provide write functionality in the app? If so, perhaps we should figure out a roadmap of desirable editing features to provide?

son1112 commented 4 years ago

I'm curious about this as well. Would love to be able to create and edit org files using this application. It's the best org viewer for mobile yet, IMO!

amake commented 4 years ago

Thanks for the request. Here's what I wrote about editing previously:

Editing would be a very big stretch goal. File access I don’t think is the main hurdle. Off the top of my head the main barriers are:

Medium difficultly: Ensuring faithful round-trip from text to parsed representations and back to text. I wouldn’t want to mangle files or make spurious changes, but I didn’t design the parser with round-tripping in mind, so that might be hard.
Very hard difficulty: Making a good interface for editing. The display is not one big text buffer with styling like in Emacs, it’s a bunch of separate UI components (“widgets” in Flutter parlance). So editing can’t be as simple as placing a cursor and typing, which is probably not very desirable on mobile anyway. It will be hard just to design a usable interface; implementing it may be even harder—it could require completely reimplementing the current UI.

That said, I may get the itch to do something a bit smaller in scope, such as allowing checking checkboxes or toggling todo status.

amake commented 4 years ago

Markor has been suggested as inspiration for implementing editing.

shombando commented 4 years ago

Markor has been suggested as inspiration for implementing editing.

Also suggesting Organice org-parser as parsing tool.

amake commented 4 years ago

I made my own parser for Orgro in Dart. Organice's org_parser is written in Clojure, and I can't see any path to making that run on iOS, so it's a non-starter as a replacement. It could be useful as inspiration for e.g. AST representation.

macdonaldster commented 4 years ago

My attraction to this software is I can quickly view org files on my mobile device. I don't necassarily want to edit. I am liking the fact that a simple "git pull" (e.g. using Mgit) gets my latest files without messing with conflict resolution because of something Orgzly did to my files (NOTHING against Orgzly - love it, but it can complicate workflow). I can see something like "org capture" that appends a headline with some other data (e.g. default TODO state, scheduled "today", etc). This would make it perfectly usable for me. N = 1, of course. I was thinking a separate app that only did that formatted append might be useful (I am guessing I could gear up something with Automate or Tasker to do this pretty easily).

amake commented 4 years ago

I can see something like "org capture" that appends a headline with some other data (e.g. default TODO state, scheduled "today", etc).

Sure, "just support appending new sections" is a useful reduction in scope that would be easier than supporting general editing.

shombando commented 4 years ago

I can see something like "org capture" that appends a headline with some other data (e.g. default TODO state, scheduled "today", etc). This would make it perfectly usable for me. N = 1, of course.

N=2, that is a great idea and goes along with @amake's comment on each node being a flutter widget. All the existing nodes can be read-only and allow a "capture" of a new node in plain text as an append to the file. Once the file is saved and rendered then any org formatting that was typed in will be displayed as intended!

chaorace commented 4 years ago

No problem from me regarding targeting simple section appending. That covers my use-case for a desktop GTD + mobile companion workflow.

If we're going with appending new sections as the main editing functionality though... I would like to chip in a request to be able to also cycle TODO states.

snuffop commented 4 years ago

What about passing the file to an editor? and re reading on save or change. thus allowing the use of next|own cloud dropbox or other to handle the sync editor of choice to edit and orgro to view.

bradyt commented 3 years ago

Maybe you can toggle the mode, so that wherever "point" is, you toggle to edit mode which takes you to a plain text version of the file, no parsing, and you're positioned to edit the same text where you were at previously, up to glitches. Then edit, save, and toggle back to parsed view. I've also wondered if there's a way to pass "point" to open the file in an external editor at the right position.

Sort of like toggling between org-viewer-mode and text-editing-mode or something.

amake commented 3 years ago

The main issue I see with doing a bimodal editing scheme like that is that for large documents parsing is already very slow. So either the UX would become quite poor for large documents, or I have to create the machinery to allow editing partial subtrees of the document. The latter could work, but right now the parsed representation doesn't remember its exact text representation, so the round trip would have to be lossy.

riccardovarenna commented 1 year ago

maybe there can be certain forms of editing that are "easier".

So rather than allowing free text editing, have some predefined edit actions and only go for the ones that give most value with least effort.

Here are in my opinion the most valuable edit actions aside from free flow typing text:

refiling a heading to a different heading
marking a todo as done / changing the todo state of a heading
adding a heading underneath another heading / at the bottom of the file

Maybe those can be achieved without having to deal with difficult UI where you need to free render text but rather only change one flutter element per edit action the user can take

amake commented 1 year ago

Medium difficultly: Ensuring faithful round-trip from text to parsed representations and back to text. I wouldn’t want to mangle files or make spurious changes, but I didn’t design the parser with round-tripping in mind, so that might be hard.

I've been playing with this a bit and I find that it's quite cumbersome to adjust org_parser to retain all whitespace.

What is the best practice for parsing with an eye to reproducing the original document verbatim? If there was a clear pattern to adopt, that would probably help.

Another thought is that there should really be a tree-parser grammar for Org syntax; tree-sitter seems more suited to this application and the parser produced could be used pretty much everywhere.

amake commented 1 year ago

Relevant discussion: https://github.com/petitparser/dart-petitparser/discussions/142

amake commented 10 months ago

Update: I've gotten org_parser to the point where it can successfully round-trip verbatim some well-formed Org documents.

The next hurdle is how to implement programmatic editing of the AST. Currently the AST is immutable. The easy thing would be to allow mutation, but I'm also looking into zippers.

amake commented 10 months ago

Zippers have proven to be fruitful. If they have a problem it's performance, as they inherently cause a lot of object allocations. So far it seems OK though.

Locally I have implemented:

Tap on a list item with checkbox to toggle it ([ ] ↔︎ [X])
The updated document is written back to the original file if possible (when opened with appropriate permissions, etc.)

I'm worried about mangling user files, but unfortunately I can't easily back up a file before saving (I would have to prompt the user for permissions on the backup file). I will have to think about how to do this.

Edit: I may be able to back up the file if I have directory permissions.