Software-update: Vim 9.2

Versie 9.2 van Vi IMproved, oftewel Vim, is kort geleden uitgekomen. Deze universele editor is ooit door Bram Moolenaar voor de Commodore Amiga ontwikkeld, maar is tegenwoordig ook voor Unix, Linux, macOS, OS/2, DOS en Windows beschikbaar. Vim wordt niet actief ontwikkeld en meestal zitten er een paar jaar tussen de verschillende versies. De releasenotes voor deze uitgave kunnen hieronder worden gevonden.

New Features in Vim 9.2

• Comprehensive Completion: Added support for fuzzy matching during insert-mode completion and the ability to complete words directly from registers (CTRL-X CTRL-R). New 'completeopt' flags like nosort and nearest offer finer control over how matches are displayed and ordered.
• Modern Platform Support: Full support for the Wayland UI and clipboard has been added. On Linux and Unix-like systems, Vim now adheres to the XDG Base Directory Specification, using $HOME/.config/vim for user configuration.
• UI Enhancements: A new vertical tabpanel provides an alternative to the horizontal tabline. The MS-Windows GUI now supports native dark mode for the menu and title bars, along with improved fullscreen support and higher-quality toolbar icons.
• Interactive Learning: A new built-in interactive tutor plugin (started via :Tutor) provides a modernized learning experience beyond the traditional vimtutor.

Vim9 Script Evolution

Significant language enhancements including native support for Enums, Generic functions, and the Tuple data type. Built-in functions are now integrated as object methods, and classes now support protected _new() methods and :defcompile for full method compilation.

Diff Improvements

Vim 9.2 introduces significant enhancements to how changes are visualized and aligned in diff mode:

• Linematch Algorithm: Includes the "linematch" algorithm for the 'diffopt' setting. This aligns changes between buffers on similar lines, greatly improving diff highlighting accuracy.
• Diff Anchors: The new 'diffanchors' option allows you to specify anchor points (comma-separated addresses) to split and independently diff buffer sections, ensuring better alignment in complex files.
• Inline Highlighting: Improves highlighting for changes within a line. This is configurable via the "inline" sub-option for 'diffopt'. Note that "inline:simple" has been added to the default 'diffopt' value.

Changed Default Values

Several long-standing defaults have been updated to better suit modern hardware and workflows. These values have been removed from defaults.vim as they are now the internal defaults.

Other Improvements and Changes

Many bugs have been fixed since the release of Vim 9.1, including security vulnerabilities, memory leaks and potential crashes.

• See the helpfile for other improvements: :h new-other-9.2
• Changes to existing behaviour is documented at: :h changed-9.2
• A few new functions, autocommands, ex commands and options have been added: :h added-9.2
• The full list of patches is documented at: :h patches-9.2

Versienummer	9.2
Releasestatus	Final
Besturingssystemen	Linux, BSD, macOS, Solaris, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11, Windows Server 2022, Windows Server 2025
Website	Vim
Download	https://www.vim.org/download.php
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (41)

[pven]

Ik kan lezen en schrijven met vi op Linux. Maar met vim op Windows kan ik gewoon niet overweg. Ik zocht een alternatief voor Notepad++, maar vim gaat dat zeker niet worden.

[kdekker]

Echt? Volgens mij is vi op Linux gewoon vim. Ik merk eigenlijk geen verschil met Linux.

Notepad++ is veel meer gui (dwz ik ken daar de toetsenbord combinaties niet, dus muis gebruiken). Bij vi gebruik je eigenlijk geen muis (in gvim kan dat weer wel). Tja, van de heel veel toetsencombinaties gebruik je toch maar een beperkte set. Dat geldt ook voor mij daily IDE (Visual Studio). Waar toch ook wel heel wat toetscombinaties weer afwijken van Visual Code. Mij ervaring is dat je altijd daily-editor de toetscombinaties het beste onthoudt.

[Room42]

Volgens mij is vi op Linux gewoon vim. Ik merk eigenlijk geen verschil met Linux.

Op veel distros is vi een symlink naar vim. Maar er zit wel degelijk verschil tussen de echte vi en vim.

[rbr320]

Er zit zeker verschil in, maar in feite is Vim functioneel een superset van Vi. Als Vim wordt opgestart middels het "vi" command, door middel van een symlink of op een andere manier, dan gaat Vim in vi-mode en gedraagt het zich vrijwel identiek aan het originele vi.

[Opifex]

dan gaat Vim in vi-mode en gedraagt het zich vrijwel identiek aan het originele vi.

Wat bedoel je in deze context met Vi-mode?

Vi-mode is doorgaans een term die men gebruikt wanneer men met een plugin een andere editor (bvb. visual studio) zich min-of-meer laat gedragen als Vi. Vim zelf heeft altijd dat gedrag dus kan volgens mij nooit in Vi-mode zitten. Het heeft uiteraard intern wel verschillende modes: Normal-mode, Visual-mode, Insert-mode, ...

Hier kan je meer lezen over de verschillende modes en wat ze doen: https://www.warp.dev/terminus/vim-modes

Ik ben het overigens zeker niet eens met je stelling dat Vim zich identiek gedraagt aan Vi. (C.f.r andere comment hieronder)

[Reactie gewijzigd door Opifex op 15 februari 2026 14:13]

[rbr320]

Wat bedoel je in deze context met Vi-mode?

[...]

Ik ben het overigens zeker niet eens met je stelling dat Vim zich identiek gedraagt aan Vi. (C.f.r andere comment hieronder)

Dat is dus wat ik bedoel. Vim lijkt in veel opzichten op Vi, maar gedraagt zich zeker niet identiek. Als Vim (of vim-tiny) echter wordt opgestart als "vi" door middel van een symlink gedraagt het zich wel (vrijwel) identiek aan het originele Vi.

[kdekker]

Bij opstarten 'weet' vim aan de hand van het opstart commando dat deze in 'vi-modus' draait. Ik zou echter zo 1-2-3 niet de verschillen weten. De vi-mode is een beperktere set en vim kan alles wat vi kan. Het zou me verbazen dat vim-in-vi mode niet de vim extra's ondersteunt.

[rbr320]

Toch is het zo, want ik ben er wel eens tegenaan gelopen
Ik zou nu echt niet meer weten wat het precies was, maar er zijn features die Vim juist "improved" maken en dus niet worden ondersteund in Vi, ook niet als die Vi onder water gewoon stiekem Vim of vim-tiny is.

Volgens dit antwoord kan je hetzelfde effect bereiken door in Vim ":set compatible" te gebruiken.

[nullbyte]

Totdat je een text bestand in een container wil bekijken en er achter komt dat vim niets doet, whereis vim? vi dus.

Zelf zet ik graag ms edit voor Linux op mijn repo server, MS doet weinig goed de laatste tijd, dit is een zeldzame uitzondering.
Ik kan uitstekend met vim overweg. Maar het afwisselen is leuk, het is weer eens even wat anders. Totdat ik het zat wordt om uit automatisme :q! in te typen wat ik zelfs in notepad++ blijf proberen

https://github.com/microsoft/edit

[Reactie gewijzigd door nullbyte op 16 februari 2026 00:19]

[Opifex]

Volgens mij is vi op Linux gewoon vim.

Ja absoluut niet dus... Vim staat voor Vi-Improved. Met Vi kan je in de verste verte niet wat je met Vim kan. Vi is een heel basic editor, in het genre van Nano e.d. terwijl Vim een editor is die een extreem hoge graad van automatisatie toelaat.

Zoals Room42 al aangaf is Vi op de meeste moderne distro's een symlink naar Vim, maar als we naar Embedded Linux systemen gaan dan is Vi nog heel erg vaak de "echte" Vi.

[rbr320]

Zoals Room42 al aangaf is Vi op de meeste moderne distro's een symlink naar Vim, maar als we naar Embedded Linux systemen gaan dan is Vi nog heel erg vaak de "echte" Vi.

Weet je dat wel zeker? Het originele Vi wordt niet tot nauwelijks nog ontwikkeld. Ik kan me goed voorstellen dat het tegenwoordig vaak vervangen wordt door vim-tiny, wat zich gedraagt als Vi als je het opstart door middel van een symlink die "vi" zoals ik hier ook uitleg.

[Opifex]

Weet je dat wel zeker?

Nogal, ja. Het is niet bepaald een groot geheim.

Vi was oorspronkelijk (in 1976) een speciale mode in de `ex` editor. Later werd het een project op zich. website , repository
Vi was echter heel rudimentair. Daarom maakte Bram Moolenaar in 1992 een verbeterde versie: "Vi - Improved", kortweg Vim. website , repository
Sindsdien zijn er uiteraard al tientallen andere varianten opgedoken. De bekendste neovim zijnde. Elk is een project op zich met andere maintainers, andere goals, andere ontwikkelingen.

Het originele Vi wordt niet tot nauwelijks nog ontwikkeld.

MS-DOS wordt ook niet meer ontwikkeld. Je kan dan toch ook niet zeggen dat DOS en Windows 11 dezelfde software is?

Ik kan me goed voorstellen dat het tegenwoordig vaak vervangen wordt door vim-tiny, wat zich gedraagt als Vi als je het opstart door middel van een symlink die "vi" zoals ik hier ook uitleg.

In welke distro wordt vi of vim by default vervangen door vim-tiny? Is werkelijk het eerste dat ik er van hoor.

[rbr320]

Nogal, ja. Het is niet bepaald een groot geheim.

Vi was oorspronkelijk (in 1976) een speciale mode in de `ex` editor. Later werd het een project op zich. website , repository
Vi was echter heel rudimentair. Daarom maakte Bram Moolenaar in 1992 een verbeterde versie: "Vi - Improved", kortweg Vim. website , repository
Sindsdien zijn er uiteraard al tientallen andere varianten opgedoken. De bekendste neovim zijnde. Elk is een project op zich met andere maintainers, andere goals, andere ontwikkelingen.

Deze feiten ben ik bekend mee, maar was mijn vraag niet. Jij stelt dat op embedded Linux systemen vi nog standaard wordt meegeleverd. Ik vraag me af of vi op deze systemen niet is vervangen door vim-tiny, wat gewoon een minimale versie van vim is en daardoor meer actieve ontwikkeling kent, maar met een subset aan features. Het is een oprechte vraag, ik kan me beiden voorstellen.

MS-DOS wordt ook niet meer ontwikkeld. Je kan dan toch ook niet zeggen dat DOS en Windows 11 dezelfde software is?

Ik snap deze vergelijking niet. Windows 11 vindt zijn oorsprong in Windows NT, wat volledig andere technologie is dan DOS. Als je de vergelijking had gemaakt tussen DOS en Windows 95/98/ME of beter nog tussen DOS en FreeDOS dan had ik het begrepen, want dat zijn stukken software met hetzelfde doel maar vernieuwde code. De laatste release van ex-vi is uit 2005, dus ik zou toch niet willen zeggen dat het nog actief wordt ontwikkeld.

In welke distro wordt vi of vim by default vervangen door vim-tiny? Is werkelijk het eerste dat ik er van hoor.

Debian blijkbaar, zie de link in mijn reactie. En bij extensie dus ook alle op Debian gebaseerde distributies zoals Ubuntu en Linux Mint. Het originele Vi zit al jaren niet meer in de Debian repositories. In een standaard Debian server installatie wordt vim-tiny geïnstalleerd met een "vi" alias via het DebianAlternatives systeem.

[Reactie gewijzigd door rbr320 op 15 februari 2026 14:18]

[Opifex]

Deze feiten ben ik bekend mee, maar was mijn vraag niet. Jij stelt dat op embedded Linux systemen vi nog standaard wordt meegeleverd. Ik vraag me af of vi op deze systemen niet is vervangen door vim-tiny, wat gewoon een minimale versie van vim is en daardoor meer actieve ontwikkeling kent, maar met een subset aan features. Het is een oprechte vraag, ik kan me beiden voorstellen.

Excuus, ik meende dat je vraag betrekking had tot het eerste deel van de quote, en niet het tweede.

Ik durf er niet meteen met zekerheid een antwoord op geven omdat dit niet direct mijn vakgebied is en ik ook niet meteen een apparaat heb om een steekproef op uit te voeren. Heb wel snel wat Gegoogled.
Busybox heeft blijkbaar by default Tiny-vi . Een nog meer stripped down versie van Vi dus. (dus geen tiny-vim)
Buildroot heeft... en dit verrast mij toch wel wat... by default enkel ondersteuning voor Vim?

Bijzonder. Dat was enkele jaren geleden toch nog wel anders. Toen was het gewoonweg Vi dat je kreeg. Ik durf niet met zekerheid te zeggen of het een echte Vi was, of de Tiny-vim die jij aanhaalt, maar als ik m'n geld er op moet zetten is het toch wel Vi. Een embedded systeem gebruik je niet om te developen. Je gaat er ook geen Visual Studio opzetten. Je wil enkel een editor om simpele config files te kunnen aanpassen e.d.. Je kiest dan ook het eerste het beste dat niet al te zwaar is. Nano en Vi zijn dan de klassiekers. Veel verder wordt daar niet over nagedacht.

Ik snap deze vergelijking niet. Windows 11 vindt zijn oorsprong in Windows NT, wat volledig andere technologie is dan DOS. Als je de vergelijking had gemaakt tussen DOS en Windows 95/98/ME of beter nog tussen DOS en FreeDOS dan had ik het begrepen, want dat zijn stukken software met hetzelfde doel maar vernieuwde code. De laatste release van ex-vi is uit 2005, dus ik zou toch niet willen zeggen dat het nog actief wordt ontwikkeld.

DOS en Windows 11 zijn allebei besturingssystemen die ver terug in de geschiedenis enige relatie hebben gehad. Net zoals Vim en Vi. Vim is from scratch geschreven en geen doorontwikkeling van Vi. Puur en alleen omdat het hetzelfde doel heeft en één van beide niet meer ontwikkeld wordt, wil nog niet zeggen dat het hetzelfde programma is. Anders kan je zelfs zeggen dat de machines van Babbage en Turing dezelfde zijn als de machines van Microsoft.

Debian blijkbaar, zie de link in mijn reactie. En bij extensie dus ook alle op Debian gebaseerde distributies zoals Ubuntu en Linux Mint. Het originele Vi zit al jaren niet meer in de Debian repositories. In een standaard Debian server installatie wordt vim-tiny geïnstalleerd met een "vi" alias via het DebianAlternatives systeem.

De link die je gaf is een volledig losstaande package. Vi zelf zit inderdaad, zoals je zelf inderdaad al aangaf, niet meer in Debian. Wat ik begrijp van je tweede link is dat je met update-alternaties voorkeuren kan geven voor welke software je wil gebruiken voor bepaalde doelen (zoals bvb. welke text editor je voorkeur heeft). Ik zie echter nergens iets over defaults, en tiny-vim zie ik ook niet vermeld. Wat ik wel vermeld zie worden is nvi.

[rbr320]

Je wil enkel een editor om simpele config files te kunnen aanpassen e.d.. Je kiest dan ook het eerste het beste dat niet al te zwaar is. Nano en Vi zijn dan de klassiekers.

Dat is nu precies waarom vim-tiny bestaat. Als zelfs Vim te zwaar is (en in vergelijking met iets als Visual Studio, VS Code of de diverse IDE's van JetBrains is Vim al behoorlijk lichtgewicht) dan neem je vim-tiny. De installatiegrootte van vim-tiny is slechts 1730kB. Ter vergelijking, de installatiegrootte van nano is 2871kB.

Vim is from scratch geschreven en geen doorontwikkeling van Vi. Puur en alleen omdat het hetzelfde doel heeft en één van beide niet meer ontwikkeld wordt, wil nog niet zeggen dat het hetzelfde programma is.

Dat beweer ik toch ook nergens?

Overigens is de enige relatie tussen DOS en Windows 11 dat ze beiden door Microsoft gemaakt zijn. Verder is het totaal andere technologie. Maar dat geheel terzijde, het is inmiddels niet meer relevant voor de discussie.

De link die je gaf is een volledig losstaande package.

Dat is nu eenmaal hoe Debian werkt. Ik heb het zojuist even getest en Vim en vim-tiny kunnen prima naast elkaar bestaan op je systeem. Waarom je dat zou willen is mij een raadsel maar het kan. De 2 packages hebben echter exact hetzelfde versienummer, wat er op wijst dat het in principe dezelfde software is. Het verschil zit hem er in dat de binary op een andere manier is gecompileerd.

Wat ik begrijp van je tweede link is dat je met update-alternaties voorkeuren kan geven voor welke software je wil gebruiken voor bepaalde doelen (zoals bvb. welke text editor je voorkeur heeft). Ik zie echter nergens iets over defaults, en tiny-vim zie ik ook niet vermeld. Wat ik wel vermeld zie worden is nvi.

update-alternatives heeft geen defaults. Dat is by design, want Debian heeft geen mening over hoe jij jouw systeem gebruikt. Ale er maar 1 programma in een bepaalde categorie op je systeem geïnstalleerd is zal deze zich als default gedragen. Daarna werkt het met prioriteiten per link groep, die je zelf in zult moeten stellen. Dus op mijn Proxmox server wijzen de commando's "vi" en "view" (vim in read-only mode) momenteel naar vim-tiny, want het is de enige geïnstalleerde vi-achtige. Het commando "editor" wijst naar nano, maar kent vim-tiny als alternatief.

[Reactie gewijzigd door rbr320 op 15 februari 2026 21:10]

[Opifex]

Dat is nu precies waarom vim-tiny bestaat. Als zelfs Vim te zwaar is (...)

Je leest heel selectief. Iemand die een embedded Linux prepareert wil zijn tijd vooral spenderen aan functionele dingen die belangrijk zijn voor de toepassing. Een Vi(m) installeren is meestal wenselijk om tijdens het developen af en toe een config te kunnen aanpassen, maar verder wil je daar als developer niet teveel over nadenken. Men kiest dus iets wat meteen beschikbaar is, en niet iets exotisch waarvoor ze nog een extra repository moeten toevoegen, of waarvoor ze moeten gaan compilen. Dat is het echt niet waard. Zolang je geen ettelijke gigabytes (zoals Visual Studio) op je systeem moet zetten is alles prima.

Dat beweer ik toch ook nergens?

Het leek alsof je dat impliceerde in je eerste bericht. Maar misschien las ik dit fout

Dat is nu eenmaal hoe Debian werkt. Ik heb het zojuist even getest en Vim en vim-tiny kunnen prima naast elkaar bestaan op je systeem. Waarom je dat zou willen is mij een raadsel maar het kan. De 2 packages hebben echter exact hetzelfde versienummer, wat er op wijst dat het in principe dezelfde software is. Het verschil zit hem er in dat de binary op een andere manier is gecompileerd.

En naar wat symlinkt hij `vi` dan? Want dat is toch wat we wouden weten?

update-alternatives heeft geen defaults.

Oké, maar dan kunnen we niet stellen dat op Debian Vi automatisch overeenkomt met Tiny-Vim. Want dat is wel wat je beweerde.

[rbr320]

Je leest heel selectief. Iemand die een embedded Linux prepareert wil zijn tijd vooral spenderen aan functionele dingen die belangrijk zijn voor de toepassing. Een Vi(m) installeren is meestal wenselijk om tijdens het developen af en toe een config te kunnen aanpassen, maar verder wil je daar als developer niet teveel over nadenken. Men kiest dus iets wat meteen beschikbaar is, en niet iets exotisch waarvoor ze nog een extra repository moeten toevoegen, of waarvoor ze moeten gaan compilen. Dat is het echt niet waard. Zolang je geen ettelijke gigabytes (zoals Visual Studio) op je systeem moet zetten is alles prima.

Ik lees helemaal niet selectief. In deze paragraaf doe jij het overkomen alsof het opnemen van vim, al dan niet de tiny versie, in een embedded systeem een complexe operatie is en dat Vi op een of andere magische wijze direct beschikbaar is. Echter als ik naar de repository ga waar jij eerder in deze discussie naar linkte kom ik daar toch echt alleen broncode tegen, dus ook voor Vi zal je moeten compileren. In de open source wereld is dat overigens heel gebruikelijk, want je kunt er niet zomaar vanuit gaan dat de ontwikkelaar een binary voor jou exotische embedded architectuur beschikbaar stelt, zelfs als de broncode prima cross-platform is. Dus sta je als ontwikkelaar/beheerder van een embedded Linux systeem voor de keuze welke software je mee neemt in je image. Nu wil ik niet voor alle ontwikkelaars van embedded systemen spreken of zelfs maar pretenderen dat ik verstand heb van het onderhouden van embedded systemen (al ken ik wel een paar embedded systeemontwikkelaars), maar als ik moet kiezen tussen code uit een repository die al ruim 20 jaar niet is aangeraakt of code voor vergelijkbare software die actief ontwikkeld wordt, dan is voor mij de keuze snel gemaakt. Dus tenzij je met bewijs komt dat Vi nog vaak op embedded systemen te vinden is neem ik die stelling met een korrel zout. Overigens zou ik zelf op een embedded systeem helemaal geen editor installeren, geen Vi noch Vim-tiny noch Nano, maar slechts een kernel en verder de minimale software die nodig is om het systeem te laten draaien en het te beheren.

En naar wat symlinkt hij `vi` dan? Want dat is toch wat we wouden weten?

/usr/bin/vi is op Debian een symlink die via /etc/alternatives/vi uiteindelijk naar /usr/bin/vim-tiny of /usr/bin/vim wijst. Zodra de vim(-tiny) binary merkt dat hij is opgestart door middels van het commando "vi" zal deze zich gaan gedragen als old-skool Vi en niet meer als Vim.

Oké, maar dan kunnen we niet stellen dat op Debian Vi automatisch overeenkomt met Tiny-Vim. Want dat is wel wat je beweerde.

Wel dus, zie bovenstaande en de reactie van @Anck.

Het ontbreken van defaults in DebianAlternatives wil niet zeggen dat er niets is. Package maintainers moeten zelf de applicatie in hun package opnemen in de alternatives database van het systeem via update-alternatives commando's in het post-install script van het pakket. Daarbij geven ze hun pakket een prioriteit mee, die hoger of lager kan zijn dan wat er momenteel al op het systeem aanwezig is en daarmee dus de standaard applicatie achter een bepaald commando vervangt of juist intact laat. Dat geeft package maintainers een zekere macht over het software ecosysteem binnen Debian, maar gelukkig zijn daar binnen het Debian team strikte afspraken over. Zo heeft in het geval van editors simpel de voorkeur over complex, dus Nano heeft een hogere prioriteit dan Vim of Emacs. Dus in die zijn was een eerdere bewering van mij niet correct, Debian heeft wel degelijk een mening over welke software jij op je systeem gebruikt. Niet dat ik denk dat er veel mensen zullen zijn die een tekst editor in de terminal opstarten met het commando editor, vrijwel iedereen typt gewoon de naam van zijn of haar favoriete editor in zodat je zeker weet wat je krijgt.

[Reactie gewijzigd door rbr320 op 15 februari 2026 23:51]

[Anck]

Niet dat ik denk dat er veel mensen zullen zijn die een tekst editor in de terminal opstarten met het commando editor, vrijwel iedereen typt gewoon de naam van zijn of haar favoriete editor in zodat je zeker weet wat je krijgt.

Dat is zeker waar, maar als je ooit sudoedit of sudo -e gebruikt, wat de voorkeur heeft boven sudo vim of nog erger: sudo su -, krijg je op een default Debian installatie dus nano. Daarom kan het handig zijn de default editor te wijzigen middels update-alternatives of door de $EDITOR environment variable te zetten.

[rbr320]

Inderdaad. Ik ben ooit sudo su - nog eens tegen gekomen tijdens een cursus voor een Red Hat certificering, ik weet niet meer precies welke. Meteen iets van gezegd tegen de docent want dat vond ik toch echt niet kunnen.

[Anck]

In een Debian base installation komt vi inderdaad overeen met vim-tiny, zie https://packages.debian.org/trixie/vim-tiny:

This package contains a minimal version of Vim compiled with no GUI and a small subset of features. This package's sole purpose is to provide the vi binary for base installations.

De default editor is overigens nano: /usr/bin/editor -> /etc/alternatives/editor -> /bin/nano.

[kdekker]

Ik weet bijna 100% zeker dat vi op Linux vim is. Kijk maar welke packages geinstalleerd zijn op je systeem, of kijk waar de sym links voor vi en vim heenwijzen. Het is al even dat ik van Linux weg ben, maar dit was al 10+ jaar geleden al zo. Ik weet alleen niet wie na overlijden van Bram Moolenaar vim ontwikkeld. Iig vi dateert al uit 'ver van de vorige eeuw'. Zoals @rbr320 ook al zegt in iets andere woorden.

[Reactie gewijzigd door kdekker op 16 februari 2026 08:34]

[Opifex]

op Linux

Linux heeft geen Vi. Linux is enkel de kernel, zonder enige vorm van packages. En ja, doorgaans is deze uitspraak onnodig muggenzifterij, maar in dit geval is het onderscheid wel degelijk relevant. Jouw stelling
impliceert namelijk dat elke distro vi symlinkt naar vim, wat absoluut niet het geval is.

Ik weet alleen niet wie na overlijden van Bram Moolenaar vim ontwikkeld

De meeste grote open source projecten hebben op voorhand een stappenplan van opvolging voor het geval de hoofd maintainer komt te overlijden. Bij Vim was dat niet anders. Op dit moment wordt het gemaintaind door een groep contributors die voorheen ook al actief waren, geleid door Christian Brabandt als ik me niet vergis.

Iig vi dateert al uit 'ver van de vorige eeuw'.

Idem voor Vim. Dateert ook uit de vorige eeuw.

Al je bedoelt dat Vi ontwikkeling stopte in vorige eeuw: de laatste commit in de BusyBox versie van Vi dateert van 2015.

Als je niet in de embedded wereld actief bent besef je het waarschijnlijk niet, maar in je huis bevinden zich waarschijnlijk minstens 10 apparaten met BusyBox op. Dit is dus niet zo obscuur als je vermoedt.

[kdekker]

Een beetje muggeziften is je reactie wel . Zonder packages geen software. Ik had niet direct aan de embedded wereld gedacht, fair punt (maar ook niet onlogisch als je niet in die wereld werkt), maar op de distributies waar ik mee gewerkt heb (Red Hat Enterprise, SLES, en prive Xubuntu) is, als er vim is, ook vi aanwezig. En voor zover ik me herinner (ik gebruik de laatste paar jaren niet actief Linux) was dat 1 package (yast, apt, whatever).

Volgens mij zie je in /usr/bin (als ik me goed herinner) allemaal symlinks naar dezelfde vim binary. En de aanroeper bepaalt in welke 'mode' vim draait. Nogmaals: ik zeg dit uit mijn hoofd. Heb geen toegang op dit moment tot een Linux bak om dat even te verifieren.

[Hydranet]

Misschien is Micro wat?

https://micro-editor.github.io

https://github.com/micro-editor/micro

[blackSP]

Micro is een fijne editor. Soms heb ik m'n hele scherm vol staan met terminals en dan pak ik toch even Micro om een bash scriptje te editten. Maar voor het serieuze werk gebruik in Kate. Met vim heb ik nooit kunnen opschieten.

[Zarlin]

Die kende ik nog niet, ziet er erg handig uit. Bedankt coor de tip!

[Magic Power]

Mijn go-to tekst editor op Linux is tegenwoordig Kate (uit de KDE stal).

Ik ben begonnen met QEdit op DOS. Toendertijd een heerlijke editor die je erg gedetailleerd kon instellen. In Windows had ik UltraEdit en Notepad++ gebruikt. Nu op Linux ben ik zeer tevreden met Kate. Het heeft 'syntax highlighting', overzicht over je te editen bestanden, en de meeste functies die ik ook in UltraEdit en Notepad++ heb gebruikt.

[Lnaisd]

Ik gebruik KWrite is een iets simpelere versie van Kate en is ook van KDE, voor terminals gebruik ik nano

[juiced01]

Misschien is Zed iets voor je?

[Lnaisd]

Zed vind ik echt zo'n goede, het is het beste alternatief voor VS code

[Keyb]

Ik ben sinds van de week eens serieus helix aan het proberen na een paar jaar neovim. Ik moet teveel sleutelen aan vim/neovim om het voor mij persoonlijk 'goed' te krijgen. Fuzzy find is gewoon onderdeel van helix zonder dat ik plugins nodig heb.

[nullbyte]

Waarom zou je een alternatief voor notepad++ willen

[downtime]

Waarom zou je een alternatief voor notepad++ willen

Ik kan de vinger er niet op leggen wat de reden is, maar Notepad++ is al jaren tweede keus voor me, als ik m’n favoriete editors niet ter beschikking heb. Want het is gratis, best uitgebreid, en veel bedrijven installeren het als alternatief voor de gewone Notepad.

Maar het is nooit m’n favoriete editor geweest. Onder Windows heb ik in de loop der jaren verschillende gebruikt. Eerst TextPad, daarna UltraEdit, maar de laatste jaren, met name nu ik thuis ook Linux gebruik, is VS Code de favoriet.

[wiskas_1000]

Ik vraag me af hoeveel mensen vim nog verkiezen boven neovim. Zal dit gaan om stabiliteit en bruikbaarheid van de vimrc?

Ontopic: Wayland support is wel echt mooi. Toch goed om te zien dat deze stap gemaakt wordt. Idem voor het gebruik van ~/.config, hoewel dat te omzeilen was met een symlink.

[Opifex]

Ik en mijn collega's gebruiken allemaal nog Vim. Kan niet voor hun redenen spreken, maar voor mezelf is dat voornamelijk uit gewoonte. Zoals je zelf al aangaf: mijn vimrc is door de jaren heen gegroeid en daar ben ik nu aan gewoon geworden. Die verliezen zou een te sterke handicap zijn voor mij.

Nu... vorig jaar zei een Visual Studio gebruiker tegen mij "Gebruik jij Vim?! Waarom gebruik je geen moderne editor?"... dat is blijven resoneren. Dus heb ik tijdens het kerstverlof toch maar eens NeoVim uitgeprobeerd


Blijkbaar is het mogelijk om je vimrc te blijven gebruiken, in combinatie met de Lua's van NeoVim. Het werkt tot op zekere hoogte, maar een perfecte oplossing is het zeker en vast niet. Voorlopig gebruik ik NeoVim dus op mijn persoonlijke computer thuis, om er aan te wennen, terwijl ik voor m'n werk nog steeds vasthoud aan die goeie ouwe betrouwbare Vim <3

[dev10]

Ik gebruik al heel lang, zeker 20 jaar, vim voor van alles en nog wat en heb niet zo veel zin om m’n vimrc en degelijke om te gaan zetten naar nvim. Daar komt bij dat voor waar ik vim gebruik er geen meerwaarde is om nvim te gaan gebruiken. Programmeren doe ik met de JetBrains IDE’s waardoor ik geen LSP support nodig heb.

[InjecTioN]

Ik kan al 10 jaar ontzettend genieten van Vim. Bij mij is overigens de muis setting by default set mouse =. Gewoon omdat ik de muis integratie niet fijn vind. Maar verder is het ontzettend heerlijk om met alleen het toetsenbord te editen. Ik ben simpelweg veel sneller met het toetsenbord dan met een muis.

Overigens gebruik ik onder vscode een vim plug-in. Daarmee wordt de editor ineens een stuk bruikbaarder.

Ik ben overigens wel erg blij met de native dark-mode in 9.2. Er waren reeds manieren om dit simpelweg met een persoonlijke config in ~./vimrc te doen, maar nu is het native. Erg fijn!

[wimdebok]

Ben ook gewend aan vi op de commandline en besloot ooit ook de vi plugin in vscode te installeren. Maar uiteindelijk toch besloten het er af te halen mezelf te laten wennen met vscode zoals het is. Vond niet prettig het is nooit helemaal vi en herinnerde conflicten tussen vscode en vi plugin commandos. Gedoe.


Systeem en configuratie files met vi, code met vscode. Dan krijg je wel eens dat je de commandos van de ene editor in de andere editor tikt.

Uiteindelijk is het ook gebruiken waar je je wel bij voelt.

[Jets]

Ik gebruik al heel lang EditPlus en vind ik het fijnst tussen alle editors, wel betaald, maar nog steeds waard tov bv Notepad++

[mcmd]

Altijd liefhebber geweest van VIM onder niet-Windows. Onder Windows gebruik ik het ook wel, maar ook Notepad++ wat voor mij meestal net wat lekkerder werkt.

De laatste jaren overgegaan naar neovim, dat is echt geweldig met LazyVim erbij. Al met al heel fijn om te gebruiken.

[beastdjw]

Als je vim wil gebruiken, dan kan je tegenwoordig beter Neovim (nvim) gebruiken. Je kan er een volledige IDE van maken als je wilt met LUA en LSP(!) ondersteuning en zelfs AI wordt goed ondersteund. Als je door de lange leercurve, dat is het nadeel, heen bent wil je nooit meer een andere editor.