/

/

- Jeg velger Emacs over Vim

/

/

- Jeg velger Emacs over Vim

/

/

- Jeg velger Emacs over Vim

/

/

- Jeg velger Emacs over Vim

Vårt delingshjørne

- Jeg velger Emacs over Vim

- Jeg velger Emacs over Vim

- Jeg velger Emacs over Vim

Martin

Klingenberg

Systemutvikler

Systemutvikler

1. desember 2021

Utvikling

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 hva fikk meg til å skifte side.


DOTADIW

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 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 endig 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å gunn 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 kraftige

Language Server Protocol og Debug Adapter Protocol 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 har hatt gode opplevelser når jeg har debugget både .Net, Node, og Golang. Bildet under viser hvor god debuggeren faktisk er.


Bedre grensesnitt

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


Batterier inkludert

Det tar lang tid å sette opp emacs eller vim helt etter sin egen smak, vim-configen 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 configen 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 med Emacs.

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

Kanskje du liker:

Kanskje du liker:

Kanskje du liker:

Utvikling

18. desember 2024

Her er det jeg har lært så langt (fra nivå1-dårlig til nivå8-ninja) 

Utvikling

18. desember 2024

Her er det jeg har lært så langt (fra nivå1-dårlig til nivå8-ninja) 

Utvikling

21. april 2024

.net 8 med nye Identity Endpoints oppsett. Vi har tatt en en nærmere titt på det. Er Identity API Endpoints i .net 8 kroken på døra for tredjepartsautentisering?

Utvikling

21. april 2024

.net 8 med nye Identity Endpoints oppsett. Vi har tatt en en nærmere titt på det. Er Identity API Endpoints i .net 8 kroken på døra for tredjepartsautentisering?

Utvikling

1. mars 2024

Mange tenker på Techlead kun som en flink utvikler, mens Techleadene selv ofte tenker på seg selv som et teknisk orakel som bør bestemme det meste. Begge disse ytterpunktene står i veien for god verdiskaping. 

Utvikling

1. mars 2024

Mange tenker på Techlead kun som en flink utvikler, mens Techleadene selv ofte tenker på seg selv som et teknisk orakel som bør bestemme det meste. Begge disse ytterpunktene står i veien for god verdiskaping. 

Utvikling

18. desember 2024

Her er det jeg har lært så langt (fra nivå1-dårlig til nivå8-ninja) 

Utvikling

21. april 2024

.net 8 med nye Identity Endpoints oppsett. Vi har tatt en en nærmere titt på det. Er Identity API Endpoints i .net 8 kroken på døra for tredjepartsautentisering?

Utvikling

18. desember 2024

Her er det jeg har lært så langt (fra nivå1-dårlig til nivå8-ninja) 

Utvikling

21. april 2024

.net 8 med nye Identity Endpoints oppsett. Vi har tatt en en nærmere titt på det. Er Identity API Endpoints i .net 8 kroken på døra for tredjepartsautentisering?

Footer Logo

Når riktig partner utgjør all forskjell



822 704 042

Pløens gate 7

0181 Oslo

hei@alv.no

+47 91 92 92 18

Copyright ©2024. All rights reserved.

Footer Logo

Når riktig partner utgjør all forskjell



822 704 042

Pløens gate 7

0181 Oslo

hei@alv.no

+47 91 92 92 18

Copyright ©2024. All rights reserved.

Footer Logo

Når riktig partner utgjør all forskjell



822 704 042

Pløens gate 7

0181 Oslo

hei@alv.no

+47 91 92 92 18

Copyright ©2024. All rights reserved.

Footer Logo

Når riktig partner utgjør all forskjell



822 704 042

Pløens gate 7

0181 Oslo

hei@alv.no

+47 91 92 92 18

Copyright ©2024. All rights reserved.