Agreed. But adding HTML & CSS code to Markdown documents easily introduces the same issue and kills also the readability.
3 Likes
If you add CSS directly to MD or HTML – Yes. Otherwise it’s all about separation of semantics from visual appearance – neither MD nor HTML are dealing with the latter.
This is the kind of question that I fear will lead to a tremendous amount of bikeshedding, but FWIW, here’s my list.
For notes:
- OmniOutliner Pro 5
- Plain text with Markdown notation (and frequent use of LaTeX/MathJax)
I’m an oddball user of OmniOutliner. I use OO for writing in a structured way, not for outlining – in fact I almost never use it for outlining [1]. My templates are oriented towards making it easy write certain kinds of notes to myself.
Since I code a lot and use GitHub, I use Markdown there and for things outside of DEVONthink more generally, despite that I personally don’t like the Markdown notation very much (but I do like plain text). It’s also the format used by the software documentation tools I’ve been using (Sphinx + MyST).
For spreadsheets:
- Apple Numbers
- Google sheets
For presentations:
- Apple Keynote
- Google Slides
It is very handy that DEVONthink can show Google docs via its built-in browser. This makes it possible for me to save bookmarks to documents in Google and view them in the context of my projects, which I store and organize in DEVONthink.
For things I read:
I save basically everything else in PDF format: academic papers (via Zotero), books, web pages, RSS feed articles, blog articles, newspaper articles, scans – basically, if it’s not something that I produced, I save it in PDF format. This not only preserves it in the way that I saw it with zero external dependencies (important if the original disappears or changes); it also lets me make notes on it/about it in a way that is searchable. DEVONthink has fabulous features for working with PDFs, and I was over the moon when DTTG introduced the new(ish) PDF markup tools. I now read and mark up articles and books in PDF on an ipad, and also use the “annotation” document feature in DT (with a custom markdown template for writing “reading notes” to myself).
For documents I write for consumption by others:
- Plain text with LaTeX markup
- Google docs
- Apple Pages
I have decades of experience using LaTeX, have even written custom LaTeX classes, and find the combination of LaTeX + Emacs very comfortable. When DEVONthink added support for MathJax, I was over the moon a second time, because I could reuse my experience with typesetting math rather than have to learn some other notation or use some kind of GUI math editing tool.
But I’m old, and younger people (and even not so young) around me prefer Google docs or Microsoft Word. I can’t stand Microsoft Word for many reasons [2], but can tolerate Google docs, and don’t mind Apple Pages for quick documents and things that need heavy visual formatting. As much as I love my Emacs and LaTeX, I have to admit it’s slower for some things than a word processer like Pages.
[1] This way of using “outliners” might have originated in the days of MORE back in the 1990’s.
[2] Mainly due to decades of muscle memory for key bindings in Emacs that can only be replicated to a small extent in Word, but also other things.
3 Likes
I am in the Markdown camp. But if the HTML-based formatted note in DT ever approaches the capability of the HTML-based note found in Evernote back in the day, I would switch to it.
2 Likes
I think this survey might have had different results if we were asked to pick out top two “writing formats”. For myself I would have chosen markdown 60% / Word 40%, and only chose markdown in the survey because it dominates my use.
I chose markdown because most of the places where I write are what I’d call “plain text with markdown support”. But for clients I’m hard-core Word, because that’s what they demand and that’s what I’m fluent in. I’d prefer Pages, but try to find a corporate or governmental client that says “sure, Pages”. I see very little upside in writing with one format and then having to convert to another – that’s just avoidable work.
6 Likes
“What’s your most commonly used writing format?” Thanks for asking.
I don’t have any single most commonly used format. The format I use depends on the purpose of the document, and whether or not I need to keep it in DT/DTTG.
For letters, captured webpages that I save as PDFs (I have my own home-brewed system for this using Keyboard Maestro, AppleScripts, and a giant Nisus macro), and any document that needs accurate placement of objects on a page, especially for printed documents, I use Nisus Writer Pro/RTF(D), kept in DT if necessary. I stopped using Office/Word decades ago and my life is much better for this decision (but I don’t need to collaborate on documents with others). I also use Scrivener/RTF for the occasional longform work that I finish off in Nisus.
For uncomplicated and throwaway documents and notes, I use plain text, created and kept in DT if necessary. In my experience, TextEdit is buggy in Monterey and frequently hangs, so I have turned to BBEdit for plain text documents that live outside of DT.
For research, notes, and general project work kept in DT, I use markdown almost exclusively. I was dragged kicking and screaming away from RTF(D) to markdown in DT because RTF(D) isn’t supported on iOS very well, and I will soon enter into The Great Sync Adventure with DTTG and my iPhone. I’ve come to be comfortable with markdown and have made a nice CSS but I struggle with it partly because DT’s editor could use some enhancements (see *note below), and also because MD/CSS quickly becomes littered with HTML and becomes hard to parse visually in the editor, because markdown is so pared down and requires custom CSS for more complex documents. And printing…well, that’s another adventure into CSS, that is baffling to me. In my experience, MD/CSS is great for simple documents that don’t need to be printed, but having to learn what appears to be an object-oriented custom syntax for text display and layout is a bit much…but it is what it is, and I make do.
On the positive side of MD/CSS are: easy AppleScript processing of text, the oft-mentioned portability insurance of plain text, and an in-effect read-only copy of a document when viewed in preview mode.
I don’t use DT’s formatted document because the editor doesn’t support lists. And it is just plain weird to me to be creating HTML for non-web purposes.
I never really got into Pages or Libre Office. No need, I guess. But I do have Libre Office installed, and use Calc as a completely adequate substitute for Excel.
Having said all that, after I gave up Office/Word, and in my former use of DTPO 2.x, I used RTF(D) almost exclusively, everywhere, for everything. Life would be so much easier for me if Apple were to support it better on iOS (and give it more complete AppleScript support).
*DT markdown editor enhancements that I’d find helpful include:
- reduction the width and height of the vertical blue bar that delineates blockquotes
- not italicizing blockquoted text
- revised editing procedures inside of blockquoted text that allows for empty blockquoted paragraphs to be entered
- termination of the blockquote by hitting return twice (similar to terminating an RTF list), and
- indentation of items in lists according to their first line indentation/list level of indentation.
Oh, and more precise indentation of list items in Preview mode.
1 Like
What do you mean by that? Preview mode is governed by CSS, so you could adjust that to your liking.
Oops, I neglected to qualify “more precise indentation of checkbox list items in Preview mode”.
Oops, I can’t attach images, so I’ll try to describe the current and my preferred behaviors:
Currently, the checkbox of a level 1 checkbox list item is indented at the same level as the text in a level 1 bulleted or numbered list item. This is to say that the list item indicators of level 1 bulleted and numbered lists fall on the same vertical line, and the list item indicator of a checkbox list is not on the same vertical line, but is indented farther to the right. And if text in the checkbox item wraps, the indentation is flush left at the position of the checkbox’s left edge, not at the position of the text of the item in the checkbox item’s first line.
My preference would be: the checkbox of a level 1 checkbox list item to be indented at the same level as the list item indicator of level 1 bulleted or numbered list item. This is to say that the list item indicators of all level 1 items, regardless of the type of list, would fall on the same vertical line. And if text in the checkbox item wraps, the indentation would behave as it does with bulleted and numbered list items, and leave all list item indicators “exposed”, enhancing recognition.
(“List item indicator”: the rendered bullet, number, letter, or checkbox, that precedes the text of a list item.)
Hope that makes sense.
I guess I have another CSS adventure ahead…maybe I’ll learn something new. Oh wait I just checked (har) my CSS and see that I am overriding ul and ol, so it’s I guess just a matter of overriding whatever a checkbox’s tag is, I think I guess.
I use rtf because my final texts are formatted in Word or Scrivener. Markdown didn’t work well for me. My notes can always be converted to another format using DT if RTF becomes a problem in the future.
My main reason for using markdown is the speed with which I can create headings. Just a few hashtags, and I have a basic outline.
Any long form writing is done in Scrivener.
Almost all my writing is done for myself, so I don’t have to worry about formatting material for other readers.
1 Like
It heavily depends… I am in consulting business and there most of the stuff I write it PowerPoint, next would be Word.
But do not forget about the millions of mails…
Privately I use pages/numbers for letters and stuff like that. My notes are in Agenda (so markdown).
I answered Markdown, but that’s for note-taking. My documentation writing for work is in (yecch!) Word. What I write to sate the muse is in Mellel.
I was going to say how I love markdown but most md editors have inconsistent or completely lacking table support (longing for org mode I guess), but since you brought it up, yes, outlining, absolutely. Anything other than quick editing or general notes, and I head for an outliner first, usually the ones you mention. Saw something online where someone made Scrivener into an outliner, but I though it was kludgy.
I’ve went through several rounds of adopting Markdown, and invariably gave up after a while. It all depends on what kind of documents we write. In my case, it comes down to two types:
(1) Internal “quick” docs (mostly lists): rather simple, text only, but nested lists are a must, boldface etc is also helpful.
(2) “Real” documents: Usually containing full-fledged formatting, in particular images, tables, footnotes etc.
For (1) I find the edit/view separation of Markdown unnecessarily cumbersome (unlike, say, with LaTeX, where it is clear why this has to be that way). For documents at that level, Apple Notes shows the way. Unfortunately it cannot be integrated with DT. For documents of this level of (lack of) fanciness within DT, I find that I keep resorting to RTF for better or worse.
For (2), operating within DT, I use Pages because it has a much nicer interface than Word, and lets me do all the formatting including images, tables, and DT and DTTG provide full quality previews. The downside is naturally that it cannot be edited within the DT window, but as long as Pages is open on my machine anyway, edits are fast and painless. On DTTG, the roundtripping to the Pages app is also a quite good experience. Depending on the purpose, it’s Keynote instead of Pages.
My strictly personal experience: Markdown has lots and lots of options, there is fragmentation, and then there is a hard line, beyond which it’s a no go. People get defensive about the correctness of where that line is drawn. All I can say for myself is that that line does not match my needs very well.
Scrivener for composing, then output to what the journal/press wants, which is usually docx. But for short documents, Pages. I hate Word.
1 Like
No love for plain text?
1 Like
Personal writing - Markdown
Work writing - Word
1 Like
There is no technical difference between the two. MD as TeX are markup languages. Both need some kind of post-processing to obtain something “nice”. In the case of MD, the target format is mostly HTML (but it could equally well be PDF or Word or perhaps even TeX). In the case of TeX, it’s mostly PDF (I think).
MD has been created to make authoring of HTML easier. Not as a note-taking format.
The way to where? A format that is inaccessible to any other app, used by an app that is lacking in scriptability? Can you even create links between notes in Notes?
Not so many “options”, simply markup tags. Fragmentation is obvious, and that’s always causing pain. Some of that comes from adoption of MD to tasks it hadn’t been conceived for, e.g. collective work on the same document (think comments, change history etc). Instead of using a version control system for that, some people decided to “improve” MD.
Hard line – nope, given that you can include raw HTML in MD. And there’s hardly anything you can’t do in HTML nowadays. But it’s of course less mouse-oriented than, say, Pages. OTOH, it forces you to structure your document, which Pages, Word et al don’t: Whenever you feel like it, you can format your 2nd 2nd-level headline differently from your 1st 2nd-level headline. Which is much more difficult with HTML and MD (and TeX, for that matter).
1 Like
Pages for 1-2 page letters, etc - save to pages and/or pdf
Mellel for long documents: export to .docx and/or pdf
Occasionally Nisus Pro .rtf
Markdown as much as possible. Love it. Mainly MultiMarkdown.
For longer more complex documents, I write the Markdown with LaTeX parts (for math, citations, etc), then convert it (via pandoc) to PDF for output/publishing.
Occasionally docx for compatibility with other people when I have to send it off to them for collaboration and they request MS Word compatibility. Then somtimes I convert Markdown to docx (via pandoc) or write it directly in LibreOffice.
Biggest problem with markdown is still that no zip format containing the images is established. Textbundle is a great proposed standard, but it hasn’t gained widespread adoption…
1 Like