Does Bike outliner support tags other tags in either the # of @ format?
Thank you.
ScottC
Saluda, NC
@jessegrosjean, have you shared any details on your plans for the tagging and filtering implementation?
Bringing it up because I wanted to bring to your attention something I like in NotePlan, that I think you should implement from the beginning:
The app has both #Tags and @Tags!
They don’t have any big differences between them, and it’s up to the user to choose how do use them. Personally I use (or *used - moving as much as possible over to Bike these days 
) the #Tags for subjects and @Tags for contexts.
So I could write like:
Send mail to Peter #Work @Mac
That would be different than:
Talk to Peter #Mac @Work
Now, is it strictly necessary? Probably not - but it’s kinda nice that I can separate between sending an email from my Mac about work and talking to someone about my Mac while at the office.
It would be easier to have separate terms for them - so even though it might be a bit opinionated, I don’t think it’s a bad idea to call them #Tags and @Contexts.
Merlin Mann (wisely) advocates for having only one tag per letter in the alphabet, so every tag can be written quickly by typing only the first letter and hitting Enter. If you have both tags and contexts, you could have twice the amount! I replicated his idea in NotePlan, and it was of great help to be able to reuse the letters for contexts. 
Having both can also make it easier to make good nested structures (of both types), like the difference between #Work/Monday (maybe because the person I need to call only is available on Mondays) and @Work/Monday (maybe because a colleague is only at the office on Mondays).
Not really. I have ideas, but no specific plans yet. Some general thoughts are “attributes” with associated values are the primary “thing”. So for example there are built in attributes such as “id”. There are also attributes such as “done” that are used by checkboxes. And it will also be possible for users to set their own attributes.
In TaskPaper (which serves as inspiration for many Bike features) attributes were defined like @attributeName and if attribute has associated value then @attributeName(value).
I like open endedness of this system. I don’t like that tag syntax is mixed in with user text. Generally I want to maintain open endedness of system, while changing attribute editing UI from embedded syntax, to separate UI command. How that will work I’m not sure.
A separate tags (in addition to attributes) is a possibility. I expect it would be implemented as an attribute named @tags="one,two,three" with a list of associated values. And then have its own UI. I go back and forth between thinking this would be nice and thinking it’s needed.
I expect to actually start working on this once themes are done.
2 Likes
Did you mean that you don’t like the behaviour in TaskPaper regarding this, and that you’d like to do it differently in Bike?
Personally I think it’s neat how the system regarding @Done (and potentially similar “system functions”) intersects with the attributes the user can type on the fly, and everything being very “out in the open”. May I ask what you don’t like about it?
I won’t claim to fully understand the technical nuances in your answer, but I checked out the way it’s done in TaskPaper - and I think the same system in Bike would be a great start!
And being able to have a second layer with a different #Prefix would be an awesome evolution! IMO, it wouldn’t really need to function any differently - just a separate instance of the same system, if you know what I mean. Like going to the hardware store, and buying two of the same toolbox. 
(And in that world, I’d love to be able to choose which prefix things like Done would get, as my non-programmer-mind finds #Done way more intuitive than @Done.)
Personally I don’t really use nesting, but I think many would appreciate that down the line as well.
Looking forward to themes! 
(I’ve been itching to style headers slightly different than bold text.)
Keep up the good work - hopefully I don’t waste too much of your time with my enthusiasm. 
1 Like
I like TaskPaper’s data model, open ended user settable attributes/values. I don’t like mixing @done into the text. The problem is once @done is embedded into text content then Bike’s file format becomes much harder to process, because you need to know Bike’s specific parsing rules.
I don’t know where I’ll end up after a few months of actual working on tags/attributes in Bike. There are nice benefits to TaskPaper’s approach, but generally it has this big weakness that I would like to avoid this second time through.
2 Likes
I am not in a position to contribute anything meaningful regarding the implementation. Being able to set something like @tag anywhere is however extremely helpful in TaskPaper.
1 Like