Maybe a better way of describing what I’m after is to speak in terms of “affordances” (though my use of the term may not be precise to its definition). For example, the editor:
- Displays a line of text preceded by header markdown in bolded text, at a relative size larger than the body text, and according to the header level.
- Displays text wrapped in asterisks italicized, text wrapped in pairs of asterisks emboldened, and text wrapped in three asterisks emboldened and italicized.
- Displays text wrapped in two ~ as struck through.
I would loosely call these behaviors affordances, and I appreciate them. They give visual cues as to the text’s formatting, and an implicit sense of context. Their implementations in the editor make sense: emboldened text is emboldened, not colored green. Italicized text is italicized, not subscripted.
But, the editor displays blockquoted text in a way that makes no sense. Instead of a thick blue border at the left that takes up far more vertical space than the enclosed text, the editor may just as well show a narrow (or wide, or wavy) vertical line of red (or yellow, or brown) dots (or triangles, or backslashes), that is crammed into the edit space with no top and no bottom padding (or with 150% padding, or 79% padding). Instead of displaying the enclosed text italicized, it may as well show it in a serif font (or shaded pink, or struck through, or in Comic Sans). None of these options, including the editor’s current behavior, make any sense at all that is related to a blockquote.
(OK, then what affordances make sense for a blockquote? Indentation according to the indentation of the “container” wherein the blockquote is placed, a visual cue indicating a blockquote, and a smooth way of working with the format. None of which, in my experience, exist today, in adequate forms.)
And the lack of hanging indents in lists just creates a visual mess that has as the only affordance one indented line and an asterisk (or dash, depending on what you like to use; or a number), per list item. This text more resembles mistakes made during editing, than conveying the ordered sense that lists implicitly lend. A hanging indent is an affordance that brings legibility, order, and context to these lists in the editor.
I’ve done what I reasonably can to change my writing habits to become more accommodating to the editor’s constraints (I don’t nest lists more than 2-3 levels, I break up large texts into smaller files that are transcluded, but there’s nothing at all I can do about blockquoting), but these do not fix any of the underlying problems. The editor is forcing me to comply. But end-user compliance (“making do”) is not a substitute for affordances. And I can’t customize or automate my way out of these conundrums. These behaviors are baked into the editor.
All this, taken together, is why I term the problem “cognitive dissonance.”
And just to be clear, I for one am not at all interested in DT implementing Scrivener’s (or any other app’s) suite of editing features.
I simply want to be able to more clearly see and make sense of what I’ve written in the DT editor, and to not have to dedicate time and energy and money into researching, testing, purchasing, and maintaining another, or maybe even more, apps, to replace the editor that DT has, or wondering at every turn, even after over a year and a half of using v3.x, for hours every day, “Why does it do this? What kind of sense does this make? I can’t make sense of what I’ve created.”
It’s very frustrating. More affordances, please.