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.
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 :)
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.)
Maybe if window managers were substantially better.
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.
Another thing to consider, how often do you need to look at the buffers, but not change to another buffer?
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 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'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.
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.
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
And I use Windows so a fancy WM is almost out of the question.
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.
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.
I've seen some vim workflows using only buffers instead of tabs, but they required doing
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.
(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 )
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.
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.
With Emacs anything is possible. You don't have to settle for buffers. There is also speedbar for a tree-based view.
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.
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.
There's an issue, and the project is in alpha, but this doesn't sound good.
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.
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.
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.
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.
It's definitely not done yet, but I've been using it as an effective replacement for Workflowy for almost a year now.
Do you mean just importing an org-mode file? Or an actual integration?
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 think this is also what Emacs-Muse is supposed to do, but I have never understood that program.
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. :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
I fully agree. For Markdown I recently found this nice little utility that I had never heard of before:
(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.)
For example a calendar and a simple spreadsheet.
More obvious nesting structure
It manages many structures for you so you don’t have to type the text
Agenda mode and associated task states and due dates
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.
Love this. Developer is really cool and responsive, too.
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.)
Also with emacs: you get synergies with the default mode of bash.
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.
Oh, come on. I thought the editor wars died with Usenet many years ago.
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
- [1/2] Foo
- [X] Bar
- [ ] Baz
- [50%] Foo
- [X] Bar
- [ ] Baz
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!