Derfor valgte han Emacs over Vim: - Diskuterer ikke editorer, men ideologi

- For meg er DOTADIW-tankegangen et prinsipp som kun hører hjemme i kommando-linja.

Systemutvikler Martin Klingenberg i Alv velger Emacs som sin kode-editor. 📸: Privat
Systemutvikler Martin Klingenberg i Alv velger Emacs som sin kode-editor. 📸: Privat Vis mer

Vi nerder har mange evig-varende diskusjoner: Xbox eller Playstation, Mac eller PC, tabs eller mellomrom?

Ingen av de diskusjonene kan måle seg med Emacs eller Vim diskusjonen, som har foregått siden 1985 (i følge wikipedia, som aldri tar feil).

Jeg har holdt med Vim / Neovim siden 2014, men dette fikk meg til å skifte side.

Ville kalt Emacs bloated

Når man snakker om Emacs vs Vim, så diskuterer man egentlig ikke editorer i det hele tatt; man diskuterer en ideologisk retning.

På Vim-siden har man en editor som bare er en editor, ikke mer ikke mindre. Mange vil si at Vim følger Do One Thing And Do It Well-prinsippet (DOTADIW) som lenge gjennomsyret Linux-miljøet.

Emacs på den andre siden er så mye mer enn en editor. Ut av boksen har Emacs en package manager, en enkel nettleser og har et grensesnitt som ikke krever en terminal for å fungere.

En Vim-fan vil kalle Emacs bloated, jeg hadde vært enig om jeg brukte en gammel maskin med lite ressurser. Det er jo ikke tilfellet, og Emacs er nå en relativt lett editor sammenlignet med Electron-baserte editorer som Atom eller VSCode.

For meg er DOTADIW-tankegangen et prinsipp som kun hører hjemme i kommando-linja, og ikke skal brukes når man snakker om komplekse applikasjoner. Det er ikke bare jeg som har denne meningen, man ser stadig stadig flere eksempler på dette i Linux-miljøet.

Et godt eksempel er hvor utbredt Systemd har blitt blandt Linux-distribusjoner. En Vim-bruker vil på grunn av prinsippfasthet aldri kunne kjenne hvor fantastisk det er å ha en live markdown preview i editoren.

«En vim-bruker vil på gunn av prinsippfasthet aldri kunne kjenne hvor fantastisk det er å ha en live markdown preview i editoren.»

LSP og DAP gjør alle editorer like smarte

Language Server Protocol (LSP) og Debug Adapter Protocol (DAP) er standariserte protokoller laget av Microsoft. LSP standardiserer autocompletion, linting og kode-navigering, og DAP gjør tilsvarende for debugging.

LSP-pakker finner man i alle editorer med respekt for seg selv. Dermed er autocompletion helt likt for Vim, Emacs og VSCode.

Nå det kommer til debugging, kan ikke Vim sammenligne seg med Emacs eller VSCode. Oppsettet for å debugge i Vim er tungvindt og fungerer sjelden godt nok. Emacs på den andre siden er helt fantastisk å bruke: Grensesnittet er utrolig enkelt å bruke, og jeg har hatt gode opplevelser når jeg har debugget både .Net, Node, og Golang.

Bildet under viser hvor god debuggeren faktisk er.

Debugging av Golang. 📸: Privat
Debugging av Golang. 📸: Privat Vis mer

Flere begrensninger

Vim er ikke selv ansvarlig for å rendre grensesnittet, og det gjør at Vim bare er så god som terminalen den kjører i.

En terminal er ikke designet for å visualisere grensesnitt. Trivielle ting som å vise bilder, fonter i forskjellige størrelser og flere farger enn 256 er ikke lett å få til.

Disse begrensningene har ikke Emacs, og selv om man kan kjøre Emacs i terminalen, så ser jeg ingen grunn til å gjøre det.

Asynkron prosessering

Noe som har plaget meg i Vim/NVim, er mangelen på asynkron prosessering.

Moderne versjoner av Vim og NeoVim reklamerer med støtte for asynkron prosessering, men det er dessverre slik at veldig mange plugins ikke er asynkrone.

Det gjør at man til tider opplever at man låser hele grensesnittet.

Raskere oppsett

Det tar lang tid å sette opp Emacs eller Vim helt etter sin egen smak.

Config-en min har sitt eget repo og har blitt tweaket i mange år. Akkurat nå vet jeg ikke om jeg er villig til å investere så mye tid til å sette opp noe slikt igjen.

Heldigvis finnes det en snarvei. Det finnes et par distribusjoner av Emacs som man kan sette opp i løpet av minutter. Mest kjent er spacemacs og doom-emacs.

Etter å ha basert meg på doom-emacs, og et par timer med knoting, så hadde jeg en editor som jeg kan bruke for all koden jeg skriver i det daglige.

Distribusjonene er enkle å sette opp, og er gjerne delt inn i lag, slik at du kan inkludere bare det du måtte ønske av funksjonalitet. Man kan selvfølgelig hacke til config-en etter eget ønske.

Vim er ikke helt forlatt

Jeg trives veldig god i kommando-linja, og for å redigere noe raskt, så vil Vim alltid være korteste vei til mål.

Men når det kommer til å skrive kode, så vil jeg holde meg med Emacs.

PS: Om noen er intressert i Vim-configen min, så finner dere den her. 😉