What an amazing app!
My requests:
- Typewriters scrolling
- Export options
- “save as” to change document type
- Full screen with some margins
- checkboxes that strikethrough a row when completed
I love it.
1 Like
Save as and checkboxes that we can strikethrough would be amazing. In a way, merging TaskPaper with Bike!
@Jerzy_Golota @ppasquet The functionality of Save as is still there.
It’s just the name/implementation that’s changed. Use Command-S and that will call the menu File > Duplicate, then you can save that duplicate document where you want using the format you want.
I think that behavior is logically cleaner and easier to understand than the old Save as behavior. It’s clear that after the operation you have two different documents. With that said it confuses me too.
All this behavior (old save as) and new duplicate behavior is provided by the underlying macOS frameworks. Bike just uses behavior provided.
My current thinking is: bug fixes, small often requested features like font setting, then rich text (bold, italic, code, links). Then decide what’s next. Maybe a big job like plugins or iOS, maybe a smaller job like tags. Depending on choice there’s a big time range.
Love the focus on font settings and rich text first.
I was going to add a suggestion for each row being able to have multiple lines for things like code snippets, etc. Do you envision that as part of the rich text support or something else?
Also like the idea of #tag support. I’ve built in a custom script that uses your lovely scripting support to very quickly pull out all tags from a file with a keyboard maestro keyboard shortcut.
If I implement code highlighting (and pretty low priority at moment), I expect it would be still implemented as one line per row. The syntax highlighting would just consider other nearby rows. Anyway not sure it will even happen, but I generally expect rows to stay single lines of text.
I do expect some sort of tags support. Not sure when, but much more likely then code highlighting.
One other thought I had for a request was jump history so you can navigate around the jump stack. Perhaps there’s a buffer that remembers your row locations so you can navigate back and forth via a menu command.
Thoughts? I think that would enable some nicer ux.
Also: small nit, but it’d be amazing if Bike remembered where you were in the document when you re-opened. Basically, saving the selected row state between app opens.
1 Like
A simple Print function. I can easily use other methods when I need to print, but my less-technical friends will have a problem with it not being there.
2 Likes
Rich-text-first approach 
: would it be possible to keep plain-text editing as an option at the very least? This is what I am enjoying the most about the app right now, just concentrating on outlining and not having to worry about styling or distractions.
Personally, I do not see myself using the app that much in the future if I am not able to rely on some kind of a plain-text approach. But that’s just me.
Autosave works great. Also, great to know fullscreen fixes are on the way (not fussed about these atm, though).
1 Like
It depends what you mean.
The current Bike 1.0 editing approach (plain text outline, no rich text) will always be possible, all you have to do is choose to not use the future formatting commands. They will be hidden in menu, easy to ignore.
You are also free to use Markdown or any other plain text formatting… save using Bike’s plain text document type and you’ll get out exactly what you’ve put in.
What I don’t think Bike will support is any automatic formatting or syntax highlighting of markdown syntax. Maybe this will change in the future, but I feel pretty strongly on this right now.
1 Like
Please break this out into another topic. I agree there’s work needed, but I’m not quite sure what you mean by a jump stack.
I agree I think this is a bug. Intention is to replicate TextEdit as exactly as possible. Added to my list.
This topic is getting big and generic. Unless replying to something already in this post please create a new post. That will make things easier to find in future.
WEll that is interesting!
It sounds as though I’m getting a very different behavior. I made a screen capture video to show how it’s working for me. Could there be some OS level setting that I have set differently…? 
Ok, well, “Close windows when quitting an app” in General System Preferences seems to be part of the answer… I usually leave that unchecked. With it checked, I can quit Bike with a doc open, and then when I reopen Bike that doc reappears with expand/collapse state as I left it.
However, what I really would prefer is that I can leave Bike running, close a document, and then reopen the document with the expand/collapse state restored, and that is still not happening regardless of that OS-wide setting.
Yes, this is just unsupported for now. Maybe in future, but it gets complicated. For example if you are sharing the file on iCloud/Dropbox with another user you might not want that state synced. Or if you have multiple windows open on the same outline then need to start storing multiple states per outline in the document. All possible to solve, but requires time and work. I’ll likely just keep current behavior for now.
Many thanks for this common sense thinking