Using Emacs in an IDE World
andrewjudson.com
andrewjudson.com
Isn't this what blogs were supposed to be? Diary-like entries?
It's exactly what the title says. Using Emacs in an IDE world, or else alongside IDEs. (Although I expected to mean using Emacs as an IDE.)
When I edit Java code, I of course grab for IntelliJ, but I am not doing much of Java any more. Yet, immediately I noticed, that while the Java support is great, you have to switch tools quickly when you want to edit something else than Java.
Emacs is very customizable, even if it is some effort, long time it is worth it. And I think Emacs is still way more optimized to be usable without a mouse than most IDEs. Reaching for the mouse is a distraction.
Finally, Emacs runs in almost any conceivable environment. If you have to switch to a different machine, sometimes with a different OS, it is easy to get an Emacs there if it isn't installed already, but getting your favorite IDE there is another task (if it is available at all).
On the other hand, it seems to look confusing for potential adopters, use archaic terminology and keybindings, it takes time to setup a dev environment comparable to VSC. Elisp has its problems and disliked by many users. Emacs slowly loses its appeal and audience, and, in my opinion, this will not change beyond small improvements.
What do you think, is there a potential niche for like NeoEmacs, a test editor written in a modern Lisp / Scheme (maybe, creating such a language would be the first goal), with the same flexibility, but with modern features included by default, modern keybinding and terminology?
Once I hoped Lighttable ( http://lighttable.com/ ) would become that, but it did not happen.
Edit: grammar.
And at the same time the source of most grievance and pain with emacs. It's so flexible that it seems many people fell into that hole where they invest to much time with tinkering. I'm curious how much of the customizing-disease in the emacs-world is driven by survivorship bias of other peoples "heroic" quest in taming and forging their emacs to their demand.
> What do you think, is there a potential niche for like NeoEmacs, a test editor written in a modern Lisp / Scheme (maybe, creating such a language would be the first goal), with the same flexibility, but with modern features included by default, modern keybinding and terminology?
There always will be a niche, if someone does the work on good enough quality-levels. But if you want it to be more than a one-men-show, something that can take over GNU emacs crowd, then you need to be more than filling a niche.
The focus on lisp seems like a fail from the start. That world is just to niche for great success. Today the best solution would be to take electron and build something like atom or vscode. Webstack is more than flexible enough for what most people wanna do, lisp would not give much benefit over this for most people. And most of emacs flexibility comes from the architecture anyway.
Basically, Emacs's success (such as it is) comes from being an application platform. Make a better application platform than Electron and you're onto a winner I reckon.
As for Emacs, if one wants the full Lisp Machine experience, there are Allegro and LispWorks left.
Emacs is only a subset of the experience.
Possible. But the language does not make the platform. Especially if we are talking about flexibility, not performance. If you just want performance, and just enough flexibility, then there are far better editors around.
> Make a better application platform than Electron and you're onto a winner I reckon.
I highly question whether this is even possible. A platform is far more than just a funky language and satisfying random benchmarks. Webstack is in terms of flexibility, support, recognition and optiomization on a level that no other platform can generally compete with today. You can compete on individual aspect, but will still lose out on most others. And this will not change in the next years. The money and time invested into the webstack is nothing any other community can even compete with.
Re: Electron, I personally feel like Electron would be the opposite of the solution. Rather, I’d be excited to see a new high-performance Emacs GUI with graphics acceleration, greater visual fidelity, etc. similar to Sublime Text. ST is the only editor I’d consider switching back to. It just feels so snappy and smooth to use.
The only other thing I’d desire in a “NeoEmacs” would just be better performance defaults — many configs including my own have plenty of lines dedicated to tweaking obscure settings to squeeze more performance out. Ideally that wouldn’t be required.
Yes, emacs is a great tool, hardly possible to deny this. But this is not the bias I meant. I just question whether the benefit people get's from this flexibility, outweights the price most people pay for it.
> Re: Electron, I personally feel like Electron would be the opposite of the solution. Rather, I’d be excited to see a new high-performance Emacs GUI with graphics acceleration, greater visual fidelity,
This would indeed be cool to have. But is it realistic that someone will materialize this dream? The amount of work to make this is enourmous, and GNU emacs-project has not even enough manpower to fix their existing GUI-problems.
If you wanna see a high-performance editor GUI, just take a look at Sublime Text. It's an insanly optimized and very good editor. But it also took them over a decade of regular work with a small company behind it. Not to mention that it's not as flexible as emacs. How long would you think an open source-project of free workers will need to build a modern emacs that will saisfy enough people?
That's the point of electron: it's here, now. It takes away all the hard work of build the important and costly groundbase and will save you a decade of investment. And it will stay and improve in the future. This makes it the ugly but realistic solution where you take the tradeoff of a slower platform to get the chance to actual get something done on a high level.
I think that's a non-starter because you instantly lose the entire ecosystem of elisp packages out there and nobody's config would work anymore. The latter is especially important when for some people that's a decades-developed init.el file in a repo that's migrated from CVS to subversion then git.
I've git bisected (mercurial at the time, but whatever) my .emacs repo to figure out what I did to break my Python config, so there's that.
The benefit of a much better language is enticing; making a language much better than Emacs Lisp, however, is not so easy.
On the other hand, I am a huge proponent of Spacemacs. It's technically just a custom Emacs config, but it is a significant enough departure from the base functionality that it is managed as its own project.
It brings Vim keybindings (as well as an improved package management system and a bunch of other stuff) to Emacs in a very intuitive and seamless way. That way you get access to the very rich Emacs ecosystem, as well as the endless potential for customization, all with the, IMO, superior text editing experience of Vim.
I've tried VSCode, and it doesn't hold a candle to Spacemacs IMO.
I do occasionally envy some of the goodies the VSCode ecosystem benefits from, however. In particular the new Github Codespaces, for example. Still not enough to make me leave Spacemacs though.
There's no way that emacs will ever reach VS Code's level of popularity, but it doesn't need to. Desktop Linux, for instance, represents a teeny-tiny share of the desktop OS market, but it's a vibrant community (or communities, really) that's constantly improving the software and desktop linux user's will let you pry the OS from their cold dead hands. Not everything needs to have an 80% market share to succeed.
And in some areas emacs is just better than other tools in my opinion. E.g. I consider emacs-cider [2] to provide the best Clojure development experience.
This is what got me into Emacs in the first place. I kept hearing that Emacs was far and away the best Clojure editor. I resisted for a while, but when I finally caved and tried it (using doom emacs), I was blown away.
Sigh... I'm the mentor in this scenario. People see what I do with emacs and they often want to start using it themselves. But I learnt emacs when I was young and in university. I barely slept and my life was primarily learning software. I learnt Lisp just for fun. I don't have the time to teach it to you, if that's even possible. You have to put in the time, like I did. And if you were prepared to do that then you would have already done it.
The only IDE I've really used on a regular basis was XCode, and that still doesn't make up a very large portion of my programming experience.
Best I can tell though, LSP is making good on its promise to allow IDE features in your editor of choice. lsp-mode and some parts of lsp-ui are pretty easy to set up for most languages, and pretty helpful from time to time.
Edit: I actually used machines where we could use emacs only if there wasn't anyone else online
In my experience of daily use of Emacs for development, it's much more responsive and helps focus immensely, while CLion only tries to eat as much RAM as is available.
Plus, the extensibility and multiple environments (think edit, shell, debug, SSH, man, etc) in a single viewport without constant context and visual switching help further with focus.
For added fun, try opening a huge file, or one with extremely long lines, and watch Emacs chug.
Now open the same file in VSCode and watch it handle the file just fine.
I guess the language also matters. Someone programming in Java would probably see a lot of value in using an IDE.
Absolutely. Learning new tools is cumbersome, and programs like Vim and Emacs are not just different but also completely unfamiliar for newcomers. Everything you know from the usual text editors is at least partially useless and when you can't even press Ctrl-S to save the file it seems hard to justify learning the basics from scratch.
It's easier to just install VS Code and click on a couple plugins. And I mean it's hard to see the benefits beforehand. Some people I met thought Vim is just some ancient editor with the featureset of Notepad and needlessly complicated controls. That those controls could be really intuitive doesn't come to mind.
Check these https://www.jetbrains.com/help/idea/extract-superclass.html and https://www.jetbrains.com/help/idea/extract-into-class-refac... for some examples of what modern IDEs can do. Note it can extract bits of code into separate class, taking into account many things such as private/public methods and variables.
Similarly, if I change the name of a class or a variable, it will change the name of the class in all files that use it. And it renames the uses of this actual class, not all identifiers that have the same name, so it's much better than just using sed.
This is nice but all of these refactoring tools require a statically compiled language because only then the IDE is able to perform the kind of static analysis that is necessary to make these features work.
My colleagues and I are working on a web application using a diverse set of Perl, SQL, lots of JavaScript and React.js — that’s why for all those dynamic languages my colleagues fancy IDEs (VScode is quite fashionable these days) do not provide them with much of an advantage over emacs. On the contrary, VSCode uses quite a lot of memory and CPU to essentially just edit plain text files. It’s always funny when they complain loudly about MS Teams being a CPU hogging Electron monster but then talk delightedly about their shiny editor.
I was able to use my rather limited Emacs setup quite productively for all the environments mentioned. Usually, it required only some minutes to google around to find the right major mode extensions to support a new syntax and then a flymake minor mode extension for convenient on-the-fly linting. I would download extension directly in emacs using Melpa and then customize them using Emacs‘ built-in customization GUI. I only rarely need to edit .emacs directly. So that’s why I am stuck with Emacs.
Not at all. This analysis is possible on any kind of language, although much easier on static languages.
For example, IntelliJ also supports refactoring on JavaScript. It's not as powerful as on Java (it's had a fraction of the effort put into it), but it's still really useful.
I don't think so. Hovering over an untyped variable like "var foo = bar;" might show you a list of possible methods available on the object "bar" but only if the context of this line contains a constructor call like "bar = new Baz()" making it possible to apply a heuristic guess by the IDE. If it is passed as an argument to a function with untyped signature, on the other hand, there is no way an IDE can reliably autocomplete possible actions on this piece of code because the variable is bound to an object only at runtime.
This is what I meant with IDEs' refactoring tools would require static analysis. The "Language Server Protocol" might make it much easier to support different languages in an editor but it does not avoid the problem of being able to know what object a variable is bound to.
AFAIK even modern, popular statically typed languages like Golang support "interfaces" revealing the true identity of a variable only at runtime.
EDIT:
Just to make myself clearer: "Automatic refactoring" meaning renaming a method in a class and making the IDE to walk over the entire code base and to rename every invocation accordingly, can only work reliably if the IDE knows a variable will always be bound to a value of a certain type or class at compile time. This is impossible for dynamically typed languages, at least in general, for the reason I tried to explain above.
That's why I believe fans of IDEs and automatic refactoring tools are almost exclusively users of languages like Java or C#. They are also the ones who love static typing. Developers working in dynamic languages usually prefer basic editors and avoid IDEs and never quite get why the other groups have so much love for static typing.
[1] http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html [2] https://irreal.org/blog/?p=259
I had the impression, most devs today would use some editor like Emacs, Vim, VSCode, Sublime, etc.
I do Java tangentially (as part of daily Clojure work) and have various Java-centric functionalities working quite smoothly.
I haven't gone as far as using lsp-mode (simply for not introducing more moving pieces) but one can certainly add jump-to-definition using runtime insights (which Clojure makes quite easy).
tldr, you can have a practical Java workflow working over Emacs, be it the easy way or the hard way. Steve Yegge has famously used Java/Emacs for about two decades, don't let people convince you that we live in an "IDE world".
Other than that I enjoy a slow-moving Emacs setup. Also for Clojure in particular which is my main area of focus, the runtime-centric approach tends to be more accurate than the static one.
That is changing though and hybrid solutions are on the rise (like the Calva plugin for VSCode).