Still rough spots, but provide feedback like it’s an app to be released soon…ish. Always the ish.
License system! Yeah!??? Ok, not the most exciting part of app, but hope I can entice some of you to WREARLYBIRD through and keep track of how it goes. There’s also Start Free Trial to test.
I’m still using Paddle for payment processing, but there license key system is deprecated so I had to build my own. It seems to be in pretty good shape, but watch for and report any oddities please.
Writing goals and counts. I’m pretty happy with how this has worked out. Much flexibility in a very tiny UI and display. Hopefully it works for what you need.
Markdown structural Edit > Move commands. Give them a try and let me know what you think and report back with problems. Escape hatch is to add Control key to the keybinding sequence and then you’ll be moving raw lines, ignoring Markdown structure. In a plain text document both variants move raw lines.
Have you shared your expected feature list for the production release? Now that this is usable for real writing, it is easier to see features I would like to have. If these are already on a list, there is no reason to take anyone’s time including my own suggesting them here.
Along those lines, from a product philosophy point of view, what kind of Markdown support are you targeting and which Markdown flavor or flavors are supported? Markdown has a lot of quirks that an opinionated writing app could smooth over, but that a “markdown editor” would have to lean into. I have already noticed this tension with the move line feature, which seems to be moving Markdown text blocks not text editor lines. I would prefer the other way, but am not sure of your goals here. So this may be a feature not a bug. [EDIT - just read your bullet list more carefully and see that the default command is meant to work this way and the control option is close to normal text editor behavior]
On the release itself, I really like the header navigation features and the gutter being used to show the # level. The combo of this, nav, folding and sticky headers is really powerful. Short of a sidebar, it would be nice to have BBEdit style section navigator in the title bar, but your feature set for document nav is already really strong.
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.
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.
The main thing I think would be helpful is an ability to have an easy way to open two windows for a single document, or to have a split window. I don’t know how the latter would work in writeroom. Maybe it could look like emacs’s approach. The two windows for a document seems more straightforward. Not a writing app, but I really like the way Things3 has a tiny “new window” button in its menu bar. That would be my only suggestion as I think keeping Writeroom simple is important.
Haven’t had the time to test everything out, but maybe a few initial comments:
That cmd+` shortcut to cycle windows sits terribly close to the undo shortcut on a US keyboard. And since using this shortcut switches window focus and text typing can be undone in one accidental mis-press, this seems a bit dangerous to me. I know we have versions but, take it from a writer, restoring that ONE perfect paragraph you wrote and accidentally deleted 4 days ago…not ideal. Maybe ctrl+backtick?
Is there a way I can see my progress while in full-screen mode?
Also, one thing I’m noticing - I like the minimap when I’m in windowed mode and shuffling text about, but don’t really need it while in full-screen writing. Maybe I missed it but there isn’t a keyboard switch to toggle it off? If not, I’d reiterate that item from my list
I’m not sure that I follow… on my (I guess US keyboard) they are quite far apart. Command-` (where ` is up high to the left of 1). Where undo is Command-Z.
For me, in all Cocoa apps, Command-` works to switch between the apps windows, and it’s a very common shortcut that I (and I think others) use. Though it’s also odd in that there is no menu item for it that I see, so kinda invisible.
Unfortunately, the default implementation of Command-` limits those switches to only the windows in a specific “Space”. Fullscreen windows are in their own space, so they are skipped. I want it to work for all WriteRoom windows…
So I created that “Cycle Through All Windows” menu item and used the Command-` shortcut to override the default behavior and not skip those windows… did it this way so that if I user really liked the other behavior they could remap that shortcut and then Command-` would go back to original implementation.
That was long explanation. Does it make any sense!?
Is there a way I can see my progress while in full-screen mode?
Currently not live as you type, you need to move mouse to top edge of window to show titlebar. Hum.
Yeah I didn’t add this yet, but thanks for reminder
Ah! Apparently there are differences between ISO layouts and ANSI layouts for US English keyboards. Mine (laptop, magic keyboard and ipad) look like this:
I do use the same (spatial) logic to cycle windows on a keyboard, which for me is cmd+§. I suppose the fix is to just use a custom menu shortcut to have WriteRoom cycle windows the same way as other apps do. Will test it out and see if I have any issues.
EDIT: Initial test looks like macOS overrides the custom shortcut I set with the one I have set system-wide for cycling app windows
Thank you. This was very clarifying. I think the only real surprise for me is that this implies you are not expecting a preview or export function. If that is the case then the markdown is really just text and the choices for it are less consequential. On the UI controls front, I very much admire your restraint.
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!
Targeting GFM seems like an obvious choice then. It has the extensions that people expect and seems to have critical mass for its syntax when it differs from multimark, kramdown, etc. On top of that you might want footnotes in a writing focused app.
On the quirks side, my preference for a writing app that always wraps lines would be to treat a single new line as a line break. This is a semantic change but Obsidian, chat apps and GitHub comments already do it this way. You could add a checkbox in settings to flip this. The other semantic change to consider is around setext headers. A line followed by an intended horizontal rule creates a header not a line and a thematic break. Writeroom shows this with syntax highlighting, so it is manageable.
Other quirks should also be syntactically highlighted. You have this mostly covered, but code blocks either fenced or indented don’t get any today. I can see the indented block causing headaches.
WriteRoom’s perspective is definitely that Markdown is just text. WriteRoom just provides some highlighting and commands to make editing it a bit nicer. If WriteRoom is missing support for some Markdown syntax, then that just means you need to manage that syntax yourself.
Also yes, to avoiding preview. Though forever, I’m not sure. On one hand I really don’t want that UI in WriteRoom. On the other hand they are useful for certain types of docs, and it would be nice to make it easy in some situations, but for foreseeable future I think answer is a third party preview like Marked.
I do think I want some sort of export. Mostly for users who want bold text, but don’t want to learn/manage full Markdown ecosystem. My thought is just some extra copy commands Copy as HTML, Copy as Rich Text, etc. This will get content out (in, depending on wanted markdown features, a limited incomplete mapping, but something that can be pasted into an email, doc, etc) for basic usage.
This is in regards to the Move commands right? If so I understand and will add option. Or is there somewhere else in app that this distinction is important?
Again you are talking about move semantics? I think WriteRoom is currently handling this as I would like for the structure moves… both elements move together.
I am parsing, but hadn’t added styling yet. I’ll add a light background. For GFM code block I’m also going to change so moves within it are alwyas raw line moves, while if you place selection on ``` then it will move the whole block structurally
I find that holding opt+up/down doesn’t move caret between paragraphs, it gets stuck at the end of line.
Also, if I do shift+opt+up/down, I won’t get a text selection at all (usually I expect this to be the equivalent of ctrl+shift+E)
This is also true if I have a selection around a word (or more words), and then hit shift+opt+up/down. I think other selections work as expected.
I feel the word count/progress bar implementation could be a little more…WriteRoomy?
Ulysses will let you detach the word count bar and drag it with you to full screen mode. Not the cleanest solution, but at least you have information available at a glance. Pagi does it with a literal progress bar:
Another useful feature I’ve found with other apps is seeing a visual indicator when I’m just shy of the goal, reached it, or significantly exceeded it (which is sometimes not a good thing). Usually that manifests in some form of colour in the goal indicator.
I did originally try to style it like DEC terminal and float it in with text in some way. But two big problems. Eventually I want anyone to be able to create a theme, it gets complicated trying to make arbitrary themes match UI. Second I never could find a good general place to put the counter. I will look at what Ulyses does, maybe draggable is good, though that gets complex.
I think easiest solve might be to show count info in a glass button that overlays the text when the titlebar isn’t visible. And also option to hide that glass on typing. And show again on mouse move. That way you could see quickly with mouse move in fullscreen. Or if you really waned all the time you could see then too.
I think I’d be happy with hide on type/show on mouse, tucked away in a corner. Might not even need the glass bubble, would be equally happy with just a tiny number.
As for styling, how far do you expect theming to go? Just background/foreground, or also syntax colors? Not sure I have a preference here, I just like Pagi’s example for progress bar because it’s satisfying to see progress build up at the bottom of the screen, and the bar’s color matches accent color.
