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

171–180 of 353 posts

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

#171

Post by codethief »

submeta wrote: post #168
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.

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.

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

#172

Post by brutal_chaos_ »

tpush wrote: post #10
elagost wrote: 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…

Most people's moral values don't concern text editors, or software in general.

True. Though a lot of tech people value libre software to some extent, so morals can often come into play. Even for something as simple as a text editor.

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

#173

Post by yrimaxi »

elagost wrote: 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…

Yes. For example I don’t buy cereal because of my ethical stance of not wanting to feel bloated from a bowl of milk-and-starch.

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

#174

Post by jpeloquin »

higerordermap wrote: post #130
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 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 default argument. It feels like you're interacting with the commits directly, which makes it easier to reason through an interactive rebase or partial push. Simple rebases like reordering or squashing recent commits take only a few seconds.

3. It seems to mostly rely on calling the core git commands and parsing their text output. The core git commands are reliable. Many git clients will hang on large (> 200 GB) repos; magit doesn't. An exception is diff colorization, but if colorization is taking too long on a big diff, Ctrl-g will make magit fall back instantly to the plain diff.

4. Has decent submodule support, in that submodules can be interacted with much like commits in the parent repo.

5. Has git annex support. (Technically, I think this is provided by another package that extends magit.)

It's not really tailored to any particular git workflow as far as I can tell. The design intent seems to be that every displayed entity should be interactive, regardless of where it is displayed.

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

#175

Post by [deleted] »

submeta wrote: post #168
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.

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…

[deleted]

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

#176

Post by mhh__ »

sedev wrote: post #55
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…

From a recent HN discussion, I learned that emacs has had a sampling profiler built in — not on MELPA or something, first-party! — since about 2013. How many widely-used applications these days contain a facility for asking "why is the command I just issued executing slowly?" and for _doing something about it?_ As far as I'm concerned, that's now table stakes for a programming environment: you should be able to not j…

Automated profiling is one of the best things to get right over a few weekends. I'm slowly putting together something for the D language to do it but it's a bit of a pain.

Anyone know of CI service that can have use rdpmc/perf_events on the cheap?

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

#177

Post by u801e »

simias wrote: post #161
u801e wrote: post #128

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

I've been using vim for decades, but was not aware of the messages command. If it's anything like the version command or the K key for displaying the man page for a keyword under the cursor, that's also an annoyance of mine. It's also why I will redirect man page output to a standard buffer by running :r !man whatever in a new split window.

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

#178

Post by skjfdoslifjeifj »

the__alchemist wrote: post #77

I'm curious if the userbase of these have tried a Jetbrains IDE (PyCharm, CLion, IntelliJ etc). I've found the Jetbrains IDEs understand the language more thoroughly - this means better code navigation, error-catching, and refactoring. I've also found the implicit project-first focus (as opposed to file-first) to be more practical for most things I work on.

I still use IDEA Ultimate for Java but over the last few years I've fallen back to vim or vscode for basically everything else since the language servers for Python, Typescript, Go and Rust now provide most of the features that I actually use in Intellij.

Intellij's performance has never been good but it has continuously gotten worse over the years and it's bad enough now where I'll probably just cancel my subscription when it comes up for renewal.

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

#179

Post by u801e »

didibus wrote: post #160
u801e wrote: post #128

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

The netrw plugin that comes with the default installation of vim on many distros allows you to navigate the directory listing like a file, but it won't let you edit the text. The terminal buffer is similar, but you have to enter a special normal mode (ctrl-w N) in order to navigate the scrollback like a conventional buffer, but you can't change the contents of the buffer.

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

#180

Post by psYchotic »

submeta wrote: post #168
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.

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…

This may have been semirecently been added to git, but look into [0]: git add -i It launches a fairly simple interactive text UI that allows you to select files to stage, and it allows one to "patch" into the staging area, which works by showing you a bunch of hunks, asking for each if you want to stage it (or you can even edit a hunk in your $EDITOR).

I'm sure it's not nearly as nice as Magit's UI, but I've been a happy user of this feature for a while.

[0]: https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging

Post reply on HN