I've been learning emacs over the last 6 month or so. How is the "hackability" of atom compared to emacs? I threw away spacemacs, started over, built all my config, am starting to build plugins etc. While the learning curve was steep, the flexibility of emacs is quite amazing and I've only just scratched the surface of the extensibility. It makes me very intrigued to hear about how other people are using editors like Atom.
I tried out Atom and found its "hackability" sorely lacking compared to Emacs. Which made me sad, because it's the only new-gen editor to really claim to be "hackable".
Specifically, what I'm looking for in an editor is the ability to introspect most/all of the editor's internals from the editor itself (including documentation, debugging, live modification of the editor, etc.). In Emacs, all of that is just a few keystrokes away. Atom is somewhat introspectable in that I can pop open a Chrome dev console and poke around at the DOM and the JS files, but it isn't at all as straightforward as in Emacs (e.g. given some keystroke or some function in Emacs, it's extremely trivial to jump to the source code and start modifying/debugging it). Given that these activities aren't clearly documented in Atom documentation, I can only assume that they aren't priorities for Atom and that, in fact, Atom isn't designed to be "hackable" in the sense that Emacs is "hackable".
Which is really disappointing, because a truly "hackable" editor a la Emacs, built on a web stack like Electron, would make me giddy with excitement.
Because building attractive UIs and doing graphical things is much easier on a web stack. Emacs can run in a terminal emulator, but as an editor in a development environment, that's not a use case I've ever had. I'd much rather be able to seamlessly plot some data with vega.js or slap together a quick UI for a tool, or be able to trivially inline images, animations, videos, PDFs, etc. without having to fiddle with native libs.
This makes me wonder what an editor would look like where you can hack at the text buffer/background data/etc in something lower level, but had that information also accessible with a web based layer for doing UI stuff. Might be best of both worlds, might just be insanely messy.
That is basically the ideal editor I have in my head. It would be messy, but in the way that Emacs is also messy, which is what makes it so great :). It significantly shortens the distance from my brain to running code.
>Specifically, what I'm looking for in an editor is the ability to introspect most/all of the editor's internals from the editor itself (including documentation, debugging, live modification of the editor, etc.).
Although it is ugly, and the documentation is poor, and web site looks like it's from the 90's, and the project lead is a bit eccentric, you may want to consider the Leo editor:
It's written in Python, and pretty much gives you access to most/all its internals. Unfortunately, the state of the documentation is pretty poor which is why I never had the time to spend mastering it. But I've followed it enough, and it really is a very powerful editor. I think only Emacs surpasses it in self-scriptability. A lot of non-programmers have used it to do pretty interesting things (helps that Python is "easier" for them than Lisp).
I would also like further discussion on this. I am full-time emacs. I hear from other colleagues that they will split time between editors. "vim for writing and VSCode for refactoring".
Ya I do periodically spend time in intellij when I work with scala, just because of the discovery and refactoring capabilities. Particularly very large/involved refactoring is helped by the tools. I did a core redesign to support an entirely new use case in a product I'm working on now. I tried to do it by hand and burnt a day, threw away everything, opened intellij, and applied a couple refactoring. In 40 minutes I had the tests passing for what was a very broad and wide refactor.
If anything the thing that is a killer feature that I always try to get out of emacs but ends up being half baked is the code completion/code aware tools (like the example given of refactoring). With emacs and yasnippet I can emit a ton of code but if I ever have to do a big surgery and have some level of assurance it's right as I go along is nice and I end up falling back into Eclipse/Visual Studio for those sorts of things. I have rarely gotten Emacs to have good code completion with most large software projects, and I end up using tools like opengrok to do the initial search because it just indexes better before diving in with emacs.
Because emacs in most implementations is not project aware the same way an IDE is (like the ways eclipse preprocesses the project and holds a coherent data model in memory while you edit) it just doesn't have the tools available to even build off of. It was only post-LLVM that tools for that kind of formatting and editing are expected to be coming from the compiler's AST itself (things such as https://langserver.org/ is pretty exciting). I think Go has some of the best source code at command line tools, but they are leveraging that there is a 'one true way' of go tools to work that is easy enough to deal with so a simple command can do just enough work to do what needs to be done as opposed to a C/C++ application that is a #define soup with custom build infrastructure that emacs has no way of getting a coherent model out of to decide whether it can refactor things or not.
I keep trying to make emacs work for it, but it turns into a lot of custom tooling that I really don't have time to build for the kinds of applications I end up having to work with. Emacs is still superior for actually reading and writing large bodies of code, just it is awful on operating on the code at a syntax-aware level and doing the same quality of IDE-grade checks to make it a mechanical thing as opposed to a brain-driven thing.
This isn’t really relevant to Atom, but... Emacs is working on this, on several fronts. In many ways, this isn’t (yet) an improvement, because what we have now are a bunch of partial implementations that mostly get different parts ‘right’. On the other hand, progress.
TBH, one of the big stumbling blocks is that a lot of the most adept Emacs hackers simply don’t do much of the sort of ‘IDE-grade’ stuff, so in a real sense, they don’t understand what they (and Emacs) are missing. (Fair cop: I’m largely in this boat myself.)
For example, Emacs has had dynamic adaptive customizable electric hippie completion for longer than there has been a publicly released Java language, BUT many (is it still most? My experience is old) Emacs hackers just never did the sort of refactoring that made people tolerate Eclipse — and that was over a decade ago.
One more thing: if you are interested in lisp, can stand to see C code, and are interested in LSP, look at Emacs-devel.
