However, ever since Sublime and now VS Code came about, I've been having this internal debate of whether I should just switch to a text editor that I can fix, but come configured sensibly OOTB, and let sunk time costs be. This used to be a tall order but VS Code seems to be really close to this ideal now.

My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box.

I use visual studio in my day-to-day job for .net and C# work. I know what it’s capable and it’s a very impressive piece of technology.

What it doesn’t do is allow me to shape it to fit my workflow. I always have to adapt to fit the tool as opposed to the other way around, and any level of customization and extensibility feels extremely shallow compared to Emacs.

With Emacs I get everything my way. And I don’t think that can be said about any other tool I know of.

Needless to say I use both editors side by side and use whatever tool is best for the job at the time.

Edit: IMO standardized technologies like LSP is now bridging the gap for many (but obviously not all) IDE features. I suspect the imminent death of the “plain editor” is vastly exxagerated :)

I don’t see why optimizing my flow and tools should be less important than optimizing what I deliver. The former practically enables the latter.

This mindset is pretty much what has given us the high quality FOSS projects we use everywhere. I wouldn't really call this is a “problem”.

That, and they are usually much more designed around a more UNIX-focused toolset than most IDEs, which means less interdependent blobs of cruft like Intellisense and the like.

What I never liked in IDEs is their features come with a huge cost. Their integrated features are great, but their implementations are so complex and opaque, when they inevitably go wrong, I can't just dive into a plugin and fix it myself. Emacs packages still goes wrong, but at least fixing them is a much easier affair. It is this reason, and that Emacs generally just come out with functioning packages for new concepts and ideas way faster than any other IDEs, I've vowed to avoid IDEs written in compiled languages like the plaque.

What I really mean is, I'd love to replicate IDE features on a text editor, but without the pain. Elisp is just a horribly outdated language and runtime environment to be honest. Everything is global, OOTB most of the modern FP constructs is non-existent in this FPL, dependency management is a mess, it's single threaded, it's a terminal app pretending to be a GUI etc, and oh god, don't even get me started with the default window management mechanism. I don't understand why so many people keep romantizing it.

Nitpick. Emacsen refer to an editor in the Emacs family. It wasn't always the case that Emacs was equated with GNU Emacs.

I feel like Atom or Visual Studio Code are good pseudo IDEs but a lot of people hate the Electron tax. I spend most of my day in PHPStorm (ugh php) but I have both Atom and VSC installed primarily to understand the life in between a seemingly more 'dedicated' IDE like PHPStorm over this in between both editors seem to fill. They're primarily editors with IDE layers on top and for the price of $0 it's a good place to cut your teeth if you can stomach the tax. The JetBrains IDEs do have generous evaluation periods but I don't think you would be in an extremely comfortable place at the end. It took me a little more than 30 days to become as intimately familiar as I am now but like the bigger Visual Studio at my last gig, there's parts of PHPStorm I just don't touch and maybe never will.

This is probably not the best answer but there really isn't a one-size-fits-all kind of transition either. I think the most rudimentary concept that sold me on a proper IDE over an editor was syntax checking. Editors like emacs or vi may have better support for that than Coda or Notepad++ but knowing the script won't compile immediately vs deploying broken code and finding it there has more than paid for the difference. The most powerful feature of PHPStorm for me is setting breakpoints and having the Xdebug integration give me a peek at everything visually. There are still cases where I debug with echo/var_dump statements but if I can attach the debugger, I can do so much more. The likely biggest draw for a JetBrains product is the refactoring capabilities. Again, some editors likely do refactorings really well but when my refactoring in Notepad++ involved just find/replace it really isn't comparable in the slightest.

I think at the end of the day productivity gains through workflow changes are something I'm constantly looking to adjust. Even though I'm very happy with PHPStorm, I have VSCode and Atom primarily as a means to reevaluate my understanding on an ongoing basis. I realize for a lot of people "if it ain't broke, don't fix it" is perfectly acceptable though and if you feel really productive, chances are you are.

Emacs has had mechanism (flymake) to call out to a background process to lint code for decades now. Recently (as in since 2012), there's a new package called flycheck that reimplements flymake's functionality. Since then process-based linters have exploded. At least in JS and Python, you can do syntax check and possibly fix your code exactly the same way as most IDEs. Better yet, these linters update so fast, you generally get much better linting on Emacs/VI than IDEs. Updating these linters is just one command line call away, whereas in IDEs, you typically have to wait for months because they are embedded. The speed of improvements is just so much faster in simple text editors. The problem with Emacs and VI are not linting, but something so much more basic such as keybindings and window management.

Do you have some examples of things I might not be aware of?

However, if all I need is a text editor, such as when hacking out a script or two or doing actual writing, then it's terminal vim all day long.

Part of that problem is that a really good IDE isn't editing text: it's editing code. One may retort "but code is stored in text files," and yes, that happens to be the primary serialization format but while it's in RAM the editor is making changes to the AST (for example)[1] and the MPS project[2] even strives to do away with "text file" façade entirely, allowing you to edit the parts that are truly editable, and just graphically render the syntatic sugar for everything else.

That distinction is relevant to the question because merely embedding vim would be problematic since the common language spoken between the IDE's mental model and vim's mental model is text, but I couldn't imagine the pain that would be involved in trying to send down the keystrokes required to update all occurrences of a variable, for example.

IntelliJ does have emacs bindings, and does have a vim plugin, but I've watched people use both of them and they suffer from the uncanny valley effect. Not to mention the fact that, and I can't stress this enough, entering character level keyboard shortcuts to change an AST is optimizing the wrong problem.

that can do something like that is emacs

I've actually spent many, many hours thinking about that very issue, and I am 100% convinced in my soul that a sufficiently determined person could in fact make Emacs as smart as IntelliJ. But the problem isn't making it that smart, it's keeping it up to date with the new bugfixes and rules. It might be possible (heh, or even preferable!) to write the AST manipulation and inspection rules using (e)lisp, but given how many developers know Java versus how many know lisps, I doubt a commercial company would bet the farm on such a thing.

---

1 = https://github.com/JetBrains/intellij-community/blob/idea/17...

2 = https://github.com/JetBrains/MPS/tree/2017.3.2#jetbrains-mps

I'm not sure what reason the emacs team has for just not adding MELPA but it would change the game for me if it were an official addition and would require it's addition to work out of the box. Till then, emacs is a long way away from being my default editor, and VS Code and JetBrains are more of my defaults.

Out of the box functionality is key for any editor in my opinion.

For me, my emacs config is my text editor, and it works out of the box on any system I install it to. Emacs is often very easy to install, but if I'm going to spend significant time on a machine I'll build it myself, and then my config is a simple git clone away and that's it. I'm working in an exact copy of my own personal text editor that I've built up over many years.

My instances of emacs also stay running for weeks at a time. I'll edit the config while it's running. If it's useful I'll commit it and pull it to other instances and run the modifications on them while they're running. It's a completely different way to work than most people are used to and it's liberating.

If this frontmacs grown in the proper direction to support a effortless mix of own and external settings, then it could become even more important than spacemacs for the community and growth of emacs.

Getting all of our tools into similar management forms ultimately makes all of coding more accessible.

* Self-documenting

* Easy to dynamically inspect and change the editor internals and all packages, from the editor itself

* Emphasis on the editor as an interface into your system (the editor as a way to process and "glue" together text from subprocesses)

Atom in particular seems promising, but from the time that I spent with it, I quickly concluded that it was missing the spirit of Emacs entirely, because it was not straightforward or well-documented how I would go about exploring and changing the internals of the editor and its packages. E.g. a package was throwing an exception...it was quite a process to find the source, set a breakpoint on that error, and fix/work around the bug. That's trivial stuff in Emacs, and IMO is at the spiritual core of Emacs.

I would love to be wrong here, so please correct me if I'm mistaken!

I got into Linux with Mandrake. A year later I was running Slack.

Not everyone sticks with their first tool when starting out