I know how to do that in CSS. I was talking about the editor. All editors I know of allow specifying the width in characters and insert an automatic soft line break when that limit is reached.
@cgrunenberg: for proportional fonts, one could still specify an average number of characters, using en or x width as average value.
This doesnât work for rich text or formatted notes which can use lots of fonts.
The thread started suggesting changes for MD editing. So thatâs what I was referring to. I guess in RTF people would use metric/imperial units for width and/or margins.
Sure but it doesnât make sense to limit it to Markdown.
Itâs your call anyway⌠But Iâd actually make a difference between WYSIWYG and other formats. Emacs, vi, VS Code etc. are used for pure text formats and thus allow setting the width in number of characters.
Word, TextEditor etc. are used for (more or less) WYSIWYG, so they use another concept: Left margin, right margin in metric or imperial units.
For every format, its concept makes sense (and the other concept not so much).
Re. Markdown source view: specifying width in terms of number of characters works perfectly well with proportional fonts. It may take more tinkering to get the view that the user wants, but once set itâs not going to be changed much, if at all.
Ulysses, for instance, allows the use of monospace or proportional fonts but only provides the ability to set width in characters.
Setting a default width in RTF or formatted notes is a different matter. As @chrillek said, WYSIWYG and text probably need different approaches. For WYSIWYG, can you use the RTF ruler, or a DT implementation of it that allows for defaults to be set in Prefs?
In case of multiple devices having different screen sizes, a simple setting might be preferable. Especially as a setting can be easily changed and affects already existing documents too.
True. And tricky.
FWIW, the fixed width editor setting in Scrivener (which is rich text) uses points. Which would make it font-independent.
Itâs also a setting of Scrivener itself, not a specific project, so you can have different settings for the same file on different computers.
Amen to that! A ruled pad and your favourite writing instrument also works!
@BLUEFROG @cgrunenberg
Any updates on implementing a kind of width control to the source document (writing mode) for markdown files ?
Thank you 
Itâs part of our endless to-do list.
My 5 cents;
I like DEVONthink, it fulfills most of my needs. Except for the editing experience. I spend my time almost equally in preview and editing views and my beef is that I find myself continually swapping between the two. I get that thereâs a split view but this takes up unnecessary screen real estate in my view and this is why I would like a genuine WYSIWYG editor in DEVONthink. Because it fulfils both of my needs reading and editing without the inconvenience of swapping between two viewing modes continually. I get why people are saying edit externally but didnât think isnât good to make this experience easy in terms of images - which I use a lot - because the external editor canât see them. So Iâm back on DEVONthink for editing which with the best will in the world is very basic when it comes to editing.
I see people arguing against full WYSIWYG Editing in DEVONthink and I fully understand why they wouldnât want to use it but equally there are others that would and the ones that wouldnât but it could be an option, surely. Or at least figure out how to have external markdown editors such as Typora play nicer with DEVONthink media.
That would be up to the Typora dev to figure out, not us.
I donât really care whose job it is, Iâm more interested in the quality of my user experience. That said, Iâm sure you guys could make it happen if you really cared enough.
Ouch.
Where does that conviction come from? There are examples of external programs playing nicely with DT, which (in my mind) does imply that DT provides the necessary scaffolding for that. Even on mobile, btw.
So, what makes you think that the DT guys and gals have to make anything happen here, as opposed to the Typora people?
As to images:
That depends on your setup. If you store your images inside DT (as opposed to indexed folders) â yes. Otherwise: no, every external editor can see everything in a folder on Mac. Also images in folders indexed by DT.
They can even use images imported into DT, but that would require you to refer to those images in your MD files by means that are complex and error-prone.
Another question is how sensible it is to rely on MD as a format if one uses âa lotâ of images. I wouldnât go there because it is known to cause problems. MD has not been conceived for that, but to be an easy way to produce HTML. And HTML in turn is not the best format to access locally stored images.
That kind of attitude really doesnât make people eager to listen to you.
If itâs important enough to you, you could also try to figure out a solution.
PS. Do you really need to see the images while youâre writing?
Markdown is not designed to accommodate âa lotâ of external images. As a lightweight markup language its primary purpose is to give formatting to (plain) text. That you can add as many image references as you want does not mean it must be a good idea.
If itâs important that images are always displayed properly along with text, then formats with embedded images, such as RTF or Formatted Note, will serve you better.
If your images are important data points which can be referenced in multiple documents (hence no embedding), why not open your images as individual documents?
You are entitled to force all your way through markdown. But, again, itâs perhaps not a good idea.
I do agree that true WYSIWYG is desirable, though technologically speaking itâs not something trivial.
That depends on the target, I think. WYSIWYG in a world of screens with varying capabilities (size, pixel density, color space, what not) is not feasible. Unless you want to go back to the âBest viewed with IE6 timesâ.
On paper, WYSIWYG is available for ages. But there you have a fixed page size (or you can fix it), you know which fonts are available (or you can embed them), and there are means for color space adjustments (the latter will always be a challenge because perceived color depends on many things).
Aiming for WYSIWYG on screen is, imo, a futile exercise. The better approach would be go with responsive and fluid design.