4 ms·

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

by Vekz 9y ago

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

xemdetia 9y ago
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/ 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.
- c256 9y ago
  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.
ninjakeyboard 9y ago
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.

by Vekz 9y ago

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

xemdetia 9y ago

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

c256 9y ago
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.

ninjakeyboard 9y ago

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.