I find these org mode re-creations in other editors neat but the problem always seems to fall to the fact that other editors can't properly support org-indent-mode as they lack support for virtual text or because of other problems.
In org with org-indent-mode mode the following text:
* Foo
** Bar
baz
Is rendered as:
* Foo
* Bar
baz
This visual indentation and separation is, at least to me, an important feature which helps when reading.
It is basically a must-have for any org-mode re-implementation (I'm not just making up obstacles here, I daily-drive neovim and like the idea behind the org-mode plugin for neovim but I've tried it multiple times and it just doesn't work for me).
There are also probably many other shortcomings too.
I would not call it a must have as the default configuration doesn't indent the body. I don't have the option set and I would wager the majority of orgmode users don't either.
I think that Emacs does print two asterisks for the Bar heading, but all save the last are coloured the same colour as the background. And a single space is used for indentation for every heading asterisk - so a four-asterisk heading is indented four spaces.
I'm also a VIM user suffering Emacs just for org-mode. Evil makes it livable.
So that's why it always looked so weird in my case, with all asterisks but one being colored white like normal text. Apparently this feature doesn't always work as intended.
At least there's another plugin which replaces the asterisks with a single symbol per heading.
I see why some might like it, and it does improve readability, but I actually turn off org-ident-mode. I use a text editor because I like to see the syntax; brutalist by design, keep the magic hat tricks for Office.
Without the agenda, without tables, without time tracking, without executable code blocks, and without exporting, this is missing the point of org mode.
Have a look at orgExtended for Sublime Text for a more fully featured reimplementation of org mode.
Org Mode is large enough for different people to value different subsets.
What's important for me is the tree structure, tags, states (like TODO, but I use many custom variants in different files), links, archiving, quoting (including code blocks, but I don't need to run them in place), easy per-file properties, easy export to many formats. I barely use time tracking, and never use agenda though.
Anyway, a subset of features implemented is a good foundation for further development.
Most if not all of the features you listed are also possible with Markdown (though unfortunately different tools & parsers slightly disagree on the syntax).
What sets org-mode apart is the interactivity: time tracking, code execution right in the file etc. Though of course if you're already an Emacs user the choice is still pretty clear.
Right now I'm trying out Obsidian, with a plugin it has kanban boards using Markdown in the background. Which is the one kind of feature I've missed for a long time: actual 2d representation of content instead of keeping it limited to linear text files, sometimes vertical lists just aren't quite enough.
You could use the Agenda from EasyOrg [0] in combination with VS Code or Sublime to get the Agenda functionality. EasyOrg has its own editor just in case.
I recently started using this, but I have to say it is of limited utility without folding. I nearly always end up opening up .org files in emacs instead just so I can collapse sections and concentrate on the stuff I care about at the time.
This honestly looks pretty interesting, and reminded me of Obsidian more than anything; I wonder what the level of effort would be on inter-compatibility between this and obsidian projects ( obsidian has a nice mobile app, which would be useful for bridging the gap back to vscode on a full machine )
I feel like it would have been nicer to have a perfect match with orgmode syntax (e.g. they use square brackets instead of chevrons for time stamps). It would make migration easier... Really impressive project nonetheless!
Org mode actually uses both square and angle brackets for timestamps [1], but the square-ones are inactive, i.e. they don't show up in the agenda view. I guess the angle ones are the most useful, though.
Not until it gets something akin to helm/ivy/consult.
I like emacs and have been using it for like 8 years, and doom makes my additional configuration small and manageable, but I’d switch to vscode in a heartbeat if it was possible to replicate basic features of an extended emacs. I just want a good editor at the end of the day.
* wgrep is hugely useful.
* Fuzzy searching with orderless is unmatched in any other editor. Being able to resume is hugely useful. Being able to plop the results into a saved buffer is hugely useful.
* magit is the only way to do complicated rebases.
I really want to move on but until vscode fixes their search, I’m stuck. I can live without a good git interface, I can’t live without navigating projects in a grep-oriented way.
It's a start (and I use it too), but it's so far from parity with Magit that even when working in VSCode (where rust-analyzer is better), I often switch to Emacs for Magit.
I agree about all of these things. But there's one thing vscode has and emacs doesn't that has recently (as of a job change) caused me to switch, because it ended up trumping everything else:
* works decently well on Windows
Emacs is just so so so painfully slow on Windows. And running the Linux version in WSL leaves me stuck in 16-color terminal mode because (at least as of Windows 10) getting an X server working on Windows without creating a security problem for yourself is, to put it mildly, easier said than done.
Sorry about being stuck on Windows 10, but Windows 11 has WSLg[0], which gives you a reasonable X server out of the box. I liked X410, but WSLg is seamless. When combined with no fuss CUDA support and great docker integration, WSL2 on Windows 11 is almost a better Linux than Linux. Then you run into an edge case, spend hours digging at it, and leave curled up into a fetal position.
I use mobaxterm on windows which has an X terminal builtin (IIRC). I've never actually had to use it - I just the the ssh/rdp/scp stuff. But its free to try it...
Exempt its installation folder (and any folders where you keep a large number of Elisp files) from Windows Defender and other antivirus software. Does that help?
The issue is fairly well documented. In a nutshell, it's that the Windows kernel has rather high-latency disk I/O, and emacs plugins tend to spam the disk.
I use all of these in emacs, but IntelliJ has equivalent functionality without any plugins. Complicated rebases are much more easily done in IntelliJ than Emacs because I can edit and pick-and-choose changes while inside the 3-way diff view, while in magit, as far as I know, I must do it separately from the diff which makes things harder.
While I'll agree that you can't accomplish all that's possible in Emacs in vim, I'd love to know what you can accomplish using fuzzy search in Emacs that you can't in vim.
The most annoying thing to me about VS Code is it cannot be extended in a way that doesn't require developing a plugin. In short there is no ~/.vscode.ts. Instead you have to create a plugin to add custom commands.
I say this a a former emacs user now using VS Code.
Among developers, probably the most popular text editors are VSCode, vim, and emacs.
On a spectrum of "notepad to IDE", vim is closest to "editor only"; although with effort it's possible to get an environment with nice bells & whistles.
Emacs has always been 'heavier' than vim (although I don't think it's "works well out of the box enough" to count as an 'IDE'). A couple of ways in which it's heavier is e.g. its fancy UI for customising properties; or its "apps" like org-mode or magit, or having an elisp shell or support for virtual terminals.
VSCode's also not quite an 'IDE'. But it's also heavier than just a pure 'editor'.
VSCode doesn't quite have the insane level of customisability that Emacs has. VSCode also doesn't have people bragging about e.g. reading email from VSCode. -- But, VSCode does have some of these features (e.g. an 'app' for interacting with Git, or inbuilt terminal).
I like to think that VSCode's discoverability owes a bit to Emacs (e.g. the key bindings showing in the command palette reminds me of emacs' which-key).
Thank you. I thought you were getting at some kind of fundamental alignment between the two products, but as I see it, you view VS Code as a product it’s as extensible as Emacs, or something close
Org mode started as an Emacs only thing. Over time it has evolved into a much more capable thing than markdown format. One can do almost anything in the org mode format: literate programming with code blocks which can be executed (org babel), plain text spreadsheets, scheduling and summarizing scheduled events in an agenda view, time tracking, thesis writing (it has the necessary syntax for element one needs when writing a thesis, unlike normal markdown), inter-document linking, and probably many other things.
Some time ago people started slowly bringing things to VS Code. Org mode syntax has also been separated out as "orgdown". Now finally other editors are catching up to what has been possible in Emacs for a long time using org mode. They still got a long way to go, because integration of org mode things in Emacs is very far ahead, but at least work is being done.
Kinda difficult to explain as I dropped emacs due to issues with it on Windows despite enjoying org-mode.
The key thing is, org-mode treats data/text as a tree graph programmatically, you move through headings, and properties can be attached to those.
So a property for a deadline time can be added, and parsed, so you can get a list of todos/schedule showing the headline, and being able to jump to it.
Your api access targets these "nodes", so you are adding under "journal" rather than line 674 when using the template feature to quickly add entries.
emacs has ridiculous levels of customisation that let this data structure do basically what you want or need with some scripting.
It is an extension of Emacs outline mode. Outliners are hierarchical text formats. Org added many useful things to outline mode: keywords, tags, timestamps, footnotes, links, tables...
What makes Org unique is the presence of interpreters, including user-defined ones, that take Org files as input and do things on them.
A famous interpreter is org-agenda which harvests TODO keywords, timestamp deadlines, etc. from different Org files to generate a weekly agenda. Another one is Babel which runs embedded code in Org files, i.e. a literate programming system.
To sum up, Org is a plain text format analogous to Markdown, but with many more features and also interpreters that define certain operations on them.
It's markdown with Excel's ease of creating buttons (in org-mode's case ascii buttons) to execute arbitrary callbacks, e.g., cross referencing, summarizing, sorting, etc.
It primarily appeals to weekly status jockeys (project managers) whose rudimentary programming skills are just good enough to hack some emacs lisp. As someone who doesn't mind grepping an omnibus "notes.txt" file and thinks "literate programming" is a waste of time, I've never found a use for org-mode.
Explaining org-mode at this point is almost akin to explaining emacs itself.
What is Emacs? Is it a text editor, for editing config files?
Is it an IDE for development? An email reader?
Org-Mode is a mode for Emacs that provides structure to documents in such a way that it allows documents to be used for many things- authorship (web sites, books, etc.) but its primary use for most of us who is it is to integrate into our todo management systems- allowing us to manage our tasks in a way that's integrated into our work. It provides flexible, queryable and programmable todo lists, document generation, literate programming, spreadsheets, living documents that can execute code, time tracking, and more.
It can also integrate with other tools, like org-roam, to provide backlinks and other features, or work with tools like mu4e to integrate email and todo lists in both directions.
In other words, it's a system for working with data/life.
Short version: an text file based note taker, an outline editor, a calendar and an operating system disguised as a text editor came together to make an incredibly handy personal information manager. The file format looks like markdown, but is not markdown (and existed before markdown).
This is a welcome extension of course which I'm sure will improve further but I've really been spoilt by the "live preview" editing mode for markdown available in various tools like Slack, Obsidian etc.
In org with org-indent-mode mode the following text:
Is rendered as: This visual indentation and separation is, at least to me, an important feature which helps when reading.It is basically a must-have for any org-mode re-implementation (I'm not just making up obstacles here, I daily-drive neovim and like the idea behind the org-mode plugin for neovim but I've tried it multiple times and it just doesn't work for me).
There are also probably many other shortcomings too.