I’m with David. The option to have a narrower writing column would make DT - at least for some of us - a far more pleasing environment in which to write.
As always, YMMV.
6 Likes
A future release might include such an option.
8 Likes
I always find these types of posts interesting. On the one hand I think it’s completely acceptable to make a feature request. I certainly agree that the markdown editor in DT isn’t as full featured as other markdown editors. But, also, instead of anxiously waiting for something that may or may not happen (DT overhauling the markdown writing experience), I’ve just changed the way I look at my work.
I’ve always been on the lookout for the perfect writing app. Mostly to procrastinate actual writing. I was snapped out of it when I had a conversation with my wife and asked her what apps she uses to write.
Wife: Word
Me: Just… Microsoft Word?
Wife: Yeah…? What’s wrong with Word? I wrote all of my college papers, a masters thesis and a phd dissertation in Word. I wrote my book and journal articles in Word. It works fine.
Me: Did you change anything in Word to make it easier to write?
Wife: What? No! Who cares about that?
May we all find apps that work for our purpose and may we all be satisfied with them!
8 Likes
Your wife is a wise, wise woman 
3 Likes
A bad encounter between my masters thesis and Word is the reason why I avoid it as much as possible. To each their own.
But it’s definitely true that searching for The Perfect Tool (which doesn’t exist) can easily become a form of procrastination. Especially since you can’t know whether this one is The Perfect Tool until you’ve used it for a while, thereby dealing with the learning curve, with extracting your material from the last (Im)Perfect Tool, and so on.
(She says sadly, having just reluctantly removed two Imperfect Tools from the toolkit.)
3 Likes
Thanks - that would be terrific.
1 Like
I made a pretty good income as a management consultant for small startups whose deliverables were big documents written by teams of people. With good instruction and coaching Word does work very well. Like all software wishful “bending the product to your will” never works. that is why I coached doing it the way that works for all so that we could focus on the deliverables not complaining about Word. That being said I have not used Word for anything significant in more than a decade and and use another favorite writing tool (not DEVONthink which I use for research). Neither product do I try to “bend to my will”.
3 Likes
OK, I have made a Keyboard Maestro macro workaround that eliminates the disorientation caused by the text insertion point jumping in and out of a blockquote as I edit it. So I can scratch this off my list.
Do I understand correctly that you are not interested in considering revising the treatment of blockquoted text rendered in the editor?
Please consider changing the appearance of lists in the editor to include level-appropriate hanging indent, to make list items more recognizable and more legible. I’m not suggesting that lists be made pretty according to some criteria, or that they be rendered with the CSS currently in use for document rendering, or asking for WYSIWYG editing, or for the DT markdown editor to emulate any other app, just that lists in the editor be made more legible with hanging indent.
Thanks.
I’m not sure who you’re talking to.
No one has said a firm “No!”.
And no one has declared “Yes!”
However, there are sound logical reasons for the current appearance. And this has been the behavior for a long time now, and without complaints.
1 Like
I thought I had replied to you but I guess somehow I didn’t. Sorry for the confusion.
I can appreciate that there are good reasons to make block quotes visually distinct in the editor. In fact, my premise is exactly that: there are good reasons to make blockquotes (and list items) more legible in the editor, by making them visually distinct, following the precedents that I’ve described concerning treatment of headers and text in the editor, which are very helpful. But I find this specific blockquote implementation (appearance and behavior) disorienting, for the reasons I’ve described.
The blockquote implementation has been bothering me as long as I can remember, some time after updating to v.3.x over a year and a half ago. As far as other complaints about the appearance of blockquoted text go, there’s another in this comment (that also also includes additional issues concerning blockquotes):
And also in this comment:
Could you please comment on:
Also, lest I sound ungrateful, I use DT for hours every day (indeed, a good portion of every day), and greatly appreciate its capabilities, the incredible scripting dictionary, and the terrific support that includes this forum and its members. There is simply no other app like DT.
Thanks.
I was just hinting (personal taste I know) that I don’t find the aesthetics of that thick blue line in a block quote too pleasing, but DT3 has always been focused on function, and it does that well. Having said that, when writing a document all the time is spent in the editor with side by side view optional, and I would think there are gains by making small changes to the editor experience as others have noted, for me the big one is choosing line spacing, and wrap too – my quip about the block quote was simply that it could be a bit more subtle rather than the wide blue line, but of course we all have our own personal tastes. I too like a bit more white spaces in the margins, as well as between lines, all that can be controlled in the preview with CSS, but the editor is less flexible in its current form, but a little bit of flexibility wouldn’t hurt in the view you will spend all your writing time in.
1 Like
@cgrunenberg +1 to the thanks! This would really be great. With indexing and markdown it’s not that bad to switch back and forth between Devonthink and iA Writer, but I’d rather just stay in DT!
But your documents are stored in DEVONthink? If you like iA Writer, use it. Best of both worlds.
I wonder what’s the usually preferred way to configure this - a setting for relative/absolute width of the writing column or a setting for relative/absolute margins? And no, we won’t add all theoretically possible options as DEVONthink has already way too many options
1 Like
My hunch is to set the width of the writing column - that way if the user resizes the window, the column width doesn’t change, unless the window becomes actually narrower than the column itself. (After writing that, I checked iA Writer and that’s how that program does it.)
2 Likes
I’d go for number of characters and perhaps a left margin.
The number of characters is of course only useful in case of a monospaced font.
body {
max-width: 72ch;
}
?
This is only useful for the Markdown previewing but not for Markdown, plain/rich text or formatted note editing.
Gotcha. 