…or, WYGIWYG
Context: in the Olden Days, I used a word processing application to write papers for school. The computer I used didn’t have pixel-level display, so rather than rendering the document as it would appear on my printer, I just got to edit the text along with the embedded control codes to turn on and turn off formatting – notably, at that time, things like underlines (for titles) and superscripts (for footnotes). I would frequently need to print out my paper just to see if the lines were long enough or too long (no auto-wrapping then!) or to make sure I’d remembered to turn off the formatting, or that I’d used the correct escape sequence.
Today, most people prefer to use a document editor that shows them, on their computer’s screen, what the output would look like if they were to print the document right now on their relatively high resolution printer. It may surprise some folks to learn that this represents a far lighter mental load than the older model, where the person writing the document had to maintain a mental model of what the output was going to look like, while simultaneously reducing the likelihood of a mismatch between the mental model (the preview) and the output! The folks who are surprised by this often advocate writing their papers using Emacs and LaTeX.
Enter Inspector Well, Actually
Storing the “turn on/off bold” control sequences in the file but only displaying the results on the screen is great for people like me, who just want to style their text, but it annoys the folks who try to solve underlying problems. See, they would argue that I don’t really want to make something bold typeface, actually, I want to emphasize it. So there really ought to be a semantic tag that marks that content as emphasized and the way that gets rendered should be up to the output device, or the reader or whatever. So we get HTML and SGML and LaTeX, but that solves a problem that most of us who are me do not have. What I want is to embed styles and not semantics, and I want to see what the output is going to look like so I can be sure I’ve done the right things. HTML is just over the top complicated because of Historical Reasons and Trying To Do It All, so for a kind of abbreviated, presentation-only, easy-to-manipulate compromise we have Markdown.
Even with Markdown, though, there’s still embedded styling sequences. So it’s kind of handy to have a preview, like maybe an editor pane that shows the actual document you’re editing and then a preview pane that shows what that document as it exists right now would look like. And a lot of people who write editors agree: SubEthaEdit does this, as does MacDown. Heck, even Visual Studio Code does this. BBEdit supports a preview, although what it really does is generate an HTML file and hand it off to whatever web browser you want, so, less a preview and more of a “I’ll save you the paper and ‘print’ it to your browser.”
But, let’s say you’re developing Swift code on a Mac and you want to document the project in, oh, a README.md file. Unless you’re targeting a non-Apple platform (Swift on server, perhaps) the odds are that you’ll be using Xcode to do it. Does Xcode understand Markdown? Absolutely! It’ll do syntax highlighting and adjust typeface sizes so that headings are big and red and things are bold or whatever. But preview? Nah, that’s for suckers. I feel like Xcode is really Apple’s way of saying the quiet part out loud, sort of like MPW in the old days: “If you know, you know, and if you don’t, then suck on it.”