Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The values of Emacs, the Neovim revolution, and the VSCode gorilla

murilopereira.com

Post reply on HN
Print view View original

281–290 of 353 posts

Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla

#281

Post by tom_ »

BeetleB wrote: post #262
dleslie wrote: post #185

Earlier quoted context omitted.

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

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

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

Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla

#282

Post by a_e_k »

sedev wrote: post #55
submeta wrote: post #30

When you finally learn to master and config Emacs, you run circles around all other editors. Emacs is so much more than just an editor. But even if you only use it for coding: Magit is the best git client I have used in years (coming from PyCharm + Git Tower App, which is nice), then there‘s Ztree-Diff (excellent folder diff tool; previously using Kaleidoscope app), then Eshell for interacting with the server from wi…

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 j…

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

Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla

#284

Post by [deleted] »

opencl wrote: post #76
nitsky wrote: post #66

Earlier quoted context omitted.

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.

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 proprietar…

[deleted]

Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla

#285

Post by jpeloquin »

GordonS wrote: post #187
jpeloquin wrote: post #174

Earlier quoted context omitted.

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 defau…

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.

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.

Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla

#286

Post by squid_demon »

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

Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla

#288

Post by Kwpolska »

kubanczyk wrote: post #140
the__alchemist wrote: post #77

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.

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?

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

Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla

#289

Post by agambrahma »

drzoltar wrote: post #127
aniforprez wrote: post #38

Earlier quoted context omitted.

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…

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.

My experience has been _exactly the opposite_.

Re: The values of Emacs, the Neovim revolution, and the VSCode gorilla

#290

Post by monsieurbanana »

BeetleB wrote: post #259
emptysongglass wrote: post #198

Earlier quoted context omitted.

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…

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

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?
Post reply on HN