Live data from Hacker News

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

murilopereira.com

181–190 of 353 posts

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

#181
post #73
post #51

Earlier quoted context omitted.

I tend to let other people "master and config" VSCode and then I just go download their extensions. IMO that's the beauty of VSCode - critical mass

That's also available with emacs, though, it has its own extension ecosystem that's about as easy to access as VSCode's.

Yeah no, emacs package system is a giant mess, it's only "easy" if you've already drunk the emacs kool aid.

Sorry I just really hate emacs.

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

#182

Earlier quoted context omitted.

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

How about $ git add -p path/to/the/file ? Combine this with your favorite tool for command line auto-completion of paths (and, maybe, a git alias to avoid typing `git add -p` all the time) and it's extremely fast.

I am presented with one hunk at a time, and have to decide if I want to stage or not (with a text "menu" underneath it: "(2/2) Stage this hunk [y,n,q,a,d,k,K,g,/,e,?]?"

And then I navigate with j/k (down/up).

Yes, it does the job. Matter of preference.

But if you worked eagerly on three / four different topics and try next to create several different commits by getting a visual overview of all hunks with the abilitiy to selectively stage is a little more comfortable.

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

#183

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…

I do something like this in VSCode as well, Markdown todo lists:

  - [ ] Task 1

    - [ ] Task 1.1

      - [x] Task 1.1.1

    - [ ] Task 1.2
etc.

In particular, I break down yearly goals into quarterly, monthly, weekly and daily, each another node in the tree getting increasingly more specific.

It really helps understand the flow from the highest to the lowest levels of details. Only problem is if goals change midway, it's not propagating up the tree automatically. I just leave it like that though, not gonna manually fix that.

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

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

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 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 and Emacs. WSL2 is intolerably broken when working on NTFS folders, so it's a nonstarter. This means Docker is broken (mounts don't work) but Emacs works well.

Yah, it sucks.

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

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

I'm a long time Emacs user and just recently I have been learning and using neovim a lot. This is the most jarring difference between Emacs and other editors. The second biggest issue is Lua instead of Emacs Lisp. s-expressions work so well in the editor extension context. Steve Yegge wrote a really nice million word essay on this topic.

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

#187

Earlier quoted context omitted.

I don't quite "get" magit, can someone tell what's great about it / for what type of git workflow?

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.

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

#189

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.

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.

> The right direction according to who?

You are asking the right question, but it applies to your comment equally well.

> For 99% of users, org-mode, magit and a pure terminal interface are not hard requirements.

You are narrowly picking the set of users to suit your comment. For 99% of users, code completion, syntax highlighting, etc are not requirements either, because 99% of users do not program.

In retrospect, it should be obvious that Emacs users are heavily weighted towards using org mode, because that's part of Emacs's value proposition. It makes sense that most VSCode users do not need/want org mode, because otherwise they'd be using Emacs, and not VSCode.

In almost every thread about Emacs, I always find the comparisons with VSCode amusing, given that the two programs serve very different purposes. The bulk of my Emacs usage has nothing to do with coding, so I personally don't see the value of comparing it with VSCode, and pointing out that VSCode is better is sort of irrelevant. Of course, this being HN, there is a programming bias. But it's the equivalent of saying "mplayer sucks because it cannot do video editing as good as some video editing tool."[1] It's great that you have found a good video editing tool, but that tool doesn't do much of what I use mplayer for.

[1] mplayer has extremely rudimentary video editing capabilities,

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

#190

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

Well with wsl2 I gave windows a go for my work dev environment. And so far emacs had been amazing via wsl2 and a x server.

I should note I did modify the xserver to allow me to toggle individual windows going fullsceen. And am running native emacs (which is blazing fast)

Post reply on HN