I'm very eager to see this project develop. Looking at the examples, here are my thoughts:
- It seems like annotations should be excluded from the "value" field. If I write something like "Frankenstein [author:Mary Shelley]", I'm probably going to want to access the title "Frankenstein" on its own after parsing.
- It would be nice to be able to omit the brackets when there's no whitespace inside an annotation. For example, you could write "broccoli type:vegetable" instead of "broccoli [type: vegetable]"
- I like that you can use different list decorators, like -, >, or *. But these don't show up anywhere except the "raw_data" field—it would be nice if there was a field that contained just the decorator, something like:
Then you could easily use different decorators to encode semantic information. For instance, a Pros/Cons list could use '+' for Pros and '-' for Cons, and that distinction would be easy to access programmatically. If you do this, I think "[ ]" and "[x]" should be end up in the decorator field. Or maybe it could be a "prefix" field and "suffix" field, to hold decorators at either the beginning or end?
Just wanted to say, I think the second point is more awkward than it's worth. Some examples:
- check that video Alice mentioned at time 3:42
- don't forget to text Bob O:)
- my favorite thing is:strawberries
It makes parsing more complicated, as well as creating unexpected results in non-obvious cases (for example the last one could just be a typo, and what if it was instead written as 'is:strawberries, cake'?). It also isn't intuitive in the case of your first example, since I think of Mary Shelley as a single thing.
Alternatively, annotations could just read to EOL, unless it's explicitly guarded off. That would depend on how people use it, I suppose.
This is the syntax used in todo.txt, which I've found works well, especially if with syntax highlighting to guard against typos. You're right that it would be harder to parse, especially if you carved out an exception for digits and special characters to account for the examples you mentioned. I'll admit that I'm not especially well positioned to weigh the benefit of syntactic sugar versus the development cost of parsing, so perhaps you're right.
Comments
I'm very eager to see this project develop. Looking at the examples, here are my thoughts:
- It seems like annotations should be excluded from the "value" field. If I write something like "Frankenstein [author:Mary Shelley]", I'm probably going to want to access the title "Frankenstein" on its own after parsing.
- It would be nice to be able to omit the brackets when there's no whitespace inside an annotation. For example, you could write "broccoli type:vegetable" instead of "broccoli [type: vegetable]"
- I like that you can use different list decorators, like -, >, or *. But these don't show up anywhere except the "raw_data" field—it would be nice if there was a field that contained just the decorator, something like:
Then you could easily use different decorators to encode semantic information. For instance, a Pros/Cons list could use '+' for Pros and '-' for Cons, and that distinction would be easy to access programmatically. If you do this, I think "[ ]" and "[x]" should be end up in the decorator field. Or maybe it could be a "prefix" field and "suffix" field, to hold decorators at either the beginning or end?Just wanted to say, I think the second point is more awkward than it's worth. Some examples:
- check that video Alice mentioned at time 3:42 - don't forget to text Bob O:) - my favorite thing is:strawberries
It makes parsing more complicated, as well as creating unexpected results in non-obvious cases (for example the last one could just be a typo, and what if it was instead written as 'is:strawberries, cake'?). It also isn't intuitive in the case of your first example, since I think of Mary Shelley as a single thing.
Alternatively, annotations could just read to EOL, unless it's explicitly guarded off. That would depend on how people use it, I suppose.
This is the syntax used in todo.txt, which I've found works well, especially if with syntax highlighting to guard against typos. You're right that it would be harder to parse, especially if you carved out an exception for digits and special characters to account for the examples you mentioned. I'll admit that I'm not especially well positioned to weigh the benefit of syntactic sugar versus the development cost of parsing, so perhaps you're right.