Pretty much what you see for the initial release.
At the same time I’m always game to add in requests that fit in with the rest of the app. Truth is most of the time I edit markdown in my code editor. Only long document I have to edit is Bike’s user guide, and that’s split into lots of files. So I need help (requests) to find the weak spots in WriteRoom for “real” writing scenarios.
This list from @Gorgonzola inspired much of this most recent release.
I do have some higher level goals:
-
WriteRoom first, markdown app second. Path to fullscreen text should always be fast. Beware extra UI.
-
Workspace option, sync, iOS (goals, not promises, and a bit hard to figure given above’s beware extra UI, but that’s what make software development interesting). WriteRooms 4’s dev was originally justified by two things: First, I wanted a simple testbed for workspace/sync that I would then apply to Bike. Second, I thought macOS 27 would brick WriteRoom 3, turns out I was off by a year!
My goal is that it will work with most any markdown, so I guess call that lean into the quirks, until there is a quirk I don’t like, then I’ll skip it!
I think we’ll get there… but probably not for 4.0 release. Have you found Go > Go to…? That would be my answer for now. The trick with sidebar/heading pull down, is not so much implementation of feature, but how to fit it into the UI.
Now the headings pulldown probably fits pretty well into the titlebar, but each new button is a decision. And after I’ve added a few and lived with them for a bit… I always (this is just with any app) turn them off and think… so much better, why did I add those in the first place. I expect UI will be added over time, but I’m just trying to avoid that feeling.