It's very interesting. I used Emacs for a long time, but slowly got weaned off it.

- I used it for email, then I had to collaborate with people who wrote "please see my comments in orange below". (Of course, they were Outlook users.) Emacs did not show that orange color, so I didn't know... Maybe these days it's possible to read Outlook emails nicely in Emacs.

- I used it for development, then the Java software I worked on got too big to internalize all APIs and Eclipse completion and refactoring really helped. I did try to build the Eclipse "quickfix" thing in Emacs, but all I got done was to add a missing import (because JDEE, I think it was, provided that functionality).

- I switched from Linux to Windows because the world around me was like that, and so I could help junior colleagues with their EOL problems...

- I used Mercurial (hg) for a while and TortoiseHg was really nice, so I didn't feel the need to use Emacs for this.

It's a pity, really. Some aspect here, some aspect there, and then you get pulled away from Emacs.

Now, with LSP, perhaps Emacs could offer code completion and refactoring, but the Java app I work on builds with gradle, and I have no clue how to tell the Java/LSP thing about the class path... So I'm on IntelliJ...

I don't understand why people are moving Linux --> Windows. At the company I work for everything is native to Linux--I am floored by the number of interns we get who are using Windows (it's all of them). We have an intake script for getting them up on WSL2 with our stack on top but man these graduates are CompSci people and they did 4 plus years of CompSci using Windows? I can only imagine the pain. Or rather, I know the pain since I have occasionally dipped my toes back into that world of hurt.

A non-WSL2 Windows person doesn't get the benefits of Nix, usually doesn't live life on the shell (since every Windows program is gui first), doesn't do dotfiles management (you can but paths for the git Atlassian method are non-obvious), ssh password protected keys are a PITA...good God I could go on ad nauseum.

I work in this industry because I love computing. But these Windows jockeys I dunno I get the feeling they don't necessarily love computing? Or in the way that it's this mundane tool for the production of money-points that they can then exchange for money. I also am receiving the money-points and it is good. But lemme crack open your head and pour in the magic y'know?

> But these Windows jockeys I dunno I get the feeling they don't necessarily love computing?

When I was younger, I wanted to work in places that had a passion for these types of things.

Older me realized that was a bad idea. It inevitably seeps into things unrelated to doing the actual work (even performance reviews via 360 feedback). People are paid to do a job, and I've found that whether they love computing or not is mostly orthogonal. Sure, there are some that are wiz's because of it, but they're usually neutralized by those who become ideological and inflexible because of it.

Tangentially related: I'm a Linux guy - it's been my primary OS for almost 20 years now. However, at my current company, I prefer roles that don't involve Linux. The reason is they typically will not give me my own machine - I'll merely get an account on some server, with a poor window manager, and missing a lot of the nicer tools I use on my home machine, and no superuser privileges. In the last job I had, their provided Emacs was a little too old for some of the features I used, and I had to compile my own Emacs from scratch (along with tens of other dependent packages). This was time wasted for me and the company. At least on my Windows machine at work, I have Admin privileges and can make things nicer.

Paradoxically, it is because I'm a "hard core" Linux user that I prefer Windows for work. I've optimized my Linux workflow, and if my work cannot provide me my preferred tools/window managers, I might as well just use Windows.

I don't even use WSL. I use xonsh, which works fairly well on Windows. I have multiple desktops on Windows. And most importantly, I live in Emacs which for the most part works just as it would in Linux :-)

(And no, using/installing Emacs on Windows is not a pain, despite what you often hear - the last time I did it some months ago, it was literally "Download and unzip into directory and you're good to go.")

What I often hear is more about Emacs on windows having performance issues in some areas, magit comes to mind. Did you run into any issues?

There is one case I know of where Emacs (via Cygwin) has performance issues on Windows: listing directories in remote volumes. Per StackOverflow [0], dired is slow because `df` is slow on NTFS. So, you can eliminate df to speed up dired by a lot.

`(setq directory-free-space-program nil)`

0: https://stackoverflow.com/questions/26128693/emacs-dired-slo...

Main issue is magit. Currently the repository I work on is small enough that I put up with it. But I can see this being a real deal breaker for many.

There are certain Emacs features that may require some UNIX tools like find or grep. Often I've found ways to configure it to use ripgrep and fd instead (both are trivial installs in Windows, and generally faster than grep and find anyway).

I think git is slow on Windows, and magit doesn't make the problem better or worse.

Nope - git is mostly fast on Windows. It's magit that's the problem - or rather how magit does things. It launches several git processes to do basic things like status or commit, and that is fundamentally slow in Windows.

See https://magit.vc/manual/magit/Microsoft-Windows-Performance....

So you are saying git is slow on Windows, but only because starting any process is slow on Windows. Interesting. I've heard there is work in progress to have magit use libgit2 instead of running the git executable. That should help.

Speaking as someone who regularly attempts to switch back to Linux, I did that because the Windows desktop is a genuinely nicer experience. In no particular order...

- The traditional start menu / taskbar is genuinely nicer than what Gnome attempts to force on me. OS X is also genuinely nicer than what Gnome attempts to force on me. I'd take either over Gnome.

- The Linux desktop environment is laggy. This is difficult to measure objectively, but nothing moves smoothly and responsiveness is through the floor. I'm using a 144Hz screen; why can I see windows jerk from position to position when I drag them?

The Zen kernel helps with some of that, bringing it about to the same responsiveness as Windows -- which is still well below OSX. No desktop environment provides it by default, and in most it's difficult to install. On NixOS it's just "boot.kernelPackages = pkgs.linuxPackages_zen;", but it's still not the default.

- nVidia's drivers are poor, and there are a lot of sharp edges. I'm using one of their GPUs. No, I can't switch to AMD; I need it for CUDA, and anyway GPUs aren't exactly cheap.

- AMD's drivers are of inconsistent quality, and I couldn't buy a 6800XT even if I'm willing to sell my first-born. Ok, that's also true for nVidia's newest GPUs, and Zen 3, and... different rant entirely.

- HDR basically doesn't work.

- Mixed-DPI screens basically don't work.

- HiDPI in general is glitchy.

- kanjiTomo doesn't work on Wayland, because there's no solid story for the screen capture protocol.

- Bluetooth audio basically doesn't work.

...

Windows isn't perfect, but for me the Linux desktop died to a thousand paper cuts. Every two or three months I make another attempt at getting it up to the same standard I get from Windows, and every two or three months I fail.

Does the above sound kind of entitled? It's not. I'm not demanding that anyone should make this work for free; I've never paid for the Linux desktop. The fact is, however, that it isn't good enough to use without unpleasant consequences, and I've spent far too much of my life fiddling with it already. At this stage I just want something that doesn't eat my evenings.

While I have to use occasionally Windows for work, on my own desktops and laptops I have used only Linux for almost 20 years and I have not seen any of the problems encountered by you.

Your problem with Wayland I could not have seen, because I have not attempted to use Wayland yet, but most of the others seem to be Gnome related.

I have never used Gnome, as I have never liked what I have briefly seen in the Linux distributions that default to Gnome.

Perhaps that is the reason why I did not have your problems.

(While KDE 3.5 was much better than Windows was at that time, I have been hugely disappointed by the unbelievable regressions in KDE 4, so I have also abandoned KDE at that time and I am using XFCE since then. XFCE imposes very little restrictions on the desktop applications, allowing the free mixing of graphical applications that were designed for either Gnome or KDE, so I can choose whichever works better.)

Linux is much more diverse than other operating systems and there are a lot of alternatives for most components.

Almost all complaints that I have seen about Linux, were in fact not applicable to Linux in general, but only to certain specific configurations that I would not attempt to use, because I agree that they are bad.

Unfortunately, choosing a Linux configuration good for a certain purpose and for certain hardware frequently requires either a lot of experience or the wasting of much time with trying various variants.

"Unfortunately, choosing a Linux configuration good for a certain purpose and for certain hardware frequently requires either a lot of experience or the wasting of much time with trying various variants."

This is why I stay with windows for my dev machines and either use WSL or ssh to a linux box. All my machines at home have WSL2 installed and I use it as my default shell, I never open powershell/cmd, they may as well not be on my machine, for all my development needs and use all the linux tools that I would be using if I was on a native linux desktop.

I can be up and running on a windows dev machine in the time it takes me to download VScode and open it, or I can spend weeks trying to get a linux environment to the same place. With my setup I still have all my linux toolset that I would use on a linux desktop, but I don't have to contend with all the issues of getting a linux desktop environment running.

I have run into all the same problems as the parent of this and more, I have tried different desktop environments including Gnome, KDE, Mate, Cinnaman, and XFCE. I have moved between xorg and wayland more times then I care to count, each ended up giving a different set of problems.

At the end of the day, I want to spend my time being productive and getting work done, not fighting with my OS to get the basics running. I love linux but it's just not ready to replace windows on the desktop.

I have also 20 years of Linux experience. XFCE (I love XFCE btw) does not solve this points mentioned. I think you're biased and this are valid points OP mentioned:

- nVidia's drivers are poor, and there are a lot of sharp edges. I'm using one of their GPUs. No, I can't switch to AMD; I need it for CUDA, and anyway GPUs aren't exactly cheap.

- AMD's drivers are of inconsistent quality, and I couldn't buy a 6800XT even if I'm willing to sell my first-born. Ok, that's also true for nVidia's newest GPUs, and Zen 3, and... different rant entirely.

- HDR basically doesn't work.

- Mixed-DPI screens basically don't work.

- HiDPI in general is glitchy.

My first Linux distribution was Slackware 2.0, offered with the Unleashed Linux book, before I had already get to know UNIX via Xenix and DG/UX.

For a couple of years I subscribed to Linux Journal, faithfully reading every issue, became a Stallman missionary, trying to spread the gospel, even though most of our university assignments were to be done from Windows (W95/WFW 3.11 back then).

Eventually I got tired of choosing configurations and taking care OS distribution bonsai trees, and nowadays just use Mac/Windows/Android (where the Linux kernel use is an implementation detail), leaving Linux for the server room.

  > The traditional start menu / taskbar is genuinely nicer 
  > than what Gnome attempts to force on me. OS X is also 
  > genuinely nicer than what Gnome attempts to force on me.

This is definitely subjective, and if Windows jives for you that's cool. To provide a counterpoint: Gnome for me is worlds better than Windows and slightly better than OS X. It definitely takes a little getting used to if, like me, you literally grew up with Windows, but I vastly prefer Gnome nowadays. Not to mention, you have choices besides Gnome -- although if you dig Windows mostly they'll just be either wildly different than what you want, or a clear imitation.

Truthfully, if you need HDR or specific AMD/nVidia features, you're right you're probably gonna have a rough time. (Bluetooth has worked just fine for me, though.)

It's definitely not all roses over in Desktop Linux land. I miss having real third-party app support -- sometimes you just need After Effects or actual Word/Excel -- and MacOS' consistency in keystrokes (Cmd+, as the "preferences" hotkey in every app is just so good) but for 90% of what I do it fits me really well.

I used Linux (XPS15) at work for a 3 month period (Pop_OS!), mostly because I really enjoy using Emacs (and the performance on stock Windows is lacklustre). With the exception of bluetooth, which is absolutely tragic on Linux (I have issues with bluetooth everywhere, but this is next level), 40% of my job was actually very good using that computer.

On the flip side, my job uses Office and Teams quite extensively, and the browser experience is subpar. OneDrive sync is also spotty (InSync works ok, but it's not "set and forget" at least for my use-case). Everything works, but it's less easy than on macOS or Windows, so you have the added cognitive load. I ended up having a VM with Windows when I really need it. It got ridiculous when I needed to join Teams on my phone and my laptop to get sound and share my screen.

On top of that, Linux works very well for the fun work. I don't especially like doing PowerPoint decks or blazing through emails, but because the tools are less friendly, I end up spending more time doing stuff I don't enjoy doing. It means that my productivity gets lower. I miss i3, the familiar command line, all the goodies I got to discover and enjoy on my "play" machine, but the 60% remaining got more tedious.

I ended up moving back to a macbook air (which is less powerful than my Dell) because of the "lack of configuration" to get it to somewhere where I feel "peak productive". Some stuff at work I just want to get "done", and ultimately Linux (or the lack of good Linux compatibility with some of the tools my workplace mandates) went in the way.

I used WSL1 a little while back. It was nice, but it was another thing to get setup which I am not familiar with. I'll get windows back on the XPS and try, maybe it'll strike the right balance.

A bummer, really.

Vanilla Gnome is terrible. You must embrace extensions. At first I loathed the idea, but it's just become part of life. One for a dock, one for weather, one for tray icons, and if you prefer, one for top menu that gives you your more traditional start menu type thing.

Or, there's always Xfce or KDE, of course.

AMD drivers are now open source and finally working well. Nvidia is not, granted.

Bluetooth audio works well, even on rando cheap noname devices I've tried. My primary speakers are some Logitech bluetooth pair.

Don't use wayland. Run gnome in xorg mode.

In fact, I'd go as far as to say I'm blown away by how much -just- works on Linux. My printer is autodetected on the network and print. My wireless mouse works. My monitor runs at 1440p.

If you're open to it, I always suggest using a modern distro that stays up to date because you get better hardware support(if using new hardware, that is). Typically, that means something Arch based, but there are distros around making that simple.

This all highlights is a lot of choices and “do this don’t do that” kind of things I don’t like about the Linux Desktop environment, I don’t want to think about these kinds of things in my usage of a desktop. It’s a summation of everything I find lacking in the Linux desktop community

Sure, but there are a lot of distros out there that do these things for you. Solus Gnome is probably my favorite out of the box experience. It's basically pre-configured exactly how I tune Gnome myself.

But how would you know to use that particular distribution, before becoming an expert first and know exactly what pre-configuration to look for? Knowing this pre-configuration is as difficult as knowing how to make such pre-configurations imho.

On windows, there's no choice. On mac osx, there's no choice (unless you try to mod it yourself after the fact).

I ended up trying Solus.

It turns out I can't install it, because the installer bundles an old version of the nouveau driver, the nouveau driver crashes on my hardware, they've deleted the nvidia driver package for the version of Solus that's on the ISO (along with every other package), and there's no terminal-mode installer or any other workaround.

If you want to install Solus, and the year-old installer doesn't work in GUI mode, then you're SOL.

> Don't use wayland. Run gnome in xorg mode.

Interestingly, for me, I only see some of the issues the GP mention when using xorg instead of wayland.

> AMD drivers are now open source and finally working well.

Only for those using modern cards, my old APU is stuck in GL 3.3, whereas the fxgl supported 4.1.

At least I can use it for GL ES 3.0 coding.

That's very weird.

I'm using both, Linux for 8 hours at work and then Windows for my personal computing needs.

I live mostly in the browser. Both OSes basically work. I can move my windows around lag free, entirely, always.

Bluetooth audio works. This 4k screen I'm using now for the first time on Linux just worked.

Which browser? I find Firefox performance unacceptable on ubunutu. I’ve got an nvidia gpu, it feels like Firefox isn’t using it.

Chromium works ok, but I don’t like using chromium.

Do you only have the one 4K display? I guess it depends on the apps you use, but I’ve had to set special scaling settings for individual apps, and that breaks down with multiple mixed-DPI displays.

Yes Bluetooth audio works, but at least on ubunutu I get a long list of MAC addresses and not device names, which has poor usability IMO.

I’ve also noticed Ubuntu with gnome in particular is slow to start apps, and doesn’t give any indication of whether the app is just slow to start or has failed.

Until very recently, Firefox on Linux did not have GPU Acceleration or WebRender. With Firefox 80 and 81, they were added but both were not enabled by default. It may very well be the case that Firefox is not using your GPU.

Regarding mixed-DPI displays and scaling, I have not had issues with GNOME on Wayland.

Bluetooth Audio also works quite well for me, and it shows device names rather than addresses.

I will agree that GNOME tends to be slow to start apps after a while, although it is very quick on fresh installs. I am not sure why that is.

I feel like GPU accel is disabled for most configurations in Firefox on Linux. I had to force-enable it, and perf got quite a bit better (even with dinky Intel graphics).

I use windows for work and as soon as im done I reboot on a linux partition. My daily driver is linux as I hate the lack of control I have and the insecurity (i feel that microsoft does whatever behind the scenes) i get on windows. For example after an update windows shoves me an edge icon on the desktop. I removed all the bloatware on the laptop and multiple times things are re-enabled after an update. I also cannot turn off updates if i want to. There are a few services for which I as an admin have no way of turning off or even change any settings. Wtf! I was able to gain some control of my machine with some registry settings but at the next update everything was overwritten. F that, i don’t wanna play whack-a-mole anymore. If i need to use some windows software i boot the windows partition, then when done boot up on linux. Ubuntu these days is low friction, most Hw works out of box, etc.

You are doing it wrong. If you are using Linux, use a window manager (sway or i3 are a good start). I'm running Archlinux with Nvidia and it's going great. No problems with the card, performance, and I have 3 screens of different DPI. I'm yet to try Bluetooth, though.

ps: If you are using an Nvidia card, you can't, unfortunately, use Wayland.

if it doesn't work out of the box, Linux is doing it wrong.

why should I have to install an os, then change my desktop environment, then spend weeks learning keyboard shortcuts for said new environment, to get basic functionality working.

Having used all 3 major platforms, for me the developer experience in Linux really is the best. And I say this as someone currently trapped on MacOS. For personal hacking I use an older Dell XPS15 w/Ubuntu and it’s like a breath of fresh air every time I dig into a project. Containers just seem to work so much faster, there’s fewer weird things, no hiccups, and things like git and Emacs scream compared to Windows.

I totally get why people prefer Mac and Windows outside of software development. But as a working developer it’s really worth the effort, if given the option, to invest in learning Linux and developing on it.

Interns doing the whole WSL thing makes me cringe. Not great for your career IMO unless you plan on making a quick exit from the dev side of things.

This might be a controversial take, but I feel like A “worse” developer with a solid workflow in Linux will appear more productive than a somewhat more skilled developer getting dragged down by WSLisms.

I always felt that Mac struck a good balance between my programming productivity and “the rest”, because I could use some great applications that were otherwise unavailable on Linux, sadly.

What pains did you have? Docker support was a big one for me, but otherwise I haven’t encountered anything too bad.

Docker and occasionally periodic sluggishness that includes my pointer skipping on some websites. Also, despite a faster CPU and an SSD at only 14% utilization things like emacs and Sublime seem more sluggish in terms of I/O.

I would probably benefit from a reinstall of Big Sur: this machine has gone through 3 OS upgrades.

What I really appreciate on Linux tho is workspace ordering and switching. Which I don’t think you can customize to the degree you can on Linux anymore in Big Sur.

That's why I work at a place where devs are basically required to use Linux. It's a great filter and training mechanism.

I work at a place where developers have no problem switching between different OS’es. And I would not hire and prefer to not work with developers who refuse to work on anything but a specific OS.

I could be wrong, but it seems like someone who is happy to frequently switch between macOS, Linux & Windows is probably not actually taking advantage of all the features of any of them, and hence is not actually terribly productive (assuming arguendo that those features actually aid productivity).

For my part, I use emacs on Linux because I believe the power of computers is in crafting a personalised productivity enhancer. Free software which can be customised down to a very low level is part of that.

> probably not actually taking advantage of all the features of any of them

Yep they are probably too busy doing their job: creating value for customers. Instead of having fun fiddling with their OS.

> I don't understand why people are moving Linux --> Windows.

Which Linux?

With Windows you can use the Home edition and still have a decent workhorse of a computer.

> A non-WSL2 Windows person doesn't get the benefits of Nix

You greatly overestimate the benefits of Nix to any person. Nix is a fringe on the margins on the footnotes of the world. Even among developers it's barely a curiosity.

> I work in this industry because I love computing. But these Windows jockeys

First thing you have to do is stop being dismissive of people for their choices.

Most of the world uses Windows.

If you're building software targeted at most of the world it makes sense to use Windows.

Most of the world uses Android to run their browsers, right? Should I develop on Android?

Are you suggesting that most of the existing Windows SW out there could be developed on Linux and would just run fine on Windows? Can MS reasonably develop MS Office on Linux? Can Adobe develop Lightroom on Linux and it'll just work on Windows?

For most Windows SW, the answer is no. So the analogy with Android doesn't make much sense.

Actually according to Google own statistics, most of Android Studio users are on Windows.

Not really. Android, Web, Embedded, Networking can be done in Linux.

I meant desktop software, but even so most Android users also use Windows, and pair Android with Windows. Most Android developers use Windows.

Back when I did my degree in the mid-90's, our labs were running a mix of LC III, Windows 3.11 for Workgroups, the recent Windows 95 and terminals for the DG/UX server.

The only classes using UNIX were the ones specific about UNIX content.

A the end of the 5 years, the DG/UX server had been replaced by a Red-Hat one and most terminals, were dual booting between the university own distribution and Win95/95 OSR, some of us also had access to the freshly released Windows NT.

The large majority of students was still only booting into GNU/Linux for the UNIX related labs.

Anything related to graphics programming, Smalltalk, databases, AI, engineering tools (UML, Boochs, CASE), digital circuits, was done on Windows/Mac OS (System).

When I started the job, the little team I was on had a special deal that allowed them to use Linux; the rest of the company was on Windows. When I switched from Linux to Windows, it was partly due to outside pressure and partly due to a desire to help team members in India who did not have that special deal and were thus forced to use Windows. But a couple of years later, the special deal evaporated and everyone had to move to Windows...

I suspect that it is still common to be forced to use Windows at $BIGCO.

I use Linux at work for development (10+ years) but prefer Windows at home. I can’t stand any of the Linux desktops. And believe me I have tried hard to like them. I love programming and have been programming since I taught myself machine code programming when I was 11. I recommend not assuming that people who choose to use Windows somehow don’t get it or don’t see the “magic” of whatever you happen to like. People are different with different tastes and experiences.

There's a whole galaxy of small and medium (and actually quite large) businesses automatizing the boring shit in a boring way. Its my experience these shops nearly always use Windows. Note that most regular people do as well, so there's a fertile ground. Think of how things like Embarcadero and Pascal survives.

That's what they teach them in University.

It's really not. I was forced to do everything on *nix systems in university. I mostly work in C# on Windows in VS today, which is not something a single class in my university was taught in. We run our code on Linux, but I really don't need to interact with it much. We model everything in our stack using Terraform. I do use WSL-2 a bit when I need to, especially when interacting with the AWS Cli or Docker and similar.

It's just a good desktop and dev environment that stays out of my way, has sensible defaults, and doesn't require endless twiddling to be productive in.

> I switched from Linux to Windows

This is where many people leave Emacs. It's not that there's better tools on Windows, it's that Emacs on windows is terrible.

Magit is orders of magnitude slower, for instance, and external tool integration is grossly impeded by the poor availability and quality of package management on Windows.

Maintaining Emacs on windows takes considerable effort.

Personally, I make do with WSL1 and Emacs. WSL2 is intolerably broken when working on NTFS folders, so it's a nonstarter. This means Docker is broken (mounts don't work) but Emacs works well.

Yah, it sucks.

> it's that Emacs on windows is terrible.

I use Emacs on Linux and Windows equally. I've used Emacs on Windows at work for a decade. Other than magit, there's virtually no difference in experience between the two platforms.[1] Of course, perhaps you use a different set of features than I do.

> Maintaining Emacs on windows takes considerable effort.

I install it on my work laptop every 2-3 years, and for the last 5 or so years, it's literally been "Download, unzip and run." Occasionally I have to make registry changes to get org-protocol to work. Even 10 years ago, it was still fairly simple - just a bit of extra work to get some GTK related stuff installed as well. But right now it couldn't be easier.[2]

And I don't even use WSL. This is native Windows.

[1] Of course, if your Emacs is calling out to tools like grep/find, etc, you'll have issues unless you install those tools. Although these days, it's not hard to configure it to use ripgrep and fd, which has excellent Windows support.

[2] And perhaps installing LaTeX if you want to export org files to PDF.

For whatever it's worth, I've found the same thing: that the amount of effort required to use Emacs on Windows is minimal. Since Windows is non-POSIX, inevitably some things are different, but it doesn't take much to deal with this.

My .emacs.d folder (now 15 years old, and a bit of a monster, a whole git repo with thousands of lines of nonsense plus a pile of submodules) has no more than a few spot hacks for Windows vs POSIX vs macOS.

(The most annoying bit has probably been keeping on top of the font names! - but interestingly these are actually super easy to deal with on Windows. It's Unix that's the pain in the arse here.)

Mostly issues with lsp servers; particularly ccls and omnisharp.

I've been using the mingw windows version every day for years. I used to spend time now and then to make new things work, recently I switched to doom emacs, and almost every new functionality or package I try works out of the box.

It's true that Magit is slow, but I still prefer it to the command line.

I'm going to give Doom a shot; I ignored Spacemacs because rebinding native keys and forcing evil-mode was a nonstarter for me. If I wanted to use Vim then I would, and did for a time.

... and that was an immediately disappointing experience.

1. Saving customizations didn't work.

2. Launching Emacs as a client that auto-launches a server _always_ failed the first time.

3. I really don't need a custom package manager built on top of another custom package manager to replace the core package manager. straight.el would've been enough, thanks.

4. My batteries-included Emacs launches a server in a few seconds, a client almost instantaneously; doom took minutes to launch a server on my Pinebook Pro and clients took a few seconds.

5. Another needless dotfile dir in my home. ~/.doom.d could easily have been ~/.emacs.d/doom.d

"forcing evil-mode"?! Spacemacs asks if you want to use "evil", "holy", or "hybrid" mode early in the process.

Interesting, I suppose I missed that when skimming the GitHub repo readme.

Well with wsl2 I gave windows a go for my work dev environment. And so far emacs had been amazing via wsl2 and a x server.

I should note I did modify the xserver to allow me to toggle individual windows going fullsceen. And am running native emacs (which is blazing fast)

WSL2 + X server was my go-to for a few weeks, but then a rather large repo I access, with git-lfs, became corrupted due to WSL2 + NTFS bugs. They've been mentioned on HN before.

Thereafter, every day or two the same bug would arise and I'd have to lose an hour or two recovering the repo. Just a week or so ago I switched back to WSL1, and I ssh into an RPi4 to access docker containers, using qemu and binfmt to execute x86 code slowly.

Yah, it sucks. ;)

From a recent HN discussion, I learned that emacs has had a sampling profiler built in — not on MELPA or something, first-party! — since about 2013. How many widely-used applications these days contain a facility for asking "why is the command I just issued executing slowly?" and for _doing something about it?_ As far as I'm concerned, that's now table stakes for a programming environment: you should be able to not just run a profiler on whatever program you're using the editor to interact with, but to do robust profiling on your editor itself.

In terms of IDEs, IntelliJ also comes with built-in profiling. And every modern web browser has robust built-in profiling tools.

I think you're referring to (its wrapper around) Python cProfile, not a profiler for the IDE itself?

IntelliJ has a profiler for the IDE itself, too.

Automated profiling is one of the best things to get right over a few weekends. I'm slowly putting together something for the D language to do it but it's a bit of a pain.

Anyone know of CI service that can have use rdpmc/perf_events on the cheap?

There's also M-x emacs-init-time if you want to know how much a change to your configuration impacted start-up time.

To be fair, of all of the editors I've used, emacs is the slowest and needs a profiler the most.

Naah, not really. I've done that emacs exercise countless of times over a few decades and now I use vscode. I don't feel like I'm missing much.

It is easy for people who love Emacs to believe that most people (or most programmers) would come to love (or prefer) Emacs if they would only put in the time to ascend the initial learning curve. But this belief is an instance of what is sometimes called the "typical-mind fallacy": an underestimation of how different people's minds are.

GNU Emacs was my daily driver from 1991 to late last year, when I switched to vscode. I wrote many lines of Emacs Lisp code -- 20,000 lines of which I "kept": I arranged for those lines to get loaded into Emacs every time Emacs starts, and since the code was almost all "UI" code, any particular function or piece of the code ran on average at least several times for every hour I spent using Emacs.

Although I do not regret choosing Emacs in 1991, vscode suits my particular mental make-up better than GNU Emacs did.

To take one example, I spent hours configuring Emacs to be less chatty. I turned off the bell that sounds every time the user makes an error (where for example asking Emacs to scroll down when the bottom of the document is already visible in the window is considered an "error" -- in contrast to vscode's not feeling the need to send a message to the user or get the user's attention when that happens). I tried (and mostly succeeded) in turning off the repetitive messages Emacs displays in the echo area, e.g., displaying "Wrote foo.c" any time Emacs writes to file foo.c and, e.g., (particularly distracting to my train of thought) the "Autosaving..." message that regularly appears in the Echo area X seconds after I stop typing. In contrast, vscode is silent (non-chatty) enough to suit me in its default configuration -- like most GUI apps since the introduction of the Macintosh in 1984 are.

P.S. The way I got rid of the "Autosaving..." message was to turn off Emacs's autosaving functionality altogether and add my own autosaving functionality, which consisted of a call to save-buffers every time the user switches buffers.

Did you use orgmode and mu4e? If so what are you using in their place now?

To read mail, I used (version 5 of) Kyle Jones's VM, but (out of my being too lazy to configure mail fetching and mail sending) switched to gmail.com about 6 years ago.

I never embraced org mode because I didn't want to learn another few dozen keyboard shortcuts ("keys" in Emacs terminology). There are for example in org mode keyboard shortcuts for moving the current line up a line and down a line. Even before I saw vscode my reaction to learning about those 2 shortcuts was that such functionality would be useful (particularly in to-do lists), but I would prefer to execute the functionality by dragging with the mouse, which it turns out that vscode lets me do (in its default configuration): particularly, I click on the line's line number to select the line (to set the mark and activate the region in Emacs terminology) then move the mouse cursor into the selection, then drag. (In emacs, I'd kill and yank to move a line relative to the other lines -- and I configured my emacs to have a menu on the right mouse button with the kill and yank actions on it.)

In general, vscode is a nice environment for keeping to-do lists. Consider for example this next small "hierarchy" of actions:

  buy milk

      drive to store

          find car keys

If we replace "find car keys" above with a string of text too long to fit on one line, then the basic structure of the small hierarchy becomes obscured in Emacs (even with visual-line mode on) but not in vscode as I explain in greater detail here:

https://news.ycombinator.com/item?id=25311743

I do something like this in VSCode as well, Markdown todo lists:

  - [ ] Task 1

    - [ ] Task 1.1

      - [x] Task 1.1.1

    - [ ] Task 1.2

etc.

In particular, I break down yearly goals into quarterly, monthly, weekly and daily, each another node in the tree getting increasingly more specific.

It really helps understand the flow from the highest to the lowest levels of details. Only problem is if goals change midway, it's not propagating up the tree automatically. I just leave it like that though, not gonna manually fix that.

I use https://quire.io to do similar. It's also 100% Markdown, and you can copy the list itself as Markdown to elsewhere.

C-x t

I'm on the same boat as you. I love Emacs, the uniform keybindings and especially Magit, I thought I could never use anything else until I started working with TypeScript React in my current job, which Emacs has very bad support for.

The funny thing is: I don't even consider VSCode a superior text editor, it's just that Emacs is _so slow_. I used Emacs back then because compared to many other editors and IDE it allowed me to work faster, but VSCode despite all its shortcomings has done the very same thing Emacs did for me previously.

I still use Emacs every day at work just for Magit, but whenever Emacs freeze just for a few seconds every time I perform a big merge I just feel like finishing up the task in VSCode

I had a similar experience recently, where I had to spend some time working in TypeScript on a React front-end and my emacs really was falling over unfortunately. Tried tide, tried the LSP, but ultimately I found myself in VSCode in order to make the deadline. Turns out there is a pretty great magit layer in VSCode (https://github.com/kahole/edamagit), and as a former long term vim user that had been using spacemacs, a great spacemacs-like bundle for VSCode (https://github.com/VSpaceCode/VSpaceCode).

It’s the first time I’ve actually felt like I could drop emacs if I wanted to, I actually was enjoying the setup.

> Emacs is _so slow_

That’s exactly what it felt like in 1991: “eight megabytes and constantly swapping!”

Do you use Emacs in windows?

I've used it on Windows before and I think I know what you're talking about. However, right now I'm using it on macOS actually, the mac-port to be more specific.

I can see that for most people. It is really something, though, to watch someone really good with Emacs or Vim fly though something like a complex refactoring.

You can refactor with IDEs too, and I don't remember emacs being better at this than JetBrains is.

I've seen a few text editor pros who just weren't aware of what modern ides are capable of, particularly with strongly typed languages. They thought grep, regex and keyboard shortcuts were impressive.

There is something that I think most programmers have, which is that seeing someone type an arcane-looking combination of characters, press enter, and suddenly a variable has been renamed in every file in the directory is more impressive then clicking on UI elements to get to find and replace, then clicking the "execute" button.

They both do the same thing, probably take the same amount of type to actually complete, but our brains are wired to see the keyboard-only method as some sort of cyberpunk magic.

Or maybe that's just me!

imo this is exactly it.

It reminds me of pre-iPhone Japanese mobile phone culture where the more complicated interfaces were prized because users had to master them like a game or a puzzle.

Sure, I assume you can, but since Emacs/Vim is a sort of environment that encourages terse keybindings, fast call outs to the shell, etc, that's where I've seen more people that can seem to do stuff almost subconsciously.

Only available resources, modern IDEs are like hardware vendors wet dream came true.

Eight MegAbytes of Continuous Swap.

Compared to many I am a relatively new emacs user, back when I began programming I let myself get intimidated by the scary stories told about Emacs and Vim configuration. Turns out a huge emacs configuration is not needed, in fact I notice my emacs config actually started to become smaller over the recent times. It's hard to express how much I value emacs now and the only regret I have is that I did not give it a chance earlier when I still exclusively used "modern" editors and IDEs.

Another aspect I see rarely mentioned is the emacs evil[1], it basicelly provides a full vi layer, it's much more than your average "vi keybindings" plugin. Emacs vs Vim? Not a question I have to give any thought when I can use both and switch between them without much effort.

[1]: https://github.com/emacs-evil/evil

Evil is rarely mentioned? I guess we hang out in different parts of the internet.

Compared to the uncountable amount of "Emacs vs. Vim" discussions? Yes, absolutely. And when someone talks about getting a vim workflow in emacs they likely only mention a big framework like Spacemacs...

Oh, maybe my brain counts every mention of Spacemacs or Doom as an implicit mention of Evil.

I'm a little suprised they didn't mention DOOM or Spacemacs.

Yeah, mine is like 500 lines with use-package and lsp-mode. And it works on Mac osx, windows, and Linux, works with Java, scala, typescript/Javascript, python, yaml,c#, xml, html, haskell, ruby, c, and c++. Haven't done any Android or ios work, but I'm sure it would work with that as well.

> When you finally learn to master and config Emacs, you run circles around all other editors.

I quit Emacs when I realized that I spent too much time on configuration rather than solving first hand problems; it can almost become an obsession. Now I use Pluma.

pluma is nice, I used it for a really long time but in the end having a linter integrated into my editor sold me on VSCode

I do still use pluma for just quickly editing files though, but for coding I use vscode now

What's Pluma?

Love the screenshot.

You can do all that and more in vscode as well... you just have to "learn to master and config" it with your own plugins in JS. It's not that hard.

I tend to let other people "master and config" VSCode and then I just go download their extensions. IMO that's the beauty of VSCode - critical mass

That's also available with emacs, though, it has its own extension ecosystem that's about as easy to access as VSCode's.

I don't think its as easy imo. vscode auto recommends extensions if you open a new file type and from what I remember (been a number of years since I installed a package in emacs), the extension "browser"/"market" was not as user friendly (in terms of raw info about the extension and in discoverability).

Yeah no, emacs package system is a giant mess, it's only "easy" if you've already drunk the emacs kool aid.

Sorry I just really hate emacs.

VSCode isn't as flexible at all though. You can't even create a keybinding that executes multiple commands (macro). There aren't hooks. You can't just write a function in a file and execute it. There isn't the same level of introspection.

In a lot of ways, VSCode is more convenient, but its extensibility doesn't come close to matching Emacs'.

I use VSCode for my day to day coding, so I have nothing against it, but explain to me how I can 'do' Magit and the like in VSCode...?

I’m not familiar with magit but from a quick skim of the “visual walkthrough” I think you can get most if not all of the functionality either built in to vscode or with the free “git lens” plugin, one of the most popular in the extension directory.

Here’s what’s built in: https://code.visualstudio.com/docs/editor/versioncontrol

and git lens: https://marketplace.visualstudio.com/items?itemName=eamodio....

I use Edamagit but I still find myself popping open emacs+magit sometimes. I guess I haven't completed the assimilation into VSCode yet.

Literally anything you can do in emcas there is an extension for or at least one in dev. Vscode will outgrow emcas given its critics mass and momentum.

Has NetCraft confirmed that Emacs is dying yet?

I keep reading on Hackernews and elsewhere that VSCode will solve world hunger. So I try it. And after a week or two, I realize what I'm missing from Emacs and go back. This has happened several times, because I keep thinking, maybe I didn't give VSCode the fair shake it deserves. But VSCode never lives up to the hype, is not compellingly better than Emacs such that I want to switch, and is in some ways worse. Emacs gives me a computing environment that I can shape and mold to my needs quickly and directly, as I use it. VSCode is extensible; for Emacs, extending it is an integral part of working with it.

What's more, VSCode is not even open source. It's more like "open core". The editor core is under an MIT license, but the binary you download from code.visualstudio.com is proprietary, as are many of the most useful plug-ins. Source ports like VSCodium are not first-class in the extension ecosystem.

Emacs, by contrast, is the next thing beyond open source: it's software that describes itself. Whether that be the tutorial for new users, built-in documentation for every function or variable, or the ability to M-. into the implementation, whether in Lisp or C, of any function, the guts of Emacs are always at your fingertips. I get the feeling RMS intended "free software" to be a baseline, a bare minimum for protecting the user's freedom. To truly emancipate the user, something like Emacs where the software actively aids the user's understanding of its internals, is needed.

I'm not a heavy VSCode user, so I don't know much about its plugin ecosystem. I'm asking the question below sincerely, not to start an argument.

Is there a plugin in VSCode to:

1. Read, write and send emails?

2. Have an org mode like system where I can do TODOs, as well as link to things in other aspects of VSCode (e.g. link to an email - something I do routinely)?

2b In general, how easy is it to interconnect the different plugins? If I have a plugin to handle email, and another to do TODOs, can I quickly write something that will read an email, and then go and add a TODO in the appropriate section of some document based on the contents of that email?

3. Use it as a window manager

4. Use it as a file manager

You've selected some use cases designed to show that VSCode is inferior to emacs. What you failed to realize is that your use cases are invalid for probably a vast majority of people:

> Read, write and send emails

I prefer to do that in a dedicated app that actually knows how to deal with emails, and not from inside my text editor/IDE

> can I quickly write something that will read an email, and then go and add a TODO in the appropriate section of some document based on the contents of that email

I tend to prefer not to spend my time programming things, but, you know, enjoy life.

If I need a todo from an email, I'll copy paste it to an app that, for example, syncs to my phone

> Use it as a window manager

Why?

> Use it as a file manager

Why?

The previous user said that you can do "literally anything" in VSCode that you can do in Emacs, I think these examples were chosen to prove that statement wrong. It doesn't mean that Emacs is better for everyone.

I would also think that no one even cares to write an email client or a window manager inside an IDE even if that is possible (it probably is).

> > Use it as a window manager

> Why?

Because I need a window manager.

> > Use it as a file manager

> Why?

Because I need a file manager? I can give you an example of a time where I needed to examine some files, and depending on what I saw, with a keystroke make notes in a text file with links to those files, but that's secondary to the topic. The simpler answer is that I need things like file managers and window managers, and Emacs is both. Viewing Emacs as a text editor is a misconception you seem to have.

My question was whether there are plugins for VSCode to do any of these. You did not address that at all. Your comment is noise in this thread.

The question is will it grow in the right direction? Org-mode, magit and a pure terminal interface (can run on remotes through an SSH sesion) are still missing. Still love the ergonomics of vs code.

VS Code runs on remote hosts through SSH, containers, or WSL: https://code.visualstudio.com/docs/remote/remote-overview

Kinda like a parallel universe swank/slime.

Yes... and has the same limitations of roundtripping files in any other IDE.

For display and editing purposes, yes. However, from what I understand, the LSP, linters, and auxiliary tools all run on remote.

The right direction according to who?

For 99% of users, org-mode, magit and a pure terminal interface are not hard requirements.

And I’m saying this as an emacs and org-mode user that does everything in the terminal.

> The right direction according to who?

You are asking the right question, but it applies to your comment equally well.

> For 99% of users, org-mode, magit and a pure terminal interface are not hard requirements.

You are narrowly picking the set of users to suit your comment. For 99% of users, code completion, syntax highlighting, etc are not requirements either, because 99% of users do not program.

In retrospect, it should be obvious that Emacs users are heavily weighted towards using org mode, because that's part of Emacs's value proposition. It makes sense that most VSCode users do not need/want org mode, because otherwise they'd be using Emacs, and not VSCode.

In almost every thread about Emacs, I always find the comparisons with VSCode amusing, given that the two programs serve very different purposes. The bulk of my Emacs usage has nothing to do with coding, so I personally don't see the value of comparing it with VSCode, and pointing out that VSCode is better is sort of irrelevant. Of course, this being HN, there is a programming bias. But it's the equivalent of saying "mplayer sucks because it cannot do video editing as good as some video editing tool."[1] It's great that you have found a good video editing tool, but that tool doesn't do much of what I use mplayer for.

[1] mplayer has extremely rudimentary video editing capabilities,

Genuine question: is there one for regional undo? That is, can you select an arbitrary region of a file and step back through modifications that have been made to that section of the file only?

This is just one "killer feature" of Emacs for me that I have yet to come across in other editors/IDEs (maybe I just haven't looked hard enough!)

“Critics mass” of whom? VS Code is very disappointing, given the hype. Can you give an example of something in the VS Code ecosystem that can impress an Emacs user enough to switch, beyond chrome?

Chrome will always attract crowds, of course.

Have you found that other extension authors have this in mind? Most extensions don't seem to be built with hooks in mind so you're kinda stuck with either the existing extension or rolling your own. There also aren't very good primitives for most use cases because of this. I assume VSCode will get there though.

VSCode extensions are driven through "commands" that are exposed through the package.json of the plugin (which can be parsed by other plugins if you wanted) and issuable through another plugin, or using a task (this is kind of annoying though and not a first class use of tasks).

>When you finally learn to master and config Emacs,

Should be "if" and not "when", in my opinion.

It's so incredibly frustrating to watch emacs from the outside. Maybe they don't want emacs to become popular? Certainly given the state of Hurd that could be true, and perhaps merely the fact that a Free editor exists is enough for them.

For me, I really like emacs. It's great. But it has flaws/warts/roadblocks that routinely turn away new users and the grognards that seem to form the most influential portions of the emacs community seem to care more about freedom than about making an editor that's welcoming to new users and that people actually want to use.

[Never mind]

Whether intentionally or not you seem to have directly reinforced the argument I was making.

>Why from the outside? You're, quite literally, one command away from being on the inside: "M-x ielm"

I have no idea what point you're trying to make here. By opening with what I'm sure is an oh-so-witty commit like this you signal that you aren't going to engage honestly in this debate.

>Emacs is very popular amongst emacs-users

It's like you didn't even read what I wrote, and instead you've constructed a straw man to argue with. I think it's pretty obvious I was using "more popular" to refer to "attracting new emacs users".

>GNU nano, GNU ed, GNU moe, GNU emacs

Again, not sure what the point of just listing a bunch of editors is. Your entire comment is pretty much one giant non-sequitur.

>Obviously the emacs community is going to care about software freedom. I don't understand how anyone would expect differently.

Again, it's like you didn't want to respond to what I actually wrote. You seem to be responding to what you wish I wrote.

I never implied that I expect the Emacs project not to care about freedom at all, merely that I think it's silly to prioritize freedom at the expense of everything else. Is Free Software of any utility if nobody uses it? Or is it merely intellectual masturbation?

The default emacs experience is clunky, ugly, and dated. It turns people away. This is an objective truth.

I categorically reject the idea that polished software is mutually exclusive of free software. I think emacs would do a better job of promoting the use of free software if emacs had a better onboarding experience and was more user-friendly, and I think it can achieve this goal without betraying the principles of Freedom on which it was founded. And yet at any suggestion of this, RMS and the other grognards are content to ridicule and belittle (just as you have done here) rather than engage honestly in the arguments being presented.

>The very least one can do when addressing perceived flaws/warts/roadblocks, is to accompany them with a snippet of code, so users/developers can actually experience these suggested improvements.

Are you seriously suggesting I should post a patch to HN? It's comments like this that leave the very distinct impression you're just trying to shield yourself from any criticism rather than have to confront viewpoints that challenge the status quo of the emacs project.

> >Why from the outside? You're, quite literally, one command away from being on the inside: "M-x ielm"

> I have no idea what point you're trying to make here. By opening with what I'm sure is an oh-so-witty commit like this you signal that you aren't going to engage honestly in this debate.

I don't think that he was trying to make a 'witty' or snarky comment, just pointing out that anyone who wants to can be 'inside' Emacs development simply by firing up Emacs and running ielm (the interactive Emacs Lisp mode). It's an Emacs REPL: one has exactly as much power in it as anyone on the dev team. If you want to, you can even recompile the C bits …

> I categorically reject the idea that polished software is mutually exclusive of free software.

FWIW, I agree. I think that the default Emacs look could be a lot better.

>one has exactly as much power in it as anyone on the dev team

Technically, perhaps, but not politically. In that respect everyone who is not a core maintainer is an outsider. The latter is more relevant when trying to get the project to change. Sure, I can make my own emacs look nice but that doesn't change the default.

I’m kinda in love with VSCode at the moment, even though I have used Emacs (or at least some mac customized version, maybe SpaceEmacs?) for agda-mode

When I tried to go outside of the agda-mode documentation, to try to learn emacs properly, I kinda struggled to find a reliable tutorial or introduction that got me started on how emacs and the culture/ecosystem works. (Maybe it was just me who got tripped up by my unfamiliarity with it.)

Do you have a good recommendation for a way or a book to get into emacs?

It does seem nice to run your editors in terminals, instead of the other way around.. haha

I do admit VSCode is a very polished product. Just like the other tools I mentioned (PyCharm, Kaleidoscope for diffs, Tower App as git client etc).

What makes Emacs different - when you look beyond the simple looking interface - is the possibility to make the packages / plugins work together not intended by the original authors by creating hooks that change the return value of the packages, and you can tie together the tools by writing Elisp scripts.

As to where to start: There are many young and ambitious hackers who are re-developing Emacs + Lisp for creating their custom dev / hacking / writing environment, and who create wonderful youtube videos. Magnar Sveen started doing this several years ago (emacsrock.com), then there are (among others) Protesilas Stavrou or the channel of "System Crafters".

When you prefer reading books: "An Introduction To Programming In Emacs Lisp" from Robert Chassell is excellent for learning the basics of Elisp. Mickey Petersens "Mastering Emacs" is excellent. Harley Hahn's Emacs Field Guide is recommended as well.

Also, r/emacs and r/orgmode are excellent communities.

Give yourself time. Don't hurry. Emacs is a tool that will keep your company in twenty years from now, when all the hyped tools are long gone (Textmate users moved to Sublime, then some of them to VS Code, who know's what's next?).

>Magnar Sveen started doing this several years ago (emacsrock.com)

Great comment! But you were missing an s in this FQDN. Here's a working link: http://emacsrocks.com/

Textmate users moved to sublime because they felt it was better, so did sublime users to vscode.

They could get a better experience with very minimal time of training or mastery, because the next tool they used was user friendly and better for them.

What’s wrong with that ? If new tools that are better and easy to use keep coming then that is something to celebrate.

Emacs has great interactive tutorials built in: C-h t and has a great info system and help functions: C-h h also: https://www.gnu.org/software/emacs/tour/ There is really a lot of excellent documentation built in and the source code is very easy to find and read.

I've had a similar experience to yours. Even when I'm curious and motivated to learn, I find it hard to learn more and improve. There seems to be a lot of assumed knowledge from most tutorials and articles about where to place code snippets, configure things, what ui elements are called, etc. One thing I'd recommend is joining the spacemacs discord/slack and just asking for help on the questions you get stuck on.

To me, it depends on the language. An IDE helps a lot with verbose languages that have somewhat complicated environments or runtimes. Like Java. I can fly with VIM and Perl though.

Yeah, this is very language dependent. Trying Emacs with Java is pure pain, even if you love Emacs.

Like most open source things, the quality of support maps closely to the density of users who are trying to accomplish something similar. This is why Emacs has fantastic support for languages like JS and Ruby, and massively subpar support for Java and C#.

I’ve been using Emacs for Java dev for a year now using LSP and it’s been great.

My holiday project was to re-tool my development environment. I am going to try using both VS Code and Emacs on my current .Net 5 project. I installed the Emacs keybindings extension for VS Code. I upgraded from an ancient version of Emacs to version 27. I do really want to do development in both so as to decide what works best for me.

Emacs configuration is a labor of love as any Emacs user can attest to. I'm already at 50 hours and guestimate that I've got another 20 hours to go before it's where I'd like it to be. This has required multiple tech support discussions on Stack Overflow and Github and Reddit. I constantly ask myself if it's worth it, and only time will tell. But I've been using Emacs for 30 years and it's a tough habit to break. Still, I can easily justify the effort as I'll be using Emacs until my last keystroke. The open question is will I be using it for C#/.Net development.

I do wish to give VS Code a fair go. And certainly it makes sense to be proficient in that editor.

> I manage several projects with it and switch contexts with one key-combination: Vagrant box is started, project folder is changed, necessary files opened, ready to hack, build, deploy, do server restarts with a single key stroke.

When I single-click to open a project in a JetBrains IDE, the same sequence of events happens (albeit using Docker Compose instead of Vagrant).

I don't quite "get" magit, can someone tell what's great about it / for what type of git workflow?

This is what sold me on magit:

1. In the magit status buffer (equivalent of git status), you can selectively stage changes by highlighting the relevant lines and pressing "a". Basically an interactive git add -p. There's also line-specific unstage and discard. This makes it easy to tidy up before committing.

2. If the cursor is on a commit, commands (show, interactive rebase, push) will take that commit ID as a default argument. It feels like you're interacting with the commits directly, which makes it easier to reason through an interactive rebase or partial push. Simple rebases like reordering or squashing recent commits take only a few seconds.

3. It seems to mostly rely on calling the core git commands and parsing their text output. The core git commands are reliable. Many git clients will hang on large (> 200 GB) repos; magit doesn't. An exception is diff colorization, but if colorization is taking too long on a big diff, Ctrl-g will make magit fall back instantly to the plain diff.

4. Has decent submodule support, in that submodules can be interacted with much like commits in the parent repo.

5. Has git annex support. (Technically, I think this is provided by another package that extends magit.)

It's not really tailored to any particular git workflow as far as I can tell. The design intent seems to be that every displayed entity should be interactive, regardless of where it is displayed.

In VSCode, you can selectively stage lines in files too, just select them in the diff, right-click, "stage selected" - I love being able to do that so easily within such a nice UI.

The big appeal of magit, at least for me, is that I can quickly do it with the keyboard. Open magit, press “s” on each hunk to stage it and magit moves to the next hunk, then “c c” to write a commit message, C-c C-c to commit, then “q” and I’m right back in the code. If you need to edit a hunk you press enter on it and it drops you into the file.

This is much much faster than doing it with the mouse, and keeps me more in “the flow”. In general Emacs becomes powerful because it’s full of little tricks that add up to much tighter feedback loops which is so helpful when coding, to keep your attention on the problem you’re trying to solve. And it is trivial to add your own “little tricks” to tighten the feedback loop for whatever you’re doing.

VSCode has an extension for that too, edamagit[0] :)

One of the big appeals of VSCode for me is the huge community around it, and the range of plugins available.

[0] https://github.com/kahole/edamagit

I get that. For me VSCode is pretty clunky in terms of replacing what I like about Emacs. Writing a plugin is way more of an exercise than writing a couple lines of elisp to change something or add some new functionality, things are not self-documenting, it's not nearly as easy to open a REPL and start poking around programmatically at open files, etc. These are the things that I value with Emacs and that make me more productive.

Yeah, there's nothing wrong with VSCode as far as I know. When I started using Magit, VSCode didn't exist. If the text editor you use isn't a hindrance—regardless of what editor it is—I'm not sure it's ever worth switching. It seems like all of them can be made to do pretty much the same things these days, which is nice because colleagues can trade tricks without having to migrate (or help others migrate) between editors.

>Many git clients will hang on large (> 200 GB) repos; magit doesn't.

Maybe it's worse with other clients(haven't used any, so I wouldn't know) but for me magit does become completely unusable in some situations, like with lots of pending changes.

For vim users fugitive is a very good plugin that does at least some of these (I'm not using it to the full extent of its capacity so I cannot be sure).

It's much quicker to do simple git things, the logs are integrated, it's super easy to stage hunks into separate commits, and it seems to make everything possible with git a little easier and more consistent (you do still need to know git though).

in theory I agree with this, the problem is just that Emacs very often shows its age. On large codebases the performance of completion frameworks is for me often abysmal, language server connections sometimes give in without discernible reason and I need to restart. A lot of things that should be done asynchronously aren't and so the UI locks up.

As a long term Emacs user I find myself going for VSCode a lot these days just because of how smooth it is and how well done the integration of major plugins is.

I wonder what other editors allow to dynamically extend/adapt much about anything.

I remember trying turbo pascal 7.0 on dosbox. I was shocked by how brilliant that tiny program was for its era. So light, so packed with features, so fast. Yet at the first editing ergonomic need I had, I was stuck.. my brain couldn't stop thinking .. 'this would already have been fixed in emacs'.

> When you finally learn to master

s/When/If

Customization is a liability. It it practical to be able to work with any hammer, not just your own. Also practical that you can lend your hammer out when the need arises, without instructing the other on the particulars of your version.

Computers are cattle, software too.

I can use almost any editor, ed(1) included, fairly efficiently without any config (well not exactly efficiently with ed).

I also have a 7kLoC init.el, and a couple little packages I've written.

Just because you wouldn't starve eating grain, olives and the occasional cheese shouldn't mean you can't eat a prime cut and have a nice glass of wine with it when you have the chance.

Do you mind sharing a bit more about your setup and workflows? Or a link to anywhere where you've discussed it before?

For many who don't have experience, lisps are intimidating

Reminds me Ryan Dahl's quip from way back when:

> I love Go so much (SO MUCH), but I cannot get past the fact that goroutines share memory or that it's statically typed. I love Erlang but I cannot get the past the syntax. I do not like the JVM because it takes too long to startup and has a bad history of XML files and IDE integration - which give me a bad vibe.

https://news.ycombinator.com/item?id=4310723