Bike 2 - current state review

I’ve been using Bike 2 pretty heavily for the past few days. Timesink.app says it’s been 10 hours and 55 minutes spent with the app window focused in November workdays. I’ve mostly been working on an outline document that has now reached 30.000 words in total. That means I have some thoughts :slight_smile:

Overall, the app feels smooth and lightning fast, just like I’m used to from Bike 1.x. Painfully, there are some features still missing for quick travel (like Focus heading), but the new filtering system is great for raking out the big picture. This is fantastic work.

There were a few things that frustrated me:

  1. Current Move up and Move down outline movements don’t make sense to me, as I’ve noted here. I’ve accepted that Bike is block-based now, but the two distinct modes of operation of Bike 1.x made for much more predicability in outline movements. In this iteration, I’m never sure where parts of my outline will end up and what I’ll end up displacing.
  2. I frequently missed the Expand/collapse all option from Bike 1.x. At this point, I’m not sure what I have to do to explode the outline fully. It seems I can select all and hit Expand row or Expand Row by Level (both seem to achieve same result), but once the outline expands beyond the current window limits, I’m never sure how many times I still need to hit to cover everything.
  3. I’m still not sold on the ⌘+0/9 to expand/collapse single row, especially when in block mode. When I navigate the outline, I use the arrow keys. Using ←/→ in block mode and ⌘+⬆/⬇ in edit mode feels much more natural for my fingers. I know this is something that can be changed via custom keybindings but that requires extra coding, and it doesn’t come without conflicts, as I noted here.
  4. Finally, the biggest part—data portability. .bikemd is a great addition to the toolset, and it plays reasonably well with other markdown editors, up until they encounter [pandoc]{syntax}. Unfortunately, there doesn’t seem to be a good .md editor on the market that’s able to reproduce these tags faithfully. I can edit, yes, but I can’t use without significant cleanup. The idea of having to learn pandoc as yet another tool that works exclusively in the macOS Terminal with a custom script to recognise highlights before I can push an outline to a dedicated writing app is something just doesn’t sit right with me. I think long-term a Publish... → RTF, MD, TXT, DOCX, PDF etc. that will produce nicely formatted, clean results is a must-have addition.

This may sound harsh, but I really love using Bike. I think it’s insanely brilliant and even more powerful. It’s an incredible tool to have and I’m thankful to Jesse for creating it. I probably couldn’t handle my books without it. I’d like to use it everywhere, especially on iPad. Right now, #4 is the bottleneck for my workflow. I really hope this gets solved.

3 Likes

I was pretty busy these days, that is why I did not followed the forum so closely.

I think the Bike made a huge progress with bikemd and talking about plain text format, I am sorry to inform to you, but if you do not know pandoc you are simply lost, there is no other alternative out there. If you really want to have portability and manipulation of data, then you really need to use the terminal, there is not other option. Also, the terminal is the most productive tool that you can use in a computer.

For sure nobody in right mind will waste time writing a parser for the proprietary (and crazy) .xml (docx) from the crap Microsoft (they intentionally change the standard just to break other people work), so, it is highly unlike that Bike will waste time with this.

To be very honest to you, I faced the same problems. Generally I really like to try other applications and see what people are doing. I like the design and other things. But at the end of the day, what matters is performance and functionality. That is why I always come back to my org-mode in emacs.

It is plain-text, it is portable, customizable to the hell. The learning curve is somewhat steep, but, nothing even comes close. I tried hard other tools, but is really difficult to adapt to them. Jesse made a wonderful work and as a developer, he is very responsive. Just see the amazing work with bikemd, but it is clear that he will never be able (alone) to archive something similar to the beast that org-mode and all emacs implementation.

The org-mode is the true state of art for outlining, has everything that you can imagine and with a myriad of export options (plus customization). Unfortunately this is the trade off, if you really want something that fulfill your needs, you need to work on a platform that helps you to do this. Jesse made a smart move for the plugin system (I misunderstood the intentions at the beginning) and for sure he will expose an api to export bike native html. He (as solo developer) simply can not cover all single request on this. Today someone request rtf, tomorrow, docx, after tomorrow tex and so on. The unique downside is that the plugins need to be written in JavaScript (the most crap programming language of all time), this could be a parsed/script language (like lisp in various implementations (C, Rust, even python) or the famous lua script that is built on the top of C), there is a lot of options. Each approach has it’s on advantages and setbacks, the point is the ability to maintain the base code clear and readable (I rewrote my elisp configuration a lot of times :slight_smile: ) for both users and the developer.

Anyway, I will keep following Jesse work and see how Bike envolves, I really recommend this software to a lot of people (some of them actually bought one license), but for my user case, it is really hard to leave my powerhouse.

1 Like

Thanks for comprehensive feedback, useful for me to get datapoints of big picture feelings/priorities.

I think 1-3 are details that are all relatively easy to change, but take a lot of thought/tradeoffs when deciding on the final design. I’m not yet ready to think through these issues at the moment, but I do think they can all be addressed with pretty simple custom commands/keybindings (and that keybinding conflict is a bug and fixed for next release) or preferences if it comes to it.

I’m still on big features (mired in glass UI at the moment) right now. When I start final debug/polish for 2.0 bring these up again if you are still interested.

Markdown improvements

Bike will always need some non-standard syntax, to support aspects of Bike’s format that are not representable in “pure” Markdown. I think Pandoc is a better choice then anything else I’ve seen.

I do think there is room for improvement in two areas (other suggestions welcome):

  1. Sometimes when you have overlapping syntax bold/italic/links I end up encoding (bold for example) as [text]{strong} to ensure that I can read back in the exact same syntax. There are a few cases where I am overdoing this, and I will try to fix those. If you run into cases where this is happening, but you don’t think it should, let me know and show me specific cases.

  2. Highlights, I think I agree, ==highlight== would be preferable to [highlight]{mark}. The reason that I don’t support it yet is because the swift-markdown lib that I base my parsing on doesn’t support it. I can add some custom custom parsing (as I do for pandoc), just haven’t got to highlight syntax… and it’s a little hard to know where to stop. There are a million custom syntaxes for Markdown, don’t want to support them all. But I agree highlight probably does make sense to support.

Are there other problem cases you are running into in your exports besides the two listed above?

I expect to get there someday! :slight_smile:

3 Likes

I agree, broadly, but messing with nvim/emacs is a rabbit hole I absolutely refuse to dive into. I like GUIs for a reason.

Other than my custom attributes polluting the outline, I don’t think so. Curious to see what happens with == highlights.

Indeed – more a genre than a grammar …

(Thank heavens for the XML/HTML standard, and the hidden layer for attributes etc.
Liberating to be able to focus on the content, and use standard tools over outline structure)