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.
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.
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.
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).
Readit News
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.
I'm also a VIM user suffering Emacs just for org-mode. Evil makes it livable.
https://orgmode.org/manual/Clean-View.html
At least there's another plugin which replaces the asterisks with a single symbol per heading.
Have a look at orgExtended for Sublime Text for a more fully featured reimplementation of org mode.
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.
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.
[0] https://easyorgmode.com
Org-Mode for Visual Studio Code - https://news.ycombinator.com/item?id=16198369 - Jan 2018 (124 comments)
[1] https://orgmode.org/manual/Timestamps.html
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.
Vim doesn’t have this either, by the way.
I use this
https://marketplace.visualstudio.com/items?itemName=kahole.m...
look into fzf vim plugins.
I say this a a former emacs user now using VS Code.
https://github.com/VSCodium/vscodium
Deleted Comment
That said, as a multi-decade Emacs (and Lisp) user, I do like VS Code and its JavaScript/TypeScript basis.
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).