Better editing workflow?

[leroycep]

When reviewing data and editing it , the user has to copy a UUID:

$ augr summary --refs coding
Date  Start Duration Total     Tags
――――― ――――― ―――――――― ――――――――  ――――――――
09/21 09:03 7m       7m       augr coding 2ad152fa-966f-41b7-a11e-182784bd8659
      09:10 35m      43m      augr coding feature-short-ref 45037ac0-8826-4b76-8c71-aefeb01c3a7f
$ augr tag 2ad152fa-966f-41b7-a11e-182784bd8659 thinking
b314a4ed-03d7-4177-8b07-64db988f87e2
$ augr summary --refs coding
Date  Start Duration Total     Tags
――――― ――――― ―――――――― ――――――――  ――――――――
09/21 09:03 7m       7m       augr coding thinking 2ad152fa-966f-41b7-a11e-182784bd8659
      09:10 36m      43m      augr coding feature-short-ref 45037ac0-8826-4b76-8c71-aefeb01c3a7f

This is a bit of a pain, especially on mobile devices.

Possible Solutions

Short References

Allow truncated references to refer to an event. So instead of typing 45037ac0-8826-4b76-8c71-aefeb01c3a7f, they could just type 450.

This downside of this approach is that synchronization could make the user accidentally change an event they didn't mean to, or be ambiguous about which event it is.

The upside is that the interface of augr wouldn't need much changing to facilitate this.

[memchk]

Perhaps another way of doing it is relative addressing, similar to git. Let HEAD be the latest event, then to edit the tag before the latest event, the command would be $ augr tag HEAD~1 thinking.

The similarity to git is nice as I would imagine most people using a tool like this are going to be familiar with it. I would be happy to take that specific mode on as a project, it should be simple to implement in the client layer, abstracting over the core.

[leroycep]

My only concern is that it is possible for augr to synchronize in between when you look at the summary and when you make an edit. git doesn't synchronize automatically, so it doesn't run into this issue. Though perhaps this doesn't really matter, as augr is designed for one user, who will likely check the summary before making changes, and know if there are changes that are not synchronized.

But just to be safe, we could disable synchronization when an editing command is run.

[memchk]

I think we can deal with the inconsistent history like this assuming you like my idea for referential syntax:

We already keep track of seen patches in each hosts file. So, a referential update could look like this:

1. Load hosts known patches
2. Build timeline using only known patches
3. Perform desired update / delete operation.
4. Update known patches file.

This could fail still if two hosts edit the same patch simultaneously, however I think that is currently an issue with editing tags anyways.

[leroycep]

1. Load hosts known patches

2. Build timeline using only known patches

This is easy enough; all that needs to be done is to put these lines in an if statement that checks whether the current command should synchronize. Probably by making a should_synchronize() function on the Command enum.

This could fail still if two hosts edit the same patch simultaneously, however I think that is currently an issue with editing tags anyways.

No edits necessary! Patches let you change previously created events. To remove a tag, augr creates a new Patch, and then adds a remove tag section. The new patch is then added to the store, and referenced as a known patch.

I need to add some documentation on the file format at some point.

[memchk]

Easy enough then. I will work up a patchset and submit a PR!