Bedste svar
Jeg kan ikke tro, at ingen har sagt Vim endnu. Vim!
Når du er kommet over den indledende indlæringskurve, det er et fantastisk værktøj til automatisering af verdslige programmeringsopgaver. Jeg giver dig et eksempel, som jeg brugte tidligere i dag.
Jeg oprettede en XML-læserklasse (nedarvet fra en base-XML-klasse) til en komponent i vores codebase. .Xml så noget ud som dette.
...
Problemet var (på grund af den eksisterende arkitektur), at disse feltværdier alle skulle være private datamedlemmer til Some\_XML\_Class i koden. Hvilket betød, at jeg var ved at gøre en masse meningsløst arbejde med at konvertere field-one til std :: string m\_field\_one , for hvert af disse felter.
Det er her Vim kommer ind. I stedet for at dræbe 20 minutter gør det på den hårde måde. Jeg klistrede ovenstående afsnit af koden ind og registrerede en makro.
^xistd::string m\_
Denne serie af vim-kommandoer gør følgende. Går til linjens første tegn og sletter den (slettes). Skifter til indsættelsestilstand og lægger std :: string m\_ til felt . Derefter finder den den første forekomst af – og erstatter den med \_. Derefter springer det til slutningen af ordet felt\_N , går i tilføjelsesfunktion og tilføjer et semikolon og flytter markøren en til højre. Så nu har vi
std::string m\_field\_one;value="value1" />
Men vi er ikke færdige. Vi går derefter i kommandotilstand og sletter resten af linjen og hopper ned til den næste. Så vi har:
std::string m\_field\_one;
Bemærk, at linje en er perfekt formateret, og markøren er i øjeblikket på linje to.
Denne næste del, hvis magien kommer ind. Før vi kørte kommandoen, begyndte vi at optage en makro for at registrere a . Brug kommandoen q efterfulgt af a . Således foretages den komplette kommando som følger (hvor den sidste q bruges til at indikere makroens afslutning).
qa^xistd::string m\_
Hvis du godt kalder den makro nu ved hjælp af Vim-kommandoen:
@a
Den kører makroen igen og formaterer automatisk din næste linje:
std::string m\_field\_one;
std::string m\_field\_two;
Men vent, vi har stadig N-2 linjer med lignende struktur! Lad os antage, at i dette tilfælde var N lig med 100. Intet problem. Vi skriver simpelthen kommandoen:
98@a
Dette kører ovenstående makro 98 gange mere og formaterer automatisk resten af din kode !! Vi har 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;
Stupendous .
* PS: Først kan disse kommandoer virke fremmed og skræmmende for dig, men når du først har brugt lidt tid med Vim som din primære editor, bliver de anden natur. Eksempelmakroen tog mig 10 sekunder at skrive og sparede en enorm mængde tid.
* PPS: Jeg ved, at eksempelkoden er temmelig dum, men jeg brugte den bare for at illustrere et punkt. Men i den virkelige verden vil du løbe på tværs af lignende sager.
Svar
Tak fordi du spurgte.
Jeg kom her oprindeligt for at advare mod et sådant mål, kun baseret på titlen … Grundlæggende skulle du i dag skrive en teksteditor, fordi:
- Du har et meget specifikt behov (men i dette tilfælde skal du stadig starte fra en eksisterende base snarere end går fra bunden, medmindre du har meget nye ideer);
- ELLER du synes det er en interessant øvelse i programmering; hvilket virkelig er dit mål.
For ærligt talt, hvis du ikke kan finde din drømredaktør i hundreder, hvis ikke tusinder af eksisterende, er du meget kræsne!; -)
Jeg var også fristet til at sige, at det at skrive en teksteditor fra bunden kan være en smule skræmmende for en nybegynder; lad os sige, at det er en opgave på mellemniveau: lidt hårdt for en absolut nybegynder, en gang du får lidt erfaring.
Når det er sagt, skrev jeg min egen teksteditor, mens jeg stadig var nybegynder: frisk ude af universitetet, kun kodet lidt i C uden noget rigtigt projekt. Men jeg var på en pc med SCO Unix, der kun havde vi som redaktør. Og jeg kan ikke lide det på grund af dets to tilstande (navigation vs. udgave), som altid forvirrer mig (begynder at skrive, ser kun min tekst efter den første i …).
Så jeg begyndte lige at kode min editor i C ved at bruge Curses som interface, lavede mine egne datastrukturer (sandsynligvis ineffektiv, men vi behandlede små filer på det tidspunkt) osv.
Jeg havde det sjovt, jeg lærte meget, og da andre brugere også begyndte at bruge det, fandt jeg ud af, at de altid gør uventede ting som at blande faner og mellemrum … 🙂
Igen, hvis du er en nybegynder, skal du starte med mindre projekter, lære om sprogets baser (sløjfer, arrays osv.), Om datastrukturer, hvordan man læser og skriver tekstfiler osv.
Det er svært at rådgive om et sprog … For et JVM-baseret projekt ville jeg bruge Ceylon, måske med JavaFX eller SWT. For et “tæt på metal” -projektet vil jeg bruge Rust (der er et startprojekt om at skrive en teksteditor i Rust, virker lovende), mens andre vil råde til at bruge C ++ (hvilket kan være overvældende for en nybegynder!). For et lettere sprog ville Lua måske være en god pasform (andre vil anbefale at bruge Python, men jeg har ingen erfaring med det). Eller måske JavaScript, med Node.js og Electron-platformen, en trendmulighed … (Atom, Visual Studio-kode og parenteser er skrevet med det. Men det er næppe fra bunden, da de bruger eksisterende JS-kodeditorer. )
Generel rådgivning: design først din datastruktur (den todelte strategi, der bruges af Scintilla-projektet, er god; reb, som brugt af Rust-projektet, er lidt mere / for meget avancerede), hvordan du manipulerer data: hvordan man tilføjer eller fjerner en trækol, en linje, et valg osv.
Så tænk på brugergrænsefladen. Ideelt set adskiller de to (datahåndtering og datavisning). På denne måde en dag du kan ændre UI-målet (fra Swing til JavaFX, fra GTK + til Qt, uanset hvad) med ringe eller ingen ændringer i din basislogik. God til bærbarhed.