file settings & sync

[tarnung]

Most of this is copied and adopted from capture templates.

Options with current defaults:

• Load on startup? --false
• Include in Agenda? --true
• Include in Search? -- false
• Include in Tasklist? -- false

Loaded files without a setting entry would be handled according to these defaults. the currently viewed file will always be included in search, agenda & tasklist.

There is also refile. Should all files always be refile targets or should it be configurable?

The 'Load on startup'-option does not do anything yet.

[tarnung]

The dropdown used is a simple html-select. If we have recommended styling for selects or a special dropdown-component, I will use that instead.

[tarnung]

I'm sorry, I continued on this branch, so the sync-functionality doesn't have its own pr.
The last commit added syncing multiple files.

I figure we have three sync types:

• manual
• live sync
• becoming visible
  Currently manual sync and becoming visible both sync the currently visible file and all dirty files.
  Live sync explicitly knows about actions that touch multiple files (currently only refile) since it is triggered before the files are marked as dirty. It's not terribly elegant, but since i doubt that there are that many actions touching multiple files I guess it's ok.
  There is currently no way to force a syncing of all loaded files. Maybe manual sync should do that.

isLoading is now a Set of paths.
the sync-conflict modal now knows which file it is concerned with. Since we operate on a one modal at a time basis, I don't know exactly what would happen when there are multiple conflicts at once. I guess the last one will be displayed while the others are lost.

I have not done anything with Capture yet.

[tarnung]

I built this so that a file path in the redux store not matching the url triggers a redirect. This way I can switch between files by dispatching an action and the url stays in sync.
This possibly breaks some other behaviour that changes the url. I have not found any problems yet, but it's a thing to watch out for.

[munen]

This looks like great progress!

Options with current defaults:

• Load on startup? --false
• Include in Agenda? --true
• Include in Search? -- false
• Include in Tasklist? -- false

Loaded files without a setting entry would be handled according to
these defaults. the currently viewed file will always be included in
search, agenda & tasklist.

Makes sense, good work!

There is also refile. Should all files always be refile targets or should it be configurable?

If it is not too much work, it would be best, because that's how Emacs handles it. Personally, I have never seen a use-case to have one set of agenda files and another for refile targets, so I just use the same: https://github.com/munen/emacs.d/#refile-targets

If adding refile is too much work, mixing agenda/refile might be a good workaround.

The dropdown used is a simple html-select. If we have recommended styling for selects or a special dropdown-component, I will use that instead.

We have no components for dropdowns, yet. Also, from personal experience, I'd say that even popular styled dropdown components can feel quite clunky and lack functionality of native html-select.

I'd say, it's a good decision to go with the native html-select here(;

[munen]

I'm sorry, I continued on this branch, so the sync-functionality doesn't have its own pr. The last commit added syncing multiple files.

No worries, I'm stoked you're working on sync!

I figure we have three sync types:

• manual
• live sync
• becoming visible Currently manual sync and becoming visible both

Yes, that's true. Tbh, sync is terribly complicated, already, and has grown organically when new bugs were found. At this point, we support the following use-cases:

1. Let the user decide whether she can't spare the bandwidth and disable live sync.
2. Let the user decide for whatever reason, that she doesn't want to sync when becoming visible.
3. Let the user decide that it's time to sync manually.

That's a lot of cases. And adding multiple files will likely not decrease the nested complexity.

If it makes things easier for you, I'd be fine if we ditched 1 and 2. Here's some thoughts around those for context: I've added those, because for me, they are completely necessary to:

• Not get sync conflicts.
• Be more concerned with editing the Org file than the question 'Did I sync already?'

I've added the latter two with switches to cater for those with less bandwidth. However, I'm not convinced this is the right approach. Less synching tends to yield more problems. If we wanted to cater to lower bandwidth users, then having stronger offline capabilities would be better than fewer syncs, imo.

If that helps reduce complexity for you, I'm happy. If you're happy to use the status-quote to build on top, that works for me, too.

sync the currently visible file and all dirty files. Live sync explicitly knows about actions that touch multiple files (currently only refile) since it is triggered before the files are marked as dirty. It's not terribly elegant, but since i doubt that there are that many actions touching multiple files I guess it's ok.

I agree that that's a valid pragmatic decision. From the top of my head, I can't think of another action that would change the contents of a different file than the currently open one. The only exception would be 'archiving', but we're not supporting this at all at this moment, so it's not really a concern. And adding two explicit actions - knowing well that these form a final set of potential actions - is still totally fine(;

There is currently no way to force a syncing of all loaded files. Maybe manual sync should do that.

Sounds like reasonably the easiest approach to build.

The alternative would be to watch the other files for changes. But, then:

• All sync back-ends would need to support that. Dropbox has a native API for long polling, for the others one could be built (if not natively supported).
• Sync on becoming visible should re-check, because long-polling in the background does not work on mobile.

So, overall, the alternative sounds quite a bit more complicated than 'manual sync forces syncing all loaded files'.

isLoading is now a Set of paths. the sync-conflict modal now knows which file it is concerned with. Since we operate on a one modal at a time basis, I don't know exactly what would happen when there are multiple conflicts at once. I guess the last one will be displayed while the others are lost.

Tbh, I don't know. They might be pushed on top of each other and the user might just see each of them at a time. But that's also a bit of wishful thinking(;

A different approach might be to collect errors on synchronisation and only when the whole set of files has 'finished' in some way, display the modal.

Just thinking out loud here. It's also ok if that edge case is not handled at the moment, and we add an issue for it. The call on how to proceed is yours, of course.

[munen]

Merging to develop as discussed in #560 (comment)