6 ms·
Emacs felt like it was stagnating around 5 to 10 years ago, but now things are just getting better and better. LSP had been a game changer, for Emacs and all ot
by smabie 6y ago
Emacs felt like it was stagnating around 5 to 10 years ago, but now things are just getting better and better. LSP had been a game changer, for Emacs and all other editors. The days of IDEs are numbered.
- simion314 6y ago>The days of IDEs are numbered. How? if you turn your text editor into an IDE with plugins then you make Emacs an IDE. In my mind an IDE "understands" the entire project not just the opened file.
- smabie 6y agoI guess an IDE has an unclear definition, but I mean stuff like Intellij, Visual Studio, or Eclipse. With LSP along with an explosion of new languages, they don't provide as much value anymore. A high quality language server can provide 99% of what a high quality IDE can (like Intellij). IDEs still have an edge, like with debugging, profiling, or SQL db integration. I've mostly ditched Intellij in favor of Emacs for a large Scala project, something I wouldn't have ever dreamed of doing 5 years ago. I still use Intellij for debugging, but hopefully debugging servers and some Elisp will solve that problem soon.
- pjmlp 6y agoThat is like 10% of IDE capabilities.
- niclo 6y agoCan you please list the other 90% of must have capabilities for day to day development ?
- pjmlp 6y ago- GUI designer for each UI framework available - Visual representation of data structures - Navigating in binary libraries - Architecture diagrams with two way editing - Integration with ticket and source control systems, so that I can relate an issue with a branch and respective set of changed lines of code - Live unit tests - Live static analysis, as one types - Incremental compilation, when hitting run almost everything is pre-compiled - SQL database integration, ER diagrams, OR mappings generation - Management of server instances and cloud services - Memory profilers - GC tuning tools - Code metrics - Graphical debuggers for GPGPU programming - Graphical debuggers for threads, tasks and processes - Handling of processes as single project for micro-services debugging And a couple of other stuff, basically the kind of goodies one gets with Visual Studio Enterprise.
- simion314 6y ago>Can you please list the other 90% of must have capabilities for day to day development ? - find definition - find usages - rename - extract method - detect code duplication - highlight unused symbols(vars or functions) - understand frameworks and libraries - can suggest useful transformation or code simplification - Intellij can understand type documentation like JSDoc and PHPDoc and use it in completion and highlight errors if using the wrong type or object member - smart spellchecking, spellchecking that understand when it is in a comment or if it is a symbol name - good VCS support(diff, commit, push) - good debugging support - IDEs have by default a lot of linting and code analyzing tools setup, trying to go from Intellij to VS Code defaults is a big downgrade , maybe it could be partially fixed by installing many plugins but I personally want to pay for a good program made by professionals and keep them profitable(and not have JetBrains fail or get bought by Google or Microsoft)
- benley 6y ago> - find definition > - find usages > - rename Emacs has these covered, especially when using LSP modes > - extract method I don't know what this is, sorry > - detect code duplication > - highlight unused symbols(vars or functions) This is what linters and static analysis tools are for, and emacs integrates with them nicely via flycheck. > - understand frameworks and libraries not sure what this implies, sorry > - can suggest useful transformation or code simplification > - Intellij can understand type documentation like JSDoc and PHPDoc and use it in completion and highlight errors if using the wrong type or object member More static analysis tooling, doesn't need to be built-in to the IDE, just hooked in with something like flycheck. > - smart spellchecking, spellchecking that understand when it is in a comment or if it is a symbol name emacs can kinda do this via flyspell but it's not perfect. You're right, this is a good idea. > - good VCS support(diff, commit, push) magit! > - good debugging support I'm mostly clueless here, sorry. > - IDEs have by default a lot of linting and code analyzing tools setup, trying to go from Intellij to VS Code defaults is a big downgrade , maybe it could be partially fixed by installing many plugins but I personally want to pay for a good program made by professionals and keep them profitable(and not have JetBrains fail or get bought by Google or Microsoft) aye, there's the rub. I suppose the "I" in IDE is the real value: the package deal with all the linters and analysis tools already hooked in. Various LSP modes have made it vastly easier to reach feature parity with this stuff in emacs with minimal effort, but I also definitely understand why things like Intellij are desirable and useful.
- taude 6y agoI don't know. I'm a very heavy Emacs Doom user, but I still load up projects in Intelli-J/Rider. I find Emacs combined with ripgrep/silver searcher a nice way to search across all my projects, and treat my local code bases as a monolith. Once I find what I need, if I'm not just reading the code, I typically open of the project in a native IDE. I'll only use Emacs for making small configuration changes, or when working with small POC type of stuff, or writing small CLI projects. I do use it extensively for magit and org-mode, org-journal, and my REST API interface via org-verb (instead of Postman/curl/httpie) though.
- pmontra 6y agoMy emacs instance is currently editing projects in Elixir, Ruby, Python and Node. None of them remotely resembles what it would be in a Java like IDE. There is no need to "understand" a project in those languages, edit save and reload has been enough for me and my customers since 2006. For Java, I used Eclipse and Netbeans. I consider the need of an IDE as a bad smell in the design of a language.
- pjmlp 6y agoAnd I consider programming languages not designed with IDE tooling in mind a design smell for the said programming language.
- leafboi 6y agoAny language that can be compiled is by design suited for IDE tooling. Think about it, if a compiler can analyze the code then so can an IDE. An example of a language that can't be analyzed by IDE tooling is the English language. Case in point the English language can't be compiled either. The parent poster is basically saying that there are languages that are so complex that to even program in these languages you (usually) need IDE tooling to assist you. C++ and Java are good examples of this.
- simion314 6y agoIDEs do a good job with dynamic languages too, if you document your types and function definitions it will provide you same features as a static language. You need to avoid abusing eval or similar constructs like p[kind+"_name"].
- NateEag 6y agoAlso worth pointing out that even static languages often have escape hatches into metaprogramming that defeat tooling. I've seen Java codebases use reflection heavily enough to utterly confuse the IDE.
- pjmlp 6y agoWishful thinking, that only proves a complete misunderstanding what an IDE is for.
- josteink 6y ago> Emacs felt like it was stagnating around 5 to 10 years ago, but now things are just getting better and better. LSP had been a game changer, for Emacs and all other editors. The days of IDEs are numbered. Agreed with the first. Disagreed with the second. LSP only ensures that the interests of independent Editors and bigger IDEs to a bigger degree aligns than they used to be before. It's not a war. This should represent a win-win for everyone.
- bloat 6y agoLSP in Emacs or in any editor, is only as good as the language server - in some (many?) cases the language server is effectively a headless IDE.
- zelly 6y agoIt's still stagnating. Emacs has something like 2% of market share. LSP doesn't add many new features. We had jump to definition etc. for decades with TAGS which was much many orders of magnitude faster than LSP. LSP just serves to foster IDE envy and make users switch to a real IDE (and honestly why wouldn't you, if you acknowledge that even a smidgen of IDE features makes you more productive). Emacs will never ever have as the same features or same types of users as IDEs--pursuing that is a losing battle. Emacs should focus on becoming as fast as vim. That's its real competition, not IDEs.
- deleted 6y ago[deleted]
- nvarsj 6y agoEmacs was never intended as "just a text editor" and it shouldn't strive to be one. It was the first IDE and it is infinitely better than almost any other IDE in terms of customizability. It's main drawback was a lack of very good support for non-LISP languages - TAGS are incredibly simplistic and only let you do basic code navigation. LSP solves that by leveraging the huge amounts of development effort put into VSCode's language support. This makes Emacs, which has a superior editing mode (with evil-mode), and superior customization options, one of the best IDEs available. The only other IDE I use now is Jetbrains for JVM support (because there is no good language server, unfortunately), but I don't enjoy it - you can barely customize it and the text editor sucks compared to what I can do in Emacs.
- zarkov99 6y agoMy perspective, as a mostly C++ programmer, is completely different from yours. LSP is great when it works, which unfortunately in my experience is seldom, and it is absolutely key to retaining advanced users. If someone like me, who knows emacs lisp, hates Microsoft and has used emacs for 25 years, is tempted to switch over to VSCode because of its superior C++ IDE tools then surely new programmers will not give Emacs a second look.
- zelly 6y agoIs this not the exact phenomenon I was talking about? You have been able to write C++ for 25 years without Microsoft, but now you've gotten IDE envy and want to switch. Of course LSP will always work best on VS Code, which is the platform it was designed for.
- slightwinder 6y agoEmacs is just fetching up to others and reducing demand for manpower with LSP. It is not inovating itself, nor moving toward a better future. The core-architecture remains the same, the old problems remain the same. Manpower is hardly growing and marketshare seems to be stable or even shrinking. Competition on the other side is outpacing Emacs by leaps and bounds. > The days of IDEs are numbered. Nope, IDEs will never die, they just change again. Editors are becoming IDEs now, merging both to become more than before.
- mijoharas 6y ago> The core-architecture remains the same https://akrl.sdf.org/gccemacs.html https://akrl.sdf.org/gccemacs.html as posted already in this thread, compiling more of emacs with gcc, very interesting change to the core architecture. > the old problems remain the same. from the linked article - Lexical-binding is used by default - Portable dumping used instead of unexec What exactly are you talking about?
- slightwinder 6y agoThis are not changes to the core-architecture, just speedups for bottle-necks. This pushes a bit the boundary until you hit problems, but does not solve the problems at all.
- truncate 6y agoMy primary development environment is Emacs for around 7-8 years now I think (used to be pretty proficient Vim user before). I mainly program in C++ and Python, but often hack on Java, Go, Rust and Haskell. I have heavily configured my Emacs, and window/buffer/workspace/panels/keybindings (you name it) work exactly the way I want -- and its muscle memory -- to the extend that I feel paralyzed in anything else -- even if it has much reliable code browser/completion or feature X/Y. So here's my two cents: Even though Emacs is not mainstream, I somewhat agree that the ecosystem is much better now and I can get to configure it as IDE. Sometimes things break, sometimes it takes frustrating amount of time to configure/fix things -- which is probably 1 click away in VSCode. And regardless anything, despite LSP, nothing just works out of box or is immediately obvious. And for these reason alone I think the mainstream IDEs are here to stay. That said, I don't care (or think doesn't matter) if Emacs remains mainstream or not, as long as the ecosystem remains healthy and strong, and it gets the work done. It will keep it afloat like past whatever 30-40 years. However, that doesn't mean it can survive without being competitive. For me, the single BIGGEST ISSUE that made me consider trying VSCode is performance. On two companies I've worked with, the C++ parser performance with LSP running is just purely BAD (more so on MacOS I think). And quite honestly I can see myself getting frustrated enough someday and move.
- truncate 6y agoSeems like native JSON parsing should help with LSP performance!
- slezyr 6y ago> LSP had been a game changer, for Emacs and all other editors Not for me. I've tried to use LSP for Chromium's code base(~40k files) and it was miserable. It took 8-10 hours to index it and each time the LSP server started it used 10GB of RAM to work. Comparing it QtCreator's Code Model (the old one which everyone hates, not clang based) takes 2 Min to start from zero without blocking the GUI.
- ddavis 6y agoWhat language server did you use? These days both ccls and clangd should be able to handle Chromium.
- slezyr 6y agoccls, they can handle Chromium, but after 8-10 hours of indexing and then it uses 10GB of RAM when you launch the editor.
- NateEag 6y agoI've used language servers in large, old codebases that took a while to parse, and they never blocked the GUI for me. I only got intelligence on as much of the project as it had finished parsing at a given point in time, obviously, but I wasn't stuck waiting for it to finish before I could work. This was using php-language-server and lsp-mode for Emacs.