[Tagore]

I keep hearing good things about VSCode. If I weren't essentially married to emacs I'd definitely try it out. I'm not sure I'd recommend emacs to everyone at this point, though I think it remains a really solid choice of editor/OS for people willing to get over the learning curve and put up with a bit of clunkiness.

Re the git stuff though- one place that I'm pretty sure emacs is the uncontested champ is in git integration via magit. I'd be inclined to recommend using emacs as their git interface even to people who want to use a different interface for everything else. It is that good, and IMHO the only git porcelain that is strictly better than the standard git porcelain.

[kenbolton]

I started playing with emacs 24 years ago, then spent 20 years as a devoted vim user with a two year work-enforced gap in Eclipse. I tried spacemacs in evil mode about four years back and stayed for magit. I tried VSCode a few weeks ago to see what the fuss was about and had my Eclipse PTSD triggered. Magit, mu4e, elfeed, eww, multiterm, restclient.el, tramp, [edit]org-mode![/edit], the list of replacements for bloated "native"- and surveilling web-apps keeps growing. I mentor an up-and-coming developer who has learned more– about git, the filesystem, shells –in four weeks of using spacemacs than the 23 months of using Atom and VSCode. I know emacs in evil mode makes me smarter and more productive, and I'm seeing anecdotal corroborating evidence in my community.

[Tagore]

There's an old joke: "Emacs is a great OS, but it lacks a decent text editor." Only vi users are allowed to tell that joke with a straight face, IMHO.

Evil-mode solves that, and just as magit is better than git evil-mode seems, to me, better than vi. Emacs is better than ever (though you do need to use auto-formatting for languages like JS that change a lot- there is no emacs mode that has kept up with ES whatever. Luckily emacs makes it easy to use formatters like prettier on a per-buffer basis.)

[kenbolton]

> "Emacs is a great OS, but it lacks a decent text editor." > Only vi users are allowed to tell that joke with a straight > face, IMHO.

Emacs users can tell that joke, but they have deliver it with a wry smile. Evil-mode users can tell that joke with a knowing laugh.

[brlewis]

Tide works well with typescript, which I find better than ES whatever.

[YetAnotherNick]

I am using vim for years now, and I haven't written more than 50 lines of vimscript apart from the bundles. Most of the thing that I have written is just maps, some configuration for other bundles, and some copied better defaults. I still don't get it when people say they heavily use elisp. Can anyone give example of a highly custom thing that you do in emacs/vim/any other editor, for which there is no famous bundle available.

[kenbolton]

The question is not elisp v. vimscript but rather the power of not having to switch contexts. To write code for a locally-hosted RESTful API I used Chrome to read the API docs, Postman to make the calls, iTerm2 to start/restart the server and read the logs, and a text editor to make changes. I replaced that flow with eww, restclient.el (amazing!), multiterm, and an editor buffer. No changing of context, conserve about ~1GB RAM in Chrome instances, full-screen if I want it, and everything is text (I'm looking at you, Postman).

On the "highly custom" level, I have a work-in-progress script that takes a URL, sends it to a Splash server, and returns the rendered HTML to eww for viewing. This is great for annoying SPAs like the article that spawned this conversation.

My current goal is to swap out my development MBP with an eInk tablet and bluetooth keyboard. Success will be measured as a function of productivity and weather-/water-/environment-proofing of the device; the goal is productivity in full sunlight and/or under water. Emacs will have a central role in that. Just need to find an eInk device with adequate screen refresh rate and Bluetooth support....

[figgis]

Not downplaying your choices but throwing this out there. Vim can and does all of that as well.

vim $DOCUMENTATION_URL (curls the page and opens in vim)

vim-rest-console

:terminal (new!..ish. Works great.)

[dangom]

I'm using Org Mode to write my thesis and, although most of the functionality I use comes from vanilla org mode, I do need to write some Elisp to get the LaTeX export working properly, and to knit different projects together into a single one. As another example, it took me less than 30 lines of Elisp to get Apple Music incremental searching from within Emacs. A highly custom thing that I don't get elsewhere.

[bhrgunatha]

I think you've assumed the wrong premise. At least for me. It's not the highly customised things, it's the accumulation of the small things that are either missing, inconvenient, slightly annoying or somewhat different to your needs.

Every package developer makes choices about how their package works (and built-in behaviour too), but sometimes that clashes with what you want, or is somehow inadequate.

It's those small conveniences that have a disproportionate impact.

I'm not saying you can't do similar in vim or there aren't other ways to achieve the same goal, I'm saying that over time, those minor improvements have a huge impact.

Here's 2 examples:

1) Splitting a window horizontally by default splits 50:50 but on a 16:9 monitor I usually want the new buffer (right) to be smaller than my current buffer (left). So I override the defaults.

2) I use paredit for lisp based languages, but (as far as I'm aware) there's no built in-command to copy (or paste) the s-expression surrounding the cursor's current position.

I often find myself wanting to do exactly that e.g. in a let or a cond form in Racket. So I wrote a couple of small functions to do just that, bound them to keyboard shortcuts and I've now made a minor extension that fits exactly what I want to do. Since lisp is based on s-expressions it turns out this extension to someone else's package is incredibly versatile and useful.... TO ME!

    (let [<CURSOR>(x (some-function with args)] 

I press my chosen key-combination and it becomes

    (let [(x (some-function with args)] 
         [<CURSOR>(x (some-function with args)] 

ready to edit the new s-expression

[kazinator]

In vim, when you're in visual selection mode, you can type `ib` (inner block) to select the innermost parenthesized block's interior or `ab` to include the parentheses. If you type these commands multiple times, the selection widens to the next, next, next ... enclosure.

There are other similar commands in the category, like a" for selecting the interior of a double-quoted literal and such.

They are documented under ":help visual-operators".

[xfer]

I occasionally use elisp while replacing with regex(you can do computation on captured strings), can you do this in vim?

[YetAnotherNick]

Yes, select in visual mode type :! and it gets processed by a unix command.

[cjauvin]

I wholeheartedly agree: Magit is that good, really. The way I see it, it reduces the burden associated with carrying the required git mental model in your mind, by giving you easier points of entry into its complexity. I owe all the slightly more advanced things I now routinely do with git (which would probably be seen as pretty basic by a lot of people though) to Magit, without question.

[Tagore]

Yep- I was reminded of how much I like magit by this thread so I just made a $100.00 donation to its development. I hope it inspires other people to at least give magit a try (if I'll donate that much it must be good, right?)

[Tagore]

Yep- I'm actually a pretty old hand when it comes to git, and I know most of what git can do, but... I'm lazy, so when I use git at the command line I do caveman git. Magit lets me remain lazy and do subtle git things,

[abritinthebay]

I'd say it's uncontested if you like using emacs. Because - for me - it's awful. Mostly because I find using vim or emacs awful and only use either of them when I absolutely can't avoid it.

But that said - it does it's job very well and magit is certainly excellent software for those that are interested in that interface.

[Tagore]

No... I mean I hear you about not liking emacs/vim/evil-emacs. I happen to like evil-emacs, but I can see why other people would prefer VSCode. That's a matter of taste, and I won't tell people to switch.

But when it comes to magit I'm not so sure. I'm inclined to think that magit is _strictly_ better than any other git interface, so much so that even if you don't like emacs you should suck it up and use magit as your git porcelain, even if you use a different editor for everything else. Magit is that good- I just gave $100.00 to the project, and I never donate to open source stuff. It is that good.

[abritinthebay]

Again - having used Magit because I heard the same effusive praise - it’s goddamn awful if you don’t like using emacs.

I don’t mean “it’s not my preferred git client”. I mean “I’d rather use almost anything else”.

Why? Because it requires emacs interface, concepts, and controls. And unless you’re ok with those it’s not better at all. In fact it’s _strictly_ worse.

That said: if you like emacs I think you’re correct, it’s almost certainly the best there is.

[whatyoucantsay]

I think it's genetic. Whatever allele is responsible for emacs affinity, some people have it. It never ceases to amaze me how early in their studies they latch onto emacs and start doing increasing amounts of their computing through it.

Others, such as myself, suffer it only when compelled by an instructor.

[SZJX]

IMO it certainly takes some learning curve to get up to speed with the keybindings and concepts. In the beginning anybody would struggle but after the learning efforts you'd find it to be much more productive than the other editors.