I actually don’t like the text that I am working on to look like a refined press article in a magazine, a beautifully typeset page from a book or a nice looking website. It is not a published text. It should look rough, unfinished, unrefined and functional (to me). When I write on a piece of paper, my handwriting looks ugly, irregular, misaligned and maybe there are some drops of ink splattered around, so I don’t want my editor to make me believe that my writing looks presentable.
For Org Mode, my main concern is that I want to quickly identify the structure of my documents and differentiate all the relevant parts visually. I like to keep font sizes and spacings small to fit as much text (= context) on my screen as possible. I also like using monospace fonts because it feels more like working on a draft (e.g. with a typewriter) to me and I can work more spatially with text (e.g. making little diagrams or figurative text arrangements) which would not be possible with proportional fonts.
When everything looks too good/refined, I get distracted by wanting to shape my text to make it fit in that perfect environment. Then there is no space for swift notes, unfinished drafts, rough edges and this becomes a problem, since I am already a compulsive perfectionist and like to waste a lot of time with irrelevant details. Of course, this is just my personal preference, so I am not saying that this is how it should be. Maybe I am just trying to understand why I like it better this way.
I wrote exactly the same thing before reading your comment. I completely agree. For me one of the great things about writing in Emacs is the distinction about my personal draft and my published outuput, which is expressed by the distinction between a 'typewriter' fixed-width font and a beautiful LaTeX processed output. Blurring that distinction produces an anxiety.
Two things though. I think org-mode syntax is not the most ergonomic and beautiful. In facts, that's the reason I stick more to Markdown when writing. Second, the problem I see here is that they want to change the source text into a formatted one. Basically introducing WYSIWYG from behind through the knee, but the source is still plain text. Can be done, but comes with challenges and side-effects (there is a reason Enriched Text[^1] never took off - although Richard Stallmann still dreams to have more WYSIWYG capabilities in Emacs)
I think this misses the point of org-mode. Markdown is even one of its outputs. Org-mode lets you write in an environment that is aware of the semantic meaning and structure of your content, from headlines, latex, diagrams and lists to blocks that can execute code or make web requests, tables that can have spreadsheet calculations not to mention the time tracking features.
I can understand wanting a simpler text format to focus on writing, but there are many editing tasks such as writing a blog or making project and study notes that really benefit from a more capable environment.
It's also very opinionated about that structure, to the extent that it'll get in the way of WYSIWYG'ing the content.
I've driven myself half-mad just saying "These two outline blocks are too close together" and adding some newlines only to have the header-collapse hide those newlines and squash the two outline headers back together.
What do you use for writing markdown? Any recommendations?
I use org mode very lightly, mostly just collapsing information I don’t want care about as I’m writing and making formatted tables. I’ve thought about exploring markdown and other editors but I haven’t really seen evidence it would be much of a gain.
My main authoring tool is then Emacs Markdown Mode (https://jblevins.org/projects/markdown-mode/). For data entry, it comes with some bells and whistles similar to org-mode, like C-c C-l for inserting links etc.
I seldom export my notes for external usage, but if it is the case, I use lowdown (https://kristaps.bsd.lv/lowdown/) which also comes with some nice output targets (among the more unusual are Groff and Terminal). Of cource pandoc (https://pandoc.org/) does a very good job here, too.
notably, the above mode lacks the single feature the grandparent uses: collapsing sub headings. In addition, it requires an external tool to export
org of course can be exported into many formats without an external tool, including several plain text formats and HTML, and is also understood by pandoc
I use Org but markdown-mode can hide subsections too:
markdown-mode supports outline-minor-mode as well as org-mode-style visibility cycling for atx- or hash-style headings. There are two types of visibility cycling: Pressing S-TAB cycles globally between the table of contents view (headings only), outline view (top-level headings only), and the full document view. Pressing TAB while the point is at a heading will cycle through levels of visibility for the subtree: completely folded, visible children, and fully visible.
oh, my apologies. I both use this mode and searched for the above functionality on the above link "to be sure" before commenting, but I guess I missed it.
In my feeble defense, it's hard to confirm a feature is missing T_T;;
For most of my writing (journal entries, notes), I have never needed the collapsible subheading and export functionality because I write primarily for myself. If I think a note is ready to be published on my blog, I will still rewrite, edit, and polish it in a separate file. Mostly also in Markdown, because the structure of such articles does not go very deep (I am not a fan of many levels of headings) and my static site generator handles the export to HTML in a fully automated way. No need to export anything manually.
I'm curious what makes you consider it non-ergonomic? For the things both support, I don't remember that many differences. Org shines, though, for all of the other things it also supports. In a real sense, it is more in the same realm as jupyter than it is markdown.
I think org-mode has several fairly orthogonal use cases, including literate programming (your Jupyter reference), outlining, markup, task management, spreadsheets, and many more. And the community has done an amazing job of implementing all of these really well, each for itself, while still maintaining a working ecosystem. But I only use a small subset of that when I use org mode. The amount of metadata that needs to be included in a full-blown org-mode document seems to be increasing, and I feel more and more like I am writing a specification with verbose syntax (and personally, I find "#+BEGIN ... #+END" blocks or similar keywords unappealing).
Literate programming is rather distinct from notebook style, though? I can see surface comparisons, but they are very different.
I can see not finding the markup appealing, but that is why you would export for viewing? And, outside of moving some of that to a binary format, I don't know how you could get this level of stuff in band? I suppose you could strictly hide it in view? Would probably still want the markup in data.
None of which is answering what makes it non ergonomic? Basic text with an actual table format is about what I'd hope for it to be. What is off?
Links are different. Everyone seems to redo that idea. Rst files, I still always get wrong on first tries.
I think that's really the key thing, and I didn't realize it until only recently: org-mode fits a Jupyter mental model better than a Markdown (or outliner, etc.) mental model.
It's great for what it is, but what it is doesn't 1-to-1 map to much else.
I think this makes sense. If you are viewing it as marking up a static document, then a ton of the affordances in org-mode make little sense. Most of it is about interacting with a lot of data that happens to be represented in plain text.
For a lot of us, that focus on the plain text is important. As it helps keep us focused on all of the other affordances that we have grown accustomed to in emacs. As soon as you move things into a binary format, you are likely giving up on a lot of the other tools you have. There can be reasons to do this, of course, but for most data that you interact with at a personal level, most of those reasons have been overcome by the power of the personal computer.
> I think org-mode syntax is not the most ergonomic and beautiful.
Which parts about it? I actually agree with the sentiment, to my taste there are some aspects of org-mode which are better than Markdown, and some which are worse, and on balance Markdown wins the contest.
I have a project which is attempting to meld the benefits of both, so I'm interested in what you see as org-mode's pain points.
I'd advise not worrying about the benefits others see to either, if you are wanting to meld them. Instead, meld the parts that you like above and beyond anything else.
My reasoning is that the main advantage of Markdown is the crowd using it. It is not an unknown quantity to a lot of folks. Similarly, the biggest "pro" of org-mode is that it has all of the power of emacs. Which, is oddly its biggest con to the crowd that doesn't like it.
I would prefer to say that the biggest "con" of org-mode is that, as the name suggests, it's tightly coupled to emacs. Implementations of the syntax for other environments are necessarily partial. org-babel might be the best literate programming system there is (it's up there), but I don't want emacs as my compiler.
> I'd advise not worrying about the benefits others see to either, if you are wanting to meld them. Instead, meld the parts that you like above and beyond anything else.
I'm not worried at all ^_^ but I don't mind learning from others either.
Totally fair, I think. My assertion would probably be restated best as "don't expect straight forward answers to the direct question of what is the best of each." I do specifically called out that network effects were the biggest pro of Markdown, and oddly the biggest con of org-mode. But, my main point in doing that is that I doubt most of the fans of either would list that.
Obviously some of us would, such that I could easily be wrong. Wouldn't be the first time. :D
Any recommendation on how to get started with emacs? I tried it a few years ago and was so hard to use it, after that I switched to nvim, but now I have interest in learning emacs again.
The built in tutorial followed by a couple of weeks of forcing yourself to use it for basic editing tasks until you find yourself comfortable again. Don’t try to recreate a full IDE experience at first. Try to walk before you run. The beauty of emacs comes from discovering that it solves problems you didn’t know you had rather than being a drop in for your current IDE.
Thanks, great advice, I would say it was my mistake before, I wanted to configure everything how I wanted and the information was overwhelming, plus the learning curve.
Emacs 29 made getting started a lot easier IMO, my from-scratch configuration is pretty minimal and I use it everyday. To plug my own project, I built a "kickstart" equivalent (https://github.com/mgmarlow/start-emacs) that sets up some recommended defaults and packages with lots of comments so you can easily extend it.
Many configuration-ish things that were hard a few years ago are now way easier. with emacs 29+. There's way fewer reason to reach for doomemacs etc now because package management, configuring LSP mode, etc is much cleaner these days.
In some ways working through setting up your .emacs the way you want it is a great way to learn the tool.
Agreed. It's gotten easier. If I was starting Emacs from scratch again, I'd probably write my own vanilla config. But Doom helped introduce me when the concept was bizarre and foreign to me, and I'm very grateful for that. Now I'm comfortable with my Doom config, and it works great, so I have little incentive to ditch it.
The problem I have with doom and spacemacs is that it seems to be bringing people into the emacs community using the vi keybindings as default, including people who were not vim users before... which is... strange.
Vanilla Emacs keybindings, or cua-mode, are fine, and probably less of a learning curve than going modal. If you're already in that headspace, all power to you, but half the reason I got into emacs in the first place was because I couldn't stand vi.
I loved working with org mode - but I would occasionally hit some accidental key sequence which would totally blow up my entire document (I am not an eMacs expert so it was probably some vim mode problem)! I also probably tried to over organize things. Maybe with a simpler setup things would work better.
If you're using evil or something similar, I would say that's probably the culprit. Writing in org mode using vanilla emacs should have about the same "surprise" as writing in Notepad. If you have speedkeys enabled (which I doubt is the default), then yes - certain keys at certain positions will cause surprising behavior.
This is why I like nano. Easily the simplest editor out there that actually feels like modern command line software and not something vestigial from the 1980s. All I need is syntax highlighting anyhow and nano checks that box after a git pull of someone elses hard work making those rules for every file format under the sun.
I enjoyed the article, but just wanted to say in case the author sees this: it's "whet" one's appetite. I don't know why. If it was me, I'd be thrilled if someone told me, so I'm taking that risk.
'Whet' means to sharpen (whetstones are used to sharpen knives, for example), so whetting one's appetite means to sharpen appetite, or to make one hungrier (for knowledge, food, whatever).
Are you running it via Xwayland? If you compile Emacs with ./configure --with-pgtk, the blurriness disappears. It’s a fractional scaling thing that does not interoperate well with X stuff.
For Org Mode, my main concern is that I want to quickly identify the structure of my documents and differentiate all the relevant parts visually. I like to keep font sizes and spacings small to fit as much text (= context) on my screen as possible. I also like using monospace fonts because it feels more like working on a draft (e.g. with a typewriter) to me and I can work more spatially with text (e.g. making little diagrams or figurative text arrangements) which would not be possible with proportional fonts.
When everything looks too good/refined, I get distracted by wanting to shape my text to make it fit in that perfect environment. Then there is no space for swift notes, unfinished drafts, rough edges and this becomes a problem, since I am already a compulsive perfectionist and like to waste a lot of time with irrelevant details. Of course, this is just my personal preference, so I am not saying that this is how it should be. Maybe I am just trying to understand why I like it better this way.