Hacker News Reader

Comment by wyuenho | Hacker News Reader

I've been using emacs for over a decade now and I have yet to reach this state of nirvana. I do want to understand every line of elisp and I've been doing a lot of elisp recently. But then again, I also have work to do, and I realize all I've been trying to achieve with my emacs config in the past 10 years is to make it work like a modern IDE. Which is perfect, because the reason I switched to Emacs in the first place is I just needed an IDE that I could fix.

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.

View on HN

Been there, done that, switched to JetBrains IDEs, and haven't looked back.

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 can relate to this. The problem is I already know how to get my work done (efficiently) in Emacs and find any change of my everyday tools to be daunting. Any advices on how to experience "what modern IDEs are capable of out of the box" without major pain?

I've found one of the best ways to experiment with other text editors is to use them for one specific type of task or type of file. So when I started using vim I only used it edit config files. Makes it easier to lock into the mental mode of using a particular editor.

This is a very good piece of advice! I do have to configure my emacs every time I take on a new type of task albeit not very often. I'll give it try next time. Thanks!

I don't think I've seen a modern IDE that doesn't either have vi/emacs keybindings included or has a rich enough ecosystem for someone else to do so. I'm someone that cut my teeth in Linux, on many distros that never had pico/nano installed but to this day I still have to lookup basic references just to get anything changed on those systems. If I have the access, I immediately install nano because I can handle those keybindings a little easier.

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.

> 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.

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.

> 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 :)

The problem is often you have to build "Your way" from the ground up. Some people just want "A way" that's working as soon as they open up the editor.

Sure. But that applies to almost any problem I face on a daily basis as a programmer.

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”.

...and that's where Emacs starter kits come into the picture. Especially when compared to VS, Emacs based solutions always seem superior to me because they don't require me to use the mouse for every. little. effing. thing. I want to achieve.

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.

Well, I think I should make it clear that I'm very well aware of what modern IDEs can do, and I think most Emacsens do too. In fact, their killer features haven't really changed much since the late 90s / early 00s.

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.

> Emacsens

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

Actually, 'emacsen' is the German plural for 'emacs', not the Scandinavian (?) for 'an emacs'.

What language is "Scandinavian"? Also, perhaps the intention was that "Emacsen" was the literal name of a version of the emacs family of editors, of which GNU Emacs is only one (XEmacs, for example, being another one).

My problem is I consider vim to be the best text editor ever created. That is, when it comes to manipulating text, there is no equal. But it's a lousy (even terrible) "IDE". Between editing text and other dev related tasks (searching, diffing, autocomplete, etc), text editing is slightly more important to me, so I use vim. Using another editor/IDE with a vim emulator doesn't cut it. I've never found one that matches real vim. Neovim could eventually allow me to have my cake and eat it too though.

I actually wonder why there aren't more IDEs that just embed vim as their text editor. Ironically, the only one that can do something like that is emacs.

Doesn't VSCode embeds neovim already, so you can use neovim plugins from VSCode as well.

embed vim as their text editor

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 quite like the Jetbrains vim emulation (Ideavim). It has a few quirks I run into every once in a while, but I find the combination of Jetbrains + Ideavim worlds better than my highly customized vim install when coding on a non-trivial project.

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.

Anything JetBrains does, emacs can be made to do. Someone should spend time extending it to do that, and share his work with the world.

I actually got half way through writing up a substantiating argument that JetBrains could benefit from AST manipulation and inspection written in a lisp-flavor, which would benefit both camps. But I actually don't know of a lisp with static typing, and reasonable people can differ about whether such a thing has merits, but for the purposes of this discussion, I bet trying to wire a dynamically typed language into a statically typed codebase would make everyone unhappy

> 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.

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

Reply on news.ycombinator.com