Live data from Hacker News

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

murilopereira.com

151–160 of 353 posts

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

#151
post #9

This is really well written and researched but confuses me. Do most people not do this - make choices based on values (and constantly re-evaluate those choices in the face of new information)? 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…

I don’t have any values that would affect the cereal I buy. I’m not even sure what values would come into play. I don’t buy cereal that isn’t magically delicious? I just buy whatever is cheapest. Is not having much money a value? 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…

> I don’t have any values that would affect the cereal I buy.

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

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

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

> When you finally learn to master

s/When/If

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

#153

Earlier quoted context omitted.

Literally anything you can do in emcas there is an extension for or at least one in dev. Vscode will outgrow emcas given its critics mass and momentum.

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.

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

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

> When you finally learn to master and config Emacs, you run circles around all other editors. 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.

pluma is nice, I used it for a really long time but in the end having a linter integrated into my editor sold me on VSCode

I do still use pluma for just quickly editing files though, but for coding I use vscode now

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

#155

Earlier quoted context omitted.

Literally anything you can do in emcas there is an extension for or at least one in dev. Vscode will outgrow emcas given its critics mass and momentum.

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.

The right direction according to who?

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.

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

#156
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'm on the same boat as you. I love Emacs, the uniform keybindings and especially Magit, I thought I could never use anything else until I started working with TypeScript React in my current job, which Emacs has very bad support for.

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

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

#157
post #97

Earlier quoted context omitted.

I’m kinda in love with VSCode at the moment, even though I have used Emacs (or at least some mac customized version, maybe SpaceEmacs?) for agda-mode 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 unfa…

I do admit VSCode is a very polished product. Just like the other tools I mentioned (PyCharm, Kaleidoscope for diffs, Tower App as git client etc). 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 t…

>Magnar Sveen started doing this several years ago (emacsrock.com)

Great comment! But you were missing an s in this FQDN. Here's a working link: http://emacsrocks.com/

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

#158
Until an editor comes along that is as extensible and keyboard efficient as emacs with lsp integration, or I get one of those combination mouse/ergonomic keyboard contraptions, I'll stay there.

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.

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

#159

Earlier quoted context omitted.

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

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 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
If we replace "find car keys" above with a string of text too long to fit on one line, then the basic structure of the small hierarchy becomes obscured in Emacs (even with visual-line mode on) but not in vscode as I explain in greater detail here:

https://news.ycombinator.com/item?id=25311743

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

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

Emacs buffers don't need to be 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.

Post reply on HN