Beste antwoord
Ik kan niet geloven dat nog niemand Vim heeft gezegd. Vim!
Zodra u de eerste leercurve voorbij bent, het is een geweldige tool voor het automatiseren van alledaagse programmeertaken. Ik zal je een voorbeeld geven dat ik eerder vandaag heb gebruikt.
Ik was een XML-lezersklasse aan het maken (overgenomen van een XML-basisklasse) voor een onderdeel van onze codebase. De .xml zag er ongeveer zo uit.
...
Het probleem was (vanwege de bestaande architectuur) dat deze veldwaarden allemaal privégegevensleden moesten zijn van Some\_XML\_Class in de code. Wat betekende dat ik op het punt stond veel zinloos werk te doen om field-one om te zetten in std :: string m\_field\_one , voor elk van deze velden.
Dat is waar Vim binnenkomt. In plaats van 20 minuten te doden door het op de moeilijke manier te doen. Ik heb het bovenstaande gedeelte van de code geplakt en een macro opgenomen.
^xistd::string m\_
Deze reeks vim-opdrachten doet het volgende. Gaat naar het eerste teken van de regel en verwijdert het (‘ wordt verwijderd). Gaat in invoegmodus en voegt std :: string m\_ toe aan veld . Vervolgens vindt het de eerste keer dat ‘-’ voorkomt en wordt dit vervangen door ‘\_’. Vervolgens springt het naar het einde van het woord field\_N , gaat het naar de toevoegmodus en voegt een puntkomma toe en verplaatst de cursor een naar rechts. Dus dat hebben we nu
std::string m\_field\_one;value="value1" />
Maar we zijn nog niet klaar. We gaan dan naar de commandomodus en verwijderen de rest van de regel en springen naar de volgende regel. Zodat we hebben:
std::string m\_field\_one;
Merk op dat regel één perfect is opgemaakt en dat de cursor momenteel op regel twee staat.
In dit volgende deel als de magie binnenkomt. Voordat we dat commando uitvoerden, begonnen we met het opnemen van een macro om a te registreren. . Gebruik het commando q gevolgd door a . Het volledige commando wordt dus als volgt gemaakt (waarbij de laatste q wordt gebruikt om de beëindiging van de macro aan te geven).
qa^xistd::string m\_
Roep nu die macro op met het Vim-commando:
@a
Het voert de macro opnieuw uit en formatteert automatisch uw volgende regel:
std::string m\_field\_one;
std::string m\_field\_two;
Maar wacht, we hebben nog steeds N-2 lijnen met een vergelijkbare structuur! Laten we aannemen dat in dit geval N gelijk was aan 100. Geen probleem. We typen gewoon het commando:
98@a
Hiermee wordt de bovenstaande macro 98 keer uitgevoerd, waarbij automatisch de rest van uw code wordt opgemaakt !! We hebben nu:
std::string m\_field\_one;
std::string m\_field\_two;
std::string m\_field\_three;
...
std::string m\_field\_ninetynine
std::string m\_field\_onehundered;
Verbazingwekkend .
* PS: in het begin lijken deze commandos misschien vreemd en eng voor je, maar als je eenmaal wat tijd met Vim als je primaire editor hebt doorgebracht, worden ze een tweede natuur. De voorbeeldmacro kostte me 10 seconden om te schrijven en bespaarde enorm veel tijd.
* PPS: Ik weet dat de voorbeeldcode behoorlijk dom is, maar ik heb hem alleen gebruikt om een punt te illustreren. In de echte wereld zul je echter soortgelijke gevallen tegenkomen.
Antwoord
Bedankt voor het vragen.
Ik kwam hier in eerste instantie om te waarschuwen voor een dergelijk doel, alleen gebaseerd op over de titel … In feite zou je vandaag een teksteditor schrijven omdat:
- Je een heel specifieke behoefte hebt (maar in dit geval kun je nog steeds beter beginnen vanuit een bestaande basis, in plaats van helemaal opnieuw beginnen, tenzij je heel nieuwe ideeën hebt);
- OF je denkt dat dat een interessante oefening in programmeren is; dat is inderdaad je doel.
Omdat, eerlijk gezegd, als je je droomeditor niet kunt vinden in de honderden, zo niet duizenden bestaande, je erg kieskeurig bent!; -)
Ik kwam ook in de verleiding om te zeggen dat het schrijven van een teksteditor vanaf het begin een beetje ontmoedigend kan zijn voor een beginner; laten we zeggen dat het een taak van gemiddeld niveau is: een beetje moeilijk voor een absolute beginner, een keer te doen je krijgt wat ervaring.
Dat gezegd hebbende, ik schreef mijn eigen teksteditor toen ik nog een beginner was: net afgestudeerd aan de universiteit, maar een beetje gecodeerd in C, zonder echt project. Maar ik zat op een pc met SCO Unix en had alleen vi als editor. En ik vind het niet leuk vanwege de twee modi (navigatie versus editie) die me altijd in de war brengen (beginnen met typen, mijn tekst pas zien na de eerste i …).
Dus ik ben net begonnen met het coderen van mijn editor in C, met Curses als interface, het maken van mijn eigen datastructuren (waarschijnlijk inefficiënt, maar we hebben destijds met kleine bestanden te maken gehad), enz.
Ik had veel plezier, ik heb veel geleerd, en toen andere gebruikers het ook begonnen te gebruiken, ontdekte ik dat ze altijd onverwachte dingen doen, zoals het mixen van tabbladen en spaties … 🙂
Nogmaals, als je een totale beginner bent, zou je moeten beginnen met kleinere projecten, om meer te weten te komen over de basis van de taal (loops, arrays, etc.), over datastructuren, hoe je tekstbestanden moet lezen en schrijven, etc.
Het is moeilijk te adviseren voor één taal … Voor een JVM-gebaseerd project zou ik Ceylon gebruiken, misschien met JavaFX of SWT. Voor een “close to the metal” -project zou ik Rust gebruiken (er is een startproject over het schrijven van een teksteditor in Rust, lijkt veelbelovend), terwijl anderen zouden adviseren om C ++ te gebruiken (wat misschien overweldigend is voor een beginner!). Voor een gemakkelijkere taal zou Lua misschien een goede match zijn (een ander zou aanraden om Python te gebruiken, maar ik heb er geen ervaring mee). Of misschien JavaScript, met Node.js en het Electron-platform, een trending-optie … (Daar zijn Atom, Visual Studio Code en Brackets mee geschreven. Maar dat is “amper” vanaf nul, aangezien ze bestaande JS-code-editors gebruiken. )
Algemeen advies: ontwerp eerst je datastructuur (de tweedelige strategie die door het Scintilla-project wordt gebruikt is goed; touwen, zoals gebruikt door het Rust-project, zijn iets meer / te veel geavanceerd), hoe u manipuleert gegevens: hoe voegt u een teken, een regel, een selectie, enz. toe of verwijdert u deze.
Denk dan aan de gebruikersinterface. Idealiter scheidt u de twee (gegevensverwerking en gegevensweergave). Op deze manier kan op een dag je kunt het UI-doel wijzigen (van Swing naar JavaFX, van GTK + naar Qt, wat dan ook) met weinig tot geen wijzigingen in je basislogica. Goed voor draagbaarheid.