Neovim

Címkék

Érdekes kezdeményezés a Neovim a GitHub-on. A projektleírás azzal nyit, hogy a Vim egy erőteljes editor egyre nagyobb felhasználói bázissal és annak ellenére, hogy az eszköz közel két évtizedes, az emberek még mindig bővítik, fejleszteni akarják. De vannak problémák. A 20 év alatt összejött 300 ezer C89 kódsor, amit kevés ember ért, vagy kevésnek van gusztusa hozzányúlni. A projekt azt is problémásnak tartja, hogy a Vim-nek egy karbantartója van Bram Moolenaar személyében, aki rendkívül óvatos a patchek elfogadásakor, hiszen ha egy változtatás része lesz a Vim-nek, akkor az új kód onnantól az ő felelőssége.

A Neovim projekt szerint ezek a problémák nagyon megnehezítik az új funkciók és hibajavítások beolvasztását a Vim core-ba. A megoldást szerintünk a Neovim adhatja.

A közösséghez a Freenode-on levő #neovim IRC csatornán lehet csatlakozni. A részletek elolvashatók a projekt GitHub oldalán.

Hozzászólások

> A 20 év alatt összejött 300 ezer C89 kódsor, amit kevés ember ért,
> vagy kevésnek van gusztusa hozzányúlni.

Hová lett a világ? :(

Nem is feltétlenül az ANSI C-vel lenne a gond, hanem hogy egy 20 éves kódban iszonyatos mennyiségű gányolás lehet, ahogy jöttek be az új feature-ek. Lehet, hogy
tized annyi kódból, háromszor olyan karbantarthatóra át lehetne írni... csak ugye ez bazi nagy meló, amit eddig senki nem mert bevállalni..

érdekelne hogy ha az ANSI C-t nem értik, akkor miben gondolták megírni a sajátjukat? mert akkor c++ kizárva esélyesen

Az én olvasatomban nem a C89-cel van a baj, hanem konkrétan ezzel a C89-ben megírt 300000 sorral. (Az angol nyelv szépsége, hogy mindenki úgy érti félre, ahogy akarja. :-) ) Másrészt a linkelt bejelentést végigolvasva kiderülnek ennél sokkal fontosabb részletek is.

-----

(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-

Bennem inkább az a kérdés merül fel, hogy tényleg kell-e egy karakteres szövegszerkesztőbe 300.000 sor... Gyorsan megnéztem: a 3.7-es joe 43.000 sorban elfér, és az is tele van fölösleges funkciókkal, amit a kutya se használ. Ezek alapján a vim megérett a pokolra takarításra.

Úgy látom nagyon nem ismered a Vim-et, nem "egy karakteres szövegszerkesztő", annál sokkal több.
/Ráadásul van grafikus felülete is: gVim (Gnome), mVim (Mac)/

Inkább az IDE-kkel lehet összehasonlítani.
Kb. az a kategória, ahol az Emacs, Eclipse, IntelliJ, Visual Studio, ... szerepel.

Mélyebben én is csak mostanában kezdek megismerkedni vele, minél inkább megismerem, annál inkább lenyűgöz.
Érdemes egy-két hétvégét rászánni! ;)

Ja, nagyon jó tutorialokat láttam arra, hogy hogyan csináljam meg önmagamnak azt, amit a VS/Eclipse már tud. Kössz, de ez így lófasz. Lehet, hogy a vim nagyon jó kódfosásra, de annál azért már jóval továbbhaladott a technika.

Pl. amikor a debugolás itt tart: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-8…

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kinek a pap, kinek a papné. Attól, hogy neked nem tetszik, attól még a vim használható mint IDE, az általad felsorolt funkciók valamilyen szinten benne vannak.

Azt láttad, hogy a debugger canvashoz vs 2010 ultimate kell? Meg, hogy halott projekt? Nem gáz olyan fordítót használni amiben még snprintf sincs?

"Azt láttad, hogy a debugger canvashoz vs 2010 ultimate kell?"

...és? .NET 4 a target nálam jelenleg.

"Meg, hogy halott projekt?"

Igen, anyázom is rendesen. Van az új VS-ekben 1-2 dolog, ami félig hasonló módon próbál segíteni átlátni a kódot, de debugolásra és edit&continue aktív használatára alkalmatlan. Sajnos.

"Nem gáz olyan fordítót használni amiben még snprintf sincs?"

Mimimimimimimimi? Mióta a fordító "tartalmazza" a függvénykönyvtárat? Másrészt miután általában C#-ra fejlesztek VS-ben, nem igazán izgat, hogy a C99-ből mit támogat és mit nem. (Abba már bele se megyek, hogy az IDE-khez mi köze).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mimimimimimimimi? Mióta a fordító "tartalmazza" a függvénykönyvtárat?

Nem a fordító, hanem a VS2010 tartalmazza a fordítót is, meg az SDK-t is. Vagy nem?

Másrészt miután általában C#-ra fejlesztek VS-ben, nem igazán izgat, hogy a C99-ből mit támogat és mit nem. (Abba már bele se megyek, hogy az IDE-khez mi köze).

Csak annyi köze van, hogy a VS 2010-ben, ami szerinted IDE, benne van fordító, meg az SDK is. És e remek debugger miatt kénytelen vagy azt használni. De biztos egyszerű használni egy újabb fordítót is régi VS-sel igaz?

Az rendben, hogy téged ez nem mind izgat, de akkor miért szólsz valakinek akit meg az nem izgat, hogy milyen C# debugger van a vimben?

"Az rendben, hogy téged ez nem mind izgat, de akkor miért szólsz valakinek akit meg az nem izgat, hogy milyen C# debugger van a vimben?"

A vita onnan indult, hogy vim egy lapon emlitendo, mint a VS, Eclipse meg a tobbi IDE. Csak epp semmi olyat nem tud, ami miatt IDE-nek lehetne nevezni. a Vim egy szovegszerkeszto. Van benne syntax highlight ehhez-ahhoz, hozza lehet meg reszelni ezt-azt, de ettol meg fenyevekre van attol, hogy IDE-nek lehessen nevezni.

Magam is hasznalok Notepad++-t, mikor mondjuk egy <100 soros PHP scriptet irok, de attol meg azt sem nevezem IDE-nek.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Jaj, gyerekek, akkor bedobtok egy snprintf implementációt a projektbe. Félálomban is összedobok egyet egy óra alatt, de aki lusta, kimásolhatja a kedvenc libc forrásából. Most komolyan, ennek ekkora feneket keríteni?

Én is rühellem a billy összes szarát, de nem pont ezért szarkupac az egész...

Nem nagy ügy, persze, de nem csak erről van szó, hanem sok másról a C99-ből, C könyvtárból, ami nincs a VS2010-zel érkező fordítóban/SDK-ban.

Btw. good luck bedobni egyet a kedvenc libc forrásból. GNU libc nem játszik a licenc miatt, freebsd snprintf meg pl. így néz ki:
http://fxr.watson.org/fxr/source/stdio/snprintf.c?v=FREEBSD-LIBC;im=exc…

Ezt csak úgy be lehet dobni VS-ba?

Nem tudom, szerintem a C99 előtt is volt világ. Én mondjuk írtam akkoriban is már programokat C-ben, olyat is, ami n platformon volt kénytelen fordulni. Meg lehetett csinálni, és nem őszültem bele.

Akinek meg abból a FreeBSD-s __vfprintf-ből akkora gondot okoz összeollózni egy snprintf-et, az tényleg inkább ne írjon C-ben programot...
A licenszdolgot se értem: LGPL, kirakod egy külön dll-be, és jónapot.

Ez a szál onnan indult, hogy milyen egy modern IDE, hogy "kell", hogy kinézzen egy modern debugger environment.

A szépséghiba az, hogy a "modern" debuggert már nem fejlesztik, és egy egyébként elavult fejlesztőkörnyezetet kell használni hozzá.

Erre volt példa az snprintf, lehet, hogy nem volt jó példa. De akkor tessék, ha csak windowsra fejlesztesz c++-ban, akkor ezekről kell lemondanod, ha ezt a debuggert akarod használni:
http://msdn.microsoft.com/en-us/library/vstudio/hh409293(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/hh409293.aspx

Az megvan, hogy a VisualC++ egy C++ fordító es nem C99 fordító?

(Debugger Canvas meg egyebkent is .NET-het van, csodallom, hogy ez meg nem tűnt fel. Mondjuk meg az alap VC++ Express debug funkcionalitasat sem tudja a vim, innen kezdve tárgytalan az egész.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezzel szemben a valóság az, hogy van benne C fordító.
http://msdn.microsoft.com/en-us/library/bb384838.aspx
"Visual Studio includes a C compiler that you can use to create everything from basic C programs to Windows API applications."

Integráltan debugolni mondjuk éppen tud a vim. Többféle nyelvet is.

"Clewn is a GDB wrapper"

Ez nalam nem meriti ki a tobbfele nyelv tamogatasat. Egyebkent meg fogsz lepodni: erdekel a dolog, mert hasznalok VIM-et eleg sok mindenre, de pont debuggingra egyaltalan nem talaltam normalisan mukodo megoldast.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

A GDB csak a forditott nyelveket tamogatja, Java-t, Ruby-t, Python-t nem tamogat.

Ezzel a Vdebuggal tapasztalatod is van, vagy csak powered by Google? En probaltam par debug modult a Vim-hez, es nem igazan talaltam _hasznalhatot_.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Pfff, fejbol meg nem mondom mar neked, a git repoba pedig nem commitoltam be oket, mert oda csak vegleges megoldasokat teszek (legalabb 3 gep szinkronizal abbol a profilbol, szoval oda nem mukodo, vagy pocsek plugineket nem rakok fel). Foleg rubyhoz keresgelek debuggert egyebkent, van 1-2 olyan Rails projektem, ami eleg kicsi ahhoz, hogy meg vimben kezelheto, de eleg nagy ahhoz, hogy idonkent igeny lenne a debuggingra.

A legtobbszor amugy az a baj, hogy szepen elindul a debugger, meg ott van a konzol, de ennyi, nem tudok a debuggerbol visszajutni a VIM-be pl. egy breakpointnal.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

És miután az IDE azt jelenti, hogy "integrált fejlesztői környezet" (amely egyébként nem azt feltételezi, hogy van hozzá integrálódó valami, hanem azt, hogy az már a csomagban integrálva van), továbbra sem minősül IDE-nek a vim.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Komoly szövegértési probléma lehet, ha még mindig nem esett le, hogy az egy kísérleti bővítmény volt a debugger koncepciójának továbbgondolására. És nem, alapból nincs benne, bővítményként tölthető le. Viszont a vimben alapból semmilyen debugger nincs (ami mondjuk kb. 40 éve alapkövetelmény bármilyen IDE-től...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"amikor a debugolás itt tart" vs. "kísérleti bővítmény volt"

Hát ebből tényleg nem esett le, bocs. Már azt hittem, hogy tényleg itt tart a debugolás, nem fogtam, hogy ez nem komoly. Honnan lehet ezt tudni egyébként, mert én az oldaluk alapján teljesen bedőltem neki, hogy munkára is alkalmas....

"alapból semmilyen debugger nincs"

Na erről nem fogok vitázni az biztos. Szerinted nem IDE, szerintem az (a megfelelő kiegészítőkkel együtt, nyilván). Ezzel nem is vagyok egyedül szerintem:

Developers who favor command-line oriented tools can use editors with support for many of the standard Unix and GNU build tools, building an IDE with programs like Emacs or Vim.
http://en.wikipedia.org/wiki/Integrated_development_environment

Ahhoz képest, hogy szerinted munkára nem alkalmas, teljesen jol mukodik.

De igen, a vim mindent tud, amit a vs/eclipse/stb, csak valahogy a vegen mindig kiderul, hogy megse, maximum, ha valaki megepiti belole az idejet.

De ugy érzem, ez mar részedről csak trollkodas, mikor a vimet idenek nevezed, mikor semmi nincs benne alapbol egy kis syntax highlighten kivul, az autocompletetol a debugon at a mindenféle egyeb kodvizualizalason, profilen, stb. at max valami felig-meddig működő megoldast lehet hozzahackooni, addig azokat a bővítményeket, amelyek az IDE-k eseten a meglévő funkcionalitast bővítik (értsd: alapbol tobbet tudnak, mint a szethakkolt vimed, legalabbis az SW fejlesztést támogató dolgokban), azokat szimplán munkára alkalmatlannak nevezed. Hat kössz, inkabb nézz korul, hogy mi a helyzet a nagyvilágban.

---------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Lehet én nem értem az angolt, de mintha itt is azt írná, hogy egyesek IDE alapnak használják (valahol mégiscsak egy "felhízlalt" szövegszerkesztő egy IDE) és készítenek belőle "IDE-t" (topicban már ki lett tárgyalva ennek nem túl meggyőző eredménye), és nem azt állítja, hogy IDE lenne.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ahhoz képest, hogy szerinted munkára nem alkalmas, teljesen jol mukodik.

TE mondtad, hogy "kiserleti bovitmeny", en meg bedoltem neked. Az a baj, hogy elhiszem amit mondasz, pl. hogy a VS-ben nincs C fordito, aztan kiderul, hogy megis van.

De igen, a vim mindent tud, amit a vs/eclipse/stb, csak valahogy a vegen mindig kiderul, hogy megse, maximum, ha valaki megepiti belole az idejet.

Senki se allitotta, hogy mindent tud.

azokat szimplán munkára alkalmatlannak nevezed.

Megegyszer, te nevezted "kiserleti bovitmenynek", akkor ez mint jelent? Vagy megint csak fullentettel? :)

Hat kössz, inkabb nézz korul, hogy mi a helyzet a nagyvilágban.

Úgy érted használjak Visual Studiot? :) Hát használnék én, de valahogy nem megy benne a C++-11. Meg nincs beleintegrálva a git.

Partially. Igazabol a gdb-vel sem integralodik annyira, amennyire kellene, mindent, amit meg akarsz tenni, valojaban a gdb-ben kell megtenned, a vim csak annyi segitseget ad - ha jol ertettem az oldalt, amit linkeltel - hogy oda tud ugrani, ahol a gdb all.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Sok ilyen rendszer van, ahol egész más szemlélet kell, mint a GUI-s csodaprogramok egérrel való bökdösése.

Pl. Latex kiadványszerkesztésre, AwesomWM ablakkezelésre, Git parancssori használata, ...
Ezeknek a tanulási görbéje általában valamivel nagyobb, mint a GUI-s megfelelőjüké, cserébe jó beállításokkal, megfelelő testreszabással, kisebb erőforrás igény mellett hatékonyabb lehet a munka és akár jobb eredményre is vezethet.

Félreértés ne essék, nem azt mondom, hogy ezek jobbak és azok rosszak, csak halkan annyit, hogy nem kell egyik oldalt sem lesajnálni, főleg, ha nem értesz azon rendszerekhez.

Azt nem vitatja senki, hogy a fenti IDE-k bizonyos dolgokból sokkal többet tudnak, mint a Vim. Itt inkább az a kérdés, hogy a Vim is tekinthető-e IDE-nek és mikor jobb, mint a fenti IDE-k.

A fenti IDE-k sem tudnak megtámogatni minden nyelvet és mindenféle rendszert.
Nagyjából itt jön képbe a Vim, amikor olyan rendszereket, nyelveket kell használnod, amiket a nagy IDE-k nem támogatnak, vagy egyszerre több mindent kell használnod. Illetve olyankor, ha nem túl erős fejlesztői gépen vagy kénytelen időnként dolgozni, pl. laptop.

A konkrét kérdésre is válaszolva. Vannak olyan fejlesztési forgatókönyvek, ahol nem igazán szükséges a debug és a profile, vagy, ha valamelyest igen, akkor ki lehet váltani naplózással (logolással), ami egyébként is szükséges. Lehet olyan megoldás is, hogy ha nagyon szükséges valamit profilozni, akkor arra időnként egy profiler eszközt bevetnek, de a napi munkához általában nem használják az egyes fejlesztők.

Deployment, unit testing és egyéb build rendszerekből meg vannak nagyon jó, nagyon nagy tudású külső eszközök, az Eclipse is előszeretettel használ ilyeneket, pl. az Ant, Maven, Gradle, Sbt (vagy az ősöreg, kis tudású Make ;).

Rengeteg fejlesztőtől hallottam, hogy teljesen Vim-re állt át, illetve van olyan fejlesztő cég is, ahol az elsődleges (ha nem az egyetlen) fejlesztői környezet a Vim (főként Ruby-s fejlesztések), ez a http://hashrocket.com.

Hat, attol fugg, melyik make-ra gondolsz. En a GNU Make-t ismerem, de eddig for ciklust egy make implementacioban sem lattam, mind az alatta futo shell hasonlo parancsara epitett.

A masik meg az, hogy a make es az ANT/Maven jellegu build toolok nem hasonlithatoak ossze, reszben mert masra valo a ketto, reszben pedig tudasban sincs pariban sehol.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

> eddig for ciklust egy make implementacioban sem lattam

Nyilván agyonra nem kerested, mert a korábban már emlegetett GMake mellett pl. a FreeBSD-féle make is tud cklust, igaz ott teljesen eretnek módon kell írni:

.for i in 1 2 3
echo ${i}
.endfor

Szóval lehet itt ekézni másokat, hogy ismerik vagy nem egy alkalmazás funkcióit, de akkor legyük már igényesek, és mi is ismerjük meg a túloldalt. Nem feltétlenül ebben a szintaxisban ugyan, de vagy 20 éve tud ilyesmit jó pár make implementáció.

Ami meg az integrált debuggert illeti, jól értem, hogy a vizuál stúdióban olyan hibakereső van, ami nem használható ónállóan debuggolásra, csak a hozzáépített egyéb funkciókkal? Hát legyen nektek. De ugye ebben az esetben nem hívjuk IDE-nek, hisz semmi nincs integrálva semmivel. Ha jól értem ezt a baromi hosszú, értelmetlen, "de-az-én-apukámnak-meg-csébje-van" szálat, akkor nincsen benne C-fordító se, vagy igen, meg nincsen benne debugger se, vagy igen, és editor sincs benne, vagy igen.
Ez a nem-IDE eszköz tartalmaz olyan részt, ami a kód odahányását megkönnyíti (régen tán editornak mondtuk volna), meg valamit, ami egy pontosan meg nem fogalmazott nyelv kompilálását is elvégzi (régen fordítónak híttuk volna, de egyelőre brit tudósok próbálják megfejteni, hogy melyik ismert nyelvre hasonlít az a nyelvjárás amit ismer), sőt valami futtatható előállító rész-izé is van (hint: ezt hívták régen linkernek); hasonlóan olyan komponense is van, amivel nem a kódba kell beleírni az if (debug) { printf( "%d\n", i ) ; } valamit, hanem katténtok az i változóra, és külön ablakban látom az echo $i kimenetét. Régen debuggernek hívtuk volna, de jelenleg ez csak egy szeletkéje ennek a hatalmas kódtömegnek.
Szóval ha ez így van, akkor örüljetek, használjátok. De ne hívjátok IDE-nek, hisz semmi önmagában működő valami nincs semmi mással integrálva. Hívjátok mondjuk Egybehányt Kódelőállító Egyvelegnek (rövide: EKE). És innentől mindenki megnyugszik, aki tudja használni a vimet meg a gdb-t, az is képes korábban megszokott módján további kódot előállítani, meg aki a VS-t ismeri, az is.
És béke leszen a Földön, meg napsütés.

"A fenti IDE-k sem tudnak megtámogatni minden nyelvet és mindenféle rendszert."

Nem is kell. Azt támogassák jól, amihez készült. Ne mindenfélét jobb-rosszabb szinten.

"Vannak olyan fejlesztési forgatókönyvek, ahol nem igazán szükséges a debug"

Bullshit.

"vagy, ha valamelyest igen, akkor ki lehet váltani naplózással (logolással), "

Überbullshit. Az ilyen "de nem kell debug" blődségekből vannak az //echo "lofasz"-ok és a bennfelejtet print_r($asdf); -ekkel teleszarva a PHP-s tákolmányok jelentős része*. Elég szánalmas, amikor valaki úgy áll hozzá, hogy kódot kell módosítani ahhoz, hogy a működését vizsgálja. (Az, hogy ez más nyelveken, pl. C-nél még mivel jár, azt már inkább meg sem említem...)

Az, amikor futás közben berakok egy töréspontot, és látom, hogy hol a hiba, és menet közben átírom a kódot, legyen szó C# vagy korlátozott mértékben C++-ról (vagy Java esetén még töréspont sem kell) és a háttérben beleszerkeszti a futó programba az új kódot az IDE/fordító, azt a csodás vimedben már azért kicsit nehezebben hozod össze, mint egy arra fejlesztett IDE-ben. És azért egy-egy ilyen nem keveset tud dobni a produktivitáson. Persze, meg lehet ragadni ott, ahol a C tartott 40 éve, de azt a pöcsölést nekem nem fizetik.

* Ott a jelenség mondjuk súlyosabb az xdebug nyomoréksága miatt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Nem is kell. Azt támogassák jól, amihez készült. Ne mindenfélét jobb-rosszabb szinten."

Bármilyen hihetetlen, de sokan vannak úgy, hogy inkább használnak egy rendszert, mint 5 másikat, amik valamely részekre vannak optimalizálva.
Ha az az egy rendszer, amit használsz lefed mindent, akkor nyilván lehet az a jó választás.

"Überbullshit. Az ilyen "de nem kell debug" blődségekből vannak az //echo "lofasz"-ok és a bennfelejtet print_r($asdf); -ekkel teleszarva a PHP-s tákolmányok jelentős része*. Elég szánalmas, amikor valaki úgy áll hozzá, hogy kódot kell módosítani ahhoz, hogy a működését vizsgálja. (Az, hogy ez más nyelveken, pl. C-nél még mivel jár, azt már inkább meg sem említem...)"

Úgy látom nem láttál még normális Log rendszert. Azt hogy valamit lehet rosszul csinálni, az nem azt jelenti, hogy az a mérce. Az überfasza VS-sel is lehet benne hagyott print "lofasz"-okat rakni, de ez elég messze áll a logolástól.

Megint a debug erőltetésével jössz, de én nem írtam olyat, hogy azt a Vim-ben kellene erőltetni.

"de én nem írtam olyat, hogy azt a Vim-ben kellene erőltetni."

Értem, szóval szerinted sokkal egyszerűbb
1) egy külön programban végigstepelni,
2) majd átlépni az editorba,
3) megszerkeszteni a kódot,
4) újrafordítani,
5) újraindítani az egészet és
6) eljutni ugyanoda ahelyett, hogy

1) a szerkesztőben ugyanott végigmegyek a kódon, majd ha megtalálom a hibát,
2) átírom a kódot
3) és már az új kód fut tovább.

Intuitív ez a vim valóban.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A debuggolás és a logolás akkor sem tökéletes helyettesek a legtöbb projektben.

Rendes debuggerrel már azelőtt ki lehet szűrni egy csomó dolgot, mielőtt akár egy dev környezetet összelegóznál az alkalmazás alá. Elvi hibát is talán könnyebb levadászni vele, hiszen sorról sorra látod, hogy mit csinál a cucc. Lehet, hogy a kódban olyan hiba van, ami miatt el sem jut odáig, hogy benyögjön valamit a logba.

A log nálam inkább már az exceptionök és társaik világa: előbb legyen egy _ideális_ körülmények között _mindig_ működő alkalmazás, utána a dinamikusan keletkező hibákról meg nyilván ír majd valamit a logba, ami alapján lehet javítani. De egyik lépést sem tartom jónak kihagyni.

> ha nem túl erős fejlesztői gépen vagy kénytelen időnként dolgozni, pl. laptop.

Azért a VS-nek nincs akkora rendszerigénye ám. Nyilván több, mint egy vimnek, de ha a 24 giga rammal megáldott dev gép elől átültem a 4 giga rammal szeránykedő laptopom elé, nem állt meg a világ.

> Vannak olyan fejlesztési forgatókönyvek, ahol nem igazán szükséges a debug és a profile, vagy, ha valamelyest igen, akkor ki lehet váltani naplózással (logolással), ami egyébként is szükséges.

What did I just read? Hirtelen nem tudok elképzelni ilyen forgatókönyvet már azon kívül, hogy valaki hegeszt egy pársoros, egyszer használatos szkriptet valamire.

"Azért a VS-nek nincs akkora rendszerigénye ám. Nyilván több, mint egy vimnek, de ha a 24 giga rammal megáldott dev gép elől átültem a 4 giga rammal szeránykedő laptopom elé, nem állt meg a világ."

Akkor itt nem Rólad volt szó. Eclipse egy közepes projektnél is pár száz MB alatt meg se moccan és még sok ilyen összetevőt tudok sorolni, amiket nem mind lehet elhagyni (böngésző, adatbázis kezelő, ...)

"What did I just read? Hirtelen nem tudok elképzelni ilyen forgatókönyvet már azon kívül, hogy valaki hegeszt egy pársoros, egyszer használatos szkriptet valamire."

Például a TDD-nél (Test-driven development), ott nagyon ritkán van szükség debugra. Amikor meg szükség van, akkor is jobb általában egy log rendszer, mert pl. nem a program sima futása okozza a hibát, hiszen azt a teszt rendszer kiszűri, hanem több komponens összeakadása. Ezek azok a tipikus hibák, amik úgy tűnnek, mintha véletlenül jönnének nagy ritkán. No ezeket szinte lehetetlen kidebuggolni, de naplózással sokkal egyszerűbb rájönni mi okozza.

Részemről egyébként itt befejezem ezen szálat (Saxus részét is), mert nem nagyon látom, hogy ezen információkra valójában kíváncsiak lennétek, inkább egyfajta kötekedést látok csak. Bár leírtad, hogy nem akarsz flamelni, de mégis olybá tűnik.

Mar megbocsass, de szerintem a TDD pont nem erre valo. TDD-nel (pontosabban a jol megirt tesztek eseteben) vizsgaljuk a bemenetet, meg a kimenetet. Azt, hogy maga az algoritmus _belul_ hogy mukodik, azt nem vizsgaljuk, pont azert, mert a teszteknek ez nem feladatuk, illetve a TDD definicioi szerint az algoritmus jol mukodik akkor, ha az adott bemenetre adott kimenetet ad. De ha a teszt elfailedezik, mert nem a megfelelo kimenet jon a megfelelo bemenetre, akkor igenis debuggerrel a legegyszerubb kinyomozni, hogy miert. A logolas nem a debugger helyettesitesere valo, es nem is a print "foobar=#{foobar}" sorok helyettesitesere.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

> Vannak olyan fejlesztési forgatókönyvek, ahol nem igazán szükséges a debug és a profile, vagy, ha valamelyest igen, akkor ki lehet váltani naplózással (logolással), ami egyébként is szükséges.

What did I just read? Hirtelen nem tudok elképzelni ilyen forgatókönyvet már azon kívül, hogy valaki hegeszt egy pársoros, egyszer használatos szkriptet valamire.

Ezek szerint még életedben nem fejlesztettél 8-bites mikrokontrollerre, amiben van 512 byte RAM, output device-ként meg mondjuk szumma kettő darab LED meg egy relé...

Miért? 512 byteon elfér egy vi+C fordító? A ledeken meg kimorzézza a forráskódot, a relé meg bekapcsolja az elektrosokkolót compiler hiba esetén?

Értsd: irreleváns, hogy mire fordítasz. Én speciel mikrokontrollerezni is Eclipse-ből szoktam. Van egy jó automatizált buildrendszerem, azt használom.

És ennek mi köze van ahhoz, amire válaszoltam? Hogy nem tudja elképzelni azt a forgatókönyvet, ahol egész egyszerűen nincs a debugra lehetőség se, tehát irreleváns, hogy a forráskód szerkesztésére használt eszköz tud-e ilyet vagy sem.

Értsd: a vi nem a fordított kód, hanem a szövegszerkesztő, amiben a forráskódot szerkeszted.

Mikrokontrollereken általában nem lehet debuggolni (vagy egyáltalán - nincs is benne erre hardver, vagy praktikusan nem: kell a láb másra; nem tolerálja a periféria vagy a kívül rákötött hardver, ha megállítod a kód futását, meg ilyenek). Logolni akkor lehet, ha van valami értelmes periféria, ahol a log "ki bír jönni", mondjuk egy soros port már jó erre a célra - bonyolultabb perifériákkal (pl. USB) meg az a baj, hogy az azt működtető szoftverrész kell a logoláshoz is, tehát abból a szekcióból nem tudsz logolni, plusz interrupt handlerből se könnyű logolni. Néha egyébként még ez sincs, van egy pár LED, oszt azokat lehet villogtatni.

Szóval az eredeti felvetésre: természetesen nem 100%-os helyettesítői egymásnak, de aki amit nem tud megoldani logolással, az debuggolással se nagyon fogja.

Nem az ANSI C a gond, hanem a C89, es a rengeteg legacy platform tamogatas. Egy csomo altaluk feleslegesnek itelt dolgot mar kidobtak, es elkezdtek refaktoralni. Teljesen vallalhato feladat (mondjuk ahogy a plugineket meg GUI-t tervezik, az meglehetosen naiv, de az mar egy masik kerdes).

--
|8]

Már csak az a nagy kérdés, hogy az általuk feleslegesnek itélt dolgokkal kapcsolatban másnak mi a véleménye. (Rémlik, hogy GCC-fejlesztők leszarták a FreeBSD-fejlesztők által kért változtatásokat; kidobták az a.out formátum támogatást, és nyilván lehet ezt még sorolni a végtelenségig. A "legacy platform" meg kicsit rosszul hangzik. Van grafikuskártya gyártó, aki a nem túl régi kártyáit minősíti ilyenre, van desktop os gyártó, aki a 32-bites x86-ot minősítette így, és ez sokaknak fáj. Persze értem, az majd használ változatlanul vim-et.

Akinek faj, az hasznal majd Vimet tovabbra is, igy van. Neha aldozatokat kell hozni, es ha a fejlesztok 99%-a Linuxon van, es a userek nagyja is, akkor barmi mast supportalni nem eri meg (nem tudom, hogy neovimnel mi a helyzet, es milyen platformokat celoztak meg, altalanossagban mondom).

Elofordul olyan, hogy egy szoftver hirtelen dobja a $kedvenc_platform tamogatast. Ez faj, de ez van.

--
|8]

Emlekszik meg valaki az yzis projektre?
https://github.com/chrizel/Yzis

A kvim-es sracok akartak irni 0-rol egy jol integralhato vim enginet. Sajnos a dolog elhalt.

En nem hiszek egy ekkora projekt refaktoralasaban. Jo ugyan a szandek, hogy a mukodokepesseg folyamatosan megmaradjon, de valahogy az ilyen merteku valtoztatasok nem szoktak megturni a regi kod szerkezetet. Azert kivancsi vagyok es drukkolok nekik. Egy jol integralhato vim enginere nagy igeny lenne. Egy csomo editor / IDE ir maganak kulon vim emulaciot.

Hat, ha tovabbra is alatamasztanak minden valtoztatast tesztekkel, es nem tornek funkcionalitast, en tamogatom a projektet. A Vim Windowsos forditasa nehezkes, lehetne sokkal-sokkal konnyebb is. Viszont arra jo lenne figyelni, hogy a Ruby, Python, Perl, stb. tamogatas Windowson se torjon el...
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

wikin találtam:

You might also want to read :help development.

Head rev buildelés után :help development
output:

E149: Sorry, no help for development

:)