Hoe ik mijn development omgeving integreer

Lang geleden toen ik nog niet zo heel veel voor mezelf programmeerde had ik een Amiga met daarop een programma editor waarbinnen je commando's kon uitvoeren.

Op Windows werd ik tijdens frustraties over editors via posts op de Python mailing list gewezen op het bestaan van een programma genaamd SciTE.

Veel later liep ik tijdens het browsen eens tegen een artikel over VI aan dat me deed besluiten het nog eens te proberen met... een programma editor waarbinnen je commando's kon uitvoeren. Scite heeft dat wel een beetje, maar dan moet het via het menu of een toetsencombinatie. Je kunt weliswaar een argumentendialoog op laten komen maar met een command line kun je toch net even iets meer.

Tussendoor heb ik nog een editor gebruikt (JEdit) waarmee je d.m.v. plugins op een IDE-achtige manier allerlei deelvenstertjes kon laten starten met nuttige functies erin zoals een filebrowser en wat niet, maar dat heeft uiteindelijk niet veel indruk achtergelaten.

Dit alles om een soort inleiding te maken op het verhaal dat ik geen kant-en-klare IDE gebruik in mijn programmeerwerk, maar juist een omgeving die ik zelf integreer en ook niet altijd in die vorm gebruiken wil.

Toen ik een beetje door kreeg wat ik altijd gebruik (een of meer editor vensters, minimaal één terminal venster, een zelfgebouwd tooltje om onder andere wat git commando's te vergemakkelijken) en waar ik nog meer behoefte aan had (zoeken in geselecteerde bestanden) ben ik een script gaan maken om dat allemaal in één keer op te kunnen starten.

Het gebruikt een configuratiebestandje dat twee dingen definieert: een aantal namen om een verzameling van files aan te duiden, en een lijstje van tools dat ik wil kunnen opstarten. Het script opent dan voor mij voor elke fileverzameling een editor en als dat in de configuratie staat een zoekprogramma, en afhankelijk van wat verder in de lijst staat een terminal in een groot venster en mijn eerder genoemde repository tool. Modulair programmeur als ik ben opgegroeid is dit een script dat weer andere scriptjes aanroept.

Om dit alles in één keer af te sluiten heb ik een ander scriptje dat gebruik maakt van de proces ids die het andere script heeft vastgelegd om de gestarte taken af te sluiten. dat is gelijk wat me steeds dwarszat bij deze methode, want de taken worden met kill de nek omgedraaid en dat is een manier om programma's af te sluiten waar ik eigenlijk niet zo dol op ben. Een ander nadeel is dat ik de history van de terminal niet bewaard blijft op deze manier.

Dus bedacht ik een manier om in plaats van een enkel script los te laten op een configuratie per softwareproject, per softwareproject een script te laten genereren op basis van die configuratie en dat uit te voeren binnen een terminalsessie in plaats van vanuit een terminalsessie. In Unix-termen doe je "source" in plaats van 'execute", zeg maar.

Dit werkt ook, maar heeft weer het nadeel dat het script opnieuw gegenereerd moet worden wanneer de configuratie verandert en dat ik niet meer alles in één keer kan afsluiten (hoewel ik daar nog wel eens iets op kan proberen te vinden).

Daarnaast stoor ik me een beetje aan de logheid van dit alles. Het voelt toch een beetje als overkill als ik even iets in één specifiek programma wil aanpassen of onderzoeken.

Daarom heb ik de scripts die ik in het session script aangepast zodat ze meer mogelijkheden hebben en daardoor kan ik ze aanroepen met een projectnaam en ofwel een modulenaam ofwel een naam uit een van de configuratiefiles om zo de gewenste verzameling modules aan te roepen om te openen. Dat geldt zowel voor de editor als voor het zoekprogramma en op deze manier kan ik me beperken tot het aanroepen van wat ik op een zeker moment nodig heb in plaats van alles tegelijk te moeten doen.