Hacker News new | past | comments | ask | show | jobs | submit login
Using Emacs in an IDE World (andrewjudson.com)
57 points by todsacerdoti 27 days ago | hide | past | favorite | 64 comments



This article is really weird. The title is "Using Emacs in an IDE World", but it's just a short note about how the author switched from Emacs to IDE for development, but then switched from iTerm to Emacs for terminal work. Nothing connects into a whole here.


>it's just

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


Agree. What even is this "article"? It's a few loosely connected thoughts about... sorry, but nothing.


The article could be better written but I didn't find it incoherent. The point made is that even if you don't use Emacs as the application you use to write code, it's still a useful tool for a software developer.


>few loosely connected thoughts

Isn't this what blogs were supposed to be? Diary-like entries?


I am using Emacs as my development tool almost exclusively. The biggest advantage to me is, that Emacs supports all languages and most file formats. I work in an environment, where I have certainly main languages, but also occasionally have to edit files from other languages or very varying text format. Emacs is one of the few tools which supports them all. And if not, can be easily tweaked to do so.

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


I recommend trying out VSCode. Just to see if it is a useful alternative. It also supports all languages and has a huge plug-in community.


On the one hand, Emacs is a very flexible platform powered by Lisp. Users can change and extend it to their needs, make smaller adjustments on the fly. That’s the source of its attractiveness and longevity.

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.


> On the one hand, Emacs is a very flexible platform powered by Lisp. Users can change and extend it to their needs, make smaller adjustments on the fly. That’s the source of its attractiveness and longevity.

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.


Somewhere I can see lisp really winning is performance. Everyone complains about bloated IDEs, but if you base your system on Chez Scheme you'll be able to write your scripts in a high level, easy-to-learn language which compiles immediately to machine code that runs at nearly C-speed, and even supports true multithreading. That's a huge win. And if you build it using an actual GUI toolkit instead of Electron, you get another huge win in not using up so much darn RAM.

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.


> Somewhere I can see lisp really winning is performance.

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.


IDEs like xcode and Visual Studio are mostly written in native languages, the "bloat" comes from the out of the box experience and available plugins in the box.

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.


I may be biased (as you point out), but I think that the flexibility Emacs’ architecture (and Lisp) provides is what makes Emacs such a great editor. It’s effectively a canvas for you to create your ideal text editor on. (Although not everyone wants to do that, I know.)

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.


> I may be biased (as you point out), but I think that the flexibility Emacs’ architecture (and Lisp) provides is what makes Emacs such a great editor. It’s effectively a canvas for you to create your ideal text editor on. (Although not everyone wants to do that, I know.)

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.


Personally, I agree that base Emacs is not ideal for most users. Ultra-customizers will feel out home, but the typical dev will not.

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.


I think this is the future of emacs -- distributions/configs. I'm doom emacs user, and I'm very happy with it. It's an easy and pleasant transition for vim users and it works well out of the box, while still giving you the option to customize it to your heart's desire.

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.


> What do you think, is there a potential niche for like NeoEmacs, a test editor written in a modern Lisp / Scheme

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.


You may have a misunderstanding here. Neovim, while it is a ground up rewrite of vim, didn't break people's configs. The team made it a point to maintain backwards compatibility while positioning themselves to be able to move towards using lua as their config language.


Yes, but then Vimscript wasn't a very good language; whereas Lua, Python (and many others Neovim enabled support for) are great languages.

The benefit of a much better language is enticing; making a language much better than Emacs Lisp, however, is not so easy.


Except the specific rewrite the op was talking about was moving from elisp to scheme. It's one thing to support a limited language like vimscript, it's a whole other thing to reproduce the semantics of elisp in scheme.


I'm using Emacs as my main development tool since more than a decade. In recent years, the improvements around language server tooling, especially lsp-mode [1], makes setting emacs up for different environments and languages a lot simpler. I regularly dabble around with Jetbrain tools mostly to compare if I'm missing out on something but I mostly don't find that to be the case.

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.

[1] https://emacs-lsp.github.io/lsp-mode/

[2] https://cider.mx/


I would love lsp-mode with auto-complete integration to be an official package. It is still abit too clunky to get going even though it got better. Also pulling in clangd for c autocomplete feels abit heavy ...


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


> My mentor, the old Lisp guy with the insane init.el file who I would pester with questions, told me: “Just use IntelliJ”.

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.


I admit that I'm not an IDE guy, and I don't really think this is necessarily an IDE world that I'm living in. I've never used IntelliJ, and I've never done serious Java dev.

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.


As a LSP user I agree. Having all my emacs muscle memories, elisp hacks, etc. Together with what amounts to perhaps 70-80% of what you get from an IDE (or at least what _I've_ gotten from an IDE) it's a killer feature.


I don’t personally have any interest in VSCode (tried it, eh), but I am profoundly grateful for its popularity and community because language servers are friggin legit these days, and so there isn’t really much downside to using a real editor. There was this uncanny valley decade where IDEs could actually do some shit that you wanted, but these days if your language is mainstream enough to have a serious IDE, it’s most likely got a monster language server as well. Life is good in code editing land.


At the risk of rehashing all the same-old arguments back and forth, one thing I like about Emacs is it's pretty lightweight and manageable on an old machine. You can bulk it up (and I do) but it's a lot kinder on comparatively-old hardware than something like VSCode.


Eight Megs And Constantly Swapping :)

Edit: I actually used machines where we could use emacs only if there wasn't anyone else online


At least, it's not "egacs" like some of the more recent apps.


Maybe these days that should be updated to "(only) Eight Megs and Consistently Snappy"


Emacs is many things, snappy is not one of them.

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.


You know how "there's an app for that" used to be a thing? Well, there's an elisp package for that: https://github.com/m00natic/vlfi


Yep, GP seems stuck about two decades in the past.

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.


Electron overtook that role from Emacs.


I switched from ansi-term to vterm (https://github.com/akermu/emacs-libvterm) and its performance is much better (specially when dealing with large bursts of output).


I think the mentor gave up and said just use what you are comfortable with. Nothing wrong with that, best to use the tools that we are most productive in. Weird article though.


This is tangential, but I still use vim with UltiSnips, cscope, and ctags for coding (C/C++, python, julia), and it works very well. I've just not been able to move to an IDE, although I briefly played with some - I think I'm just too used to the vim keybindings.


Have you tried JetBrains vim more? It has the same bindings as vim from what I hear.


Yes, I did try PyCharm for python with the somewhat-vi keybindings. But it didn't feel very responsive, and I didn't see too much that I was missing. It's possible that I didn't try it long enough. Haven't tried their C/C+ IDE.

I guess the language also matters. Someone programming in Java would probably see a lot of value in using an IDE.


It doesn't have the same keybindigs but it has a good enough vim plugin.


I read the whole article in the emacs screenshot before I realized it was right above in text...and i preferred it.


I was always intrigued by how other people paying attention to posibilities that each IDE gives you. For me it was always a simple vim, which I can use on any machine with simple predefined .vimrc file (can be done mainly from scratch with a few seconds). Sometimes, where I am talking to other people about some tech likes, they alwas make a big eyes where I am talking that i use vim, nano, emacs etc. I think that comfort and convenience are playing a very important role, sometimes too important imo.


I think you underestimate how much modern IDEs, especially in languages like Java, C#, Kotlin can help the programmer.

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.


> Note it can extract bits of code into separate class, taking into account many things such as private/public methods and variables.

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.


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

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.


> Not at all. This analysis is possible on any kind of language, although much easier on static languages.

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.


Spend a day using a Smalltalk derivative like Pharo, or surviving Common Lisp commercial offerings from Lisp Works and Allegro.


Not really, most of the refactoring tools were born on Smalltalk and Interlisp-D, copied into XDE and Mesa/Cedar and then kid of grew into other industry endeavours.


I agree, I am far away from criticize how modern IDEs works and looks like. My point is that this extensions are jump on at the startup without stricly specyfing new user needs. Extension linked by you are really cool, all best!


> I think that comfort and convenience are playing a very important role

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.


I am happy to use emacs, and I deeply appreciate the fact that, for example, bash understands some of its keybindings. My biggest problem by far is that few applications I use daily do that, and so every time I switch to a web browser or when I am presented with a dialog, etc. I must remain acutely aware that I am not in emacs any more and I cannot use any of its keybindings. This does not come easy.


A nice bonus of being on macOS is that native Cocoa applications/controls understand a handful of Emacs bindings by default, and can be tweaked [1] to understand far more Emacs keys [2].

[1] http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html [2] https://irreal.org/blog/?p=259


I think I've nearly gotten used to it, but I definitely relate. It's frustrating that c-a and c-e don't work in every application, that forward-word and backward-word don't have consistent keybindings or function in the same way in every application. There is probably a moment's hesitation every time I copy text while I consider "Is it c-c or m-w?"


If you find yourself missing emacs keybindings in the browser, you might be interested in the Nyxt browser, which incorporates emacs keybindings (and much of emacs overall philosophy) https://nyxt.atlas.engineer


As fantastic as IntelliJ and VSCode IDEs are, I still find myself (sometimes) preferring working on remote servers with mosh/tmux/Emacs for two main reasons: 1) being close to data on cloud platforms like GCP and AWS. 2) being able to spin up a VPS to work for a few hours that is much faster than any of my laptops and has faster network access.


IDE world?

I had the impression, most devs today would use some editor like Emacs, Vim, VSCode, Sublime, etc.


VSCode is mostly used as an IDE by web developers.


Because it is the only workflow that makes sense shipping a full browser disguised as editor.


How do you know this? I use VSCode mostly for C++.


The article mentions VSCode. Shouldn't Emacs' lsp-mode just work over it?

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


Lsp-mode didn’t add to my config, but replaced many bespoke autocompletion solutions for various languages. I’d recommend taking that leap


Yes I regard LSP highly and used it for one past job in particular.

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


XEmacs (not Emacs) was a good enough replacement back when IDE and UNIX worlds did not meet, but that was 25 years ago.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: