Org-Mode for Visual Studio Code | Hacker News Reader

Org-Mode for Visual Studio Code

github.com

331 points_lbaq124 comments

As much as I like spacemacs/emacs, org mode truly is one of the best things about that editor, and its amazing to see it gaining some real momentum with those outside that ecosystem. This should do wonders for org mode, but more than that, give a lot of people scared off by emacs the chance to use the amazing org mode features.

org mode is literally the only reason I have spacemacs installed. If this is at the same quality bar I may move to VSCode completely.

[edit]

It's missing a lot of the keybindings that made org mode so fast to use so not 100% there yet. Still awesome project and hope it gets continued investment like VIM mode for VSCode.

magit is also a good reason to have it installed outside of it's text editing capabilities.

dito, the problem with spacemacs is that it starts so slowly, VSCode is way faster to start.

The usual workflow for emacs is to launch it as a daemon and use emacsclient

Oh, I usually have it running 24/7. The problem with spacemacs is it's an absolute bear to get running on win32. Takes me a good day+ to sort out the exact details every time I setup a new machine since it seems to change. Last time if I recall right I had to turn off https which was not confidence inducing.

I've given up on running emacs on win. These days I run an X server, use bash-on-windows for SSH, and then forward X from a headless tower in a closet or a virtual machine to my desktop.

Same thing here. I am looking for a lightweight editor because Spacemacs is heavy for me.

> give a lot of people scared off by emacs

I'm not even scared off, but I won't use Emacs because it doesn't have tabs. I know about the alternatives presented, but I just want tabs. I find it funny that the kitchen sink "Eight Megabytes and Constantly Swapping" Emacs doesn't have a built in tab implementation while the supposedly small Vim has one :)

I've found tabs to not scale as a UI idiom, generally. They're ok for up to about 10 documents, after that, I'm looking for something else.

I normally use IntelliJ with two panes open, and about 120 tabs between the two of them. But because IntelliJ tabs can't scroll and Java filenames are long, the tab I want to switch to is never visible, and the tab list dropdown is painful to scan. C-n and C-S-n are what I end up using.

And for the browser, I use tree-style tabs. The hierarchy keeps related tabs together, and I can collapse when I do a context switch. The fact I can see all the (top-level) tabs at once in a long list means spatial memory works better.

In emacs, I use Helm and Projectile, bound to F11 and F12 for buffer and project searches. I've bound buffer switching to C-prior and C-next (those are PgUp and PgDown), and since the buffer order is basically a LIFO of whatever buffer you jumped to, the buffer you're looking for is usually within easy scrolling reach.

I'm curious. Do you end up with so many tabs open because you don't bother to close them when you're finished with them? Or is there another reason?

I also use a really big amount of open tabs in my web browsers (I group them in different windows). On IntelliJ, though, I use tabs as my "working area", and it never spans more than 8-10 files. It helps me keep my commits small and focused, never touching too many files.

PS: You can disable tabs entirely by setting tab placement to "None".

I can only see three to five tab titles at a time per pane given the screen width and long class names, and I'm generally navigating across 10+ files at a time (jumping to definition and uses, usually). This means the right tabs are never available for me to click on, so I just ignore the tab bar altogether for selection purposes. And since I never close them, the open set expands to my working set including reference code.

I can't hide the tab bar because I need it to control which pane a file is showing in. E.g. I want test and implementation visible at the same time; this usually requires that I drag one or the other tab to the other pane, because IntelliJ brings tabs to the front of whatever pane they're already living in, rather than moving them to the currently focused pane.

I do my commits from magit in emacs. I generally don't commit at all until I've done something somewhat significant, but I'll break it down into commits on a diff hunk by hunk basis, which magit makes easy. I don't use the IntelliJ SCC tooling.

In the current reality as it is tabs seem an essential part of a web browser and some other apps. But I feel like tabs should not be done by any app - a window manager is to take care of this IMHO.

I especially don't like tabs in IntelliJ Idea: I never (except the cases when I want to detach one to a separate window) actually use them, every time I want to switch to a particular file in a project I choose it in the project tree in the left panel, the tabs only pile up atop of the editor pane and annoy me so I close them every now and then.

Hey, I'm with you in feeling that tabs are essential to web browsing but that they should ideally be the window manager's responsibility. For a while I used surf [1] (which lacks tabs) and the i3 window manager, but for various reasons I wanted to move back to Firefox.

I made a very simple webextension that disables tabs in firefox, so that I can use my window manager's tabs instead. I've been using it since the stable release of Firefox 57. http://static.adrusi.com/notable.html

[1] https://surf.suckless.org/

You can get rid of the tab bar in IntelliJ: http://hadihariri.com/2014/06/24/no-tabs-in-intellij-idea/

And I use Windows so a fancy WM is almost out of the question.

I close all tabs now and then, it feels very refreshing.

Many Emacs users don't use a mouse much or at all, and the tab interface is primarily for people who do most navigation using their mouse. For those of us who find having to take a hand off the keyboard slow and irritating, tabs are a waste of valuable screen real estate.

Also bear in mind that an Emacs session for many users lasts for days or months (I just checked---the Emacs server session running on the machine I do most of my work on has been running since last November, and I currently have more than 50 buffers open). In that sort of use-case, tabs don't make any sense, but tools like Helm and Projectile make it quite efficient and easy to navigate among your files and buffers.

I don't have any great need or investment in convincing others to use Emacs. However, people might want to consider that, while new users often detest it, those who do spend the time to actually learn it---which, to be honest, probably requires an investment of time and focus few are willing to offer---then refuse to ever use anything else. Surely they're finding something of value that casual users aren't encountering.

Complaints about Emacs invariably seem to be some variant of "it's not like my favourite editor, which has feature x, so I won't use it". Which always sounds to me a lot like an experienced car driver refusing to try a helicopter because it doesn't have a steering wheel.

I don't use tabs with the mouse. There are many shortcuts for tab management: previous tab/next tab, open tab/close tab, switch to tab 1-9, move tabs around, etc.

Also, with Vim you can mix and match tabs and splits to have many files open at the same time. You also have buffers, which I believe are the exact equivalent to Emacs buffers, you can have a gazillion buffers open at the same time and only a few visible.

Same, I use tabs both in i3 and vim, and I never use my mouse (I use keynav when I have to, for instance with firefox).

I've seen some vim workflows using only buffers instead of tabs, but they required doing :ls :b buff_number to switch to another file, which seems worse than looking at your tabs and repetitively do "gt" to access the corresponding tab.

I could use the ctrlp plugin or one of its alternative to fuzzy search on the file name instead of manually changing the buffer, but I still don't see a real benefit over using tabs. I guess it makes sense with really big projects where you have to open more than 10 files at a time.

For what it's worth, instead of tabs, I used to use file marks. That gives you up to 24 "tabs" that you can switch to using just two keypresses. `mA` to set the current buffer as tab 'A', and `'A` to go to A. That gets you heaps more speed than repeatedly `gt`ing your way through an array of open buffers.

(I don't use file marks for this purpose any more. I got annoyed at how file marks saved and restored the cursor position within the buffer, so I wrote my own vim plugin to use a similar "map this buffer as A", "go back to buffer A" system, without saving/restoring the cursor position as well. I never really properly released it, but feel free to give it a try if you feel it would scratch an itch for you. It's over here: https://github.com/vectorstorm/vim-spacelanes )

Why not use perspectives(or workspaces I can't remember which is which) then? Those are basically tabs without the visual top.

Because the visual top is the most important part for me. I flip through using key shortcuts (I never mouse in my editor), but I hate not having tabs when I use Spacemacs.

Love the closing analogy. Especially because it does not rule out there being a better way to drive helicopters.

To underline that, what folks have working for them is working for them. Sometimes, it can help to try and push out of a comfort zone. But, there are no guarantees. To that end, try what others report as working for them. But don't sweat it.

Install the `tabbar` package using `M-x package-list-packages` or by adding `(use-package tabbar :ensure t)` to your init file and evaling it. To change what buffers show in a bar you can point `tabbar-buffer-groups-function` at a function of your own devising (`C-h v tabbar-buffer-groups-function`) patterned off the default `tabbar-buffer-groups` (`C-h f tabbar-buffer-groups` and follow the link to its definition in `tabbar.el`).

That said, instead of tabs, I recommend getting used to something like helm. When you have 150 files open even windowing and LRU won't help you enough. Switching to buffers by typing in a few characters of their name and then hitting enter can be done open-loop and not having to find things with your eyes is a major speedup.

Emacs can have tabs, besides the obvious tab-bar mode, you could also just use i3. Set it to tabbed mode with super+w,then hit ctrl-x-5-2 to open new frames, they will open as tabs. (Frame means window in emacs lingo)

With Emacs anything is possible. You don't have to settle for buffers. There is also speedbar for a tree-based view.

As a long time Emacs user, I feel the exact opposite. I wish my Window manager, browser, terminal and other things all had buffers which I could easily search through by name rather than tabs.

If you're using a compatible window manager, you may like [rofi](https://github.com/DaveDavenport/rofi/), which in one of its mode, allows you to jump from window to window through their name, a bit like the buffer selector in emacs.

I won't lie, when I first started using Spacemacs it kinda blew my mind there were no tabs; I don't really mind it now that I've installed unimpaired and can cycle through buffers with ]b and [b.

Do you see in advance how many times you will have to do ]b or [b? For me this is the advantage of tabs over buffers, and it's faster than checking the buffer every time it changes.

I'm mostly a Vim user and I could navigate the buffers with its buffer commands, yet I prefer tabs.

The reason for that is probably that Emacs has buffers to support parallel editing of multiple documents, and has had them long before TABs where popularized by web browsers.

Vim has buffers too, but also realized the utility of tabs after a point.

They did but not in the way you suggest -- tabs in Vim are equivalent to Emacs perspectives. If you're using one tab per buffer you're missing out on a lot of functionality.

When I first started using emacs I wanted tabs. I actually almost started using gvim instead just because it has them (shudders). But before long I realised they are completely unnecessary. Why do I need to spend screen space on knowing what files I have open constantly? I don't. I only care when I'm actually ready to switch files, and ido makes that a breeze. Not only that, but I have hundreds of files open in emacs because I leave it running for weeks on end. I use something called midnight-mode to kill the idle ones but still have hundreds sometimes. How would tabs work?

Me too. I fought Emacs for a solid month trying to make it use tabs, and use browser/Sublime/VS style navigation behaviors.

But Emacs eventually won, and I’m glad that it did. Searching for a buffer with a few keystrokes is way better than flipping linearly through a huge stack of arbitrarily-ordered tabs.

(Plus, a minimal interface just looks cooler.)

"Searching for a buffer with a few keystrokes", like using the [Ctrl/Cmd-T + fuzzy filename search] shortcut all those editors implement natively?

Exactly.

I use tabs for managing multiple contexts, where each context is a set of open files. Some tabs might have four different files open at once.

Using tabs as contexts sounds interesting. What do you use for this? TabBarMode (https://www.emacswiki.org/emacs/TabBarMode)?

How about opening multiple emacs frames and letting your window manager act as the "tabber"?

Mixing the contexts of my text editing with the contexts of every other application running in my wm doesn’t sound like an improvement.

Maybe if window managers were substantially better.

Tabs are amazing for visual thinking. I use them as a shortlist of my mental workspace.

As for Emacs, "open files" mean nothing for me as an end user. The editor could hide that feature away and I would still work in the same way. I just use projectile and neotree to switch to the file I want. And efficient as that may be, I still lack a visual cue of what I'm doing. Tabs do that job perfectly.

Even if you need the list, you don't need it constantly, only when you need to recap, where you could just hit `SPC b b` and get the list of buffers to see all the "tabs" you need, furthermore, that can show you way more information than what a single line of tabs could.

Another thing to consider, how often do you need to look at the buffers, but not change to another buffer?

Spacemacs with a properly setup evil bindings and a consistent bindings for all the packages and the Org mode, magit, helm, swoop modes/features are all just simply amazing and game changing.

This is not org-mode if it can't do folding. Folding is main purpose of every outliner.

Another fundamental thing is narrow to subtree (C-x n s/w in org-mode or just click in workflowy)

So this is just .org syntax highliter with some snippets and shortcuts.

.org markup language is much less common than markdown, and this is bad. Nobody wants to learn 2 similar languages with conflicting syntax.

https://github.com/ajtoo/vscode-org-mode/issues/85

There's an issue, and the project is in alpha, but this doesn't sound good.

The thing is, org-mode is quite big. No new project will have implemented all of the features.

For myself, I've never used narrow to subtree, but I was struck by the apparent lack of scheduling C-s, agenda view C-a a, tables (org-mode's tables are just fantastic) and source blocks.

Maybe they'll get to some of these later. For now, just having a hierarchy of headings that you can move up-and-down and in-and-out easily seems pretty useful.

I'm one of the many non-coders who uses Emacs just for Org-Mode and would love to be able to work in a more, well, "normal" editor. But you're right, without folding, or many other features (Refile being a major one), this just isn't there. Unfortunately, so much to Org-Mode that I'm not sure it can be cloned without an obscene amount of work.

It can fold if you indent the text, not ideal but hardly a dealbreaker. I'm happy to say the VS Code is how I started with orgmode and I'm excited to see what's missing/coming, it's great!

For anyone who thinks infinitely nested lists sounds like a good way to organize things, but would prefer an online, less editor-centric (but still keyboard friendly) tool, I recommend workflowy.com (or their more recent competitor dynalist.io who add more rich content support if that is your thing).

I've been using Workflowy for years to organize my work, both for tasks and for mental maps and note-taking. I've found that it maps extremely well to the recursive nature of my mental map of an application and it subcomponents, tasks and subtasks, and so on. And overall I find that collapsible nested lists have all the benefits of a classic 'mind map' but without the constraints and 'easier to read than edit' nature of a bubble visualization.

For me the whole point of org-mode is that the stuff in it is to valuable to trust with a vendor that stores it in a proprietary format that cant be extracted in a meaningful way if the service/company folds.

So one more note here, my open source Workflowy clone backs up all your data to a .txt file in your Dropbox every night. If my hosted service goes away, you can just run it locally, import the .txt file, and you're good to go. https://github.com/NickBusey/BulletNotes

A large part of the reason I made it was for exactly the scenario you described. I run my entire life out of it and wasn't comfortable relying on one company for it.

Nick, thank you for this, you've got another user!

Hey thank you! And please don't hesitate to create GitHub issues or let me know about any problems.

Can it be made to run locally on your machine ?

Absolutely. It's one `npm start` away.

Awesome! Starring it for this very reason (I'll probably run an instance for personal / family use, after I finish setting up the home server). I'm a big supporter of every web tool that you can self-host.

Great to hear! As far as I know no one besides myself has spun it up, so I'd love to hear how it goes!

In that case, I'm putting this on my todo list (in org mode :)) and will spin up an instance on my home dev machine somewhen in the next 10 days (I'll have an extremely busy week). I'll get back to you with the report.

Looks like something I'd really want.

FWIW, I've already cloned it and was preparing a comment to say I had done it but instead it became:

> + CategoryInfo : OperationStopped: (Couldn't find b...ball to extract:String) [], RuntimeException

> + FullyQualifiedErrorId : Couldn't find bootstrap tarball to extract

> The install of meteor was NOT successful.

> Error while running 'C:\ProgramData\chocolatey\lib\meteor\tools\chocolateyinstall.ps1'.

> See log for details.

> Chocolatey installed 0/1 package(s). 1 package(s) failed. See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Couldn't even get Meteor to install on my Windows machine.

Workflowy.com has export in 3 formats: formatted, plain text and OPML.

OPML is about as standard as you can get in that space.

It also has an option to backup to DropBox every day.

dynalist.io also allows export in plain text and OPML.

While I'm sure this won't be what you want or care about, FWIW they do offer export into plaintext that could easily be massaged into any form you'd like (I'm sure it'd take at most a line or two of lisp to get it into org-mode) and can do so daily to dropbox.

Just thought I'd mention my open source Workflowy clone, https://github.com/NickBusey/BulletNotes

It's definitely not done yet, but I've been using it as an effective replacement for Workflowy for almost a year now.

org-mode support would be awesome!

I have definitely considered this, not exactly sure what it would entail as I never really got into org-mode, started using Workflowy and then BulletNotes instead.

Do you mean just importing an org-mode file? Or an actual integration?

I meant org-mode or a subset thereof as a supported working file format.

I'll chime in with a thumbs up for checkvist.com (no affiliation, happy user). I discovered workflowy.com first but moved across as I was seduced by "try without registration", the export options - text, markdown, OPML - and the keyboard shortcuts.

Dynalist.io is a related/similar app and really awesome.

Seconded, Dynalist is like workflowy if they continued to improve the application. Totally worth moving to since workflowy is on life support

> For anyone who thinks infinitely nested lists sounds like a good way to organize things [...] I recommend

And for anyone who thinks hierarchies are an "OMG, you're joking, right?!?" inadequate way to organize thinking... :)

... any recommendations for an Org-ish app with good support for non-hierarchical full graphs, with flexible link and node types?

Writing one is on my todo list, for project management of long-term opportunistic projects, in VR, but in the meantime...

I would look at org-brain: https://github.com/Kungsgeten/org-brain

I think this is also what Emacs-Muse is supposed to do, but I have never understood that program.

> Emacs-Muse[?]

Looks more like a publishing (markdown/pandoc) solution. Abandoned 2010 as folks moved to Org.

> org-brain [inspired by TheBrain.com]

Hierarchy plus one additional link type. Org-mode integration. "One node and neighbors" presentation.

I'm struck again by how much code is about to be rewritten for VR/AR. If anyone has a programming language they wish to mainstream, here comes an opportunity to ride a selective sweep. :)

I love Workflowy. The Broadband Mechanics guys had an excellent web-based outliner. It disappeared and I've always wondered if Workflowy was built from that.

This is OT, but workflowy has a really bad website. No information at all as to what it is, just a sign up page. How did you find out about it?

Honestly, I'm kind of surprised they still exist, given the half-life of random web startups being ~3 years. Personally, I've seen them (and used for a while) back around... 2011? Don't remember what their page looked like back then, but it was quite easy to figure out.

There was a recent Indie Hackers podcast with one of the WorkFlowy founders (https://www.indiehackers.com/podcast/037-jesse-patel-of-work...) where he admits marketing/user acquisition is most definitely one of his growth areas - quite a good listen.

Forgive my ignorance but what makes org mode better than markdown? Whenever I see it demonstrated it seems to be just another way of marking up content in plain text. Is there more to it?

If you're looking at it purely as an interchange format for pretty documents, no. However, once you think about actually using it, the tooling for the format is fantastically more powerful. A small selection of some of the standouts:

Emacs' better understanding of the structure gives you much better editing; I have chords for operations like "move this item up/down" and "promote/demote this item", plus excellent folding, jumping, and a measure of intellisense-like functionality.

org-babel can do anything that even looks like literate programming. I make regular use of both its notebook functionality (like ipython) and its more traditional features (compile to a documentation part and a code part), and its integration with emacs lets you do things like pop out to edit a code block in its native mode as if it were a little tiny file.

org-agenda and org-todo use the format's support for rich semantic metadata to do anything you could want from a calendar, bug tracker, organizer, note-taker, or list manager. You can tag your items with indexed keywords, arbitrary and even simultaneous to-do workflows, and arbitrary (and I do mean arbitrary, it's emacs and everything can be an elisp snippet) to-do deadlines and recurrences. And all that data isn't just a wash; a wealth of options exist for slicing and dicing your data in any number of ways, high-level overview or detailed statistics.

And on top of all that, you can render org-mode documents to nearly any markup under the sun! I regularly compose documents in org, using all of this power, and export to markdown or html to publish.

But it really sounds like you're telling me about things Emacs can do. If I don't use Emacs, what advantage does org mode hold for me? This link is for org mode in vscode, which I do use, but from what I can see it doesn't do any of that fancy stuff there?

Yes, if you're not using emacs you don't get much from the format itself. Which is why everyone talks about org-mode, not the file format. That said, available libraries matter when you're choosing a programming language, and interop and available integrations matter when you're choosing, say, a bug tracker; why wouldn't the available editing tools matter when you're choosing a calendar+agenda+literate-programming environment+note-taker+organizer?

I'd almost say that a "mode" for editing org-mode files almost doesn't deserve to be called "org-mode for X" if it doesn't do all the fancy stuff. It'd be like calling telnet a gmail client because you can theoretically negotiate an SSL handshake by hand - yes, but that's not the point. I think that people came into this thread hoping for a vscode extension that does everything that emacs org-mode does, but I don't think that that's something that'll happen, unfortunately, not unless vscode's architectural philosophy is very different from what I expect.

Those are not things that emacs does outside the context of org mode. From your comment, the implementation of org mode in vscode sounds sparse. This is not a deficit in org mode but rather the implementation.

> Is there more to it?

Yes. Org Mode. I.e. the huge, extremely versatile, extensible and powerful (and complicated at times) Emacs package that uses (and defines) this format.

As a way of marking text up, it's not much different from everything else. But combined with org mode, it's probably the most hacker-friendly system for managing todos, events, habits, information, and multiple-format publishing - and all of that in simple plain text.

Personally, I use org mode for blog posts on my new site, for managing my todos, meetings, notes, brainstorms and personal wiki. People also use it as a better (self-hosted!) equivalent of Jupyter notebooks, for literate programming, and plenty of other cool things.

So, TL;DR: it's not the format that's the magic, it's the software around it.

EDIT:

Oh, and tables. Org mode has the single most productive plaintext interface for manipulating tables. It can even work as a basic spreadsheet in a pinch.

So if I don't use Emacs, org mode is sort of pointless then? This link is for org mode in vscode which can't do any of those things?

The main feature of org-mode I find really helpful is the org-agenda. You could just try a bit.

You don't have to learn Emacs shortcuts, arrow keys work. For navigating between files use the menubar with a mouse.

File -> Open file -> testtodo.org Type "* Something to do", hit C-c C-t, TODO will appear, hit C-c C-t again, the state will be marked as DONE. Hit C-c C-s, calendar will open you can select a date to schedule. Hit C-c [ to add the file to your agenda (permanently). Hit M-x, type "org-agenda", a menu will apear, hit a, to see all your scheduled items for the week. Hit j to select another date. (C is control key, M is meta key, a.k.a Alt) (C-c means ctrl+c, C-s means ctrl+s, M-x means alt+x, you get the idea)

That's all there is, it takes some getting used to, but a plain text format is really productive. You can easily search between items, transfer your files, customize it all you want. I probably use very of org-mode's capabilities, but it really helped me organize my life.

Yes, the org file format is only really powerful when combined with the Emacs extension. That said, for people who already DO use the Emacs extension, it's fantastically more convenient to use as a document markup format than anything else, since you can add tags, TODO items, scheduled dates, etc, and it will all integrate with your existing calendaring/reminders/project planning/whatever. Obviously those people (like me) would prefer if they could use their precious file format everywhere.

So no, org-the-file-format doesn't really offer anything to anyone that isn't an org-the-emacs-extension user, but on the other hand it is pretty much feature-equivalent to Markdown/ReStructuredText/etc for most things. Therefore, other than the (significant) switching friction, it would seem to make sense to make more tools speak org-the-file-format in at least a rudimentary way: non-org-the-emacs-extension users don't really lose anything, and org-the-emacs-extension users will gain quite a bit. Github allows a README.org file to be the project front page now, and it's great. It doesn't deal with ALL the features of org, but I can pretty much treat it as an ordinary org file with tasks, and subtasks, and so on, and still have it look relatively nice for someone looking at the repo in a browser.

That's all the VScode thing is trying to do: make org-the-file-format a little bit less painful to use outside Emacs. It's not trying to ape all the features of org-the-emacs-extension, which would be madness.

Org-mode's syntax isn't necessarily better than markdown's. The selling point of Org is that it is extremely extensible and synergizes well with the rest of the Emacs ecosystem. Tools like org-export, org-babel and the org-agenda - examples of the power of Org-mode - could in theory be implemented for markdown within any other editor. Until that happens, though, Org-mode continues to be better.

Markdown is for writing human-readable text. Org-mode is for organizing many kinds of information (dates, tables, checklists...) in structured documents, while letting the user decide what that structure actually is. Both can be used for writing README files, but their feature sets are very different on the whole.

Other people have pointed out that most of the power comes from using Emacs.

However, speaking as someone who used to use Notepad++ and Markdown, and now uses Emacs and org-mode, I do think .org is a slightly better markup syntax.

I can't quite put my finger on it. For some reason, Markdown seems great for a page or two, but gets irritating if I try to write longer documents. Possibly it's just a matter of editor support for treating it as a tree and letting you move bits around.

Also, the tables in org-mode are really good.

For one, other markdowns haven't really stuck to a standard, so there are many slightly varied markdown variants and it gets annoying keeping up with them.

Another reason I prefer orgmode is the built in exporting functions are second to none. Customize the css and export to html, or my favorite is to export to latex+pdf, because everyone knows latex makes the most beautiful documents.

As an aspiring data scientist (transitioning senior sysadmin), the code snippets function and the ability to evaluate and execute code makes it the ideal data science notebook.

The power of lisp stands on its own.

Org mode task tracking, todo, GTD functions are also very awesome functions just markdown doesn't have.

That's just a few reasons, but orgmode isn't orgmode if it's in visual studio EEE version or whatever the duck new bullshit ms is doing imnsho.

> or my favorite is to export to latex+pdf, because everyone knows latex makes the most beautiful documents.

Hah, my observation from early days of using org-mode: LaTeX makes the most beautiful documents, but writing tables in them absolutely sucks. OTOH, org-mode has the most productive interface to plaintext tables that I've ever seen. When I was working on my BSc thesis, I would make tables in org-mode, and then export them as LaTeX to paste into the thesis code.

That's a statement I hear a lot. A good friend wrote his physics dissertation entirely in org mode because of the TeX integration. You can even bring in the custom TeX templates every University's thesis publishing offices unaccountably seem to have.

org-mode has the most productive interface to plaintext tables that I've ever seen

I fully agree. For Markdown I recently found this nice little utility that I had never heard of before:

https://tableflipapp.com/

(I still do some websites in Jekyll + Markdown. I know that Jekyll can be combined with org-mode, but Markdown is the 'low-entropy and I do not have time' option.)

https://news.ycombinator.com/item?id=15321850

I tried learning and using org mode. In my case it doesn't make it better than markdown, it's faster to use if you know the keyboard shortcuts, it's more structured if you want to export content and it provides more functionalities. But for a simple list or an agenda markdown is fine, so I personally went back to markdown like that I can do things from ST.

I have never really used org-mode in anger but it's markdown in the context of an editor to which you have access to the primitives of in lisp with lots of attached features.

For example a calendar and a simple spreadsheet.

Literate programming/ops

More obvious nesting structure

It manages many structures for you so you don’t have to type the text

Time tracking

Agenda mode and associated task states and due dates

We always need another way to mark up plain text content. The current dozens or so of mostly incompatible solutions is clearly not enough for the world.

Org mode is slightly older than Markdown, and certainly older than Markdown's status as a default way to mark up text.

More than that, it doesn't make sense to think that Markdown is the best solution, or at least the best solution for all use cases. People should continue to try and innovate, at least if they're aiming for something bigger than trivial improvements on the status quo.

https://plugins.jetbrains.com/plugin/7095-org4idea

We need that on Vim

You might try vim-orgmode, although it's not a complete clone: https://github.com/jceb/vim-orgmode

I've been running my life on VimWiki[0] and calendar.vim[1] for over a year now, and while I'm sure hardcore org-mode users will scoff at its shortcomings, it's been perfect for me. I don't know why it isn't more widely used.

[0] https://vimwiki.github.io/ [1] https://github.com/mattn/calendar-vim

I'm also a vimwiki fan. Used to use emacs just for org mode but didn't find the extra effort worthwhile for the returns. I haven't used calendar.vim ... I will tomorrow, thanks!

Workflowy translated to a Vim motif:

https://github.com/WuTheFWasThat/vimflowy

Love this. Developer is really cool and responsive, too.

As a long time vim user, could I persuade you to try spacemacs in evil mode? I always liked the idea of the superior emacs ecosystem, but couldn't leave the brilliant vim command language. I found that this gives a good balance.

I was under the impression (from trying exactly this) that the vim keybindings conflict heavily with org-mode's keyboard shortcuts. For example, the table shortcuts didn't work at all for me in evil mode.

It may not work for everything, but spacemacs includes packages with evil bindings for the common modes and i use vim style org commands without hassle.

Or just accept that emacs is objectively better software and switch to it? Evil mode is by far the most complete/true to vim vim emulation that exists, as far as I know.

It's easier said than done. I decided to switch about a month ago, and after playing around with evil mode for a week, I gave it up in favor of emacs-std bindings. The core editor evil emulation was flawless. All my 20-year muscle memory commands just worked without a second thought.

When going into other packages like org, magit, etc. I noticed that all their default bindings were emacsey as well (for obvious reasons). I realized that I would be forever mapping evil bindings into new packages every time I wanted to use something new, so I gave it up as a bad job and just bit the bullet and switched to stock emacs without evil. I'm like halfway through the learning curve (I hope!) and it's tough. I've always had the caps lock key mapped to Ctrl anyway, but I still feel like my pinkie is about to fall off. After using vi/elvis/vim for almost 25 years, I do admit that I like emacs, but "just switch" still means a period of remarkably reduced productivity to many.

(Yes, I know that for any popular package someone has published evil mode bindings and use-package makes them trivial, but it's not the point.)

I did the same as you. Also took the learning as a challenge. It's also just so nice sometimes to start anew and learn something from zero. (I do also understand it takes time. But take it as motorcycle maintenance ;)

EDIT:

Also with emacs: you get synergies with the default mode of bash.

Regarding moving Ctrl, my experience is that the pinky finger just isn't strong enough to handle the Ctrl key in emacs even when Ctrl is bound to caps lock. I think it's more comfortable to swap Ctrl with Alt (or whatever key is adjacent to the spacebar) so the thumbs can be used for Ctrl. This is beneficial even in other software, since Ctrl+C, Ctrl+V, and Ctrl+X are pretty common.

have you looked into evil-collection? This is a collection of evil bindings for various emacs packages. https://github.com/jojojames/evil-collection

Thanks; I have, but I thought I might as well try to do it right. If after another month or so, I still have "Emacs pinkie", I might just bite the bullet and go to evil mode.

And yet the remaining 10% makes me want to go on a killing spree every time I try switching to it, while the remaining 10% of IntelliJ or VSCode seems perfectly user-friendly to me to tolerate.

I'd rather just port any possibly interesting features to (Neo)vim rather than having to deal with all the baggage that comes with Emacs. And this is the conclusion I make after many attempts at switching over the years--I just cannot stomach its way of doing things.

> Or just accept that emacs is objectively better software and switch to it?

Oh, come on. I thought the editor wars died with Usenet many years ago.

I think the fact that evil and spacemacs are en vogue right now changes the game a little bit. The debate doesn't seem to center around what editing method is best but which editor does 'Vim' best. There's a strong case that it's no longer Vim itself but projects like neovim or Emacs.

There was https://github.com/hsitz/VimOrganizer/ but it's inactive since 2014. Maybe there is a more recent one that I'm not aware of.

Now that neovim is a thing, we dont need it in vim, we need a vim editing front end to orgmode.

Are “checkboxes” like [ ] and [x] understood by the real org mode or would I need to define say [_] and [x] as TODO keywords if I wanted highlighting of that sort of syntax? (It’s been ~20 years since I was a heavy emacs user, looking forward to finally getting to play with Org Mode or at least an alpha of it)

Yes, they're understood, but in the different way. Org mode opted to treat headlines as TODO items (this choice is important for the purpose of e.g. generating agendas), whereas checkboxes apply to list items.

As for the checkboxes, org mode understands [ ] and [X], and can process them relative to checkboxes in a sublist. For instance, if you write something like this:

  - [/] Foo
    - [X] Bar
    - [ ] Baz
  - [%] Foo
    - [X] Bar
    - [ ] Baz

and then make org-mode reevaluate the list (by e.g. using a shortcut that toggles a checkbox state), it will automagically turn into:

  - [1/2] Foo
    - [X] Bar
    - [ ] Baz
  - [50%] Foo
    - [X] Bar
    - [ ] Baz

(similar / and % feature is available for TODOs in headlines too). Org mode maintains such associations itself, recomputing them as you change state using org-mode commands, and it can also be configured to enforce additional structural constraints - e.g. preventing you from turning a TODO to DONE, if its subtasks are not all in DONE state.

"Every item in a plain list can be made into a checkbox by starting it with the string ‘[ ]’. "

https://orgmode.org/manual/Checkboxes.html

Finally, a thing that I was using before it made it to the top of HN.

Very nice! Congrats for this.

In GNU Emacs, Org is both a plain text format and a set of tools to edit .org files: it's nice to see both implemented outside Emacs!

These all seem really useful. Specially the date thing, handy.

Reply on news.ycombinator.com