Support .orzgly file to project complex hierarchy into simple flat view

[memeplex]

(A more evolved view of this feature request is described from my third comment on)

Often a folder contains a ton of notes but only some of them are worth accessing from a mobile device. The strategy of splitting the notes in different directories to avoid exporting to orgly would be too invasive both by disrupting logical organization and, say if notes are in a git repo, other sync and storage technologies. I propose to support simple .orgzlyignore files with a list of files to avoid syncing to/from a repository. This will improve performance in many fronts: syncing time, agenda indexing, searching. Also the user won't be overwhelmed by lots of unnecessary notebooks in orgzly strictly flat interface (no hierarchy nor grouping for notebooks).

[memeplex]

Alternatively .orgzlysync with the only files that have to be synchronized. This may be better given that at the point you are trying this you probably want to keep a few important notes/agenda files from a lot of reference material. Also, it might be simpler to implement: check for .orgzlysync, if available only request the repository for the files listed there.

[nevenz]

Related to #273.

[memeplex]

I've been thinking a bit more about this. There are a couple of severe limitations in the current flat-repository approach: (i) it's all at the top level and (ii) it's nothing at the levels below. Only (i) was addressed above. But consider an .orgzly that included files at some depth in the tree:

gtd.org
proj1/notes.org
proj2/notes.org
inbox.org
important.org

This solves many shortcomings in a simple and effective way:

1. Orgzly hasn't to do an expensive recursive sync.
2. The user isn't overwhelmed by tons of reference notes in a flat list that are quite irrelevant in a limited mobile environment (vs his/her main computer, in any case it's the user who decides what is relevant where).
3. The user can selectively access notes in a hierarchy of projects without (i) refiling notes or moving around files, (ii) breaking apart the logical structure of folders and files, (iii) referencing every .org file in every inactive or archived project.

Of course, in an unix environment one would achieved the above by creating an orgzly directory and symlinking the relevant files and folders, but most cloud storages don't support that pattern so another mechanism is needed.

[memeplex]

Notice that I'm not suggesting to radically change anything in orgzly UI. The flat interface is ok, the phone is mostly useful as an agenda and an inbox, you don't want to manage complex hierarchies and contents from there. What is missing is an explicit mapping from that complex hierarchy that you keep in you computer to a simplified flat view that you access from your phone. This .orgzly file is just that mapping. Going further, one can think of renaming here, to avoid clashes while flattening the hierarchy:

proj1/notes.org -> proj1.org
proj2/notes.org -> proj2.org

[memeplex]

I have commented in #148 how both features can be seen as partial substitutes one of each other.

[memeplex]

Far from a solution, but here are a couple of workarounds to keep a selection of read-only reference notes in-sync with orgzly. Assuming you have an /orgzly repository to put them:

1. I realized that dropbox preserves a symlink as far as you don't write anything on it. Say you have notes.org -> orgzly/notes.org and you edit notes.orgin your computer and you don't do that from a second computer and you never write anything on orgzly/notes.org from orgzly itself, this should do the trick.

2. If your setup includes a second computer I haven't tested it but I assume the above won't work since as soon as you touched notes.org in one computer changes would propagate to orgzly/notes.org in the other computer and dropbox would replace the symlink. So I have written a simple bash script using inotifywait to monitor changes. This script reads an .orgzly file with a list of files (and optional renames) implementing the aforementioned mapping that selectively flattens the hierarchy. Of course, this is still a read only workaround:

   inotifywait -m -r -e close_write \
           --format '%w %f' --exclude '\.#' --exclude 'orgzly/' \
           ~/dbox/{notes,projs} | while read dir file; do
   [[ $file == *.org || $file == .orgzly ]] && while read src dest; do
       [[ $file == $src || $file = .orgzly ]] && \
           cp -f ${dir}"$src" ${dir}orgzly/"${dest:-$(basename $src)}"
   done < ${dir}.orgzly
   done

   In the example, notes and projs hierarchies are simplified to notes/orgzly and projs/orgzly lists according to the instructions at notes/.orgzly and projs/.orgzly.

[memeplex]

Another option is to simply support file links to other org files and use one or more notebooks at the top level as index files. This would exploit the fact that orgzly already knows how to handle complex hierarchies inside a notebook. Of course, it requires support for links relative to repo as requested in https://github.com/orgzly/orgzly-android/issues/496.