Should Bike add created and modified dates to each entry?

Bike Outliner
1

since the thread mentions Time, I’ll post this here

  • TimeOfLastEdit-feature for Bike!
    • I wish there was a way to tell when the last time a node was edited.
    • For instance, hovering over the open/close triangle on each entry, one could show the date/time as a transient (popup?), or as a permanent fixture to the left of each node, slightly dimmed. Just an idea?
    • I use Bike mostly as a log (love the sparse interface btw), and I understand I can insert the time/date via a shortcut-macro in macOS.
2

Any other thoughts here?

This is easy enough to add, I think.

I guess the consideration is that I don’t think it makes sense to add an option for this, and that means adding two new attributes to all entries. That will use a bit more memory, and add some noise to the file format. I think none of these are showstoppers, I’m just wondering if there’s anything else I should consider before adding a new built in attribute.

At the moment the only built in that is always included is id.

And for attribute names I guess “data-created” and “data-modified” make sense for names?

6 Likes
3

I think this would be a worthwhile addition particularly when searching for checkbox items combined with dates.

1 Like
4

I’d really love to have “data-created” and “data-modified” attributes. I don’t mind those attributes making the files a bit “noisier”. However, I’d want those attributes to be optional. One reason is that we won’t know what those attributes should be for old files. Another is that making them optional would make life easier for anyone writing bike files.

1 Like
5

However, I’d want those attributes to be optional

They would be optional in the file format, but I feel like it might make things easier to make them non-optional in the runtime model. I was thinking to fill in a value of “distant past” if the date wasn’t provided in the read file.

5 Likes
6

My concern would be making Bike fatter and slower, perhaps even cluttered, as someone noted above. If that would be the effect of this change, I would rather see it left out.

That said, I often have “Date created” and “Date modified” lines at the top of note files and spreadsheets. :wink:

1 Like
7

I think, if it doesn’t have any negative, observable near term or long term impacts to user experience, I’m fully onboard! Sounds like a nice addition.

8

I’ve added this to Bike 2.0. Any thoughts on which rows modified date should be updated, if any, when moving rows?

9

IMO moving rows does not change the content of the row, so no change…

3 Likes
10

The content of the child row doesn’t change – I agree.

On the other hand, any parent rows which are losing (or gaining) children in the move,
could, perhaps, be seen as changing ?

(They are losing or gaining some elaboration or underpinning. On the other hand, as the data structure is recursive, that could become an argument for updating all the ancestors of a move, which sounds a bit noisy and unnecessary, occluding the more interesting inline edit times.)

In short, I think I agree that just recording the time of inline edits sounds useful and efficient.

2 Likes
11

This probably isn’t for everyone, but an alternative DIY route: I keep some Bike documents (and other files) in a one-branch git repo for version control. You can run a git annotate to see when each line was written.

5 Likes