Beste svaret
Jeg kan ikke tro at ingen har sagt Vim ennå. Vim!
Når du kommer over den innledende læringskurven, det er et fantastisk verktøy for å automatisere bort verdslige programmeringsoppgaver. Jeg vil gi deg et eksempel som jeg brukte tidligere i dag.
Jeg opprettet en XML-leserklasse (arvet fra en base XML-klasse) for en komponent av kodebasen vår. .Xml så ut som dette.
...
Problemet var (på grunn av den eksisterende arkitekturen) at disse feltverdiene alle trengte for å være private data-medlemmer av Some\_XML\_Class i koden. Noe som betydde at jeg var i ferd med å gjøre mye meningsløst arbeid med å konvertere field-one til std :: string m\_field\_one , for hvert av disse feltene.
Det er der Vim kommer inn. I stedet for å drepe 20 minutter å gjøre det på den harde måten. Jeg limte den ovennevnte delen av koden og spilte inn en makro.
^xistd::string m\_
Denne serien med vim-kommandoer gjør følgende. Går til den første ruten på linjen og sletter den (‘ blir slettet). Går inn i innsettingsmodus og legger std :: string m\_ til felt . Så finner den den første forekomsten av ‘-’ og erstatter den med ‘\_’. Deretter hopper den til slutten av ordet felt\_N , går i tilføyingsmodus og legger til et semikolon og flytter markøren en til høyre. Så nå har vi
std::string m\_field\_one;value="value1" />
Men vi er ikke ferdige. Vi går deretter inn i kommandomodus, og sletter resten av linjen, og hopper ned til neste. Slik at vi har:
std::string m\_field\_one;
Merk at linje en er perfekt formatert, og markøren er for øyeblikket på linje to.
Denne neste delen hvis der magien kommer inn. Før vi kjørte den kommandoen, begynte vi å spille inn en makro for å registrere a. . Ved hjelp av kommandoen q etterfulgt av a . Slik gjør du den komplette kommandoen som følger (der den endelige q brukes til å indikere avslutningen på makroen).
qa^xistd::string m\_
Nå, hvis vel, kall den makroen ved hjelp av Vim-kommandoen:
@a
Den kjører makroen på nytt og formaterer automatisk din neste linje:
std::string m\_field\_one;
std::string m\_field\_two;
Men vent, vi har fortsatt N-2 linjer med lignende struktur! La oss anta at i dette tilfellet var N lik 100. Ikke noe problem. Vi skriver ganske enkelt kommandoen:
98@a
Dette kjører ovennevnte makro 98 ganger til, og formaterer automatisk resten av koden din !! Vi har nå:
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;
Stupendous .
* PS: Først kan disse kommandoene virke fremmed og skumle for deg, men når du har brukt litt tid med Vim som din primære redaktør, blir de andre natur. Eksempelmakroen tok meg 10 sekunder å skrive, og sparte enormt mye tid.
* PPS: Jeg vet at eksempelkoden er ganske dum, men jeg brukte den bare for å illustrere et poeng. Men i den virkelige verden vil du kjøre på lignende saker.
Svar
Takk for at du spurte.
Jeg kom hit først for å advare mot et slikt mål, bare basert på tittelen … I utgangspunktet ville du i dag skrive en tekstredigerer fordi:
- Du har et veldig spesifikt behov (men i dette tilfellet, bør du fortsatt starte fra en eksisterende base, i stedet for går fra bunnen av, med mindre du har veldig nye ideer);
- ELLER du synes det er en interessant øvelse i programmering; som virkelig er ditt mål.
For, ærlig talt, hvis du ikke finner drømredaktøren din i hundrevis, om ikke tusenvis av eksisterende, er du veldig kresen!; -)
Jeg var også fristet til å si at å skrive en tekstredigerer fra bunnen av kan være litt skremmende for en nybegynner. La oss si at det er en oppgave på mellomnivå: litt vanskelig for en absolutt nybegynner, gjøres en gang du får litt erfaring.
Når det er sagt, skrev jeg min egen tekstredigerer mens jeg fremdeles var nybegynner: nylig ute av universitetet, kodet bare litt i C, uten noe reelt prosjekt. Men jeg var på en PC med SCO Unix som bare hadde vi som redaktør. Og jeg misliker det på grunn av de to modusene (navigasjon mot utgave) som alltid forvirrer meg (begynner å skrive, ser teksten min bare etter første jeg …).
Så jeg begynte nettopp å kode editoren min i C, ved å bruke Curses som grensesnitt, lage mine egne datastrukturer (sannsynligvis ineffektiv, men vi håndterte små filer på den tiden) osv.
Jeg hadde det veldig gøy, jeg lærte mye, og da andre brukere begynte å bruke det også, fant jeg ut at de alltid gjør uventede ting, som å blande faner og mellomrom … 🙂
Igjen, hvis du er en nybegynner, bør du begynne med mindre prosjekter, for å lære om grunnleggende språk (sløyfer, matriser osv.), Om datastrukturer, hvordan du leser og skriver tekstfiler osv.
Det er vanskelig å gi råd til ett språk … For et JVM-basert prosjekt vil jeg bruke Ceylon, kanskje med JavaFX eller SWT. For et «nærmetallet» -prosjektet vil jeg bruke Rust (det er et startprosjekt om å skrive en tekstredigerer i Rust, virker lovende), mens andre vil råde deg til å bruke C ++ (som kan være overveldende for en nybegynner!). For et enklere språk ville Lua kanskje passe bra (andre vil anbefale å bruke Python, men jeg har ingen erfaring med det). Eller kanskje JavaScript, med Node.js og Electron-plattformen, et trendingalternativ … (Atom, Visual Studio Code og Brackets har blitt skrevet med det. Men det er knapt «fra bunnen av når de bruker eksisterende JS-kodeditorer. )
Generelt råd: design først datastrukturen din (den todelte strategien som brukes av Scintilla-prosjektet er god; tau, som brukt av Rust-prosjektet, er litt mer / for mye avansert), hvordan du manipulerer data: hvordan du legger til eller fjerner en røye, en linje, et utvalg osv.
Tenk så på brukergrensesnittet. Ideelt sett skiller du de to (datahåndtering og datavisning). På denne måten du kan endre UI-målet (fra Swing til JavaFX, fra GTK + til Qt, uansett) med liten eller ingen endringer i baselogikken din. Bra for bærbarhet.