The values of Emacs, the Neovim revolution, and the VSCode gorilla(murilopereira.com)
murilopereira.com
The values of Emacs, the Neovim revolution, and the VSCode gorilla
https://www.murilopereira.com/the-values-of-emacs-the-neovim-revolution-and-the-vscode-gorilla/
352 comments
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 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?
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.")
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...
`(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).
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....
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.
- 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.
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.
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.
- 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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).
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 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.
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.
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.
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.)
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.
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
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
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)
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. ;)
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?
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.
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:
https://news.ycombinator.com/item?id=25311743
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
https://news.ycombinator.com/item?id=25311743
I do something like this in VSCode as well, Markdown todo lists:
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.
- [ ] Task 1
- [ ] Task 1.1
- [x] Task 1.1.1
- [ ] Task 1.2
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
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.
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!”
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!
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.
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.
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
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.
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
I do still use pluma for just quickly editing files though, but for coding I use vscode now
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.
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'.
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....
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 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
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?
> 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.
> 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.
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.
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,
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!)
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.
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.
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.
>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.
> 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.
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
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?).
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/
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.
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#.
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.
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).
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.
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.
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
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.
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.
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'.
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
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.
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.
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
> 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
> It also shines in areas where Emacs doesn’t: if you’re a programmer working on typical contemporary projects, mostly just wanting to get stuff done, things usually… just work. You install VSCode, open a source code file, get asked to install the extension for that particular language, and that’s it. You get smart completion, static analysis, linting, advanced debugging, refactoring tools, deep integration with git, and on top of that, great performance and a cohesive user experience.
These days I mostly use VSCode due to great language server integration (Pylance, gopls, rust-analyzer, etc.), but I still rely on Emacs with Magit for almost all my git interactions. This is not helped by VSCode's shitty commit message box, which after five years is still this ~250x20px by default input field with some after-the-fact validation tossed in. The great thing about Emacs is that everything is a buffer, you get the full editing power afforded by a buffer, not some second-class input field, especially for something as important as commit messages.
These days I mostly use VSCode due to great language server integration (Pylance, gopls, rust-analyzer, etc.), but I still rely on Emacs with Magit for almost all my git interactions. This is not helped by VSCode's shitty commit message box, which after five years is still this ~250x20px by default input field with some after-the-fact validation tossed in. The great thing about Emacs is that everything is a buffer, you get the full editing power afforded by a buffer, not some second-class input field, especially for something as important as commit messages.
>The great thing about Emacs is that everything is a buffer[...]
It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours.
Every time I get a shitty modal with some text I can't copy paste, every time I have a crappy edit box lacking basic editing capabilities, every time I get some large text dump I can't search through with normal editing commands, every single time that happens I pray to the altar of RMS for him to smite the heathens and bring us to the age of enlightenment.
It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours.
Every time I get a shitty modal with some text I can't copy paste, every time I have a crappy edit box lacking basic editing capabilities, every time I get some large text dump I can't search through with normal editing commands, every single time that happens I pray to the altar of RMS for him to smite the heathens and bring us to the age of enlightenment.
>>The great thing about Emacs is that everything is a buffer[...]
> It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours.
Perhaps I don't understand emacs well enough, but I know that every file loaded in vim can be accessed via its buffer number. How it's displayed depends on the window and tab layout. Quickfix, help, and terminal buffers behave differently, but the vast majority of buffers are just associated with open files.
> It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours.
Perhaps I don't understand emacs well enough, but I know that every file loaded in vim can be accessed via its buffer number. How it's displayed depends on the window and tab layout. Quickfix, help, and terminal buffers behave differently, but the vast majority of buffers are just associated with open files.
Emacs buffers don't need to be associated with open files.
Basically menus, project trees, terminal tabs, etc. Are all just text buffers. So you can navigate them like they were a file opened in a regular text buffer.
Basically menus, project trees, terminal tabs, etc. Are all just text buffers. So you can navigate them like they were a file opened in a regular text buffer.
The netrw plugin that comes with the default installation of vim on many distros allows you to navigate the directory listing like a file, but it won't let you edit the text. The terminal buffer is similar, but you have to enter a special normal mode (ctrl-w N) in order to navigate the scrollback like a conventional buffer, but you can't change the contents of the buffer.
Yeah quickfix pane is a big annoyance of mine, but you also have things like :message that dumps a bunch of text to stdout that you can't meaningfully use directly. Compare that to Emacs' permanent Messages buffer that is just like any other buffer.
Vim is not the worst offender by any mean, but it's definitely a lot less uniform than Emacs.
Vim is not the worst offender by any mean, but it's definitely a lot less uniform than Emacs.
You can redirect stuff to a register with the following dance:
:redir "a :messages :redir END
Then, you can just paste from that register using "ap.
:redir "a :messages :redir END
Then, you can just paste from that register using "ap.
I've been using vim for decades, but was not aware of the messages command. If it's anything like the version command or the K key for displaying the man page for a keyword under the cursor, that's also an annoyance of mine. It's also why I will redirect man page output to a standard buffer by running :r !man whatever in a new split window.
I'm a long time Emacs user and just recently I have been learning and using neovim a lot. This is the most jarring difference between Emacs and other editors. The second biggest issue is Lua instead of Emacs Lisp. s-expressions work so well in the editor extension context. Steve Yegge wrote a really nice million word essay on this topic.
Have you looked into fennel? Is it possible to use that within neovim?
Same here in regards to Magit. I've tried seriously using Emacs (Spacemacs) for a year or two, but something always doesn't work as intended, code completion and static analysis is extremely hard to configure, especially you have some non-standard project setups. Then switched to a mix of vim for simple stuff or clion/pycharm in vim mode for rust/cpp/python... BUT, subjectively, Magit is the best git client ever created; Magit in evil-mode easily beats all of the 20+ git clients I've used. So I keep emacs/spacemacs on every machine now solely to be able to use magit.
Try Doom Emacs (https://github.com/hlissner/doom-emacs) instead of Spacemacs. It's much lighter weight and doesn't replace the configuration system to nearly the extent Spacemacs does.
Doom is not really better than spacemacs. It's just the same pain in a different flavor. Sure, in the micro-cosm of emacs it's pretty good, but in the macro-cosm it's still a pain and can't lift the limitations and problems of emacs.
sincerely curious, what are the limitations and problems of emacs? I use both vs code and emacs. I've been using vs code a bit more these days because I feel like the UI itself is a bit more powerful and modern. I've also come to like that If i want a language support it often installs all the things I'd want to make a good experience, and I have less to mix and match. I like the mix and match approach I've always used in emacs, but it turns out there fewer scenario where I want that power then I'd have thought, and more where I just want some out of the box functionality from an extension author
Why do you need to use a git "client"? What's wrong with just using the standard CLI? I use VS code and never bother with its git ui. Just open a terminal and use git commands.
Git CLI is fantástico if you want to do two things per hour. If you want to do twenty, it's just too many keystrokes. Even if we only talk basic add/commit/push.
Two especially laborious operations are `git add -p` and `git rebase -i`. Try them out on magit, you'll see the difference.
Two especially laborious operations are `git add -p` and `git rebase -i`. Try them out on magit, you'll see the difference.
git gui is way to go.
How do you selectively stage several hunks from command line in git? - Imagine you edited a large file, fixed two different things, now you‘d like to select the changes related to one thing first and commit them. And then the next changes.
In Magit you visit the file you changed, hit `C-x g' and see all diffs. Now you can review and select hunks by hitting „s“ (stage), go to the next relevant hunk and hit „s“ again to mark for staging. And when you‘re done selecting all changes that are relevant for one ticket, you hit „c“ twice to write a commit message. And off to the modifications/ hunks regarding second ticket.
So how‘d you do this in command line?
In Magit you visit the file you changed, hit `C-x g' and see all diffs. Now you can review and select hunks by hitting „s“ (stage), go to the next relevant hunk and hit „s“ again to mark for staging. And when you‘re done selecting all changes that are relevant for one ticket, you hit „c“ twice to write a commit message. And off to the modifications/ hunks regarding second ticket.
So how‘d you do this in command line?
This may have been semirecently been added to git, but look into [0]:
git add -i
It launches a fairly simple interactive text UI that allows you to select files to stage, and it allows one to "patch" into the staging area, which works by showing you a bunch of hunks, asking for each if you want to stage it (or you can even edit a hunk in your $EDITOR).
I'm sure it's not nearly as nice as Magit's UI, but I've been a happy user of this feature for a while.
[0]: https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging
I'm sure it's not nearly as nice as Magit's UI, but I've been a happy user of this feature for a while.
[0]: https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging
How about
$ git add -p path/to/the/file
?
Combine this with your favorite tool for command line auto-completion of paths (and, maybe, a git alias to avoid typing `git add -p` all the time) and it's extremely fast.
$ git add -p path/to/the/file
?
Combine this with your favorite tool for command line auto-completion of paths (and, maybe, a git alias to avoid typing `git add -p` all the time) and it's extremely fast.
I am presented with one hunk at a time, and have to decide if I want to stage or not (with a text "menu" underneath it: "(2/2) Stage this hunk [y,n,q,a,d,k,K,g,/,e,?]?"
And then I navigate with j/k (down/up).
Yes, it does the job. Matter of preference.
But if you worked eagerly on three / four different topics and try next to create several different commits by getting a visual overview of all hunks with the abilitiy to selectively stage is a little more comfortable.
And then I navigate with j/k (down/up).
Yes, it does the job. Matter of preference.
But if you worked eagerly on three / four different topics and try next to create several different commits by getting a visual overview of all hunks with the abilitiy to selectively stage is a little more comfortable.
If you have multiple files then you can choose to omit the file name and git will let you decide on each hunk for each file.
You can also hit "s" to split a hunk to only commit a part of a hunk of if you want fine grained control you can hit "e" to edit just that hunk in your $EDITOR to only select a specific line or whatever you want.
Personally I tried fugitive and other git clients in the past and always come back to git add -p on the command line. It just feels the most natural and it also forces you to look at the hunks, so there's really no chance you'll accidentally forget to add something.
When using GUIs with sidebars showing what files changed, etc. it's easy to forget to add something because you skim it without really paying attention to what was changed.
You can also hit "s" to split a hunk to only commit a part of a hunk of if you want fine grained control you can hit "e" to edit just that hunk in your $EDITOR to only select a specific line or whatever you want.
Personally I tried fugitive and other git clients in the past and always come back to git add -p on the command line. It just feels the most natural and it also forces you to look at the hunks, so there's really no chance you'll accidentally forget to add something.
When using GUIs with sidebars showing what files changed, etc. it's easy to forget to add something because you skim it without really paying attention to what was changed.
[deleted]
Try Magit. You’ll know whether it works for you. It clearly does for many people.
Or fugitive in Vim.
The difference is like that between using Ed and Vi. Seeing things as you do them is valuable.
Or fugitive in Vim.
The difference is like that between using Ed and Vi. Seeing things as you do them is valuable.
[deleted]
imo the strength of Magit (and its author has certainly said so) is that while the Git CLI provides a slightly different interface that you have to learn for each different operation, Magit provides a consistent UI for every single Git operation it supports (around 90% of Git features).
Nothing's wrong with using CLI. You might not need it, but sometimes it's nice to have something with more. Most people on this planet think that managing files from terminal is pure insanity, and I do just that, I didn't even bothered to install a graphical file manager. And yet I use a git client/front-end in my text editor, because it's nicer to do some things that way. The most useful feature is probably interactively staging hunks just like you'd edit a text file over what standard git does.
Completely agree that magit is superb. The fantastic integration with git forges to check out PR branches as worktrees has really been a game changer for me. I can see what PRs are open, create a worktree with fuzzy selection on PR branches, and then switch to that worktree to review changes in ediff.
I use Emacs inside VSCode's terminal just for Magit. And I've configured Emacs to open directly with the magit-status buffer. It beats all the VSCode extensions I have tested.
(when (string-match "code" default-directory)
(magit-status)
(delete-other-windows))
(with-eval-after-load 'magit
(define-key magit-status-mode-map (kbd "q") 'save-buffers-kill-terminal))I use this for git interactions in VSCode
https://github.com/kahole/edamagit
https://github.com/kahole/edamagit
On the discussion of values, I'd also like to submit "(expected) longevity" for consideration, which I think is distinct from "stability".
I made the switch from Vim to Neovim as soon as I felt confident that (1) the project was going to be around for a while, and (2) it was on track to "overtake" Vim (you may choose to disagree with me on this, I found built-in LSP to be a compelling selling point, but the specifics aren't really related to the point I'm trying to make). That it was almost completely a drop-in replacement, down to the init file, certainly didn't hurt.
Under the author's framework, Neovim apparently prefers "progressiveness" while Vim prefers "stability", and those two sound dimetrically at odds based on their descriptions; but both have large, active communities that aren't going anywhere. I'm not sure I can say the same about Kakoune, for example, which is a certainly a promising project but hasn't yet convinced me to jump the fence.
[edit for Emacs thoughts]: Now that I think about it, "text centrism" in my mind is also closely related to longevity. I don't care as much about the properties of plain text as I do about the fact that I'll be able to open/view/edit them _even if the application ecosystem dies_. I find Emacs attractive here with org-mode and, to a lesser extent, org-roam (the comparison here would be between e.g. SaaS productivity offerings like Notion).
I made the switch from Vim to Neovim as soon as I felt confident that (1) the project was going to be around for a while, and (2) it was on track to "overtake" Vim (you may choose to disagree with me on this, I found built-in LSP to be a compelling selling point, but the specifics aren't really related to the point I'm trying to make). That it was almost completely a drop-in replacement, down to the init file, certainly didn't hurt.
Under the author's framework, Neovim apparently prefers "progressiveness" while Vim prefers "stability", and those two sound dimetrically at odds based on their descriptions; but both have large, active communities that aren't going anywhere. I'm not sure I can say the same about Kakoune, for example, which is a certainly a promising project but hasn't yet convinced me to jump the fence.
[edit for Emacs thoughts]: Now that I think about it, "text centrism" in my mind is also closely related to longevity. I don't care as much about the properties of plain text as I do about the fact that I'll be able to open/view/edit them _even if the application ecosystem dies_. I find Emacs attractive here with org-mode and, to a lesser extent, org-roam (the comparison here would be between e.g. SaaS productivity offerings like Notion).
> I'm not sure I can say the same about Kakoune, for example, which is a certainly a promising project but hasn't yet convinced me to jump the fence.
I've made that jump a couple of months ago, and so far I love it. There isn't as large of an ecosystem, but Kakoune just feels better integrated with the environment. Is your hesitancy based on some particular feature, or the ecosystem, or something else? Or is there some default that you dislike?
I feel like it doesn't need to have as many maintainers in order to be successful, because its philosophy is much more spartan. The maintainers pretty aggressively keep the project's scope in check.
I've made that jump a couple of months ago, and so far I love it. There isn't as large of an ecosystem, but Kakoune just feels better integrated with the environment. Is your hesitancy based on some particular feature, or the ecosystem, or something else? Or is there some default that you dislike?
I feel like it doesn't need to have as many maintainers in order to be successful, because its philosophy is much more spartan. The maintainers pretty aggressively keep the project's scope in check.
I haven't tried Kakoune, so I'm not really qualified to speak about its merits or demerits. From a place of limited knowledge, I see nothing wrong with it, and want to reiterate that it seems really interesting and worth keeping an eye on.
To add some nuance to my earlier comment: I don't really worry about the existence of Kakoune (or $OPEN_SOURCE_SOFTWARE_PROJECT) in a trivial sense; we'll always be able to find a copy somewhere and compile it from source, modify it, etc. That being said, I think one of the advantages of a large/durable ecosystem is that it lets me worry less about problems I don't yet have. I use (neo)vim daily, but there are certainly still lots of ways I can improve my workflow. Inevitably I'll run into something that goes wrong or doesn't work like I want it to, and a larger and more active community makes it more likely that someone else has already figured out how to fix it.
The (relatively small) differences in keybindings are also worth a mention, but I think the vims have a bit of an unfair advantage here; IMO learning vim keybindings is almost unquestionably a good investment because you'll find them everywhere.
> Kakoune just feels better integrated with the environment
Out of curiosity, is this an argument for enjoyment or productivity? :) (Either is a fine answer! I frankly can't measure the latter so my personal usage of vim is probably motivated by the former.)
To add some nuance to my earlier comment: I don't really worry about the existence of Kakoune (or $OPEN_SOURCE_SOFTWARE_PROJECT) in a trivial sense; we'll always be able to find a copy somewhere and compile it from source, modify it, etc. That being said, I think one of the advantages of a large/durable ecosystem is that it lets me worry less about problems I don't yet have. I use (neo)vim daily, but there are certainly still lots of ways I can improve my workflow. Inevitably I'll run into something that goes wrong or doesn't work like I want it to, and a larger and more active community makes it more likely that someone else has already figured out how to fix it.
The (relatively small) differences in keybindings are also worth a mention, but I think the vims have a bit of an unfair advantage here; IMO learning vim keybindings is almost unquestionably a good investment because you'll find them everywhere.
> Kakoune just feels better integrated with the environment
Out of curiosity, is this an argument for enjoyment or productivity? :) (Either is a fine answer! I frankly can't measure the latter so my personal usage of vim is probably motivated by the former.)
> I think one of the advantages of a large/durable ecosystem is that it lets me worry less about problems I don't yet have.
That's true. If you're finding numerous workflow problems with neovim, it'll probably be true of Kakoune, as well.
> > Kakoune just feels better integrated with the environment > > Out of curiosity, is this an argument for enjoyment or productivity?
Both, though it's a more persuasive argument for productivity. Because it's easier to integrate with the environment, those workflow problems you mention can be solved by delegating to the environment, in some cases. For example, kakoune delegates to the environment for window management -- so things like resizing windows and switching between them is handled through tmux for me. Obviously, though, that's could be a poor substitution for some dedicated solutions in the editor. But overall, I prefer it, as it allows me to get familiar with unix utilities, which are useful in a wider range of applications. It also means there isn't an arcane scripting language associated with using the editor. I have a thing against vimscript.
> differences in keybindings are also worth a mention
I suppose. Having used vim for years, I was able to pick up the keybindings relatively quickly (< 1 day); they're almost identical. The main difference, that the selection comes before the action, also makes it easier to pick up.
But, yeah, that muscle memory is a loss. I find myself trying to do multiple selections and use kakoune keybindings in bash vi-mode, often.
That's true. If you're finding numerous workflow problems with neovim, it'll probably be true of Kakoune, as well.
> > Kakoune just feels better integrated with the environment > > Out of curiosity, is this an argument for enjoyment or productivity?
Both, though it's a more persuasive argument for productivity. Because it's easier to integrate with the environment, those workflow problems you mention can be solved by delegating to the environment, in some cases. For example, kakoune delegates to the environment for window management -- so things like resizing windows and switching between them is handled through tmux for me. Obviously, though, that's could be a poor substitution for some dedicated solutions in the editor. But overall, I prefer it, as it allows me to get familiar with unix utilities, which are useful in a wider range of applications. It also means there isn't an arcane scripting language associated with using the editor. I have a thing against vimscript.
> differences in keybindings are also worth a mention
I suppose. Having used vim for years, I was able to pick up the keybindings relatively quickly (< 1 day); they're almost identical. The main difference, that the selection comes before the action, also makes it easier to pick up.
But, yeah, that muscle memory is a loss. I find myself trying to do multiple selections and use kakoune keybindings in bash vi-mode, often.
Does neovim have a gvim equivalent nowadays?
The redraw speed for gvim on native ubuntu is awful, you can literally distinguish when top and bottom of the window is drawn, it doesn’t feel good. Sublime Text redraws almost instantly the entire window when you page through code.
The redraw speed for gvim on native ubuntu is awful, you can literally distinguish when top and bottom of the window is drawn, it doesn’t feel good. Sublime Text redraws almost instantly the entire window when you page through code.
This is really well written and researched but confuses me. Do most people not do this - make choices based on values (and constantly re-evaluate those choices in the face of new information)?
When I decide to use software, move to a new location, purchase cereal at the grocery store, buy music, and a variety of other daily activities, these are choices I make based on my values. Many times I end up picking something that I find slightly less convenient or usable because it aligns with my values better, and I'm unwilling to compromise my ethical stance for a little bit of convenience.
It seems unrealistic to me that people would choose otherwise, given enough information.
When I decide to use software, move to a new location, purchase cereal at the grocery store, buy music, and a variety of other daily activities, these are choices I make based on my values. Many times I end up picking something that I find slightly less convenient or usable because it aligns with my values better, and I'm unwilling to compromise my ethical stance for a little bit of convenience.
It seems unrealistic to me that people would choose otherwise, given enough information.
No, they don't. You're an exception. Most people choose based on practicality or price. Free = even better.
I find that one of the few places where people act based on their values is raising children. And even there, a lot of people skip raising their children completely.
For everything else: convenience, price, maybe risk.
I find that one of the few places where people act based on their values is raising children. And even there, a lot of people skip raising their children completely.
For everything else: convenience, price, maybe risk.
And tech people tend to be much more willing to spend time&effort "optimizing" their choices to fit their values than the average population. At least for "small to medium" choices - not sure about raising children.
Are we? I'm severely skeptical of this. Tech people tend to be financially secure so we can afford to pay more for stuff we care about, but I doubt we're significantly more opinionated and value-driven that the average population on average.
I don't follow? I wasn't implying that this is a good thing, or that it makes tech people special, and certainly not that it makes them superior.
Edit: here's an xkcd more relevant to what I meant: https://xkcd.com/309/
Edit: here's an xkcd more relevant to what I meant: https://xkcd.com/309/
Most people's moral values don't concern text editors, or software in general.
True. Though a lot of tech people value libre software to some extent, so morals can often come into play. Even for something as simple as a text editor.
Software developers aren’t most people
Contrary to the other replies to you I think that most people do "make choices based on values" but the crucial problem is "given enough information".
Remember that everyone of us is in an information bubble. We constantly filter out unimportant information based on our experiences.
If you are using Emacs and encounter a new problem you will first try to solve it with the tools you are used to (if you have a hammer, everything looks like a nail).
Finding new sources of information to change our filters is hard. Think back to the last time you came to a completely new technology and how lost you feel until you get a good grasp about it and how much of an uphill battle this can be.
The sunk cost fallacy runs deep there as well. Going back to something you know already well enough is often a tempting option.
Remember that everyone of us is in an information bubble. We constantly filter out unimportant information based on our experiences.
If you are using Emacs and encounter a new problem you will first try to solve it with the tools you are used to (if you have a hammer, everything looks like a nail).
Finding new sources of information to change our filters is hard. Think back to the last time you came to a completely new technology and how lost you feel until you get a good grasp about it and how much of an uphill battle this can be.
The sunk cost fallacy runs deep there as well. Going back to something you know already well enough is often a tempting option.
So I view a difference here between choosing a tool and designing a tool.
As a user/consumer, sure, you mostly decide pragmatically. Though values do come into play. For instance, if you value extensibility over approachability, you might be ok choosing a more complex tool even if it is more difficult to use at first.
But if you're building or designing a tool and you're making trade-offs, your values end up defining what you design and build.
As a user/consumer, sure, you mostly decide pragmatically. Though values do come into play. For instance, if you value extensibility over approachability, you might be ok choosing a more complex tool even if it is more difficult to use at first.
But if you're building or designing a tool and you're making trade-offs, your values end up defining what you design and build.
I don’t have any values that would affect the cereal I buy. I’m not even sure what values would come into play. I don’t buy cereal that isn’t magically delicious? I just buy whatever is cheapest. Is not having much money a value?
Other than Richard Stallman, I don’t think I’ve ever heard anyone talk about how their personal values determine what software they will use. If I can afford it (free is better!) and it does the job, I use it.
Other than Richard Stallman, I don’t think I’ve ever heard anyone talk about how their personal values determine what software they will use. If I can afford it (free is better!) and it does the job, I use it.
I can't say I choose based on values, but I can give you an example of what people may mean by choosing based on values.
Apparently a Nestlé representative recently declared that if a law that requires large corporations to disclose and to stop getting raw materials from suppliers which use forced labor (i.e. slavery) passes, coffee customers might be impacted, probably by higher coffee prices. It's at best a clumsy statement and at worst an endorsement of slavery (!), all for reducing coffee costs by probably a few percent.
A moral choice, based on values, would be to never buy coffee from Nestlé brands and instead buy from companies that guarantee that their suppliers don't use forced labor.
Apparently a Nestlé representative recently declared that if a law that requires large corporations to disclose and to stop getting raw materials from suppliers which use forced labor (i.e. slavery) passes, coffee customers might be impacted, probably by higher coffee prices. It's at best a clumsy statement and at worst an endorsement of slavery (!), all for reducing coffee costs by probably a few percent.
A moral choice, based on values, would be to never buy coffee from Nestlé brands and instead buy from companies that guarantee that their suppliers don't use forced labor.
Yes, lowest cost is a value. But there are probably 5 or 6 cereals at the lowest price point at your local grocery store. Which one do you pick, and why? Whatever the answer is, reveals your values. (Even "the one at eye level" reveals the value of minimum energy expenditure)
> If I can afford it (free is better!) and it does the job, I use it.
OK so one value is clear. But there are literally tens of software options that fit into those requirements. So why do you pick gdocs over libreoffice, or your workplace MS365 subscription?
Every choice you make is determined by your values, whether you're conscious of it or not. Very often, people think they hold one set of values (eg "i'm a vegetarian because I value animal life") but that is belied by their actions (eg wearing leather soled shoes). You can guess which one is a better indicator of their real values.
> If I can afford it (free is better!) and it does the job, I use it.
OK so one value is clear. But there are literally tens of software options that fit into those requirements. So why do you pick gdocs over libreoffice, or your workplace MS365 subscription?
Every choice you make is determined by your values, whether you're conscious of it or not. Very often, people think they hold one set of values (eg "i'm a vegetarian because I value animal life") but that is belied by their actions (eg wearing leather soled shoes). You can guess which one is a better indicator of their real values.
>Which one do you pick, and why?
Easy. Whichever one has the most chocolate. All the cheap ones have a lot of chocolate? Buy them all! You can never have enough chocolate flavored cereal.
Easy. Whichever one has the most chocolate. All the cheap ones have a lot of chocolate? Buy them all! You can never have enough chocolate flavored cereal.
Personally I do buy cereal partially based on values. I absolutely refuse to buy stuff from nestle.
> I don’t have any values that would affect the cereal I buy.
* Would you buy cereal made by slaves?
* Would you not prefer cereal made by a small cooperative of people you know, over something made by BigCorp inc. ?
etc.
* Would you buy cereal made by slaves?
* Would you not prefer cereal made by a small cooperative of people you know, over something made by BigCorp inc. ?
etc.
> Would you buy cereal made by slaves?
No, but I don't know which cereal is made by slaves and which isn't. Maybe none of them are.
> Would you not prefer cereal made by a small cooperative of people you know, over something made by BigCorp inc. ?
No. I have nothing against BigCorp.
No, but I don't know which cereal is made by slaves and which isn't. Maybe none of them are.
> Would you not prefer cereal made by a small cooperative of people you know, over something made by BigCorp inc. ?
No. I have nothing against BigCorp.
Most people are creatures of habit. Once they make a decision ("this is my brand of toothpaste") they tend to stick to that in spite of any new information.
This reminds me of a quote from Surely You're Joking, Mr. Feynmann!.
"When you're young, you have all these things to worry about - should you go there, what about your mother. And you worry, and try to decide, but then something else comes up. It's much easier to just plain decide. Never mind - nothing is going to change your mind. I did that once when I was a student at MIT. I got sick and tired of having to decide what kind of dessert I was going to have at the restaurant, so I decided it would always be chocolate ice cream, and never worried about it again - I had the solution to that problem."
"When you're young, you have all these things to worry about - should you go there, what about your mother. And you worry, and try to decide, but then something else comes up. It's much easier to just plain decide. Never mind - nothing is going to change your mind. I did that once when I was a student at MIT. I got sick and tired of having to decide what kind of dessert I was going to have at the restaurant, so I decided it would always be chocolate ice cream, and never worried about it again - I had the solution to that problem."
There's one exception to that which is that it's sometime more fortuitous to throw energy into developing something you already know further rather than throwing all existing knowledge away and starting again on a whim.
I'm not sure and I see your point, but also, you are maybe saying that, effectively, "convenience" or "usability" are values you (and most people) prioritize.
Which is not so different from when the OP article talks about emacs prioritizing "stability" really. "stability" isn't, like an ethical value or something really, it's a practical one, as are many of the others listed in OP.
Which is not so different from when the OP article talks about emacs prioritizing "stability" really. "stability" isn't, like an ethical value or something really, it's a practical one, as are many of the others listed in OP.
I don't think "convenience" is a value for the buyer of a consumer good any more than "going downhill" is a value for the designer of a roller coaster. It's just easier.
Sometimes people choose a path that is less convenient, they don't always choose the most convenient, right?
You may go to an ice-cream shop further away, because you like their ice cream better. You may choose to buy from an independent bookseller instead of amazon because you want to support them to stay in business. Or you might have to choose between a cheaper but less convenient option (say with two week delivery time), or a more convenient but more expensive option -- some people at some times will choose cheap, others at other times convenience.
Convenience/being "easier" doesn't always win against other values.
This shows that convenience or "easiness" is in fact just one of several values, weighted differently in different contexts.
Or are you talking about the fact that it might not be totally conscious and explicit? True, I think the way the OP is thinking about values, they are not always totally conscious and explicit.
Compare to other values in OP's list -- they aren't all "ethical" at all. Values in this context aren't about morality or ethics, just about what factors are valued. Say, "stability" or "velocity". A software development process doesn't necessarily consciously and explicitly acknowledge that they have chosen "velocity" over "approachability".
You may go to an ice-cream shop further away, because you like their ice cream better. You may choose to buy from an independent bookseller instead of amazon because you want to support them to stay in business. Or you might have to choose between a cheaper but less convenient option (say with two week delivery time), or a more convenient but more expensive option -- some people at some times will choose cheap, others at other times convenience.
Convenience/being "easier" doesn't always win against other values.
This shows that convenience or "easiness" is in fact just one of several values, weighted differently in different contexts.
Or are you talking about the fact that it might not be totally conscious and explicit? True, I think the way the OP is thinking about values, they are not always totally conscious and explicit.
Compare to other values in OP's list -- they aren't all "ethical" at all. Values in this context aren't about morality or ethics, just about what factors are valued. Say, "stability" or "velocity". A software development process doesn't necessarily consciously and explicitly acknowledge that they have chosen "velocity" over "approachability".
Yes. For example I don’t buy cereal because of my ethical stance of not wanting to feel bloated from a bowl of milk-and-starch.
Amazing how ethics (especially around software freedom) are shunned on "hacker" news.
https://en.wikipedia.org/wiki/Hacker_ethic
[edit: let's the downvote fest begin...]
https://en.wikipedia.org/wiki/Hacker_ethic
[edit: let's the downvote fest begin...]
"Maintainability - The degree to which it can be modified without introducing faults"
I can see why VS Code might get the Maintainability checkmark in the sense that it's hard to break from a user POV, but I wouldn't consider it "maintainable" in certain aspects as long as it isn't FOSS. Your IDE/editor is subject to the whims of Microsoft's release engineering team. If you do want to build from the open-source version and have the same experience, then you're going to have a bad time: https://www.reddit.com/r/linux/comments/k0s8qw/vs_code_devel...
I can see why VS Code might get the Maintainability checkmark in the sense that it's hard to break from a user POV, but I wouldn't consider it "maintainable" in certain aspects as long as it isn't FOSS. Your IDE/editor is subject to the whims of Microsoft's release engineering team. If you do want to build from the open-source version and have the same experience, then you're going to have a bad time: https://www.reddit.com/r/linux/comments/k0s8qw/vs_code_devel...
The source code version of vscode (ie, your own binary) is incompatible with one of the extensions microsoft developed (pylance?), which is AI powered python code completion.
Microsoft did not open source this extension. Therefore, the fact that it does not work with a non-microsoft build of vscode is not surprising - and in fact, should be perfectly acceptable. To claim that microsoft _should_ be releasing this proprietary extension as open source and free is to claim that a user is entitled to it, without paying the cost (presumably, that being the telemetry that the microsoft build of vscode collects).
Microsoft did not open source this extension. Therefore, the fact that it does not work with a non-microsoft build of vscode is not surprising - and in fact, should be perfectly acceptable. To claim that microsoft _should_ be releasing this proprietary extension as open source and free is to claim that a user is entitled to it, without paying the cost (presumably, that being the telemetry that the microsoft build of vscode collects).
I'm curious if the userbase of these have tried a Jetbrains IDE (PyCharm, CLion, IntelliJ etc). I've found the Jetbrains IDEs understand the language more thoroughly - this means better code navigation, error-catching, and refactoring. I've also found the implicit project-first focus (as opposed to file-first) to be more practical for most things I work on.
Pycharm is fantastic for code navigation. Jumping into a new codebase can be intimidating but I use Pycharm for the preview windows for function definitions, the option+f7 find all usages of a variable, and a few other features. IdeaVim is also the best vim emulator that I've tried in any IDE. But I'm also too deep into neovim to stop using every feature + plugin while writing and editing code, so I usually have Neovim running in the Pycharm terminal and jump back and forth between the Pycharm editor and terminal based on my context (writing or reading)
I'm slowly learning the Android IDE. Text editors have the following advantages
- One config for all: no need to specify keybindings for each program, and other settings
- Similarly, multipurpose tool: a text editor can help with most of the programming languages out there, IDEs are generally tailored towards a specific bunch of languages and tools, with little variation possible
- Non-programming tasks: I'm doing an MA in linguistics, and plan to be a researcher; while coding is useful it's only a part of what my text editor helps me with (emacs, in my case, but true even for VSCod{ium,e})
- Can VCS configs along with other dotfiles
- Free software
- Deep customisability helps automate away repetitive tasks add some nifty useful features
- Keyboard first: many IDEs have plugins for this and even embedding but it's never as good as the real deal
Personally I like to pick the best tool for the job and I wouldn't really bother with Emacs for Android or Java or C# etc., but when working with many other environments, customisable text editors are pretty advantageous.
And over that most if not all features you list are possible at least in Emacs (IDK how well they are done in the Vim world but I bet they have some great tools for all that, nvim esp.).
- One config for all: no need to specify keybindings for each program, and other settings
- Similarly, multipurpose tool: a text editor can help with most of the programming languages out there, IDEs are generally tailored towards a specific bunch of languages and tools, with little variation possible
- Non-programming tasks: I'm doing an MA in linguistics, and plan to be a researcher; while coding is useful it's only a part of what my text editor helps me with (emacs, in my case, but true even for VSCod{ium,e})
- Can VCS configs along with other dotfiles
- Free software
- Deep customisability helps automate away repetitive tasks add some nifty useful features
- Keyboard first: many IDEs have plugins for this and even embedding but it's never as good as the real deal
Personally I like to pick the best tool for the job and I wouldn't really bother with Emacs for Android or Java or C# etc., but when working with many other environments, customisable text editors are pretty advantageous.
And over that most if not all features you list are possible at least in Emacs (IDK how well they are done in the Vim world but I bet they have some great tools for all that, nvim esp.).
I still use IDEA Ultimate for Java but over the last few years I've fallen back to vim or vscode for basically everything else since the language servers for Python, Typescript, Go and Rust now provide most of the features that I actually use in Intellij.
Intellij's performance has never been good but it has continuously gotten worse over the years and it's bad enough now where I'll probably just cancel my subscription when it comes up for renewal.
Intellij's performance has never been good but it has continuously gotten worse over the years and it's bad enough now where I'll probably just cancel my subscription when it comes up for renewal.
A small gripe for me was startup time of JetBrain IDEs. Another small one is that they need /dev/null redirection because they spew weird errors to stdout/stderr.
A big one: on Windows, do they have a WSL1 or WSL2 integration now, i.e. cam they run/debug the compiled artifact under Linux? Use Linux-based compiler/toolchain?
A big one: on Windows, do they have a WSL1 or WSL2 integration now, i.e. cam they run/debug the compiled artifact under Linux? Use Linux-based compiler/toolchain?
The expected workflow is to launch it once — say, when you come to work — and have it running for the rest of the day. The startup time is completely neglible if you do that. And well, running GUI apps from a terminal is likely to flood that terminal with logs (which is why I launch them outside of terminals).
Apart from it's fantastic refactoring and everything else i really like the progressive selection.
The most significant value of Jetbrain IDEs is that all programming languages have good support. I switched between Java, Python, JS, Typescript, C, Golang, and so on regularly. For example, Java and Kotlin support are miles better than all other IDEs.
IntelliJ is pretty excellent. And one of the things I like most about it is that it has excellent Emacs-style keybindings
[deleted]
VSCode has great and convenient language support, but the trade-off is reduced text editing efficiency, slower speed and more bloat. It is a worthy trade-off in many situations, I use it often when working on projects that are written in languages I am not too familiar with.
I would like to emphasize how big of a game changer the next release of Neovim 0.5.0 will be. With builtin LSP support it will get code navigation, auto-completion and refactoring support on the level of VSCode out of the box, while being way more efficient and faster. I will likely still keep VSCode installed just in case, but only expect it to use it in rare occasions in the future.
Emacs is really powerful, but its age is showing and there are some serious technical deficiencies under the hood. I would challenge the idea from the post that the need for "Neoemacs" is not that great. From the history it appears to me more like that many people tried, but due to complexity of Emacs nobody has been able to successfully pull it off yet.
I would like to emphasize how big of a game changer the next release of Neovim 0.5.0 will be. With builtin LSP support it will get code navigation, auto-completion and refactoring support on the level of VSCode out of the box, while being way more efficient and faster. I will likely still keep VSCode installed just in case, but only expect it to use it in rare occasions in the future.
Emacs is really powerful, but its age is showing and there are some serious technical deficiencies under the hood. I would challenge the idea from the post that the need for "Neoemacs" is not that great. From the history it appears to me more like that many people tried, but due to complexity of Emacs nobody has been able to successfully pull it off yet.
I've used Neovim prior to trying vscode because it has a language server protocol client extension. Unfortunately, the extension didn't work too well (it had issues with `clangd`) at the time. So, just to compare I installed vscode and was amazed at how polished it was.
Still, I had it in my mind that I wanted to have and fast alternative to vscode so I kept trying to work with Neovim. That is 'till I noticed how much I dislike using vim. You see it has that learning curve that if you've stopped using it for awhile it's a struggle to do basic things. So I used a configuration that made it act more like normal editors. So problem solved? Unfortunately, most extensions are made for a normal vim settup not my easy mode settup. Plus, I started missing having simple things like scrollbars and tabs I could click on and move with the mouse. (I remember the graphical front end for Neovim not meeting these needs at the time.)
So ultimately, I just moved on and stayed with vscode. I would still like an alternative (kedit/k-develop looks promising). However, I'm sort of addicted to the plugins.
Still, I had it in my mind that I wanted to have and fast alternative to vscode so I kept trying to work with Neovim. That is 'till I noticed how much I dislike using vim. You see it has that learning curve that if you've stopped using it for awhile it's a struggle to do basic things. So I used a configuration that made it act more like normal editors. So problem solved? Unfortunately, most extensions are made for a normal vim settup not my easy mode settup. Plus, I started missing having simple things like scrollbars and tabs I could click on and move with the mouse. (I remember the graphical front end for Neovim not meeting these needs at the time.)
So ultimately, I just moved on and stayed with vscode. I would still like an alternative (kedit/k-develop looks promising). However, I'm sort of addicted to the plugins.
That’s amazing news. Native LSP would be game changing. I use coc, but it takes a bit of messing about to get everything working smoothly. Also vscode has has a bunch of extra stuff beyond what’s available via LSP for python now, which is a shame because I’d love to get a full pyright + bells experience in vim.
Coc has coc-pyright extension. You don't have to use pyls.
https://github.com/neoclide/coc.nvim/wiki/Using-coc-extensio...
https://github.com/fannheyward/coc-pyright
I use it, but MS have forked pyright with some features now locked just to vscode without support in the LSP.
https://devblogs.microsoft.com/python/announcing-pylance-fas...
https://devblogs.microsoft.com/python/announcing-pylance-fas...
I’ve had great luck using ALE lately. I don’t have much experience with coc but the ALE setup process is very straightforward.
hmm in terms of neomacs, is this what remacs was trying to do but in rust?
I don’t find VS Code to be a good text editor in the sense of a tool to wrangle text: the keyboard shortcuts are rather arbitrary and don’t seem to be logically organised, and it seems not to have learnt much from eg modern text editors like Sublime Text (even Sublime compatibility isn’t as good as the real thing).
That said, for writing code, it’s fine because most of the time I’m thinking and typing in short runs of text.
I’d love for it to receive a bit of love so it’s a better at wrangling text out-of-the-box, however.
That said, for writing code, it’s fine because most of the time I’m thinking and typing in short runs of text.
I’d love for it to receive a bit of love so it’s a better at wrangling text out-of-the-box, however.
I completely share your sentiment. VSCode is by far my favorite programming environment, its killer features as far as I'm concerned are its excellent debugging functionality and the remote mode (we often work on multiple remote machines simultaneously -- being able to have ad-hoc remote configs is a life-saver!)
The worst part is, ironically, the editor itself. As a former vim user I'd love to have vim keybindings, but the vim extensions are painfully slow and unresponsive. I ended up just using the default in spite of it being incredibly mediocre.
The worst part is, ironically, the editor itself. As a former vim user I'd love to have vim keybindings, but the vim extensions are painfully slow and unresponsive. I ended up just using the default in spite of it being incredibly mediocre.
Have you tried the vscode-neovim (https://github.com/asvetliakov/vscode-neovim) extension? It uses an instance of neovim to provide the vim behaviour rather than emulating it, and I’ve found it to be more responsive than VsCodeVim.
Shortcuts in VS Code are a setting. Just load which shortcut-setup you prefer. That's pretty normal with good dev-tools nowadays, because everyone has different preferences and habits.
> Shortcuts in VS Code are a setting. Just load which shortcut-setup you prefer.
There are quite a few shortcuts that cannot be implemented due to missing capabilities in VS Code. For example -- this list from an author of a VS Code plugin that emulates Sublime[1].
[1] https://github.com/Microsoft/vscode/issues/3776
There are quite a few shortcuts that cannot be implemented due to missing capabilities in VS Code. For example -- this list from an author of a VS Code plugin that emulates Sublime[1].
[1] https://github.com/Microsoft/vscode/issues/3776
Those are very special and seems most of them are fixed/possible already?
Only a few of them are done. The others are marked essentially closed wontfix ("To keep the number of issues in our inbox at a manageable level, we're closing issues that have been on the backlog for a long time")[1] or "write an extension for this"[2].
The bigger issue, which is lost in this forest of Github issues, is that VS Code needs a good hard look at its keyboard and text processing model.
[1] https://github.com/microsoft/vscode/issues/14028
[2] https://github.com/microsoft/vscode/issues/14093
The bigger issue, which is lost in this forest of Github issues, is that VS Code needs a good hard look at its keyboard and text processing model.
[1] https://github.com/microsoft/vscode/issues/14028
[2] https://github.com/microsoft/vscode/issues/14093
True, but those are still exotic edge-cases. In terms of shortcut-ability VS Code plays in the top on par with emacs, vim and KDE. You are complaining about the missing 0.1%, not something like >50% of lacking features.
Also, your original complain was that the shortcuts are "arbitrary and don’t seem to be logically organised". This can be fixed by loaading which ever organisation-scheme you prefer. So your actual complain is, it does not match your habits out-of-the-box?
Also, your original complain was that the shortcuts are "arbitrary and don’t seem to be logically organised". This can be fixed by loaading which ever organisation-scheme you prefer. So your actual complain is, it does not match your habits out-of-the-box?
I've tried all of them, and still prefer vim because it's the least hassle to install/configure anywhere - my dotfile setup installs my plugins automatically, and I'm set.
However, I do use VSCode extensively as well, largely because of the language servers. But sometimes it takes so long to start up (and nags me to do so many updates to itself and extensions) that I just toss the window aside and use a native Mac editor (like Textastic) to work while it finishes.
Sometimes I don't go back -- it's all a matter of taste, really.
However, I do use VSCode extensively as well, largely because of the language servers. But sometimes it takes so long to start up (and nags me to do so many updates to itself and extensions) that I just toss the window aside and use a native Mac editor (like Textastic) to work while it finishes.
Sometimes I don't go back -- it's all a matter of taste, really.
Emacs can also install your packages/plugins automagically via the wonderfully designed use-package combined with MELPA. It's a game changer when it comes to managing an emacs configuration, especially if you work across a range of servers. Just copy the .emacs, install use-package manually and you're off to the races with anything and everything you need.
By the time I discovered use-package I couldn't believe that I had been tar-balling a mess of crap around all these years.
By the time I discovered use-package I couldn't believe that I had been tar-balling a mess of crap around all these years.
I used emacs for a while while I was in college, for everything (including reading mail) and gave up because I just didn't find the command keys efficient enough.
This was really well-written.
One thing I'd recommend is to think more about "principles" than "values". The difference, in my mind, is that values are sort of ingrained into us as humans, and we can't change them. They include good beliefs but also a lot of personal baggage.
Principles, on the other hand, are things we _choose_ to act on. Ideally they are the same as our values, but when building/designing something, it's best to choose principles.
One thing I'd recommend is to think more about "principles" than "values". The difference, in my mind, is that values are sort of ingrained into us as humans, and we can't change them. They include good beliefs but also a lot of personal baggage.
Principles, on the other hand, are things we _choose_ to act on. Ideally they are the same as our values, but when building/designing something, it's best to choose principles.
Are powerful editors really that much of a force multiplier? My career path has pulled me from a CS degree into loosely related fields so I mostly only code as a hobby. I end up using basic editors (e.g., gedit) and reaching for grep/sed/etc when I need something fancy. Is having that power in the editor versus the command line that much of an advantage?
You can't achieve what a modern IDE can do using a simple editor and the command line.
Autocomplete, hinting, type checking, navigation, documentation display, automated refactoring, interactive debugging, and integration with other tools like test runners and databases, are some of the major features which yes, are indeed force multipliers.
This all becomes even more important when working on large codebases, and/or code you didn't write all yourself.
Autocomplete, hinting, type checking, navigation, documentation display, automated refactoring, interactive debugging, and integration with other tools like test runners and databases, are some of the major features which yes, are indeed force multipliers.
This all becomes even more important when working on large codebases, and/or code you didn't write all yourself.
My vim configuration, environment, and screen splitting using tmux giving me CLI tools in other windows together gives me every single feature you listed and more. My shell and environment being Turing complete not counting vimscript I imagine it would be hard to find anything a IDE could do that I can not.
For reference: https://gitlab.com/datenstrom/home
Edit: just saw your response to the sibling reply didn't realize you included (enhanced) Vim in IDEs as I haven't heard of it referred to as one before, quite the opposite usually.
For reference: https://gitlab.com/datenstrom/home
Edit: just saw your response to the sibling reply didn't realize you included (enhanced) Vim in IDEs as I haven't heard of it referred to as one before, quite the opposite usually.
It's not so much that I include Vim as an IDE, as that it's not a "basic editor" like gedit.
Although I will say that I've been using Vim a lot less since I started using VScode.
That looks like an awesome Vim environment though!
Although I will say that I've been using Vim a lot less since I started using VScode.
That looks like an awesome Vim environment though!
You can do all of those things in all four of the editors discussed.
The comment I replied to was asking about comparing those kinds of editor to "basic editors (e.g., gedit) and reaching for grep/sed/etc when I need something fancy." You certainly can't reasonably do most of those things with that toolset.
Yes. Switching context is expensive for humans and modern editors mean you do it less frequently and with fewer conventions to learn. A big one for general editors is that they work for everything: you can build, lint, debug, refactor, etc. using the same UI for every language which reduces the frictional cost significantly in fields like web development. Having code-aware auto completion, function signatures, and type validation is especially good here since you waste a fraction of the time realizing that you were omitting an argument by mistake or passing the wrong type – especially when that isn’t something which a quick compile check will tell you.
Refactoring is a good example: I’ve noticed that most programmers who don’t use advanced editors avoid fixing things which require analysis because it’s tedious to do right. That leads to accumulated technical debt over time with variables or methods having now-inaccurate names, etc. Nothing critical but a frictional cost which goes down when you have easy tools to perform language-aware refactoring (e.g. replacing a name in a function but not the same name used elsewhere in the same file).
Refactoring is a good example: I’ve noticed that most programmers who don’t use advanced editors avoid fixing things which require analysis because it’s tedious to do right. That leads to accumulated technical debt over time with variables or methods having now-inaccurate names, etc. Nothing critical but a frictional cost which goes down when you have easy tools to perform language-aware refactoring (e.g. replacing a name in a function but not the same name used elsewhere in the same file).
John Carmack admitted a while back that he's not much of a power user when it comes to text editors.
https://twitter.com/ID_AA_Carmack/status/1302651878065475584
https://twitter.com/ID_AA_Carmack/status/1302651878065475584
I don't believe so. I am an Emacs user and I wouldn't trade it for the world, but I know people that are increadible productive using just about anything.
When writing well-contained code where I can easily understand external dependencies I could just as well use notepad. Emacs shines when I want macros or multiple cursors, interactive development (I am a schemer) at just general code navigation. When doing things that are not scheme I could probably edit code just fine in just about any editor.
The only things I really miss in other editors (probably because I never looked) are the features for jumping around. I can jump to a definition (across files) in 1s which sets a "mark" from the place I left. Jumping back takes less than a second. I could of course do it, but it was more involved and I couldn't do it without having to think and let go of what was in my mind at the time.
Anyway, you grow into your editing style. A friend told me he would likely get seizures by developing like me.
When writing well-contained code where I can easily understand external dependencies I could just as well use notepad. Emacs shines when I want macros or multiple cursors, interactive development (I am a schemer) at just general code navigation. When doing things that are not scheme I could probably edit code just fine in just about any editor.
The only things I really miss in other editors (probably because I never looked) are the features for jumping around. I can jump to a definition (across files) in 1s which sets a "mark" from the place I left. Jumping back takes less than a second. I could of course do it, but it was more involved and I couldn't do it without having to think and let go of what was in my mind at the time.
Anyway, you grow into your editing style. A friend told me he would likely get seizures by developing like me.
As always: It depends.
Better be proficient in command line tools and a simple editor than not being proficient in an fancy editor.
But once you are used to the fancy editor it can be very efficient to be able to lookup a definition, do some refactorings, get an code outline view, auto completion, editing helps (text templates or the automatic } and indention) etc.
Better be proficient in command line tools and a simple editor than not being proficient in an fancy editor.
But once you are used to the fancy editor it can be very efficient to be able to lookup a definition, do some refactorings, get an code outline view, auto completion, editing helps (text templates or the automatic } and indention) etc.
I believe so, looking for definitions of functions you’re using and being able to jump to their implementation is great, starting a debugger, getting errors as you type... it all saves time.
Being able from the same interface to visualize your database and state of the program is also good !
Being able from the same interface to visualize your database and state of the program is also good !
On vim vs neovim: My deep vim usage hasn't really changed much since it stopped being my primary editor usage 5 years ago, so this isn't the world's most informed opinion, but I've not noticed a drastic difference between vim and neovim. The one difference I've noticed and literally the only reason I've moved to neovim is that it uses XDG dirs by default and thereby clutters my home directory less. Otherwise, the two seemed pretty interchangable.
Vim 8 and neovim don't have any major differences. Even as a decades-long Vim power user, I can use either. neovim deserves credit for stimulating Bram to accept changes, though. Most notably Vim 8's support for async plugins. I don't think Vim 8 ever would have happened without neovim.
Well after reading your comment, I thought maybe the big win for neovim might be reduced (code-size) complexity. So I checked the code sizes for latest versions of both vim and neovim (from github):
- vim is at 900k (717k without po files)
- neovim is at 677k (562k without po files)
Savings of only 25% of code size is unfortunate. It's even worse if we ignore the po data files (only 22%). I would like to see a fully-capable modern editor/IDE for under 100k of clean, readable code. Until then, the quest goes on.
- vim is at 900k (717k without po files)
- neovim is at 677k (562k without po files)
Savings of only 25% of code size is unfortunate. It's even worse if we ignore the po data files (only 22%). I would like to see a fully-capable modern editor/IDE for under 100k of clean, readable code. Until then, the quest goes on.
github.com/rxi/lite-editor
Thanks. Found the correct link: github.com/rxi/lite
- First, it's ~20k ... which I admire in itself, but I doubt it'll have all the functionality of an advanced editor/IDE system.
- Second, I don't know lua, don't have plans to learn lua. I'll take lua a teeny bit more seriously the day I don't have to decide if I need to shell out 22 pounds just to read the latest official documentation of a programming language I'm trying to learn [0]
[0] https://store.feistyduck.com/products/programming-in-lua-fou...
- First, it's ~20k ... which I admire in itself, but I doubt it'll have all the functionality of an advanced editor/IDE system.
- Second, I don't know lua, don't have plans to learn lua. I'll take lua a teeny bit more seriously the day I don't have to decide if I need to shell out 22 pounds just to read the latest official documentation of a programming language I'm trying to learn [0]
[0] https://store.feistyduck.com/products/programming-in-lua-fou...
I essentially treat them as the same thing and will switch back and forth as one gets a regression or the other fixes an old regression. My config works perfectly in both and frankly I can't tell the difference 99.999% of the time.
For some reason the real-estate on vscode like file browser etc is really small compared to any other tool, on vs code I always have to move scrolls to see anything, I think this is the main thing why I don't use it while I really want to.
I use Emacs, but I like the polish of VSCode too.
Emacs is a portable programming platform and once you learn it, it's so easy to program that it's trivial to create mini applications with a text/keyboard interface to get things done or quickly automate recurring tasks. (Those who can create VScode plugins and don't know emacs, have no idea how convoluted creating a vscode plugin is, and how trivial it is in emacs).
Even if I happen to do something via VSCode, I still use Emacs for Org, Magit, etc. and also as the above mentioned programming platform, because I found these mini apps with key/text interface help a lot with everyday tasks.
Emacs is a portable programming platform and once you learn it, it's so easy to program that it's trivial to create mini applications with a text/keyboard interface to get things done or quickly automate recurring tasks. (Those who can create VScode plugins and don't know emacs, have no idea how convoluted creating a vscode plugin is, and how trivial it is in emacs).
Even if I happen to do something via VSCode, I still use Emacs for Org, Magit, etc. and also as the above mentioned programming platform, because I found these mini apps with key/text interface help a lot with everyday tasks.
I run neovim within vscode with neovim plugin. Relatively easy and fast to get started, takes time to reconfigure lsp and clean up shortcuts conflicts, but that is about it
Is there a way to standardize your fixes for others, e.g. through a pull request to teh neovim plugin?
It isn’t much. I will take another look
I don’t see why everyone needs to have the same opinion and editor, I’m fine with everyone using the editor they like best. It’s a tiresome endless debate
In principle, I agree with you. But there is a practical issue: if everyone used the same editor core, then we could all share improvements to it. Kinda like how the explosion of creativity in the Web (for good or for ill — I am still unpersuaded the JavaScript and SPAs are a good thing) was enabled by the common platform of HTTP+HTML+CSS+JavaScript.
Instead, we have some people writing extensions in elisp for Emacs, some in Vimscript for vim, some in JavaScript for VSCode, some brilliant madmen in rc for acme, some poor saps in Java for Eclipse.
In the end, I wonder if this is not more of a theoretical waste, though. Just like a command economy theoretically has less waste than a free market, but in practice every real-world free market has orders of magnitude less waste than any command economy, I wonder if in practice the profusion of editors has helped keep us from being locked into a local maximum (and argument which can be made against HTTP+HTML+CSS+JavaScript, BTW …).
It’s tough to say, it really is. For my part, I wish more folks would give Emacs a fair try, and I also wish that Emacs were a little easier to give a fair try. It is by far the single best editor/IDE/platform/OS out there.
Instead, we have some people writing extensions in elisp for Emacs, some in Vimscript for vim, some in JavaScript for VSCode, some brilliant madmen in rc for acme, some poor saps in Java for Eclipse.
In the end, I wonder if this is not more of a theoretical waste, though. Just like a command economy theoretically has less waste than a free market, but in practice every real-world free market has orders of magnitude less waste than any command economy, I wonder if in practice the profusion of editors has helped keep us from being locked into a local maximum (and argument which can be made against HTTP+HTML+CSS+JavaScript, BTW …).
It’s tough to say, it really is. For my part, I wish more folks would give Emacs a fair try, and I also wish that Emacs were a little easier to give a fair try. It is by far the single best editor/IDE/platform/OS out there.
My daily driver is VSCode with Vim editing and Emacs Spacemacs keybindings. I use a VSCode port of Emacs' Magit client for version control.
I'm genuinely curious, from other folks perspectives, what I'm missing with this setup. I've tried standalone Vim, I've tried standalone Emacs (Spaceamacs), and this is by far the best developer experience I've had. I don't know why I would ever switch to another tool, this feels to me like the best of all worlds.
VSCode Spacemacs: https://github.com/VSpaceCode/VSpaceCode
VSCode Magit: https://marketplace.visualstudio.com/items?itemName=kahole.m...
I'm genuinely curious, from other folks perspectives, what I'm missing with this setup. I've tried standalone Vim, I've tried standalone Emacs (Spaceamacs), and this is by far the best developer experience I've had. I don't know why I would ever switch to another tool, this feels to me like the best of all worlds.
VSCode Spacemacs: https://github.com/VSpaceCode/VSpaceCode
VSCode Magit: https://marketplace.visualstudio.com/items?itemName=kahole.m...
After 10+ years with Vim, and 5 on emacs before that I switched to vscode this year and have been pleasantly surprised.
I tried vscode in 2018 and it wasn’t there yet.
What I like better than vim:
Better integration with python.
Per-workspace interpreter and linter path settings.
Outline view.
Integrated terminal.
direnv and venv both work well.
JSON Schema integration. This is actually what sold it for me.
Edit: format
I tried vscode in 2018 and it wasn’t there yet.
What I like better than vim:
Better integration with python.
Per-workspace interpreter and linter path settings.
Outline view.
Integrated terminal.
direnv and venv both work well.
JSON Schema integration. This is actually what sold it for me.
Edit: format
For me, the value of emacs lies in the fact that it works from the cli ie. Ssh, and that I can use it productively from termux on my phone- with a Bluetooth keyboard I can do split-screen working with ease. Vscode would be considerably harder to setup.
I'm more excited about Onivim [1] than I am about Neovim making Lua a first-class language for writing plugins.
[1]: Onivim is a VSCode/Vim hybrid in the works (https://onivim.io/)
[1]: Onivim is a VSCode/Vim hybrid in the works (https://onivim.io/)
Still kinda restrictive with its license. Still uses NodeJS under its hood. 60+mb in size
I am surprised nobody talked about https://github.com/rxi/lite
Its a really simple Editor. I have recently started working on it. Not very feature rich, but gets the job done. Lua as plugins are also a plus
I am surprised nobody talked about https://github.com/rxi/lite
Its a really simple Editor. I have recently started working on it. Not very feature rich, but gets the job done. Lua as plugins are also a plus
VSCode is Slow to me. Emacs is great for lisp programming and I like the TODO feature of org mode, there’s a lot of useful features, however it’s a bit too different from modern UI so I get a bit jarred using it from time to time —> my job is using many programs, of which an editor is one, so I can’t happily stay in emacs 90% of the time.
I really like Sublime - fast and clean. Currently I use both sublime and emacs depending on what I’m doing.
I wish I discovered emacs 20 years ago! How many years I wasted without it :(
I really like Sublime - fast and clean. Currently I use both sublime and emacs depending on what I’m doing.
I wish I discovered emacs 20 years ago! How many years I wasted without it :(
A thoughtful essay. I find myself frustrated with Sublime Text these days, and as a former (novice) vim user, I’ve been debating if I should go for VSCode like all the young guns these days or commit to Doom Emacs to leverage a solid initial setup and my vim memory and fully embrace libre route, which are a little more aligned with my values (although not to the degree of RMS). I remain oddly indecisive.
I'm an old gun (learned to program in Fortran in 1977), and I recommend giving VScode a try.
Its barrier to entry is very low, so you don't need to invest a lot of time to find out whether it's going to be productive for you. It's a real usability jump over older IDEs.
I've switched from a combo of, mostly, Intellij IDEA and Vim to almost exclusively VScode (for development). I do still use Spacemacs just for org mode.
> my vim memory
There are vim compatibility plugins for VScode.
> fully embrace libre route
VScode is open source and MIT licensed, here's the repo: https://github.com/microsoft/vscode
Someone would need to explain to me what values I'm forgoing in order to use this. Although I should warn that someone I'm likely to have a strong rebuttal.
Its barrier to entry is very low, so you don't need to invest a lot of time to find out whether it's going to be productive for you. It's a real usability jump over older IDEs.
I've switched from a combo of, mostly, Intellij IDEA and Vim to almost exclusively VScode (for development). I do still use Spacemacs just for org mode.
> my vim memory
There are vim compatibility plugins for VScode.
> fully embrace libre route
VScode is open source and MIT licensed, here's the repo: https://github.com/microsoft/vscode
Someone would need to explain to me what values I'm forgoing in order to use this. Although I should warn that someone I'm likely to have a strong rebuttal.
The default builds of vscode include telemetry and a non-free license.
For a truly free build of vscode, you need to use vscodium. See their description: https://github.com/VSCodium/vscodium#why-does-this-exist.
I suspect many developers are unaware of this.
For a truly free build of vscode, you need to use vscodium. See their description: https://github.com/VSCodium/vscodium#why-does-this-exist.
I suspect many developers are unaware of this.
The most important practical detail here is that if you run vscodium, or download and build the vscode repo from microsoft yourself, or use any forks of vscode, you cannot install any of the extensions hosted on microsoft's servers without violating their license terms.
There are alternative extension marketplaces such as https://open-vsx.org/ but they are missing a lot of the extensions, some of which are proprietary.
There are alternative extension marketplaces such as https://open-vsx.org/ but they are missing a lot of the extensions, some of which are proprietary.
[deleted]
The vscode marketplace also provides a link to download extensions as a vsix file on every extension page. So if the extension isn't on open-vsx I just download it directly and install it.
That's true, although anyone who cares about truly free software presumably would look into the details to check.
You can disable the telemetry: https://code.visualstudio.com/docs/supporting/faq#_how-to-di...
My point was really that it's free and open enough for any practical purpose I'm able to discern. Refusing to use it on the grounds of insufficient openness or freedom seems to me to require an unreasonably absolutist ideological stance on the issue.
You can disable the telemetry: https://code.visualstudio.com/docs/supporting/faq#_how-to-di...
My point was really that it's free and open enough for any practical purpose I'm able to discern. Refusing to use it on the grounds of insufficient openness or freedom seems to me to require an unreasonably absolutist ideological stance on the issue.
I use VSCode with a vim plugin. I’m mostly happy with it. As opposed to Vim, VSCode makes it easy to setup as a general purpose IDE. The downside is that it doesn’t feel as responsive (it’s not terrible, but noticeable) and has a larger memory footprint.
I read this "definition" of philosophy elsewhere: we all share the exact same set of moral values, but their relative order is different. It's the order of the moral values that determines a philosophical stance.
The article starts by recalling this, but then it describes each project by the principles that it holds, but not by their order. This is a bit strange.
The article starts by recalling this, but then it describes each project by the principles that it holds, but not by their order. This is a bit strange.
Performance should be listed on there too. Without it, none of the other features matter to me. If I type a character I would like, ideally, 0 ms lag. That has to be a starting point. THEN, you can add the additional layers of niceness (while keeping the performance, of course). VSCode certainly does not achieve this (gorilla is being polite).
Nothing to add - just a great article that provides an objective and humanistic review of the field which is extremely refreshing to me.
It invites the reader to consider their values and its mapping to the tooling we use (instead of working backward by having a gut feel of what they like and trying to justify why a specific feature is The Best)
It invites the reader to consider their values and its mapping to the tooling we use (instead of working backward by having a gut feel of what they like and trying to justify why a specific feature is The Best)
They have wrote such a list of values down but seemingly forgot such values as aesthetics (e.g. Sublime and VSCode look great, at least after you install a theme which suits your taste) and smart context-aware code completion and refactoring facilities (e.g. try IntelliJ once and you are hardly ever going back).
doom-emacs looks wonderful from the get go. https://github.com/hlissner/doom-emacs
Indeed! Does it have a light theme also? I have a window behind my back so I mostly prefer to use the ayu-light or alike themes wherever available.
The article discusses it in sections related to Emacs' attitude toward modernization and progressiveness (see the citation from Ahmed Khanzada).
VSCode sends your private data to Microsoft servers. Emacs and Vim don't.
Use https://vscodium.com/ it's vs code without any telemetry.
blackrock(1)
Wasn't emacs forked several times in the past? Would be curious to see an exploration of the difference and why they converged back to mainly one offering. (Or are there others still thriving?)
Noob question: Is Sublime text still a good text-editor in 2021? Did it just loose momentum or not being open-source is insurmountable? I still think its speed and usability are not easy to match.
Sublime is a perfectly fine and frankly faster editor than VSCode. The problem is the slow nature of the updates, the underwhelming API and people abandoning it in droves because they opt for VSCode makes the extension library not as comprehensive or feature packed. Half the extensions I use in VSCode don't have a parallel in Sublime
I still use it to quickly edit text or read some files quickly cause it opens really fast but it's definitely never going to be my daily driver unless something changes drastically
I still use it to quickly edit text or read some files quickly cause it opens really fast but it's definitely never going to be my daily driver unless something changes drastically
In my workflow, one reason I prefer VSCode over Sublime is for dealing with large (10mb+) files. Sublime takes upwards of a minute to open such files but VSCode is nearly instant.
For smaller files, Sublime is great.
For smaller files, Sublime is great.
My experience has been _exactly the opposite_.
I think sublime is a fantastic text editor. But it just doesn't cut it for me as a development environment. Getting productive in vscode is easy. It just works. Though Sublime hq's sublime merge git client is fantastic. I don't really care about sublime text anymore, but I'm a devoted user of sublime merge.
It’s my primary editor. It’s a better text editor than VsCode, but VsCode is a better IDE.
Open source is kinda irrelevant IMO.
The answer is, of course, it depends. How much do you value language integration? Do you have muscle memory for vim or emacs? There are many more questions here.
VSCode supports language server protocol arguably best, because LSP/VSCode/TypeScript were all developed somewhat in parallel. But some languages don't have complete language servers, or already had their own forms of IDE integration. JetBrains ReSharper has it's own csharp parser which it uses for analysis and automated refactoring.
The answer is, of course, it depends. How much do you value language integration? Do you have muscle memory for vim or emacs? There are many more questions here.
VSCode supports language server protocol arguably best, because LSP/VSCode/TypeScript were all developed somewhat in parallel. But some languages don't have complete language servers, or already had their own forms of IDE integration. JetBrains ReSharper has it's own csharp parser which it uses for analysis and automated refactoring.
> Open source is kinda irrelevant IMO.
Good tools become even better with time investment. I don't want to invest time into a tool that dies if the dev company loses interest/goes bankrupt/gets bought by oracle/... . Emacs is much older than me and will be around for decades to come. Sublime 2? Probably not. Sublime 3, probably several years. Sublime 4,5,6... who knows.
Good tools become even better with time investment. I don't want to invest time into a tool that dies if the dev company loses interest/goes bankrupt/gets bought by oracle/... . Emacs is much older than me and will be around for decades to come. Sublime 2? Probably not. Sublime 3, probably several years. Sublime 4,5,6... who knows.
[deleted]
My problem with sublime was it was just less polished. Harder to find extensions. Extensions randomly don't work. Etc.
Vscode strikes a good balance. It's mostly got enterprise level of "polish" and stability, but still feels light-weight and flexible.
Vscode strikes a good balance. It's mostly got enterprise level of "polish" and stability, but still feels light-weight and flexible.
Perhaps this might be interesting to anyone which wants to give Emacs a try: https://emacs.zeef.com
Maybe I'm lazy but I prefer to buy an intellij product.
Until an editor comes along that is as extensible and keyboard efficient as emacs with lsp integration, or I get one of those combination mouse/ergonomic keyboard contraptions, I'll stay there.
Every other IDE requires mouse usage to accomplish even the most basic commands. With helm in emacs, my hands never have to leave the keyboard. Vocoder comes really close, but still requires you to build a plug in rather than exposing a quick api to do project specific one off tasks with eval or macro recording and repetitive application without using the mouse for anything.
Every other IDE requires mouse usage to accomplish even the most basic commands. With helm in emacs, my hands never have to leave the keyboard. Vocoder comes really close, but still requires you to build a plug in rather than exposing a quick api to do project specific one off tasks with eval or macro recording and repetitive application without using the mouse for anything.
Emacs is a typewriter that comes with a one thousand-page user manual and can also serve as a piano and a chainsaw.
[deleted]
i just wanna know how anyone still uses emacs insanely bad movement bindings
I find them incredibly ergonomic, another bonus is that it provides the same defaults found in most terminal emulators. Most people try to use pinky for Ctrl, or map to Capslock, but using the side of your palm for Ctrl is really comfortable. I generally run circles around colleagues in a terminal or working with text, especially when utilizing macros, but the learning curve is definitely steeper and took some time to get used to.
Universally.
Outside of Emacs, I have those "insanely bad" bindings in GUI text widgets, my shell prompt, when choosing/searching in in fzf, navigating scrollback in tmux, and inside REPLs of all flavors. Basically anywhere text is entered, I edit with those bindings. My Kinesis keyboard has 12 thumb buttons, and for me Control, Meta, Super and Hyper are all easily within reach.
Outside of Emacs, I have those "insanely bad" bindings in GUI text widgets, my shell prompt, when choosing/searching in in fzf, navigating scrollback in tmux, and inside REPLs of all flavors. Basically anywhere text is entered, I edit with those bindings. My Kinesis keyboard has 12 thumb buttons, and for me Control, Meta, Super and Hyper are all easily within reach.
tldr Neovim is a more actively developed vim. Vscode is a more than good enough editor for all seasons. Emacs is both stymied and celebrated for its adherence to "software freedom."
Editorial: No one cares about "software freedom." If it takes [more than 2000 words](https://www.gnu.org/philosophy/free-sw.en.html) to describe what "free" means (another bad case of tldr), then forget it.
Editorial: No one cares about "software freedom." If it takes [more than 2000 words](https://www.gnu.org/philosophy/free-sw.en.html) to describe what "free" means (another bad case of tldr), then forget it.
Emacs "doesn't, however, affect progressiveness as much as freedom. Because of freedom, when faced with a question of using technology that is 1. Non-free, but objectively better, 2. Free, but objectively worse, the latter will always be picked. Given that most technological progress happens through the mechanisms of capitalism, "free" alternatives commonly lag behind to a large degree."
Emacs has a degree of integration and customization ability that VSCode just can't touch, so all this talk about VSCode being "objectively better" is pretty myopically focused on just a handful of things geared towards ordinary developers "who mostly just want to get stuff done".
Those aren't the only people in existence, and if Emacs doesn't cater to those it's not because of its philosophy of Freedom, but because it doesn't have enough developers who care to steer it in that direction.
Emacs is an editor-creation toolkit which is about customization, flexibility, and power. Making it easy to use for people who don't want to invest much time crafting their own editor with this toolkit is just not a big priority.
That said, there are some packages like Prelude, which aim at giving Emacs sane defaults and making it easier to use for beginners (though I've never used any of them, so can't vouch for how well they achieve this aim, and I doubt that any of them would give you a full VSCode-like experience out of the box).
To me the biggest weakness of Emacs, but also a strength, is that like a typical large open source meta-project (like Linux, the OS including all the software developed for it, not just the kernel) it's a multi-directional effort of hundreds of volunteer developers each running in their own direction.
There are no orders from the top steering in one direction, no army of paid developers to make thorny, decades-old bugs finally disappear. Volunteers will get to those if they're interested, and go the way their own interests take them.
It just so happens that the stars aligned so that we have the Emacs of today, given the volunteers of yesterday. If they were different volunteers with different priorities, Emacs would be different, and different volunteers tomorrow may steer Emacs in yet another direction. There is no plan. It's an anthill without a queen, with each ant building what it personally wants.
This is why, like mature languages with large ecosystems, like Python, like other flexible editors (ie. vim, with its many plugins), and like Firefox (with all of its extensions) you have packages that "interfere with one another, depend on functionality from other packages that get deprecated, changed in incompatible ways, or removed."
You really can't have a large package ecosystem developed primarily by volunteers and not have this problem. People work on what they want to work on, and if they don't want to spend the time maintaining their package or making sure it's compatible with whatever package combination any particular user happens to be using, then there are going to be incompatibilities.
But I'll take that incompatibility in a heartbeat for the enormous flexibility and power it offers, especially if the alternative is a meager, inflexible package ecosystem where how I edit is dictated from on high by people who cater to the average developer who "just wants to get things done".
If you want Emacs to be something else you either have to be really good at herding cats, do it yourself, or pay someone to do it for you. Even then, you'll have to somehow convince all of its users to switch to your "improved" version. Good luck.
Emacs has a degree of integration and customization ability that VSCode just can't touch, so all this talk about VSCode being "objectively better" is pretty myopically focused on just a handful of things geared towards ordinary developers "who mostly just want to get stuff done".
Those aren't the only people in existence, and if Emacs doesn't cater to those it's not because of its philosophy of Freedom, but because it doesn't have enough developers who care to steer it in that direction.
Emacs is an editor-creation toolkit which is about customization, flexibility, and power. Making it easy to use for people who don't want to invest much time crafting their own editor with this toolkit is just not a big priority.
That said, there are some packages like Prelude, which aim at giving Emacs sane defaults and making it easier to use for beginners (though I've never used any of them, so can't vouch for how well they achieve this aim, and I doubt that any of them would give you a full VSCode-like experience out of the box).
To me the biggest weakness of Emacs, but also a strength, is that like a typical large open source meta-project (like Linux, the OS including all the software developed for it, not just the kernel) it's a multi-directional effort of hundreds of volunteer developers each running in their own direction.
There are no orders from the top steering in one direction, no army of paid developers to make thorny, decades-old bugs finally disappear. Volunteers will get to those if they're interested, and go the way their own interests take them.
It just so happens that the stars aligned so that we have the Emacs of today, given the volunteers of yesterday. If they were different volunteers with different priorities, Emacs would be different, and different volunteers tomorrow may steer Emacs in yet another direction. There is no plan. It's an anthill without a queen, with each ant building what it personally wants.
This is why, like mature languages with large ecosystems, like Python, like other flexible editors (ie. vim, with its many plugins), and like Firefox (with all of its extensions) you have packages that "interfere with one another, depend on functionality from other packages that get deprecated, changed in incompatible ways, or removed."
You really can't have a large package ecosystem developed primarily by volunteers and not have this problem. People work on what they want to work on, and if they don't want to spend the time maintaining their package or making sure it's compatible with whatever package combination any particular user happens to be using, then there are going to be incompatibilities.
But I'll take that incompatibility in a heartbeat for the enormous flexibility and power it offers, especially if the alternative is a meager, inflexible package ecosystem where how I edit is dictated from on high by people who cater to the average developer who "just wants to get things done".
If you want Emacs to be something else you either have to be really good at herding cats, do it yourself, or pay someone to do it for you. Even then, you'll have to somehow convince all of its users to switch to your "improved" version. Good luck.
I don't like any of the three. I like Xcode, even better now that interface builder is destined for the garbage heap.
I use vim frequently. But I think that people should realize and be able to admit that vim and emacs are outdated. They can still be useful especially for people like me who have a sunk cost in learning them. But the honest evaluation is outdated. For example, the core modal interface of vim is related to historical limitations at the time it was created.
http://xahlee.info/kbd/keyboard_hardware_and_key_choices.htm... Basically historical happenstance has become part of multiple religions defending dated programs.
My current favorites are Jupyter Notebooks and the combination of gedit with fish shell.
VSCode is great but a lot of times feels like overkill and a little bloated.
http://xahlee.info/kbd/keyboard_hardware_and_key_choices.htm... Basically historical happenstance has become part of multiple religions defending dated programs.
My current favorites are Jupyter Notebooks and the combination of gedit with fish shell.
VSCode is great but a lot of times feels like overkill and a little bloated.
> the core modal interface of vim is related to historical limitations at the time it was created.
While that's true, the type of text manipulation and navigation one can achieve in normal and command mode far exceeds what one can do with the standard keyboard shortcuts for text manipulation, navigation, and selection in most GUI applications using, with or without holding the shift key, the arrow, del, home, end, pgdn, and pgup keys, or the ctrl-{a,c,f,x,v,y,home,end} key combinations.
While that's true, the type of text manipulation and navigation one can achieve in normal and command mode far exceeds what one can do with the standard keyboard shortcuts for text manipulation, navigation, and selection in most GUI applications using, with or without holding the shift key, the arrow, del, home, end, pgdn, and pgup keys, or the ctrl-{a,c,f,x,v,y,home,end} key combinations.
>My current favorites are Jupyter Notebooks and the combination of gedit with fish shell.
Do you mind elaborating on what you're doing with notebooks?
Do you mind elaborating on what you're doing with notebooks?
Just to be clear, those are two separate cases: 1) Jupyter and 2) gedit + fish. Two different types of programming projects.
I am using Jupyter Notebooks for what they are normally used for: machine learning experiments.
But it might be a good idea to try to expand to other use cases since its such a powerful concept.
I am using Jupyter Notebooks for what they are normally used for: machine learning experiments.
But it might be a good idea to try to expand to other use cases since its such a powerful concept.
>I am using Jupyter Notebooks for what they are normally used for: machine learning experiments.
I'm interested to know what kind of problems you may be having doing machine learning. Are you doing that as part of a team or for fun?
We're making something in that space[0]. It's our machine learning platform because we've been doing ML projects for many years and are building this to help us. Does the description in that post solve some/all/none of your problems?
- [0]: https://news.ycombinator.com/item?id=25802764
I'm interested to know what kind of problems you may be having doing machine learning. Are you doing that as part of a team or for fun?
We're making something in that space[0]. It's our machine learning platform because we've been doing ML projects for many years and are building this to help us. Does the description in that post solve some/all/none of your problems?
- [0]: https://news.ycombinator.com/item?id=25802764
That sounds amazing. Right now I am just learning about CNNs and I just bought a gaming laptop specifically so I wouldn't have to rely on Paperspace and vast.ai for everything.
So at the moment I am probably going to try to take advantage of the laptop a bit more. In the future if I have a contract or am trying to get a ML contract I may take advantage of some of your features which sound like a big advantage. How does the detection and automatic saving of models work? Seems pretty hard to do that. Does it work with the latest keras for example? And so I can just skip down to the cell that uses the trained model? To be honest I haven't used it much but I guess I thought if I committed the docker process after doing the training then I would already be able to use the trained model when I ran that image again.
My real goal is eventually to actually build a relatively novel real-time computer vision system for a simulated robot. So at some point I am not sure that Jupyter is going to be right. But I like it so maybe I can stretch out it's utility.
So at the moment I am probably going to try to take advantage of the laptop a bit more. In the future if I have a contract or am trying to get a ML contract I may take advantage of some of your features which sound like a big advantage. How does the detection and automatic saving of models work? Seems pretty hard to do that. Does it work with the latest keras for example? And so I can just skip down to the cell that uses the trained model? To be honest I haven't used it much but I guess I thought if I committed the docker process after doing the training then I would already be able to use the trained model when I ran that image again.
My real goal is eventually to actually build a relatively novel real-time computer vision system for a simulated robot. So at some point I am not sure that Jupyter is going to be right. But I like it so maybe I can stretch out it's utility.
Congratulations for your new laptop : )
What we mean by automatic model detection is that you don't have to add experiment tracking code to your notebook to "log" most of the usual stuff such as model, parameters, metrics; we do that for you so you don't clutter your notebook. You can do it explicitly if you want to or if you're trying to log something in particular, but you mostly don't have to think about it, or generate experiment names, or worry about where you are logging your models.
- You use a notebook to write code to train and evaluate your model
- You schedule it (https://iko.ai/docs/resources/img/async.gif)
- Your notebook is executed and the experiment is tracked (notebook, model, parameters, metrics). This way you can compare your runs.
- You can then deploy your model to a "REST API" (https://iko.ai/docs/resources/img/deploy.gif), or build its Docker image and push it to use elsewhere (https://iko.ai/docs/resources/img/model_docker_image.gif).
Then you can monitor your deployed model's performance on a live dashboard.
>So at some point I am not sure that Jupyter is going to be right. But I like it so maybe I can stretch out it's utility.
Generally speaking, you use the notebook to train models and you use these models to return predictions. In the workflow I described above, the models produced are deployed and interacted with through requests.
What we mean by automatic model detection is that you don't have to add experiment tracking code to your notebook to "log" most of the usual stuff such as model, parameters, metrics; we do that for you so you don't clutter your notebook. You can do it explicitly if you want to or if you're trying to log something in particular, but you mostly don't have to think about it, or generate experiment names, or worry about where you are logging your models.
- You use a notebook to write code to train and evaluate your model
- You schedule it (https://iko.ai/docs/resources/img/async.gif)
- Your notebook is executed and the experiment is tracked (notebook, model, parameters, metrics). This way you can compare your runs.
- You can then deploy your model to a "REST API" (https://iko.ai/docs/resources/img/deploy.gif), or build its Docker image and push it to use elsewhere (https://iko.ai/docs/resources/img/model_docker_image.gif).
Then you can monitor your deployed model's performance on a live dashboard.
>So at some point I am not sure that Jupyter is going to be right. But I like it so maybe I can stretch out it's utility.
Generally speaking, you use the notebook to train models and you use these models to return predictions. In the workflow I described above, the models produced are deployed and interacted with through requests.
Our text editor is a tool, there’s no fundamental value in a tool vs the other, they do not possess life. They’re tools like a fork is a tool.
I wonder what of the things you use in the day to day you analyze so deeply, your microwave ? The forks you buy?
Might be an interesting exercise of thought but for something that I use to make money, I will use the best tool available for the job, thank you very much.
I wonder what of the things you use in the day to day you analyze so deeply, your microwave ? The forks you buy?
Might be an interesting exercise of thought but for something that I use to make money, I will use the best tool available for the job, thank you very much.
> there’s no fundamental value in a tool vs the other
> I will use the best tool available for the job
The article is pointing out that the way you decide which tool is best depends on values that you have, which is certainly true whether or not you consciously think about or recognize those values.
Describe your decision process for selecting the best tool in a given scenario, and the values you use should become clear.
> I will use the best tool available for the job
The article is pointing out that the way you decide which tool is best depends on values that you have, which is certainly true whether or not you consciously think about or recognize those values.
Describe your decision process for selecting the best tool in a given scenario, and the values you use should become clear.
Maybe not forks for eating. But when I buy a pitchfork, I do care about the source of the handle's wood because I do not want to contribute to deforestation. I also look at the repairability. For example, would any standard handle fit? And can I attach one myself? And the "usability" of the handle, and the fork as a whole, is another factor that is important to me. Often, just from handling them, you do get a good feel if the pitchfork makers actually seem to care about their users and know what they are doing or not.
My values certainly informed my decision when I last purchased forks. My values are that the design should lean towards minimalism over overt decoration, that they should have appreciable weight, and be likely to last a lifetime.
I could have saved a few dollars by getting those really cheap forks you see that are obviously just stamped out of sheets of steel, but cheapness wasn't one of my values. Instead I got forks that have never bent, or rusted, or tarnished, or shown any signs of wear in almost a decade of use. Plus they feel nice in the hand, they look good, and they don't have flowers or birds carved into the handle or any of that nonsense. It was also a nice bonus that I found them at a Target a mile from where I live. I hate shopping, so that satisfied a tertiary value by not making me visit a lot of stores.
It's the same with editors. Most people value price above all else, so there's no business in selling editors any more. Back in the day I used a rather nice commercial editor called VEdit. My Dad must have bought it, because at that age I never would have. It had a ton of features, and came with an inch-thick printed manual. I don't recall how extensible or introspectable it was (I was 12 at the time, and didn't care about such things), so probably it wouldn't satisfy my values today. On the other hand, it satisfied (or cultivated) values that I didn't even know at the time that I had. When I discovered VEdit's hex-editor, I started using it on everything. I explored how file names were stored in directory entries. I hex-edited some games to change their messages. I learned quite a lot from those sorts of things, so I'd say that it was money well spent.
But you're correct in saying that editors are not alive, and cannot themselves have values. However, the people who develop the editor certainly do have values, and those values affect the choices they make when they write code. If those values are similar to your own values, then the developers of the editor will make similar choices to the ones you would have made if you had been developing the editor. Thus, the editor will fit you well.
I could have saved a few dollars by getting those really cheap forks you see that are obviously just stamped out of sheets of steel, but cheapness wasn't one of my values. Instead I got forks that have never bent, or rusted, or tarnished, or shown any signs of wear in almost a decade of use. Plus they feel nice in the hand, they look good, and they don't have flowers or birds carved into the handle or any of that nonsense. It was also a nice bonus that I found them at a Target a mile from where I live. I hate shopping, so that satisfied a tertiary value by not making me visit a lot of stores.
It's the same with editors. Most people value price above all else, so there's no business in selling editors any more. Back in the day I used a rather nice commercial editor called VEdit. My Dad must have bought it, because at that age I never would have. It had a ton of features, and came with an inch-thick printed manual. I don't recall how extensible or introspectable it was (I was 12 at the time, and didn't care about such things), so probably it wouldn't satisfy my values today. On the other hand, it satisfied (or cultivated) values that I didn't even know at the time that I had. When I discovered VEdit's hex-editor, I started using it on everything. I explored how file names were stored in directory entries. I hex-edited some games to change their messages. I learned quite a lot from those sorts of things, so I'd say that it was money well spent.
But you're correct in saying that editors are not alive, and cannot themselves have values. However, the people who develop the editor certainly do have values, and those values affect the choices they make when they write code. If those values are similar to your own values, then the developers of the editor will make similar choices to the ones you would have made if you had been developing the editor. Thus, the editor will fit you well.
You didn't even skim the headline correctly.
The Neovim section participates in the popular sports of ganging up on top developers who have spent decades of their life in the public interest, for free.
The Neovim developer is called its "author", which is poor form and probably a copyright violation. Go and write your own editor from scratch.
The Neovim developer is called its "author", which is poor form and probably a copyright violation. Go and write your own editor from scratch.
The only place that the developer of neovim is referred to as its “author” is in a quote. But also, I didn’t get this impression at all while reading the article.
The article is deliberately using selective quotes to paint Bram Molenaar in the worst possible light.
A common tactic among people who take over code bases in order to cruise on other people's hard work.
A common tactic among people who take over code bases in order to cruise on other people's hard work.
I don’t know. I don’t think the author paints him in a particularly bad light. It mostly seems to be trying to point out why neovim was made, specifically that its authors valued different things than the author of vim.
I also think the amount of work that’s gone into neovim is way more than enough to call the authors authors at this point. The forking of vim doesn’t seem to me to be “tak[ing] over code based in order to cruise on other people‘a hard work,” but open source working as intended. The neovim authors were able to take a project, adjust it to fit with their values, and let people decide which they prefer.
I also think the amount of work that’s gone into neovim is way more than enough to call the authors authors at this point. The forking of vim doesn’t seem to me to be “tak[ing] over code based in order to cruise on other people‘a hard work,” but open source working as intended. The neovim authors were able to take a project, adjust it to fit with their values, and let people decide which they prefer.
You and thread OP seem to have signed up just to make these comments. Do you think your obvious bias against Neovim is coloring your perceptions of the piece? Because it is not about trashing Vim or Moolenaar.
author (plural authors)
The originator or creator of a work, especially of a literary composition.
As opposed the popular sport of denigrating a critique of something because the critic hasn't, or doesn't the ability to, create the thing themselves?
i am both a vim and neovim user. i dont see any ganging up here.
the difficulty of getting patches into vim is a fairly well known fact and is much older than neovim. the vim codebase is a horrible mess of ifdef's supporting platforms that haven't existed for years.
and vim wasn't written from scratch either, it was based on an earlier clone.
the sad truth is that neovim was a godsend for the vim community because bram finally woke up and put into vim what the neovim people were offering him for free in the spirit of open source before creating neovim.
the difficulty of getting patches into vim is a fairly well known fact and is much older than neovim. the vim codebase is a horrible mess of ifdef's supporting platforms that haven't existed for years.
and vim wasn't written from scratch either, it was based on an earlier clone.
the sad truth is that neovim was a godsend for the vim community because bram finally woke up and put into vim what the neovim people were offering him for free in the spirit of open source before creating neovim.
What makes Emacs exceptional is you can link all these packages together, create your own workflows by scripting Emacs in Lisp. And I write the docu in Emacs in org-mode, with org-babel I can run shell-scripts / python-scripts and other code in my org-file and see the output underneath it (like Jupyter notebooks), link to code fragments in my org files etc
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.
I think VS Code is a nice coding environment with good defaults and many things done right (compare installing packages in VS Code to Sublime! What an improvement) but nowhere near the capabilities and the productivity of Emacs.