Live data from Hacker News

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

murilopereira.com

121–130 of 353 posts

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

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

[deleted]

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

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

Naah, not really. I've done that emacs exercise countless of times over a few decades and now I use vscode. I don't feel like I'm missing much.

I can see that for most people. It is really something, though, to watch someone really good with Emacs or Vim fly though something like a complex refactoring.

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

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

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

#124
post #65

VSCode has great and convenient language support, but the trade-off is reduced text editing efficiency, slower speed and more bloat. It is a worthy trade-off in many situations, I use it often when working on projects that are written in languages I am not too familiar with. I would like to emphasize how big of a game changer the next release of Neovim 0.5.0 will be. With builtin LSP support it will get code navigati…

I've used Neovim prior to trying vscode because it has a language server protocol client extension. Unfortunately, the extension didn't work too well (it had issues with `clangd`) at the time. So, just to compare I installed vscode and was amazed at how polished it was.

Still, I had it in my mind that I wanted to have and fast alternative to vscode so I kept trying to work with Neovim. That is 'till I noticed how much I dislike using vim. You see it has that learning curve that if you've stopped using it for awhile it's a struggle to do basic things. So I used a configuration that made it act more like normal editors. So problem solved? Unfortunately, most extensions are made for a normal vim settup not my easy mode settup. Plus, I started missing having simple things like scrollbars and tabs I could click on and move with the mouse. (I remember the graphical front end for Neovim not meeting these needs at the time.)

So ultimately, I just moved on and stayed with vscode. I would still like an alternative (kedit/k-develop looks promising). However, I'm sort of addicted to the plugins.

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

#125
post #72

I've tried all of them, and still prefer vim because it's the least hassle to install/configure anywhere - my dotfile setup installs my plugins automatically, and I'm set. However, I do use VSCode extensively as well, largely because of the language servers. But sometimes it takes so long to start up (and nags me to do so many updates to itself and extensions) that I just toss the window aside and use a native Mac ed…

Emacs can also install your packages/plugins automagically via the wonderfully designed use-package combined with MELPA. It's a game changer when it comes to managing an emacs configuration, especially if you work across a range of servers. Just copy the .emacs, install use-package manually and you're off to the races with anything and everything you need.

By the time I discovered use-package I couldn't believe that I had been tar-balling a mess of crap around all these years.

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

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

Naah, not really. I've done that emacs exercise countless of times over a few decades and now I use vscode. I don't feel like I'm missing much.

It is easy for people who love Emacs to believe that most people (or most programmers) would come to love (or prefer) Emacs if they would only put in the time to ascend the initial learning curve. But this belief is an instance of what is sometimes called the "typical-mind fallacy": an underestimation of how different people's minds are.

GNU Emacs was my daily driver from 1991 to late last year, when I switched to vscode. I wrote many lines of Emacs Lisp code -- 20,000 lines of which I "kept": I arranged for those lines to get loaded into Emacs every time Emacs starts, and since the code was almost all "UI" code, any particular function or piece of the code ran on average at least several times for every hour I spent using Emacs.

Although I do not regret choosing Emacs in 1991, vscode suits my particular mental make-up better than GNU Emacs did.

To take one example, I spent hours configuring Emacs to be less chatty. I turned off the bell that sounds every time the user makes an error (where for example asking Emacs to scroll down when the bottom of the document is already visible in the window is considered an "error" -- in contrast to vscode's not feeling the need to send a message to the user or get the user's attention when that happens). I tried (and mostly succeeded) in turning off the repetitive messages Emacs displays in the echo area, e.g., displaying "Wrote foo.c" any time Emacs writes to file foo.c and, e.g., (particularly distracting to my train of thought) the "Autosaving..." message that regularly appears in the Echo area X seconds after I stop typing. In contrast, vscode is silent (non-chatty) enough to suit me in its default configuration -- like most GUI apps since the introduction of the Macintosh in 1984 are.

P.S. The way I got rid of the "Autosaving..." message was to turn off Emacs's autosaving functionality altogether and add my own autosaving functionality, which consisted of a call to save-buffers every time the user switches buffers.

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

#127

Noob question: Is Sublime text still a good text-editor in 2021? Did it just loose momentum or not being open-source is insurmountable? I still think its speed and usability are not easy to match.

Sublime is a perfectly fine and frankly faster editor than VSCode. The problem is the slow nature of the updates, the underwhelming API and people abandoning it in droves because they opt for VSCode makes the extension library not as comprehensive or feature packed. Half the extensions I use in VSCode don't have a parallel in Sublime I still use it to quickly edit text or read some files quickly cause it opens really…

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.

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

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

>>The great thing about Emacs is that everything is a buffer[...]

> It frustrates me endlessly that this one simple, almost self-evident piece of Emacs wisdom failed to gain traction almost everywhere else. Even the venerable Vim drops the ball hard here, with the various "widgets" it uses in its interface which have slightly different semantics and behaviours.

Perhaps I don't understand emacs well enough, but I know that every file loaded in vim can be accessed via its buffer number. How it's displayed depends on the window and tab layout. Quickfix, help, and terminal buffers behave differently, but the vast majority of buffers are just associated with open files.

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

#129
post #75
post #65

VSCode has great and convenient language support, but the trade-off is reduced text editing efficiency, slower speed and more bloat. It is a worthy trade-off in many situations, I use it often when working on projects that are written in languages I am not too familiar with. I would like to emphasize how big of a game changer the next release of Neovim 0.5.0 will be. With builtin LSP support it will get code navigati…

That’s amazing news. Native LSP would be game changing. I use coc, but it takes a bit of messing about to get everything working smoothly. Also vscode has has a bunch of extra stuff beyond what’s available via LSP for python now, which is a shame because I’d love to get a full pyright + bells experience in vim.

Coc has coc-pyright extension. You don't have to use pyls. https://github.com/neoclide/coc.nvim/wiki/Using-coc-extensio... https://github.com/fannheyward/coc-pyright

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

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