Live data from Hacker News

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

murilopereira.com

161–170 of 353 posts

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

#161
post #128
post #108

Earlier quoted context omitted.

>The great thing about Emacs is that everything is a buffer[...] It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours. Every time I get a shitty modal with some text I can't copy…

>>The great thing about Emacs is that everything is a buffer[...] > It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours. Perhaps I don't understand emacs well enough, but I know…

Yeah quickfix pane is a big annoyance of mine, but you also have things like :message that dumps a bunch of text to stdout that you can't meaningfully use directly. Compare that to Emacs' permanent Messages buffer that is just like any other buffer.

Vim is not the worst offender by any mean, but it's definitely a lot less uniform than Emacs.

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

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

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

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

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

#164
post #108
post #5

> It also shines in areas where Emacs doesn’t: if you’re a programmer working on typical contemporary projects, mostly just wanting to get stuff done, things usually… just work. You install VSCode, open a source code file, get asked to install the extension for that particular language, and that’s it. You get smart completion, static analysis, linting, advanced debugging, refactoring tools, deep integration with git…

>The great thing about Emacs is that everything is a buffer[...] It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours. Every time I get a shitty modal with some text I can't copy…

You wrote a lot here, without saying anything at all.

It’s like you’re a master at the art of hot air speaking.

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

#165

Earlier quoted context omitted.

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

VS Code runs on remote hosts through SSH, containers, or WSL: https://code.visualstudio.com/docs/remote/remote-overview Kinda like a parallel universe swank/slime.

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

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

#166
post #123
post #93

On the discussion of values, I'd also like to submit "(expected) longevity" for consideration, which I think is distinct from "stability". I made the switch from Vim to Neovim as soon as I felt confident that (1) the project was going to be around for a while, and (2) it was on track to "overtake" Vim (you may choose to disagree with me on this, I found built-in LSP to be a compelling selling point, but the specifics…

> I'm not sure I can say the same about Kakoune, for example, which is a certainly a promising project but hasn't yet convinced me to jump the fence. I've made that jump a couple of months ago, and so far I love it. There isn't as large of an ecosystem, but Kakoune just feels better integrated with the environment. Is your hesitancy based on some particular feature, or the ecosystem, or something else? Or is there so…

I haven't tried Kakoune, so I'm not really qualified to speak about its merits or demerits. From a place of limited knowledge, I see nothing wrong with it, and want to reiterate that it seems really interesting and worth keeping an eye on.

To add some nuance to my earlier comment: I don't really worry about the existence of Kakoune (or $OPEN_SOURCE_SOFTWARE_PROJECT) in a trivial sense; we'll always be able to find a copy somewhere and compile it from source, modify it, etc. That being said, I think one of the advantages of a large/durable ecosystem is that it lets me worry less about problems I don't yet have. I use (neo)vim daily, but there are certainly still lots of ways I can improve my workflow. Inevitably I'll run into something that goes wrong or doesn't work like I want it to, and a larger and more active community makes it more likely that someone else has already figured out how to fix it.

The (relatively small) differences in keybindings are also worth a mention, but I think the vims have a bit of an unfair advantage here; IMO learning vim keybindings is almost unquestionably a good investment because you'll find them everywhere.

> Kakoune just feels better integrated with the environment

Out of curiosity, is this an argument for enjoyment or productivity? :) (Either is a fine answer! I frankly can't measure the latter so my personal usage of vim is probably motivated by the former.)

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

#167
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 don't quite "get" magit, can someone tell what's great about it / for what type of git workflow?

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

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

#168
post #19

Earlier quoted context omitted.

Same here in regards to Magit. I've tried seriously using Emacs (Spacemacs) for a year or two, but something always doesn't work as intended, code completion and static analysis is extremely hard to configure, especially you have some non-standard project setups. Then switched to a mix of vim for simple stuff or clion/pycharm in vim mode for rust/cpp/python... BUT, subjectively, Magit is the best git client ever crea…

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.

How do you selectively stage several hunks from command line in git? - Imagine you edited a large file, fixed two different things, now you‘d like to select the changes related to one thing first and commit them. And then the next changes.

In Magit you visit the file you changed, hit `C-x g' and see all diffs. Now you can review and select hunks by hitting „s“ (stage), go to the next relevant hunk and hit „s“ again to mark for staging. And when you‘re done selecting all changes that are relevant for one ticket, you hit „c“ twice to write a commit message. And off to the modifications/ hunks regarding second ticket.

So how‘d you do this in command line?

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

#170
post #63
post #45

Earlier quoted context omitted.

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

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

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

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

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

Post reply on HN