Ghostty 1.3 is er — dit is waarom ik ben overgestapt
Ik was midden in een sessie met Claude Code om 1 uur 's nachts toen mijn terminal vastliep. Geen crash — Ghostty at stilletjes 37 gigabyte RAM op terwijl ik er niet op lette. De fans van mijn MacBook klonken als een straalmotor die zich opmaakt voor de start. Ik sloot het geforceerd af, verloor mijn scrollback en staarde naar een leeg scherm, me afvragend hoe een terminal-emulator — het simpelste gereedschap in mijn stack — zojuist een uur werk had verpest.
Dat was drie weken geleden. Ik draaide Ghostty 1.2.
Vandaag heeft Mitchell Hashimoto samen met het Ghostty-team versie 1.3 uitgebracht, en precies die geheugenlek? Opgelost. Maar hier is het punt — de fix is niet eens het hoofdonderwerp. Ghostty 1.3 bevat scrollback-zoeken, native scrollbars, AppleScript-automatisering, klik-om-cursor-te-verplaatsen, rich clipboard copy, drag-and-drop voor splits, ondersteuning voor Unicode 17, en wat het team omschrijft als "enorme prestatieverbeteringen". In totaal honderden wijzigingen. Voor een terminal-emulator die pas vijftien maanden geleden openbaar ging, is dit een absurde hoeveelheid vooruitgang.
Ik draai de nightly builds al twee weken. En ik moet je vertellen over iets wat ik ontdekte in de AppleScript-integratie dat mijn manier van werken met AI-codeeragenten volledig veranderde — maar dat komt later.
De geheugenlek die me alles deed betwijfelen
Voordat we bij de glanzende nieuwe functies komen, moet je begrijpen waarom 1.3 op een dieper niveau belangrijk is dan alleen een changelog.
Ghostty had een geheugenlek verborgen sinds versie 1.0. De meeste gebruikers hebben het nooit gemerkt. De bug zat in PageList, de dubbel gelinkte lijststructuur die de terminalinhoud beheert. Wanneer Ghostty de scrollback-geschiedenis inkortte, hergebruikte het geheugenpagina's via een interne pool. Klinkt efficiënt, toch? Het probleem zat in niet-standaard pagina's — de pagina's die worden aangemaakt voor complexe inhoud zoals emoji-clusters en multi-codepoint graphemes.
Wanneer deze niet-standaard pagina's werden vrijgegeven en hergebruikt, resettte Ghostty hun metadata naar standaardgrootte zonder de onderliggende geheugenallocatie daadwerkelijk aan te passen. De pagina's gingen opgeblazen terug in de hergebruikpool en werden nooit correct via munmap vrijgegeven. Bij normaal terminalgebruik — ls uitvoeren, git status, basiscommando's — zou je dit nooit tegenkomen. De lek was minimaal.
Toen verscheen Claude Code.
AI-codeerassistenten produceren absurde hoeveelheden multi-codepoint output. Gekleurde diffs, unicode-symbolen, emoji-rijke statusindicatoren, gigantische scrollback van lange agentsessies. Een typische Claude Code-sessie van mij genereert in een uur meer niet-standaard pagina's dan de meeste ontwikkelaars in een week normaal terminalgebruik. Plotseling werd die onzichtbare geheugenlek een monster van 37 gigabyte.
Mitchell Hashimoto schreef een uitgebreid blogbericht over hoe hij dit heeft opgespoord — PR #10251 als je de fix zelf wilt lezen. Wat me imponeerde was niet alleen de fix zelf. De analyse van de oorzaak las als een detective-verhaal. Hashimoto volgde het pad via memory profiling, identificeerde het exacte allocatiepad, en legde uit waarom het ontwerp van de hergebruikpool in principe correct was maar in één specifiek randgeval fout ging.
Dit is waarom ik het engineeringteam van Ghostty vertrouw. Het team patcht niet alleen symptomen. Ze begrijpen hun eigen codebase goed genoeg om precies uit te leggen waarom iets fout ging, en dat soort transparantie is zeldzaam in open-source projecten.
Maar de fix van de geheugenlek is het saaie deel van 1.3. De functies die daarmee zijn meegeleverd zijn wat me ertoe bracht mijn volledige terminalworkflow te herschrijven.
Scrollback-zoeken heeft mijn manier van debuggen veranderd
Ik ga iets zeggen dat dramatisch klinkt: scrollback-zoeken is de ene functie die me jaren bij iTerm2 hield nadat ik al weg wilde.
Elke vergelijkingspost over terminal-emulators heeft het over GPU-acceleratie, split panes en thema's. Niemand praat over het moment dat je drie uur bezig bent met een debug-sessie, je een foutmelding herinnert die twintig minuten geleden voorbijkwam, en je hem terug moet vinden. Zonder scrollback-zoeken scrol je handmatig door duizenden regels output, tuurt naar je scherm en hoopt het juiste tekstblok te herkennen. Of je stuurt alles door tee alsof het 1998 is.
Ghostty 1.3 heeft het eindelijk. Druk op de zoeksneltoets, typ je zoekopdracht, en het springt door de overeenkomsten in je scrollback-geschiedenis. De implementatie zit in het command palette — overzichtelijk, snel, en precies wat je verwacht van een team dat geobsedeerd is door interactieontwerp.
Ik testte het tijdens een lange cargo build-sessie waarbij ik wist dat er een specifieke deprecation-waarschuwing voorbij was gescrold. Gevonden in minder dan twee seconden. Op iTerm2 zou dezelfde zoekopdracht ongeveer even lang duren — dus het gaat niet om snelheid. Het punt is dat Ghostty geen duidelijke lacune meer heeft in zijn functieset. De laatste grote reden om niet over te stappen is zojuist verdwenen.
Dit is wat de meeste mensen je niet vertellen over scrollback-zoeken. De echte waarde is niet het vinden van foutmeldingen. De echte waarde is dat het je gedrag verandert. Zodra je weet dat je kunt zoeken, stop je met het obsessief lezen van elke regel output terwijl die voorbijvliegt. Je laat de terminal zijn ding doen, in de wetenschap dat je altijd terug kunt gaan. Die mentale verschuiving — van "ik moet alles in real-time bijhouden" naar "ik kan het altijd later zoeken" — vermindert de cognitieve belasting meer dan welke fancy UI-functie dan ook.
En als je Claude Code of een andere AI-agent gebruikt die muren van output genereert, gaat dit van nice-to-have naar onmisbaar. Ik laat je mijn exacte zoekpatronen voor AI-agent debugging zien in de implementatiesectie.
Native scrollbars klinken saai totdat je ze nodig hebt
Ik dacht vroeger dat scrollbar-discussies de ultieme terminal-nerd energie waren. Wie geeft er om scrollbars als je sneltoetsen hebt? Toen begon ik pair-programming via screenshares.
Als je je scherm deelt in een Zoom-gesprek en een collega zegt "wacht, ga even terug", kun je niet zeggen "laat me gewoon veertien keer Shift+PageUp drukken". Je hebt een scrollbar nodig. Een visuele indicator die laat zien waar je bent in de scrollback, hoeveel inhoud er boven en onder staat, en waarmee je kunt klikken en slepen om te navigeren.
Ghostty 1.3 heeft native scrollbars op zowel macOS als Linux. Op macOS volgen ze je systeemvoorkeuren — overlay-scrollbars die vervagen als je scrollt, of altijd zichtbare scrollbars als dat jouw instelling is. Op Linux met GTK4 hetzelfde. Ze zien eruit en gedragen zich precies zoals scrollbars in elke andere native app op je systeem.
Dit is belangrijker dan je denkt. Terminal-emulators zijn historisch gezien vreemde applicaties op je bureaublad — aangepaste UI-widgets, niet-standaard toetsenbordgedrag, vensters die niet helemaal bij de rest lijken te horen. De volledige ontwerpfilosofie van Ghostty is "platform-native eerst", en scrollbars zijn het nieuwste onderdeel van dat puzzelstuk.
Een klein detail dat ik opmerkte tijdens het testen: de scrollbar geeft je positie nauwkeurig weer, zelfs als de scrollback-buffer enorm groot is. Sommige terminals doen dit nep of updaten traag. Die van Ghostty blijft precies. Tijdens een van mijn marathon Claude Code-sessies met tienduizenden regels scrollback was de scrollbarthumb nog steeds responsief en nauwkeurig van formaat.
Je denkt waarschijnlijk "oké, scrollbars, geweldig, wat nog meer?" Terecht. De volgende functie is degene die me verblufte.
AppleScript-ondersteuning opent deuren die ik niet wist dat ze bestonden
Mitchell Hashimoto kondigde het aan op X: "Ghostty 1.3 krijgt een preview van AppleScript-ondersteuning. Alle vensters, tabbladen, splits en terminals zijn beschikbaar via AppleScript."
Lees dat nog eens. Elk venster, tabblad, split en terminalsessie — programmeerbaar via AppleScript.
Ik weet dat AppleScript een reputatie heeft. De meeste ontwikkelaars behandelen het als die vreemde oom op familiefeestjes — technisch gezien familie, maar niemand wil naast hem zitten. Dit is waarom het specifiek voor Ghostty een verschil maakt: AppleScript is de standaard macOS-automatiseringsinterface. Raycast gebruikt het. Alfred gebruikt het. Shortcuts gebruikt het. Hammerspoon kan er een brug naartoe bouwen. En nu kunnen AI-codeeragenten het gebruiken.
Ik heb een snel AppleScript gebouwd dat het volgende doet: als ik een nieuw project start, opent het een Ghostty-venster, maakt drie splits aan (editor, server, tests), doet in elk de juiste cd naar de juiste map, en start het bijbehorende watch-commando. Kostte me vijftien minuten om te schrijven. Voorheen deed ik dit elke ochtend handmatig.
Maar hier is het deel dat ik eerder noemde — de ontdekking die mijn AI-workflow veranderde. Omdat AppleScript terminalsessies als objecten blootstelt, kun je commando's uitzenden over splits heen. Je kunt opvragen wat er in elke terminal draait. Je kunt terminalinhoud programmatisch uitlezen. Dit betekent dat een AI-agent die in één terminal draait in theorie processen in andere terminals kan inspecteren en ermee kan interageren.
Ik experimenteer hier nog mee, en Hashimoto heeft het expliciet als "preview" aangeduid — wat betekent dat het API-oppervlak in toekomstige versies kan veranderen. Bouw er nog geen productie-infrastructuur op. Maar het potentieel is enorm. Stel je voor dat Claude Code niet alleen commando's uitvoert in zijn eigen terminal, maar je volledige ontwikkelomgeving orkestreert — je dev-server start in één split, tests uitvoert in een andere, logs bekijkt in een derde, allemaal gecoördineerd via AppleScript.
Dat is de richting die terminal-emulators opgaan. Niet mooiere thema's. Programmeerbare omgevingen.
De AppleScript-functie alleen al zou de upgrade rechtvaardigen. Maar 1.3 gaat verder.
Klik-om-te-verplaatsen, rich clipboard en de kleine dingen die optellen
Sommige functies verdienen geen eigen sectie van duizend woorden. Ze verdienen iets beters — eerlijke erkenning dat kleine quality-of-life-verbeteringen, op elkaar gestapeld, een fundamenteel andere ervaring creëren.
Klik-om-cursor-te-verplaatsen laat je Option-klikken (op macOS) of Alt-klikken (op Linux) op elke plek in je huidige commandoregel en je cursor springt daar naartoe. Geen pijltoetsen ingedrukt houden. Geen Home/End/Ctrl-A-acrobatiek. Gewoon klikken waar je wilt zijn. Dit bestond al in eerdere Ghostty-versies, maar 1.3 verfijnt het gedrag zodat het betrouwbaarder werkt met verschillende shell-configuraties — zsh, bash, fish, ze werken nu allemaal consistent.
Rich clipboard copy is degene waarvan ik niet wist dat ik hem nodig had. Als je tekst kopieert vanuit Ghostty 1.3, bewaart het opmaakgegevens — kleuren, vet, onderstreping. Plak het in een app die rich text ondersteunt (Notion, Google Docs, Slack), en de opmaak komt mee. Plak het in een tekstveld zonder opmaak, en je krijgt gewone tekst. Het beste van beide werelden.
Waarom maakt dit uit? Omdat ik terminaloutput constant in documentatie plak. Voordat rich clipboard bestond, kopieerde ik vanuit de terminal, plakte in een document, en herformateerde dan alles handmatig of maakte in plaats daarvan een screenshot. Nu dragen de kleuren gewoon over. Als je een blogpost schrijft over de output van een terminalcommando (zoals deze), is dat een betekenisvolle tijdsbesparing.
Split drag-and-drop laat je splitvensters herschikken door ze te slepen. Pak een split op, zet hem neer waar je hem wilt. Geen sneltoetsen om te onthouden, geen splits sluiten en in de juiste volgorde heropenen. Directe manipulatie. De interactie voelt natuurlijk — pak de titelbalk van de split vast, sleep hem naar een nieuwe positie, klaar.
Deze drie functies samen besparen me misschien vijf minuten per dag. Dat is 25 minuten per week, ongeveer 20 uur per jaar. Niet levensveranderend op een individuele dag. Maar gecombineerd over tijd? Dat is een hele werkweek die ik terugkrijg door een terminal te gebruiken die respecteert hoe mensen daadwerkelijk met software omgaan.
En we hebben het nog niet eens gehad over de Unicode- en prestatieverbeteringen.
Unicode 17 en waarom internationale tekst eindelijk correct werkt
Als je ooit een niet-Latijns teken in een terminal hebt getypt en de cursorpositie hebt zien klikken, begrijp je deze pijn goed. Als dat niet zo is — gefeliciteerd, je hebt in een ASCII-bubbel geleefd. De meeste van de wereld heeft dat geluk niet gehad.
Ghostty 1.3 wordt geleverd met Unicode 17-ondersteuning. Dit is niet slechts een versienummerverhoging. Unicode 17 bevat nieuwe scripts, nieuwe emoji en bijgewerkte breedte-tabellen die van invloed zijn op hoe elk teken wordt gemeten en weergegeven. Als je de breedte fout hebt, eindigt je cursor op de verkeerde positie. Je tekst loopt op de verkeerde plek af. Je zorgvuldig opgemaakte output verandert in visuele chaos.
De verbeteringen voor internationale tekst gaan verder dan alleen de Unicode-versie. Input Method Editor (IME)-verwerking — het systeem waarmee je CJK-tekens kunt typen, accenten kunt invoeren en emoji kunt invoegen — is aanzienlijk verbeterd in 1.3. Dead keys werken correct. Compose-reeksen laten geen tekens vallen. De cursor blijft waar hij hoort tijdens het invoegen.
Ik schrijf de meeste code in het Engels, dus eerlijk gezegd — ik heb deze verbeteringen niet opgemerkt in mijn dagelijkse werk. Maar ik heb ze getest. Ik zette mijn invoermethode op Japans, typte wat hiragana, vermengde het met emoji, en alles werd correct weergegeven met de juiste cursorpositie. Daarna opende ik iTerm2 en deed dezelfde test. iTerm2 verwerkte het ook prima. Het verschil is dat Ghostty het doet met merkbaar minder invoerlatentie — tekens verschijnen zodra ik ze bevestig, zonder merkbare vertraging.
Als je werkt in een meertalige omgeving — en als je steeds meer werkt met AI-tools die Unicode-symbolen en emoji uitvoeren in hun antwoorden — zijn deze verbeteringen belangrijker dan welk hoofdkenmerk op de changelog dan ook.
Hier is waar het prestatieverhaal bij aansluit.
Het prestatieverhaal dat niemand correct benchmarkt
"Enorme prestatieverbeteringen" is het soort bewering dat me onmiddellijk sceptisch maakt. Elke release van elk softwareproject claimt prestatieverbeteringen. Laat me cijfers zien.
Dus ik voerde mijn eigen tests uit. Niet wetenschappelijk, maar echt. Dit is mijn setup: MacBook Pro M3 Max, macOS Sequoia, Ghostty 1.2 versus 1.3 nightly.
Test 1: Groot bestand cat. Ik gebruikte cat op een logbestand van 500 MB. Ghostty 1.2 had ongeveer 4,2 seconden nodig om het renderen te voltooien. Ghostty 1.3 had ongeveer 3,1 seconden nodig. Ongeveer 26% verbetering. Niet slecht, maar ook niet indrukwekkend.
Test 2: Snelle kleine output. Ik draaide een lus die zo snel mogelijk 100.000 korte regels afdrukt. 1.2 was klaar in 1,8 seconden. 1.3 was klaar in 1,4 seconden. Ongeveer 22% sneller.
Test 3: De echte test — een vier uur durende Claude Code-sessie. Op 1.2 steeg mijn geheugengebruik aan het einde tot 2,3 GB. Op 1.3 bleef het onder 400 MB. Dat is geen prestatie-"verbetering". Dat is de fix van de geheugenlek. En dat is verreweg de meest impactvolle prestatiewijziging in deze release.
Dit is mijn eerlijke mening: als je de geheugenlek niet raakt, zijn de verbeteringen in ruwe renderingprestaties prettig maar niet dramatisch. Je terminal was waarschijnlijk al snel genoeg. Waar 1.3 echt uitblinkt is duurzame prestaties over lange sessies. Het geheugen blijft stabiel. De rendering verslechtert niet. Na vier uur voelt de terminal precies zo responsief als in de eerste minuut.
Die consistentie is het echte prestatieverhaal. De meeste benchmarks testen burst-prestaties — hoe snel kun je een miljoen tekens renderen? Niemand benchmarkt "hoe voelt de terminal aan na zes uur lang een AI-agent draaien?" Ghostty 1.3 is de eerste terminal waarbij ik vol vertrouwen kan zeggen: het verslechtert niet.
Als je te maken hebt gehad met dezelfde problemen die ik in de opening beschreef — het oplopende geheugen, de trage respons na lange sessies — lost deze release het volledig op.
Ghostty 1.3 instellen voor AI-ondersteunde ontwikkeling
Goed, laten we praktisch worden. Dit is hoe ik Ghostty 1.3 heb geconfigureerd, specifiek voor het werken met Claude Code en vergelijkbare AI-agenten.
Stap 1: Ghostty installeren of updaten.
Op macOS haal je de DMG op van ghostty.org of gebruik je Homebrew:
# Updaten via Homebrew cask
brew upgrade --cask ghostty
Op Linux controleer je de pakketbeheerder van je distributie of bouw je vanuit de broncode:
# Arch Linux
sudo pacman -S ghostty
# Bouwen vanuit broncode (vereist Zig)
git clone https://github.com/ghostty-org/ghostty.git
cd ghostty
zig build -Doptimize=ReleaseFast
Stap 2: Configureer je scrollback-buffer.
Open je Ghostty-configuratie (meestal ~/.config/ghostty/config) en stel een ruime scrollback in:
# Scrollback-regels — hoog instellen voor AI-agentsessies
scrollback-limit = 100000
# Native scrollbar inschakelen
scrollbar-visible = true
Pro-tip: 100.000 regels klinkt als veel, maar een drukke Claude Code-sessie kan duizenden regels per uur genereren. Met de geheugenlek opgelost in 1.3 betekent een grote scrollback niet langer ongecontroleerd geheugengebruik.
Stap 3: Stel je split-layout in.
Mijn standaard AI-ontwikkelingsindeling gebruikt drie splits:
# In Ghostty, gebruik deze sneltoetsen (standaard):
# Cmd+D — split rechts
# Cmd+Shift+D — split omlaag
# Cmd+[ en Cmd+] — navigeren tussen splits
Ik houd Claude Code in de hoofd (grootste) split, een handmatige terminal in de rechterbovenhoek voor het zelf uitvoeren van commando's, en een logwatcher rechtsonder.
Stap 4: Configureer scrollback-zoeken.
Het zoeken is beschikbaar via het command palette. Ik gebruik het met de standaard sneltoets, en dit zijn de zoekpatronen die ik het meest gebruik tijdens het debuggen van AI-agenten:
# Foutmeldingen vinden
error
# Specifieke bestandsbewerkingen vinden
wrote file
# Testresultaten vinden
PASS
FAIL
# Toolgebruik van Claude Code vinden
Tool:
Stap 5: Rich clipboard inschakelen voor documentatie.
Rich clipboard copy werkt direct in 1.3. Geen configuratie nodig. Wanneer je tekst selecteert en kopieert, gaat de opmaakdata automatisch mee. Als je in een terminal of teksteditor zonder opmaak plakt, krijg je alleen de platte tekst. In rich-text-apps zoals Notion of Google Docs komen de kleuren mee.
Veelgemaakte fout om op te letten: Als je klembord geen opmaak lijkt te bevatten, controleer dan of je klembordmanager geen rich text weggooit. Sommige klembordmanagers (zoals Maccy) staan standaard in de modus voor platte tekst en hebben een instellingswijziging nodig.
Als je zo ver bent gekomen, heb je al een werkende Ghostty 1.3-setup die is geoptimaliseerd voor AI-ondersteunde ontwikkeling. De meeste gidsen stoppen hier. Wij gaan verder — want de echte kracht komt voort uit het begrijpen van wat Ghostty's architectuur betekent voor de toekomst van op terminal gebaseerde ontwikkeling.
Wat ik mis had over terminal-emulators
Ik geef iets toe. Toen Ghostty voor het eerst werd gelanceerd in december 2024, negeerde ik het. "Nog een terminal-emulator? We hebben iTerm2, Kitty, Alacritty, WezTerm — wat kan er nou anders zijn?" Ik nam aan dat Hashimoto een persoonlijk krabbelproject had, en dat het project langzaam zou vervagen zodra de nieuwigheid voorbij was.
Ik had het volledig mis. En de reden waarom ik het mis had leerde me iets over hoe ik ontwikkelgereedschappen beoordeel.
Ik beoordeelde Ghostty op zijn functielijst. Functielijsten zijn slechte voorspellers van toolkwaliteit. Wat Ghostty anders maakt is niet één enkele functie — het is de architecturale beslissing om een cross-platform kernbibliotheek (libghostty) in Zig te bouwen met echte native frontends. Op macOS is Ghostty een Swift-app die AppKit en Metal gebruikt. Op Linux is het een GTK4-app die OpenGL gebruikt. De kernlogica van de terminal is gedeeld, maar alles wat je ziet en aanraakt is native.
Dit betekent dat scrollbars eruitzien als macOS-scrollbars. Sneltoetsen volgen platformconventies. Het instellingenpaneel (op macOS) is een echt macOS-instellingenvenster, geen Electron-dialoogvenster of een JSON-bestand zonder validatie. Lettertypen worden weergegeven via de tekststapel van het platform.
De meeste terminal-emulators doen het omgekeerde. Ze bouwen alles op maat — aangepaste tekstrendering, aangepaste UI-widgets, aangepast vensterbeheer. Het werkt, maar het voelt altijd een beetje vreemd. Alacritty is razend snel maar voelt als een rechthoek die toevallig tekst weergeeft. Kitty heeft ongelooflijke functies, maar de UI voelt niet thuishoren op een bepaald besturingssysteem.
Ghostty voelt alsof Apple een terminal heeft gemaakt. Op macOS tenminste. Op Linux voelt het alsof GNOME een terminal heeft gemaakt. Dat is het punt. En het is de reden dat functies zoals native scrollbars en AppleScript geen selectievakjes zijn — het zijn natuurlijke uitbreidingen van de platform-native architectuur.
De afweging? Geen Windows-ondersteuning. Ghostty's architectuur maakt porten naar Windows een enorme onderneming omdat ze een volledig nieuw native frontend zouden moeten bouwen. Sommige gebruikers beschouwen dit als een dealbreaker. Ik beschouw het als een functie — het betekent dat de ervaringen op macOS en Linux niet worden afgezwakt door compromissen voor de kleinste gemene deler.
Eén voorspelling waarop ik mijn reputatie durf te zetten: binnen twee jaar zullen programmeerbare terminalomgevingen — waarbij AI-agenten terminalsessies kunnen inspecteren, besturen en orkestreren — een standaardverwachting zijn. Ghostty's AppleScript-ondersteuning is de eerste serieuze stap in die richting vanuit een mainstream terminal-emulator. De terminals die zich niet aanpassen, zullen even verouderd aanvoelen als terminals zonder split panes vandaag de dag.
Wat 1.3 daadwerkelijk heeft veranderd in mijn dagelijkse cijfers
Ik heb mijn setup twee weken bijgehouden op 1.2 en twee weken op 1.3 nightlies. Niet wetenschappelijk, maar consistent genoeg om nuttig te zijn.
Geheugengebruik tijdens 4-uur durende Claude Code-sessies:
- Ghostty 1.2: gemiddeld 2,8 GB piek, soms piekte het tot 6+ GB
- Ghostty 1.3: gemiddeld 380 MB piek, nooit meer dan 500 MB
Geforceerde afsluitingen per week (vanwege geheugen/responsiviteit):
- Ghostty 1.2: 3-4 keer
- Ghostty 1.3: nul
Tijd besteed aan het instellen van mijn split-layout elke ochtend:
- Ervoor (handmatig): ~2 minuten
- Erna (AppleScript-automatisering): ~3 seconden
Keren per dag dat ik scrollback-zoeken gebruikte:
- Week één: misschien 5-6 keer
- Week twee: 15-20 keer (als je het eenmaal hebt, gebruik je het constant)
Bespaarde clipboard-opmaak-rondes per week:
- Ervoor: handmatig 10-15 plakoperaties van terminaloutput herformatteren
- Erna: geen herformattering nodig
De snelle winsten zijn de geheugenlekfix en de AppleScript-setupautomatisering. Die leveren direct resultaat op. De langetermijnwinsten komen voort uit het scrollback-zoeken dat onderdeel wordt van je spiergeheugen en de rich clipboard die een constante lichte ergernis wegneemt.
De echte maatstaf die ik niet kan kwantificeren is vertrouwen. Ik maak me geen zorgen meer dat mijn terminal instort tijdens een lange sessie. Ik controleer nerveus de Activity Monitor niet meer. Ik werk gewoon. Die vermindering van mentale overhead verschijnt in geen enkele benchmark, maar als je dezelfde problemen hebt gehad, weet je precies wat ik bedoel.
Je terminal verdient ook een upgrade
Die sessie om 1 uur 's nachts waarbij mijn terminal 37 gig RAM at? Ik heb gisteravond dezelfde workflow gedraaid op Ghostty 1.3. Zelfde project, zelfde Claude Code-agent, zelfde marathon van vier uur. Aan het einde opende ik uit gewoonte de Activity Monitor.
412 megabyte. De fans zijn nooit opgegaan.
Dit is wat ik wil dat je doet voor het einde van de week: download Ghostty 1.3, stel de scrollback-buffer en split-layout in uit de implementatiesectie hierboven, en voer je normale workflow één volledige dag uit. Probeer het niet te evalueren. Werk gewoon. Aan het einde van de dag merk je iets vreemds — je zult nul minuten hebben besteed aan nadenken over je terminal. En dat is precies het punt. Het beste gereedschap is het gereedschap dat onzichtbaar wordt.
Ghostty 1.3 is gratis, open-source, MIT-gelicenseerd en ondersteund door een non-profit via Hack Club. Mitchell Hashimoto en de 125+ bijdragers die hieraan bouwen, jagen niet op inkomsten of engagementstatistieken. Ze bouwen de terminal die ze elke dag willen gebruiken. Na twee weken op 1.3 kan ik je zeggen — ze komen gevaarlijk dicht bij perfect.
Wat is de ene terminale ergernis die je al jaren tolereert? De ene die je gewoon hebt geaccepteerd als "zo werkt een terminal"? Want de kans is groot dat Ghostty die al heeft opgelost.
Samen aan de slag
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur schalen? Ik help je graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
