Emacs 2011-2023 | Hacker News Reader

Emacs 2011-2023

bastibe.de

64 pointstodsacerdoti85 comments

Why must it always be either or and not in symbiosis? I understand that the author has to use different tools as required by the employer or external constraints. He even lists the various purposes Emacs serves in his digital life, such as org-journal, code editing, etc. And isn't that exactly a point for Emacs? Emacs is not just a code editor or an IDE, but a whole operating system around plain text. So even if I have to use different IDEs, I find enough reasons to use Emacs for personal knowledge management, as a Postman replacement, for journaling, and much more. All in all, the reasons to move 100% away from Emacs are not convincing to me. If everything else that Emacs offers has failed, including its hacker friendliness, there is at least the ethics to it for which I will keep it cherished among a dark, propriety neighborhood that a system that provides Visual Studio is setting.

Because it's hard. I use tons of tools in my digital ecosystem, and the divide is tiring sometimes. Tool switching adds a little overhead, which can become not little when you're trying to do a lot of things because life demands it.

I use Eclipse as my main IDE, but for smaller stuff I use KATE on Linux and BBEdit in macOS. Similarly, my knowledge base has to be divided between two tools.

When you have time, this is no burden. But if you don't, then it starts to bother you. Also, creating digital systems requires time and experience.

However, I'm very with you on VSCode thing. It's a proprietary tool looks like a free one, and keeping people imprisoned without they realize. As a fun side note, VSCode's Java language server is a headless Eclipse instance.

VSCode looks really Free, in what way is it proprietary that you're thinking of? In which language are you using it?

vscodium is really Free. vscode's default python language server for example is not open. I think the remote connection stuff isn't either.

It's free as in beer, not Free as in speech. Tons of plug-ins are Microsoft proprietary, or being closed down step by step.

I'm not and won't be using it.

They’re extensions, nothing prevents you from reimplementing proprietary extensions as open source packages. As a matter of fact, there’s probably an oss alternative for each proprietary extension already. Maybe it’s not on par with the proprietary extension, but then… work on it?

Official VSCode builds are also closed source binaries, which comprise of latest VSCodium stable plus Microsoft's secret sauce (per their wording).

And, I don't prefer to feed closed source ecosystems with open source plugins, since the core is not open to begin with.

It's not that I'm in need of an IDE-like code editor. I got that part covered already. Also for larger needs, I use the same tool for the last 20 years, which is Eclipse.

Lastly, while I love to support Free Software, I have limited time and have to choose my battles wisely. So, instead I build the tools I need in my personal and professional life instead of developing plugins.

If I have more time, I'd rather develop plugins for Eclipse, though.

Exactly. At work I have Emacs running in WSL, after a bit of tweaking it runs almost as fast as on Linux and doesn't give any trouble. I also have VS Code for when some coworker wants to work on something together and asks for it. You don't have to use only one of them!

What also helps is keybindings. I like vim so I use evil and whatever the VSC equivalent is, and most other commands are done with a "leader key" in both editors, so there's not a big difference in ergonomy.

It's really not much trouble to have these two setups co-existing. In fact I'd be upset if I had to choose only one.

> Why must it always be either or and not in symbiosis?

At the end of the day, it's just another tool with its own weight. And if the weight becomes bigger than the benefit, it's time to move on.

Yeah, this. And sure, with enough effort, I could "scratch my own itch" and fix whatever bothers me, but it is often not a trivial effort, and afterwards... it's still emacs, and whatever my fix was, I have to remember how it works forever to navigate other challenges that will come up.

It is more pragmatic to simply find a tool that works for whatever I'm doing and call it a day.

>Why must it always be either or?

OP explains as follows:

>as my Emacs usage waned, so its ancient keyboard shortcuts started to become a liability. I started mis-typing Emacs things in Visual Studio, and hitting Windows shortcuts in Emacs.

I use (basic) Emacs shortcuts everywhere via Karabiner Elements. Caps is control. And Enter is control when pressed with another key.

The point is that the basic Emacs shortcuts don’t work in VS or VSCode. Also your solution does nothing for the “temptation” to use Windows shortcuts in Emacs. There are ways of working around both of these problems with enough effort, but these workaround get exhausting and it becomes easier to just stop using Emacs.

Author here. Exactly right.

>Emacs is not just a code editor or an IDE, but a whole operating system around plain text.

This meme really needs to die.

I use emacs a lot, but the attitude that it's not just a text editor leads people to accept UX mediocrity.

Emacs has fallen behind VS Code in many ways, including text editing.

LOL. I use Emacs for note-taking, spreadsheets, calculations, to-do lists, calendaring, email, static site generation and more. Please show me VS Code extensions that have feature sets comparable to those of Emacs packages like Org, mu4e, calc, etc. Here, I'll save you some time by eliminating a couple options:

- VS Code Org Mode[1] has maybe 2% of the features of Org for Emacs.

- The only VS Code-based mail client I've ever found is VSCode Mail Client[1], which was developed during a single month and then abandoned.

VS Code is clearly for normies who use WYSIWYG word processors, webmail, etc. Suggesting that VS Code has surpassed Emacs for non-coding activities is laughable.

[1] https://github.com/vscode-org-mode/vscode-org-mode

[2] https://github.com/buhe/vscode-mail

“Normies” why do we belittle people who just want to get work done and move on with their lives?

>I use Emacs for note-taking, spreadsheets, calculations, to-do lists, calendaring, email, ...

Hey, me too. Or at least, I used to. I've done most of those things but you know what? There are specialty tools that do almost everything better than emacs does it.

Emacs calendar is inferior to Google calendar, thunderbird, or even Apple's calendar app.

Org mode spreadsheets pale in comparison to libre office and excel.

Emacs's email handling is straight up dog shit.

Doing simple calculations is better/easier in a python or sbcl repl than am emacs buffer.

Generation of static sites is easier, more flexible, and generally better dx with a shell script.

Actually writing text is better in vscode. It's more performant, for starters. Imagine a program in 2024 that locks up the GUI if you make a network request. Oh wait that's emacs. Embarrassing.

I've used emacs since the early 2000s and I am not afraid to admit VS Code is a better text editor than emacs.

And yet emacs is the only tool doing all these at once, able to save important emails in org mode list you can annotate and export in calc for further integration, running some python scripts to get the last vales to be included and update your static internal site with the result and progress on your tasks...

I guess I just don't see the value of having a "jack of all trades/master of none" text editor.

I'd rather use specialized tools for each task, maybe gluing them together with python or bash if needed.

I never understood the all-in approach either. Different tools handle things better.

I personally am using a mix of tools with my editors being vim for editing files quickly on cli, emacs for magit (honestly I just use it as a git tool and it works amazing, the startup and leaving it running 24/7 is no issue on a modern computer), intellij for java (it just works), and vscode for python, terraform, javascript/node.

I see absolutely no issue with this setup, I’m not sure I would recommend it to everyone but if you use a tool, that you feel works better for even a specific case why not use it for that. If new tools popup in the future I’m always willing to try them, if they work better I’ll add them to my workflow.

Emacs has really funky (and useful) keyboard shortcuts and behaviors that make it awkward to switch to anything else.

It took a few weeks, but it wasn't that hard to switch, and I'd used emacs for going on 20 years. That's not to say there aren't things it did better than VSCode -- it's a given that any switch between tools will have trade-offs. But it wasn't horrible.

Escaping Emacs terminology ("buffers", "frames", etc.) was a big win, as far as I'm concerned.

Few reasons:

* Keybindings are different, and switching back and forth adds friction.

* You get looks if you use Emacs. From those over 45 it's like "I remember that from my DEC days; why use it now in the age of Eclipse/JetBrains/Atom/VSCode?" From those under 45 it's more like "You're using that ancient thing from the 70s?!" There are probably Facebook memes out there with an Emacs screenshot and the caption "If you use this to code you're a psychopath." Social pressure these days is against Emacs, so if you're going to use something else, may as well go with the flow and use something else, not something else and Emacs and be thought a weirdo.

I've been labeled a weirdo my entire life, this does not scare me.

I like open source, but a lot of other considerations are higher on my list of priorities.

I wonder how Magit was replaced. Magit is the sole reason I can use Git at all. I have never used Git from the command line, and every time I see non-Emacs-using coworkers trying to use git, it always seems like a mess the moment they do anything more complicated than switching branches.

I remember briefly using the Git features in Xcode and IntelliJ, but both were pretty convoluted and lacked specific features I use daily, such as staging ranges of a diff (rather than an entire diff). There's also little things that make Magit essential to me, like cherry-picking a commit from the reflog having virtually identical UI to cherry-picking in general. Never bothered to try learning how to these things in Xcode or IntelliJ since the interface was complicated enough just to create commits and view a log.

I don't use VS Code, but my coworkers that do use VS Code seem to use git entirely from a terminal window. So I am guessing VS Code doesn't have a Magit equivalent.

There's edamagit[0] for vscode, it's pretty good! I've been using it for a couple of weeks now and haven't needed to touch git via the terminal.

0. https://marketplace.visualstudio.com/items?itemName=kahole.m...

I come from a vim background and have used vscode and intellij as well. But picked up emacs solely due to magit. A coworker showed me it and I have to say it’s really amazing. Nothing really compares to it, the closest I’ve seen are the cli tools “tig” and “lazygit” but magit really outshines them feature wise.

There’s nothing “similar” to it but vscode does have git tools, it just feels really clunky to use imo. Same goes for intellij’s UI. I guess it works for some people but they sort of just hurt my head to look at.

VSCode has excellent git and github support (especially with the GitHub Pull Requests and GitLens extensions). In my workflow, it has surpassed anything Magit had to offer. While I still use the command line git extensively, I've come to rely on VSCode for a lot of the more complex contextual information available when editing, resolving merge conflicts, staging, and contextual git history available in popups.

I always leaned on emacs due to its versatility working in remote environments on the command line. I still use it occasionally, but for me the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin. It's a game changer and the best remote IDE experience I've ever had. Then Copilot came out and cemented the change.

I think in general emacs and vi users learn to live with the UX and legibility issues of the software. I find vscode to be better at that. It strikes the right balance on a lot of things, in particular I find myself learning new things faster and with less frustration because the shortcuts, commands, and contextual information are more intuitive and in line with my expectations.

OSS Code's Git support is embarrassing compared to Magit. (Perhaps the proprietary extension is better, but I refuse to depend on proprietary tools for my core computing needs.)

No line-by-line committing, no branch spinout/spinoff, no worktree support, no interactive rebase support, no reflog, the list goes on.

I can see OSS Code being better for only novice Git users.

> VSCode has excellent git and github support (

no, it really really doesn't, compared to magit.

> the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin

Have you tried using TRAMP? Depending on the specific backend chosen (ssh, scp, ...) it has varying levels of speed, but I have found it sufficient for my needs.

Regarding Copilot, that's an interesting use case. It makes me wonder if other editors have extensions that try to recreate this experience. I wouldn't be surprised if Copilot is the killer feature of VS Code nowadays.

TRAMP is unusable if you have a high-latency connection. The UI thread blocks for a few seconds after every operation, which are really frequent if you use a complex configuration. The remote SSH plugin makes high-latency connections bearable, it's not perfect, but IO operations run in the background and so the UI thread does not block.

I expect rewriting Emacs to use async IO to be a massive effort. It's difficult to write async code in Elisp.

TRAMP is unusable for my needs and doesn't really implement the remote IDE paradigm at all. I would argue that no IDE really implements the remote IDE paradigm aside from VSCode with the remote SSH plugin; it sets a new benchmark. I've tried several other IDEs and I haven't seen anything that works nearly as well.

Take a look at the diagram here: https://code.visualstudio.com/docs/remote/ssh - you will see that VSCode does not simply connect to the remote computer to read and write some files. It installs an entire VSCode server - seamlessly to the user every time they connect to a remote - that keeps track of all project facilities, shells, extension accessory runtimes, takes care of embedded or computationally heavy tasks like compiling, building, running project-wide code analysis tools, etc. while keeping all settings, editor windows, and accessory panes local (which is critical for UX and latency). VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions.

These latency optimizations and offloads are not ad hoc; they are rooted in VSCode's origin as a browser-based IDE, and make use of the LSP and other architectural features that simply don't exist in Emacs because nobody really thought deliberately about running the extensions at an arm's length from the editor UI in Emacs, using an async protocol that doesn't allow extensions to impact core UI latency.

A routine issue with TRAMP is that some unrelated plugin makes editing very slow and subject to random freezes because it expects low-latency I/O to the file being edited and to other accessory files next to it. This is a major issue that absolutely kills editing UX and confidence. It doesn't really happen with VSCode (worst case, the red squiggles show up a few seconds late), and just as importantly, the entire project behaves predictably because it's not just TRAMP running on the remote but the entire IDE infrastructure.

Ironically, I think Emacs' origin on X-based systems foreclosed on the architectural possibility of a clean separation of concerns that can be seen in browser-based IDEs; it would be wildly disruptive to the package ecosystem.

Author here: I love magit. But at the end of the day, I mostly use it for simple stuff like committing, pushing, and the odd merge or blame. And these simple things also work very well with the IDE's git integration.

For everything else, I stick to the command line. That's the only part of git that will always work no matter the interface. I find it easier to memorize, too, and it's of course much easier to search for online.

I abandoned Emacs for a year or so and used BBEdit for regex-replace and VS Code for dev tasks. Also gave up on org-mode and org-roam because I could not find a mobile companion. Adopted Obsidian for all my note taking use-cases and journaling in markdown.

A few weeks ago I asked myself if I can use Emacs as a front end for my markdown files in my Obsidian vault. So I started setting up Emacs for searching files via counsel-fzf and via ripgrep (I can jump to any heading in my markdown files, find any content in my 17k+ files, in an instant, using Emacs). I use yasnippet for templates.

After a week or so I realize this:

0. I love writing documents in Emacs, use Elisp to automate my workflow, and have all my files available on the go via Obsidian.

1. Emacs + Elisp are a wonderful platform for all things text.

2. Markdown is less capabable then org-mode, but it's available everywhere.

3. Org-mode is tied to Emacs, and thus no mobile solution.

4. Broke down my 5k lines Emacs config file into packages and import them. This made it more managable. And now I version control my configs and packages. This also made it more managable.

I still use VS Code for writing code, BBEdit for regex search/replace across files, I just have re-discovered Emacs again. It's just unbelievably versatile with the Emacs Lisp language. I cannot automate Obsidian just as fast (or at all).

## Edit

I have said fare-well to Emacs soo many times, just to realize how absolutely lovely it is / was, and come back to it. Always. And then, with a fresh perspective, appreciating it even more. So I don't believe this fella is going to stay away from it :)

## Edit 2

What boosted my Emacs usage is ChatGPT and Claude 3. I have never created that many Emacs packages in my life like in the past two weeks or so. With the right prompt and a few iterations I can make Emacs do whatever I need it to do. Absolutely stunnig.

Interesting! Just over the past month, I've reduced my emacs usage a lot. I'd switched to VSCode for most coding a while ago, but I still kept my daily journal notes in org-mode, but I recently switched to Logseq for that.

I don't know if I'll stick with it, or if it'll get sluggish after a while, but right now the searching, rich-text, and pdf-annotation seems refreshing.

I moved into management 5 years back. And since then I have reduced the amount of coding to a degree that I don't write anything that goes to production. Most of my coding is scripts to automate something or discovering something personally. I juggle between Emacs, vim, and VS Code for many of those; VS code especially if I want to navigate code. But Emacs is my daily driver. I use plain text files to keep track of things, write meeting notes, etc. The one editor that I keep coming back to is Emacs. May be it is me, but its flexibility is unbeaten. And as strange it sounds to say this these days, but Emacs is light. So much so than VScode. It isn't vi/vim, but it is snappy to get started.

Just recently I wanted the M-x shell to support OSC 8 links(you can click them to go to a file), and all it required was to write a small function to do so. This function goes into the thousand odd lines of lisp that I have curated over a 16 years. It is an editor that keeps evolving.

My experiences cover roughly the same period (early 2000s through August 2023), and then I switched to VSCode. I switched partly because I was sick of the kludge-y nature of Emacs -- yes, it could do anything, but there was a lot of tinkering to enable it. The problem with this stuff is that you never escape it -- 10 years later, you are still replacing packages or tweaking packages, or finding new issues with a newer package... I got tired of it. Even though I liked Emacs Lisp OK, I came to feel it was a big productivity drain.

But although I've used VSCode since (mostly for TypeScript development), I can't say that I like it. It is forever showing me things (pop-ups) I didn't ask to see, and it has problems working with WSL2 (it doesn't seem to notice filesystem changes correctly), etc. As usual, though, I am busy enough with real work that worrying about the ideal development environment has had to take a back seat.

So it's possible I will eventually return to Emacs. More likely I will find some other tool. I'm tired of the Emacs way of doing things, even though I think the architecture of the editor was brilliant.

See, it's not that you have to tweak Emacs; it's that you can tweak Emacs.

ALL software has flaws; it's just a question of whether you can fix it yourself or you have to live it with and hope someone fixes it for you.

The design is old enough that it needed a fair amount of tweaking to be tolerable. It doesn't really have a workable notion of projects, out of the box. Lots of stuff like that.

Author here: That's an important aspect actually. These days I'm just not excited any more to tinker with my development environment. I've got better things to do...

When it comes to only writing code and executing it, then Emacs is not the best editor. I used Lapce for Rust, and it is fast, lightweight and modern. Lapce also has some keyboard shortcuts and it is a joy to use. Emacs has some features relevant to editor appearance and tiling, but not that big of a deal compared to other editors.

When it comes however to keyboard focused, unmoused control of a cumputer, then Emacs is the only option, there is no other option. Text is of course very central to Emacs, but images or anything else can be embedded and processed inside Emacs.

Emacs lacked till now the killer app, and i think that app is LLMs. Emacs has already 5 different packages for interfacing with LLM's. Personally, i just cannot imagine using LLM's without Emacs.

One example i could give, by using the GhostText extension, one can write in a textarea in a browser inside of emacs. Poe.com for example has a textarea the size of which, is not adjustable like HN comment-textarea, and writing anything more than 3 lines is confusing. Big deal, write inside the textarea using emacs, much faster and accurate.

If someone knows, what's the big deal with pair programming that Emacs cannot replicate? Is is a good implementation of CRDT's?

A typo, and no edit button after some period of time. Darn.

I'm at the point where I just wouldn't take a job if I didn't think I could use Emacs. I'd be hobbled to such an extent. Like carpenter unable to use a hammer.

When I first entered the market 15 years ago there were loads of Windows only places that were completely out of the question for me. The world then seemed to change and it was easy to get a good job for a while. But the forces of darkness never went away, it seems. I always said I'd rather just quit computers then do anything Microsoft. I hope I don't have to put my money where my mouth is, but I'm still prepared to.

The need for grown-up computing is not ever going away. It gets less visible, harder to see against all the noise.

Before you get all smug, Vim people, this applies just as much to you as to us. :P

I'll probably never let go of Emacs, but have encouraged both of my kids to avoid it and use VSCode instead.

I would, however, encourage anyone to learn the GNU readline keyboard shortcuts. I don't use emacs but I think they are emacs adjacent. I've come across those shortcuts in many many places (that used readline or not). There's also rlwrap which wraps any non readline REPL.

https://discuss.kakoune.com/uploads/default/original/1X/f458...

I've jumped ship from vim to vscode ~5 years ago, for better or worse, after having been a vim person for previous ~20.

There are still things I miss which are impossible to replicate in vscode without breaking it, but I feel the out of the box experience and reduction in configuration complexity is a rather large net positive.

vim is still what I use to edit stuff via ssh and in docker images, though.

I wouldn't say I've jumped ship, simply because I'm still using both. I've got vim in a terminal and a vscode window up, and it's not seamless, but I wield the two together to get the job done. Debugging is done in vscode, but vscode doesn't have all the vim stuff in, so in still attached there, plus it runs in a terminal and vscode doesn't.

Do you use one of the vim plugins in vscode?

I tried and they kinda sorta 95% work, but then you hit the missing motions or a keybinding conflict or some extension issue and it’s either fight the thing or go the opinionated way.

I've been using Emacs for as long as the author and I've also never really recommended it to anyone. I've never met anyone I could imagine going through with it. I feel like if you're the type to use Emacs you'll find Emacs yourself.

I think that's probably true. You have to dig to see what's good about Emacs, and to get past the initial "this is so alien" impression.

I don't think it applies. Vi's key idea is a composable text editing language, and it's transferrable between editors, with a few quirks but mostly intact. (although there are new editors that iterate on this idea, and they have their own, better designed, but incompatible text editing languages).

Emacs' key idea is a composable environment, which translates poorly to non-LISP languages and other programmable editors due to their more rigid design. It's really an operating system with a non-conventional architecture.

As the joke goes: Emacs is a great OS, only lacking a decent text editor

I've taught programming at the university for a decade. There would always come the time when students would ask what text editor to use. This was an interesting and varied question for many years.

But nowadays, it's just VSCode. It may not be open source, and it may not be a particularly exciting (or good?) text editor. But it has become so ubiquitous that I'd just short-change my students if I recommended anything else.

They'd still occasionally see me type into my Emacs (which looks nothing like stock Emacs). And sometimes it would even get a kid or two interested. Some even switched to Emacs because of those classes. I have since given up teaching, though.

I've long used Emacs and org-mode for all my legal writing for Web posting, including my course materials (which have turned out to be a pretty-long PDF for print-on-demand). I once tried to use Microsoft Word, but in really-large documents, Word's internal cross-referencing just isn't reliable. So I can't imagine ditching Emacs.

(I started using Emacs in law school, and wrote keystroke emulators for both Word Perfect BITD and Word. Nowawdays, when using Word on others' machines, I have to remember that, say, Ctrl-A doesn't go to the beginning of the line.)

Ehm... I fail to see substantial arguments... I can just extract:

- having others using different tools and being non in comfy position it's a known thing, and often demonstrate that others choose bad habits instead of you

- pair programming is harmful

nothing else. I almost live in Emacs digitally since I boot to EXWM, have my files as org-mode attachments, info in general in notes and so on, I have some complaint like poor handling of floating windows, some blocking operation, rare crashes, ... witch are Emacs issues (well, Emacs ecosystem, at least), but the fact that others have other tools and working together due to the tools other use, not made to play with other, is an issue it's not an Emacs issue. It's like saying "Emails are bad because my contacts use WA and WA can't read or send emails". Pair programming fall in a similar category: "hey, I'm tall/short/fat/hairy/with little|large feet|hands so I do not fit well in common clothes, it's the final nail I have to conform my body to the others". It's not an argument, it's the DEFEAT of a human choosing to be part of a machine instead of being a human, with it's idea, tools and so on cooperating with other humans, similar, but different where the difference is the key of intelligent innovation, evolution, if our peers are smart.

Working in a setup that demand such level of conformism means working in a fragile setup (too tied to some third party tool) with limited innovation margins since different vision can't be compared and discussed regularly boosting idea migration.

Some conformism is useful under certain emergency, not in the ordinary life. Making ordinary life like an emergency means being unable to live.

I have just the opposite problem. I've tried Visual Studio Code many times, each time wondering if there were some productivity benefit I was missing because everybody seems to use and love it. I'm just not seeing it. Having Emacs Lisp right there, in which I can knock together some automation that smooths the pain points out of my workflow, is just too much a benefit.

Visual Studio Code is just aimed at a different kind of developer than I am. (ThePrimeagen fans, stay quiet; you risk violating someone's code of conduct if you speak up now.) It doesn't work the way my mind works, so I will always be a foreigner in its lands. Plus, Emacs is just too cozy. It's like a beanbag chair: once ensconced in it, you struggle to get out... and you really don't want to.

Emacs now has a package called crdt that uses -- you guessed it -- CRDTs to provide collaborative editing. I've seen YouTube videos of it in use and it seems to work rather well. So you can pair program remotely with it, but I don't pair program often enough to need it.

Thanks, Bastien, for org-journal. I've used it almost every day for the last 4 years. Perhaps you'll find a new use for Emacs someday.

You're welcome! I find daily research/work notes completely indispensable at this point.

> But it was of course a complete non-starter for pair programming. After having tasted Visual Studio (± Code) Live Sharing, there was simply no going back.

Interesting that the straw that broke the camel's back for the author was pair programming. I've been pairing pretty regularly for a long time now, and everybody using their preferred editor/IDE was never a problem. Live editing the same code is something we played around with every now and then, but there wasn't real utility. One person sharing their screen is pretty much how I've done it for the last five years or so. If we want to switch who's driving, we just commit.

Edit: In fact, my experience is that it has never been so _easy_ for everyone to use different editors. CLI toolchains, editorconfig, auto formatters and linters, LSP, ...

I have a lot of experience pair programming and I definitely find that minimizing the friction to switch driver is a huge deal. Especially when knowledge-sharing or mentoring across experience divides, being able to take over for a few seconds but then fluidly hand control back just makes it not feel like a big deal for either person.

In non-remote jobs I would always set up my station with two keyboards and two mice for this reason. Now that I work remote I always keep VS code configured for the codebase and use it for pairing. Even though my personal editor is, yes, emacs.

Author here: the neat thing about Live Share in VSCode/MSVC is that both people can type at the same time, both can use the shared command line and shared debugger, and both can navigate the shared project files. Independently, of course, with each on their own color scheme and keyboard setup.

I don't want to oversell it. It's not perfect, and has loads of bugs. But the fact that we can refractor the code base with two cursors simultaneously, is actually super powerful. Often one person is typing while the other is cleaning up a typo a few characters ago. It feels like symbiosis. It's really good.

And noticeably less lag than screen sharing, too.

I went through something similar, I enjoyed emacs TRAMP for so long... One day, I saw a colleague opening remote vscode through SSH. Turns out I hadn't seen that on vscodium... it's kinda proprietary. (Should I care?) It's work! It needs to get done!! (: and another feat was magit, but that I left behind when I started using gitui ... I still highly appreciate and respect emacs. Maybe one day vscode will turn shit because, hey! it happens, and emacs will still be there for me <3

It's okay to use different tools. Don't worry about it so much.

FWIW, I spent a lot of time in Notepad++ with my own syntax and settings setup for a specific video game I made mods for. And then I learned Linux and really bought into BOTH Vim and Emacs. And then I stopped playing around with computers and pretty much forgot about all of that stuff. No hard feelings.

I was also unhappy with emacs breaking across versions, but I learnt to adopt to the new and sane keyboard shortcuts for org mode. http://muratbuffalo.blogspot.com/2024/01/dude-wheres-my-emac...

I've been a casual user of Emacs forever.

But I never gelled with it.

I've always found its complexity a bit overwhelming.

I learned the few things I needed. Things like read and write files, arrows to move, pgup, pgdown, ^S, ^R, M-X compile, ^K, ^Y -- honestly, that's about it, no doubt there are others, tab, auto-indent, paren matching. I've made a little progress using Slime for Lisp, or the scratch buffer, but tend to just fall back to save the file and reload.

Emacs is infinitely customizable, and I don't customize things.

To quote the Genie: "Phenomenal cosmic powers! Itty bitty living space!"

That's the emacs I live in.

I've never been comfortable with its chording control style. While everything is documented, it's not necessarily discoverable. Never got comfortable with its scrolling style. I always fumble with switching between buffers, particularly when it's more than just to and fro with ^X-b.

There's a drop down menu on the menubar (on my Mac, I use stock Emacs), but it actually takes 2 clicks to use.

And trying to set it up to develop Java is just...well, complicated.

I originally used Emacs to write Java, back in the pre-IDE days. I liked its free syntax coloring, I liked that Ant worked with it, out of the box (maybe with -e for emacs messages or something). And I muddled with that for several years.

Eventually I switched to NetBeans, and I can't do Java without all of the autocomplete and other gizmos NetBeans gives me out of the box.

And why NetBeans rather than Eclipse? Because it works great out of the box, and I don't have to customize it (note earlier). Early Eclipse was plug-in mania.

I won't give it up, I use it for my Lisp coding (auto-indent and paren matching mostly). But, I doubt I'll ever curl up with it.

VS Code people: how do you not go crazy when you try out a new language? I just opened up a love2d project I've been working on and everything has error squiggles. Do y'all just spend hours getting your tooling figured out every time you try something new or do you just disable diagnostics?

I once happened to be with a coworker setting up VSCode on his new laptop. I was shocked by the reckless abandon with which he installed all kinds of third party extensions.

First thing I do with a new Jetbrains IDE is add a bunch of plugins. It’s pretty much the way most IDEs roll.

Do you worry about malware?

Doesn’t the average emacs user load dozens of packages? I know I do. Malware crosses my mind, but it would be a lie to say I do a fully audit of every package I use.

The surprising part for me wasn't that he was installing packages. It was that he just did a super fast search-click-install loop, where many of them had handful of ratings max, some even 3 stars or less. I'm used to checking out the Github repo of the package first, considering how many stars it has, how many releases there have been, etc before adding it to Emacs.

But you bring up a good point. Perhaps installing packages willy nilly is orthogonal to the editor choice.

I guess we don't until there are supporting extensions.

Or we switch back to vim.

It’s not hugely different than working with a new project in a fancy IDE, once you figure out adding generated sources, aiming the tools at the right config files if everything’s not in the root, etc. If you’re lucky they’ve set up a docker-compose.yml to get started with, otherwise you have a couple hours work ahead. It’s a one-time cost you don’t have to pay again unless you wipe and clone the project from scratch.

I vastly prefer IntelliJ, but project setup on vscode has never been a major speed bump in my shop.

What would you do in Emacs? The reason I switched to VS Code was exactly because I could instantly get set up with most languages by installing an extension, instead of messing around with Elisp configs and a hodgepodge of packages. I couldn't even figure out how to set up a working Java environment in Emacs.

I don't really do anything fancy. I use citre and ctags for goto definition and use buffer and tag based autocomplete.

Spending time fiddling with extensions makes me want to stick forks in my eyes, but I'm genuinely curious if other people just generally suck it up and get it figured out or if they just ignore error squiggles a lot.

I would never go anywhere near Java with Emacs though, I would just bust out Intellij or Eclipse for that.

Just ignore it. Errors will be fixed or deactivated with time. Especially with something new, there are already enough things to figure out, error squiggles are just another bag of noise.

> love2d

For Lua last time I tried I just did not install any Lua extension, just use the native syntax highlighting and move on.

Emacs is still kicking on for me, though Helix is looking its biggest competitor. Not in the same league in terms of extensibility (Helix is deliberately non-extensible) but the out-of-the-box experience couldn't be more different.

I just can't come at the combination of Electron, non-free components, and the owning company. Codium helps, but not enough

I've recently actually switch to Emacs from VSCode.

I've done the journey Vim -> VSCode -> Emacs -> Neovim -> Kakoune -> and then Emacs back again. This time I'm sticking with it. The reason is simply that I think it provides capabilities for:

- great devdocs and info pages integration

- automations (compile project, set up project specific bindings etc.)

- email (mu4e)

- navigation (vertico + ripgrep integrations)

- note-taking (howm)

- magit for git handling

... and then everything else it comes with. I'm quite a big fan of everything being minimal and text only.

I have to say that the author's story is sad. It is scary how Microsoft is locking down the ecosystem though through their pair-programming tools and other integrations. I really wish we could use the tools we prefer rather than succumb to Microsoft overlords.

Reply on news.ycombinator.com