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

241–250 of 353 posts

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

#241

Post by piazz »

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

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

#242

Post by cle »

ashtonkem wrote: post #114
tyingq wrote: post #111

Earlier quoted context omitted.

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

Yeah, this is very language dependent. Trying Emacs with Java is pure pain, even if you love Emacs. Like most open source things, the quality of support maps closely to the density of users who are trying to accomplish something similar. This is why Emacs has fantastic support for languages like JS and Ruby, and massively subpar support for Java and C#.

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

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

#243

Post by aporetics »

hollerith wrote: post #159
joaogui1 wrote: post #142

Earlier quoted context omitted.

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…

C-x t

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

#244

Post by cle »

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.

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.

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

#245

Post by hawski »

kubanczyk wrote: post #131
perryizgr8 wrote: post #86

Earlier quoted context omitted.

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.

git gui is way to go.

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

#246

Post by Jugurtha »

ilaksh wrote: post #240
Jugurtha wrote: post #118

Earlier quoted context omitted.

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

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.

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

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

#247

Post by BeetleB »

dmitriid wrote: post #219
BeetleB wrote: post #193

Earlier quoted context omitted.

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

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…

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

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

#248

Post by spamizbad »

emptysongglass wrote: post #198
hibbelig wrote: post #136

Earlier quoted context omitted.

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

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…

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.

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

#250

Post by agumonkey »

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…

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

Post reply on HN