6 ms·

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

by oefrha 6y ago

> 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, and on top of that, great performance and a cohesive user experience. These days I mostly use VSCode due to great language server integration (Pylance, gopls, rust-analyzer, etc.), but I still rely on Emacs with Magit for almost all my git interactions. This is not helped by VSCode's shitty commit message box, which after five years is still this ~250x20px by default input field with some after-the-fact validation tossed in. The great thing about Emacs is that everything is a buffer, you get the full editing power afforded by a buffer, not some second-class input field, especially for something as important as commit messages.

africanboy 6y ago
I use this for git interactions in VSCode https://github.com/kahole/edamagit https://github.com/kahole/edamagit
- oefrha 6y ago
  Interesting, I’ll check it out, thanks.
- thom 6y ago
  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.
aldanor 6y ago
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.
- beojan 6y ago
  Try Doom Emacs (https://github.com/hlissner/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.
  - slightwinder 6y ago
    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.
    - moocowtruck 6y ago
      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
- perryizgr8 6y ago
  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 6y ago
    [deleted]
  - kubanczyk 6y ago
    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.
mplanchard 6y ago
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.
simias 6y ago
>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.
- u801e 6y ago
  >>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.
  - didibus 6y ago
    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.
    - u801e 6y ago
      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.
marcmarc 6y ago
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))

by oefrha 6y ago

africanboy 6y ago

I use this for git interactions in VSCode https://github.com/kahole/edamagit https://github.com/kahole/edamagit

oefrha 6y ago
Interesting, I’ll check it out, thanks.
thom 6y ago
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.

aldanor 6y ago

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.

beojan 6y ago
Try Doom Emacs (https://github.com/hlissner/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.
- slightwinder 6y ago
  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.
  - moocowtruck 6y ago
    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
perryizgr8 6y ago
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 6y ago
  [deleted]
- kubanczyk 6y ago
  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.

mplanchard 6y ago

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.

simias 6y ago

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

u801e 6y ago
>>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.
- didibus 6y ago
  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.
  - u801e 6y ago
    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.

marcmarc 6y ago

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