Hacker News Reader

>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 paste, every time I have a crappy edit box lacking basic editing capabilities, every time I get some large text dump I can't search through with normal editing commands, every single time that happens I pray to the altar of RMS for him to smite the heathens and bring us to the age of enlightenment.

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

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.

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.

You can redirect stuff to a register with the following dance:

:redir "a :messages :redir END

Then, you can just paste from that register using "ap.

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.

Have you looked into fennel? Is it possible to use that within neovim?

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 created; Magit in evil-mode easily beats all of the 20+ git clients I've used. So I keep emacs/spacemacs on every machine now solely to be able to use magit.

Try Doom Emacs (https://github.com/hlissner/doom-emacs) instead of Spacemacs. It's much lighter weight and doesn't replace the configuration system to nearly the extent Spacemacs does.

Doom is not really better than spacemacs. It's just the same pain in a different flavor. Sure, in the micro-cosm of emacs it's pretty good, but in the macro-cosm it's still a pain and can't lift the limitations and problems of emacs.

sincerely curious, what are the limitations and problems of emacs? I use both vs code and emacs. I've been using vs code a bit more these days because I feel like the UI itself is a bit more powerful and modern. I've also come to like that If i want a language support it often installs all the things I'd want to make a good experience, and I have less to mix and match. I like the mix and match approach I've always used in emacs, but it turns out there fewer scenario where I want that power then I'd have thought, and more where I just want some out of the box functionality from an extension author

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.

Git CLI is fantástico if you want to do two things per hour. If you want to do twenty, it's just too many keystrokes. Even if we only talk basic add/commit/push.

Two especially laborious operations are `git add -p` and `git rebase -i`. Try them out on magit, you'll see the difference.

git gui is way to go.

Nothing's wrong with using CLI. You might not need it, but sometimes it's nice to have something with more. Most people on this planet think that managing files from terminal is pure insanity, and I do just that, I didn't even bothered to install a graphical file manager. And yet I use a git client/front-end in my text editor, because it's nicer to do some things that way. The most useful feature is probably interactively staging hunks just like you'd edit a text file over what standard git does.

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?

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.

If you have multiple files then you can choose to omit the file name and git will let you decide on each hunk for each file.

You can also hit "s" to split a hunk to only commit a part of a hunk of if you want fine grained control you can hit "e" to edit just that hunk in your $EDITOR to only select a specific line or whatever you want.

Personally I tried fugitive and other git clients in the past and always come back to git add -p on the command line. It just feels the most natural and it also forces you to look at the hunks, so there's really no chance you'll accidentally forget to add something.

When using GUIs with sidebars showing what files changed, etc. it's easy to forget to add something because you skim it without really paying attention to what was changed.

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

Try Magit. You’ll know whether it works for you. It clearly does for many people.

Or fugitive in Vim.

The difference is like that between using Ed and Vi. Seeing things as you do them is valuable.

imo the strength of Magit (and its author has certainly said so) is that while the Git CLI provides a slightly different interface that you have to learn for each different operation, Magit provides a consistent UI for every single Git operation it supports (around 90% of Git features).

Completely agree that magit is superb. The fantastic integration with git forges to check out PR branches as worktrees has really been a game changer for me. I can see what PRs are open, create a worktree with fuzzy selection on PR branches, and then switch to that worktree to review changes in ediff.

I use Emacs inside VSCode's terminal just for Magit. And I've configured Emacs to open directly with the magit-status buffer. It beats all the VSCode extensions I have tested.

  (when (string-match "code" default-directory)
    (magit-status)
    (delete-other-windows))
  (with-eval-after-load 'magit
    (define-key magit-status-mode-map (kbd "q") 'save-buffers-kill-terminal))

I use this for git interactions in VSCode

https://github.com/kahole/edamagit

Interesting, I’ll check it out, thanks.

I have found this mostly good enough that it gives me hope for VSCode. I wish more extensions took inspiration from Emacs and were implemented in texty ways as editor windows though.