The values of Emacs, the Neovim revolution, and the VSCode gorilla
murilopereira.com
murilopereira.com
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.
Sorry I just really hate emacs.
Chrome will always attract crowds, of course.
Kinda like a parallel universe swank/slime.
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.
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,
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
> 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?
> 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.
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.
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!)
Here’s what’s built in: https://code.visualstudio.com/docs/editor/versioncontrol
and git lens: https://marketplace.visualstudio.com/items?itemName=eamodio....
In a lot of ways, VSCode is more convenient, but its extensibility doesn't come close to matching Emacs'.
> 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.
Anyone know of CI service that can have use rdpmc/perf_events on the cheap?
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
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?).
Great comment! But you were missing an s in this FQDN. Here's a working link: http://emacsrocks.com/
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 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!
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.
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.
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
- [ ] 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.
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
It’s the first time I’ve actually felt like I could drop emacs if I wanted to, I actually was enjoying the setup.
That’s exactly what it felt like in 1991: “eight megabytes and constantly swapping!”
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.
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#.
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.
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.
One of the big appeals of VSCode for me is the huge community around it, and the range of plugins available.
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.
- 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...
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.
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)
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. ;)
It's true that Magit is slow, but I still prefer it to the command line.
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
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.
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.)
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?
If you're building software targeted at most of the world it makes sense to use Windows.
For most Windows SW, the answer is no. So the analogy with Android doesn't make much sense.
- 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.
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.
- 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.
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.
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.
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.
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.
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.
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.
Interestingly, for me, I only see some of the issues the GP mention when using xorg instead of wayland.
On windows, there's no choice. On mac osx, there's no choice (unless you try to mod it yourself after the fact).
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.
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.
ps: If you are using an Nvidia card, you can't, unfortunately, use Wayland.
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.
> 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.
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.
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.
Yep they are probably too busy doing their job: creating value for customers. Instead of having fun fiddling with their OS.
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.
What pains did you have? Docker support was a big one for me, but otherwise I haven’t encountered anything too bad.
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.
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 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.")
`(setq directory-free-space-program nil)`
0: https://stackoverflow.com/questions/26128693/emacs-dired-slo...
See https://magit.vc/manual/magit/Microsoft-Windows-Performance....
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).
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.
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.
I suspect that it is still common to be forced to use Windows at $BIGCO.
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 do still use pluma for just quickly editing files though, but for coding I use vscode now
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).
s/When/If
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.
>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.
> 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.
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 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'.
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.
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.
Computers are cattle, software too.
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.
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.
Two especially laborious operations are `git add -p` and `git rebase -i`. Try them out on magit, you'll see the difference.
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?
$ 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.
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.
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.
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
Or fugitive in Vim.
The difference is like that between using Ed and Vi. Seeing things as you do them is valuable.
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.
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.
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.
Vim is not the worst offender by any mean, but it's definitely a lot less uniform than Emacs.
:redir "a :messages :redir END
Then, you can just paste from that register using "ap.
(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 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'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.
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.)
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.
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.
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.
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.
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.
> 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.
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.
* 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.
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.
"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."
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.
Edit: here's an xkcd more relevant to what I meant: https://xkcd.com/309/
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.
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.
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.
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".
https://en.wikipedia.org/wiki/Hacker_ethic
[edit: let's the downvote fest begin...]
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...
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).
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?
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.
- 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 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.
https://devblogs.microsoft.com/python/announcing-pylance-fas...
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 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.
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.
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].
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.
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?
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.
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.
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.
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.
Being able from the same interface to visualize your database and state of the program is also good !
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.
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.
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!
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).
https://twitter.com/ID_AA_Carmack/status/1302651878065475584
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.
- 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.
- 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...
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.
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.
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 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
[1]: Onivim is a VSCode/Vim hybrid in the works (https://onivim.io/)
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 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 :(
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.
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.
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.
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.
Does that includes Vim?
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.
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)
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.
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.
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
For smaller files, Sublime is great.
Vscode strikes a good balance. It's mostly got enterprise level of "polish" and stability, but still feels light-weight and flexible.
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.
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.
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 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.
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.
Do you mind elaborating on what you're doing with notebooks?
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'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?
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.
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.
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.
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 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 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.
The Neovim developer is called its "author", which is poor form and probably a copyright violation. Go and write your own editor from scratch.
A common tactic among people who take over code bases in order to cruise on other people's hard work.
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.
author (plural authors)
The originator or creator of a work, especially of a literary composition.
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.