HOVD 2023 - Kedvenc szövegszerkesztő

HUP

  Itt a HUP Olvasók Választása Díj 2023 szavazás. Az idei HOVD immár a tizennyolcadik a sorban.

  A HOVD 2023-on minden HUP olvasó szavazhat. A HOVD 2023 választás ideje - két hónap - alatt a 20 kategóriában állított jelöltekre lehet majd szavazni.

  Szavazz az alábbi kategóriákban! Kedvenc ...

atom
2% (19 szavazat)
brackets
0% (1 szavazat)
emacs
3% (32 szavazat)
geany
3% (39 szavazat)
kate / gedit / notepad - de/os alap grafikus szövegszerkesztői
9% (103 szavazat)
nano / joe / ed / mcedit / sandy / konzolos egyszerű szövegszerkesztők
15% (176 szavazat)
notepad++
22% (252 szavazat)
sublime text
3% (36 szavazat)
vi, vim / gvim / neovim
21% (245 szavazat)
vscode
21% (243 szavazat)
Összes szavazat: 1146

( kleinie | 2023. 08. 20., v – 10:12 )

Szerkesztve: 2023. 08. 20., v – 10:13

Fel kellett hoznom az Emacs-et a Vscode mellé. De van egy olyan érzésem, ez a fej-fej meletti eredmény nem sokáig lesz így. 😅

Mire leírtam már el is húzott...

Az a baj az emacs-el, hogy az egy OS, nem egy szovegszerkeszto :D Mondjuk a vscode az meg egy webbrowser...

(Es mielott valaki megkerdezne, igen, az emacs-ra szavaztam, mivel az eredeti celjaval ellentetben en szovekszerkesztonek hasznalom :) )

I hate myself, because I'm not open-source.

Ja, a nano-t én se szeretem, bár nem olyan rossz, csak default configban agyrém, hála istennek, aki rászánja az időt, be tudja konfigurálni akármilyenre, lehet bele interface-színeket, kódszínezést tenni, gyorsbillentyűket átdefiniálni, képernyő aljáról és tetejéről a fejléceket, helpet eltüntetni, stb.. De aki ilyen munkát képes belevinni, az inkább tanulja meg a vim-et, jobban jár, jobb időbefektetés. Esetleg akkor érdemesebb már helyette a nano, pico, stb. egyik klónját, a micro-t használni, ami sokkal jobb, Lua makrókkal, pluginekkel bővíthető, kicsit a neovim-re is hasonlít.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez mind nagyon szép, de én egyszerűen csak rühellem, mikor az arcomba ugrik, mint default editor. Nem szeretnék rajta semmit konfigolni. (A terminálos editorokkal egyébként is az van, hogy csodálatos, hogy lehet konfigolni, aki tologatja azt az 1-2-pár gépét, annak akár, de ha random szembejön random gép, akkor ott ezzel a fene szenved)

Azért egy jól elhelyezett export EDITOR=vi (akár rögtön belépés után parancssorban) sokat tud enyhíteni az ilyesmin. De amúgy egyetértek, rohadt idegesítő, hogy a könnyítés jegyében mindenféle bohócságokat be bírnak állítani alapértelmezett karakteres szövegszerkesztőnek.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ja, ezt felejti el az ember, aztán mikor jön, akkor "pánikszerűen" megnézem lent, hogy kell kilépni, aztán exportálok egy editort...

Egyébként én szélesebb közönségnek szóló distroknál tök értem, ezzel elboldogul kb bárki, a vi-al meg rohadtul nem. Csak személy szerint nem szeretem. 

Jo, de a nano legalabb kiirja hogy kell kilepni, a vi-bol meg sok sikert kitalalni ha nem tudod.

Mindig agyfaszt kapok amikor rasshzok valami random busybox-os gepre, ahol csak a busybox vi van mint editor, meg lehet probalkozni szorakozni i meg escape meg dd meg :wq es kb ki is fujt a vi tudasom :D, de inkabb tramp, meg ha csak par sort kell atirni is. (Es ha van opcio felrakok egy qemacs-ot, mint valami minimalis de kb hasznalhato editor...)

I hate myself, because I'm not open-source.

Ja, egyetértek, idegesítő, de a nano configjában ezt ki tudod szedni, hogy ne legyen ez az infobar a képernyőn, meg a billentyűket is át tudod állítani másra, hogy mivel lépjen ki, mivel mentsen, stb.. Nyilván vi-módja nincs, de rendesen bekonfigolva kevésbé idegesítő a nano, mint default konfignban, mert azzal iszonyat szar, valóban, szemem ráng tőle nekem is.

Ez egyben több FOSS programnak is idegesítő tulajdonsága, hogy default beállításokon irtó fosul néznek ki vagy szarul működnek. Pl. Tom's Windows Manager (az X11/X.org beépített ablakkezelője), ratpoison, Openbox, i3wm, dwm, IceWM/JWM sem a legjobb alapkonfiggal, Emacs, vim (kicsit idetartozik), nano, xterm, stb.. Ez azonban csak látszat, mert ahogy utánanéz az ember a konfigurálásnak, rendesen megcsinálja, keres rá a neten témákat, ~/.config/ példákat, onnantól egy sokkal jobb, szebb megoldássá lehet őket gyúrni. Nem is értem, hogy ezt miért csinálják, mert ezekkel az ocsmány default-okkal szinte riasztják el a usereket. Jobb lenne ezekhez valami normálisabb defconfigot mellékelni vagy használni, mert akkor többen esélyt adnának ezeknek.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ja, egyetértek, idegesítő, de a nano configjában ezt ki tudod szedni, hogy ne legyen ez az infobar a képernyőn, meg a billentyűket is át tudod állítani másra, hogy mivel lépjen ki, mivel mentsen, stb.. Nyilván vi-módja nincs, de rendesen bekonfigolva kevésbé idegesítő a nano, mint default konfignban, mert azzal iszonyat szar, valóban, szemem ráng tőle nekem is.

Továbbra sem akarom, egyáltalán nem akarom használni, ha muszáj, akkor pont jó lesz a default működés, ott azon a baron pont elárulja a gombokat, a szerkesztés az hálisten csak gépelés, az nekem elég. És ezt pont nem csinálja pl a vi/vim, amivel kb meg is van szopatva a gyanútlan r=1, szóval jó ez defaultnak.

Ez egyben több FOSS programnak is idegesítő tulajdonsága, hogy default beállításokon irtó fosul néznek ki vagy szarul működnek. Pl. Tom's Windows Manager (az X11/X.org beépített ablakkezelője), ratpoison, Openbox, i3wm, dwm, IceWM/JWM sem a legjobb alapkonfiggal, Emacs, vim (kicsit idetartozik), nano, xterm, stb.. Ez azonban csak látszat, mert ahogy utánanéz az ember a konfigurálásnak, rendesen megcsinálja, keres rá a neten témákat, ~/.config/ példákat, onnantól egy sokkal jobb, szebb megoldássá lehet őket gyúrni. Nem is értem, hogy ezt miért csinálják, mert ezekkel az ocsmány default-okkal szinte riasztják el a usereket. Jobb lenne ezekhez valami normálisabb defconfigot mellékelni vagy használni, mert akkor többen esélyt adnának ezeknek.

Hát, ennek szerintem több oka van: van, hogy az a cél a defaulttal, hogy biztosan működjön, van, aki szerint a minimumra kell törekedni, nem akar mindenféle advanced dolgokat alapból odatenni (vagy azért mert nem akar alapból bloatot, hogy azon sírjanak, vagy azért, mert azt gondolja, hogy nem akarja a user helyett a saját nekem így jó workflowját), vagy simán azért mert szarik rá, featuret akar fejleszteni, az izgi, jó defaultokat csinálni r=1 usereknek meg nem izgi, meg egyébként se érdeklik őt.

Persze, vitán felül áll, hogy a vi az igazi unixos módja a szerkesztésnek, jobban beleillik a unixos filozófiába is. Én is azt preferálom. De azt kell érteni, hogy a Linux meg a többi unixlike rendszer már nem csak néhány rendszergazda, programozó, egyetemi oktató meg kutató rendszere, hanem ki van nyitva mindenféle windowosos meg egyéb omgubuntu-típusú normi tutorialokat követő emberkének, és ők küszködnek a vi-jal, így inkább szokás megtenni valami mást default editornak, tipikusan nano, de pl. FreeBSD-n is a default az easy editor (ee), bár talán telepítéskor átállítható, meg a shell rc-jében, EDITOR és VISUAL változókban, stb..

Másik oldalról viszont be kell látni, hogy a vi is elég pótlék csak, mert aki haladóbb, az úgyis feltesz vim-et, neovim-et, Emacs-et, vagy amit preferál, stb., és használja inkább azt.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Persze, vitán felül áll, hogy a vi az igazi unixos módja a szerkesztésnek, jobban beleillik a unixos filozófiába is. Én is azt preferálom. De azt kell érteni, hogy a Linux meg a többi unixlike rendszer már nem csak néhány rendszergazda, programozó, egyetemi oktató meg kutató rendszere, hanem ki van nyitva mindenféle windowosos meg egyéb omgubuntu-típusú normi tutorialokat követő emberkének, és ők küszködnek a vi-jal, így inkább szokás megtenni valami mást default editornak, tipikusan nano, de pl. FreeBSD-n is a default az easy editor (ee),

Én értem, írtam is. Tisztában vagyok vele, hogy egyéni nyomorom, hogy sajnos terminálban azonnal vi bevitelre kapcsol az izommemóriám.

bár talán telepítéskor átállítható, meg a shell rc-jében, EDITOR és VISUAL változókban, stb..

Ha sok rendszerrel dolgozol, akkor a defaultok felértékelődnek, nem konfigolgat mindenhol ilyeneket az ember, mer a fene se tölt ezzel időt. Jó, ez pont olyan, hogy legtöbbször vi azért van, szóval mordulsz egyet, azt elindítod, de azért volt már olyan, ahova nem lehetett kroozo két szép szeméért telepíteni.

Másik oldalról viszont be kell látni, hogy a vi is elég pótlék csak, mert aki haladóbb, az úgyis feltesz vim-et, neovim-et, Emacs-et, vagy amit preferál, stb., és használja inkább azt.

A saját / kis számú gépen igen. A sima vi meg arra pont jó, hogy az alap dolog menjenek benne, ha meg kell írni három sort, akkor ne akadjon fel az agyam azon, hogy most hogy a picsába kell ezzel az izével savelni, meg, hogy ne legyen ott az inputban, hogy ddpi mire észreveszem, hogy mi ez itt előttem. 

A vi nem csak mentő megoldásnak jó, meg SSH konzolban, hanem pl. azért is érdemes használgatni, mert 1-2 helyen hatékonyabb, mint a vim és társai, mivel nincsenek benne extra funkciók, kényelmi módok (pl. kijelölés mód, online sugó, stb.), extra beállítási lehetőséget, powerline, szkriptelhetőség, stb., és ez rászorít arra, hogy még jobban, eredeti vi-os logikával, és hatékonysággal használja valaki. Plusz nincs benne kódszínezés, témázás, pluginkezelés, így minimialista marad, és distraction free. Plusz mivel a hardverigénye tényleg az abszolút 0-át verdesi (3-4 MB RSS = 0,5-1 MB USS + 2,5-3 MB SHR memóriaigénye van, plusz a terminál vagy konzol fogyasztása, amiben fut, emellett 0% prociidőt igényel), ezért egy 486-oson, Pi pico-n, Amiga-szintű hardveren, stb. se lassú, egy vim meg pláne egy Emacs azon már nagyon küszködős lehet, még pluginek nélkül is. Hálózati sávszél is kevesebb kell neki. Emiatt én néha próbálom használgatni, retró feeling, minimalizmusos gyakorlat gyanánt.

Mondjuk én nvi-ra esküszök ilyenkor, mert a vanilla, Joy-féle eredeti vi-nak van néhány hülyesége, pl. nem lehet nagybetűs, meg két karakteres billentyűeseményeket beállítani rajta, mert ráokádja az emberre az idióta Too dangerous to do that hibaüzenetét.

Ami nekem vi-ból, nvi-ból nagyon hiányzik az a több szintű undo, és block mode, ami ritkán kell, de akkor nagyon. Amiatt nem tudom a neovim-et feladni, pedig nem lennék tőle messze. Meg az is idegesít benne, hogy az insert belépési pontig tud csak törölni, azt meghaladóan nem, bár ez normiság részemről, mert megszokható, workaroundolható lenne, csak profibban kéne használni, több szerkesztési módot a normál módban futtatni, nem insert módban visszalépve törölgetni, mint egy hülye. Ezért rendszeresen gyűrődök vele, hogy fő text editorként megszokjam.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

hat en rendszergazda es programozo vagyok, 25 eve hasznalok unixokat (eleinte sgi irix, aix, solaris, bsd-k, utobbi 2 evtizedben inkabb linux es macos) de a vi-t (es klonjait) mindig is ruhelltem. sose tudtam megszokni, ezert inkabb kilepek belole ha veletlen az indulna el valamiert...

Híjj, ilyeneket mondani. Lehet a ChatGPT-nek lesz csak igaza, halott vagy, vagyis az leszel itt nekünk ilyen beszólogatások után :D

Komolyra fordítva: ajánlom, hogy tanuld meg, mert tényleg jó. Nem véletlen népszerű. Tény, hogy míg nem érted a lényegét, addig agyrémnek, logikátlannak, nehézkesnek tűnik, mivel teljesen más, mint a hagyományos text editorok, teljesen másmilyen gondolkodást, megközelítést igényelnek. Én épp ezért nevezem ezeket az ed, sed, ex, vi, vim, stb. inkább text processornak, mint text editornak. A lényegük ezeknek egyébként a modális interakciós filozófia, ami nem csak szövegszerkesztéskor jó, hanem különböző viewer, pager, file selector, fájlkezelő, stb. programokban is jó, sőt, még ablakkezelőknél is népszerű.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

> hogy tanuld meg

anno megtanultam... tudom hasznalni ha muszaj

> Nem véletlen népszerű

szerintem nem az. van par perverz akinek bejon de a nagy tobbseg utalja. en is...

> agyrémnek, logikátlannak, nehézkesnek tűnik, mivel teljesen más, mint a hagyományos text editorok

ez igy van.  kb akkor lehetett letjogosultsaga amikor meg a terminalokon a betukon kivul semmi se ment at, ezert kellett betukkel iranyitani. amiota feltalaltak a vt100-at azota lehet normalis editorokat is hasznalni :)

Kezdőknek mindig azt mondom el, ha már unix programozó vagy, akkor a sed, vi, awk közül elég egyet megtanulni.

kb akkor lehetett letjogosultsaga amikor meg a terminalokon a betukon kivul semmi se ment at, ezert kellett betukkel iranyitani

A "terminálon" ugyanazok a "betűk" közlekednek, bármi a modell kódja. Persze, ha ismernél néhány terminált és nem csak az emulált capability-re hivatkoznál, akkor már beljebb lennénk. Speciális kivételt képeznek a dumb és a sor-módú terminálok. Persze a vi számára ez is mindegy.

Manapság a DIN billentyűzet helyett lenyomják a torkodon a 104(++) gombos billentyűzetet. (Amin még a vt100 - inkább vt102 - is jobban megy. ;)) Ezzel csak az a baj, hogy abszolút nem ergonómikus, elfárad az ember keze, mert rossz helyen és rossz távolságra helyezkednek el a billentyűk. Pl. a 83/4 gombos még közelítette a használhatót. A laptop billentyűzet sem jobb. Ha tudsz gépírni, akkor rájössz, hogy mennyivel kevesebb és kisebb mozdulattal lehet vi-ben ugyanazt a műveletet leírni.

Az, hogy milyen műveletet minek feleltetsz meg, megegyezés kérdése. Pl. vi: hátrafejé, jefejé, kfejfejé, lelőre. :-D Ha ez számodra agyrém, logikátlan és nehézkes, akkor figyelmedbe ajánolm a (Norton)(Windows)Midnight) commander logikáját: F5 -> Copy, F6 -> Ren, F7 -> Mkdir, F8 -> Delete. Ez nem agyrém, hiszen mindenki így használja, teljesen magától értetődő és logikus. Bár kissé nyerítésre ingerel, hogy ugyanakkor az Xtree(Pro) agyrém, logikátlan és nehézkes, de megegyező parancsai rendre a C, R, M és D betűkkel működtek. Nnna, ezt nem tudta megtanulni senki. :-DDD

És dumb terminálon <300 baud sebességgel, akkor MS Word vagy más? ;)

> vi: hátrafejé, jefejé, kfejfejé, lelőre. :-D Ha ez számodra agyrém, logikátlan

a dehogy...  legalabb mappeltek volna a WASD-re, akkor a gamereknek menne :)

> És dumb terminálon <300 baud sebességgel, akkor MS Word vagy más? ;)

akkor en meg meg se szulettem amikor <300 baudos terminalokat hasznaltak, pedig nem vagyok fiatal...

mikor eloszor lattam netet 90-es evek elejen, mar joval tulvoltak a 300 baudon. es dos/win311 alatt senki se hasznalt vi-t :)

a leglassabb kapcsolat amin linuxal dolgoztam az olyan 6-8kbps korul lehetett, analog modemre betarcsazas mobiltelon keresztul a 2000-es evek legelejen. de ott is elvoltam vi nelkul...

legalabb mappeltek volna a WASD-re, akkor a gamereknek menne :)

Az ifjú korosztály! A WASD nem a vt100, hanem a 104 gombos. Láttad a linkelt képeket?

Nekem is 500Mb/s internetem van, fizettem érte és felhívom a szolgáltatót meg irgumburgum! De mi van, ha dolgozni akarsz és se telefonálás, se a vágyakozás vagy jogos méltatlankodás nem oldja meg a problémát? Sőt, a születésed pontos dátumát is a hajadra kenheted. Kb. ugyanabban az időben dolgoztam olyan helyzetben, amikor a 2Mb vonal leakadt, a három telephelyet összekötő 16db 64kb vonalból 9 elszállt, a maradékon meg ment az 1GB adatbázis update és kb. 200 operátor lekérdezései. (Fogadjunk, hogy sokkal jobb paraméterekkel rendelkező rendszert is le lehet hasonlóan lassítani!) És mese nincs, az éles rendszer megy, a hibát el kell hárítani! És hiába vagy el vi nélkül, az AIX szervereken jobb, ha a de facto standard Unix editort keresed. ;) És mi van akkor, ha valaki rosszul állitotta be a környezetet/egyebet és csak dumb terminált érsz el?

Nekem könnyű, mert Windows (és olykor DOS) alatt is vi-t használok. ;) Az meg csak hab a tortán, hogy most is US klaviatúrán írok, de minden billentyű azt a betűt írja, amit gyárilag rárajzoltak.

Kíváncsiságból megnéztem: Androiból vim és nano, TWRP terminálról vi és nano érhető el. Persze a standard senkit nem kötelez. Nemrég egy ubuntu live alapú toolt használtam, és igen gondolkoznom kellett, hogy milyen szövegszerkesztőt érek el. A vi(m) kezelése itt is könnyebb :-D

Hát... ez a régi "kattogós" billentyűzetekkel meg terminálokkal kapcsolatos fétis teljesen érthetetlen számomra. :)

Mondjuk az az én ifjúkorom meghatározó számítástechnikai élménye, hogy mennyire szar úgy általában a billentyűzet, de főleg a magyar elrendezése - ha kicsit is más szeretnél, mint angol szöveget gépelni. Hogy ebből eredeztethetően a vi-nak az évek során valamiféle "előnye" keletkezett - "és nem tűnt el a pi*ába a pereputtyával együtt" (trey kell a tm? ;D), az (szinte) abszurd és elkeserítő.

Na mindegy.

Hát... ez a régi "kattogós" billentyűzetekkel meg terminálokkal kapcsolatos fétis teljesen érthetetlen számomra. :)

Úgy látom, amit írtam, az is. ;)

Az meg csak hab a tortán, hogy most is US klaviatúrán írok, de minden billentyű azt a betűt írja, amit gyárilag rárajzoltak.

Na mindegy.

Az Xtree nekem is agyrém, pedig van unixlike rendszerekre is, Ytree néven implementálva. Nem a legjobb fájlkezelő, de néhányan szeretik. A Norton, Windows/Total, Double/Tux, Midnight Commanderrel nekem mai szemmel az a bajom, hogy nem tudnak vi-módot, ezért használok Vifm-et. A mai modern Miller-oszlopos/Mac Finder/Windows Explorer típusú fájlkezelőkkel az a bajom, hogy nem kétpanelesek, meg a középső oszlop zavar, kb. pedig minden használja, Ranger, lf, nnn, stb..

Az F5-F8-cal az is a baj Commanderek alatt, hogy nem minden billentyűzeten van, és nem minden konzol fogadja be őket, mint speciális billentyű.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ezért kell betűkkel irányítani. Ilyenje volt annak a szerencsétlen Bill Joy-nak. (Egy kései interjúban egyébként megtagadta gyermekét és azt mondta, interjúkori eszével nem vi-szerű editort csinálna, még ha olyan is a hardverkörnyezet. Erre szokták mondani: jó ötletnek tűnt.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Közben meg kiderült, hogy nem hogy nem jó ötlet, hanem zseniális volt. Én mióta megtanultam használni, nem is értem, hogy hogyan voltam el előtte enélkül, ma már mindent vi-módban használok, interpreterek/readline programok, shell parancssor szerkesztése, fájlkezelő, task manager (htop-vim), mailkliens, böngésző (Tridactyl plugin), viewerek, pager-ök, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Komolyra fordítva: ajánlom, hogy tanuld meg, mert tényleg jó. Nem véletlen népszerű. Tény, hogy míg nem érted a lényegét, addig agyrémnek, logikátlannak, nehézkesnek tűnik, mivel teljesen más, mint a hagyományos text editorok, teljesen másmilyen gondolkodást, megközelítést igényelnek

És aki esküszik rá, az azt képtelen megérteni, hogy nem mindenki van úgy huzalozva, hogy neki ez jó legyen. Én is tudom használni (mint a mellékelt ábra mutatja, meg is szoktam annyira, hogy terminálon hiányozzon), de ettől még nem kifejezetten szeretem, és messze nem vagyok vele olyan hatékony, mint mással, mert képtelen vagyok ennyiféle izét vegetatívan használni (pedig de, értem a lényegét, felfogtam a struktúrát). Egyszerűen az én agyamnak segítenek a kicsi guideok, sokkal hatékonyabb vagyok mondjuk egy multicursorral, mint valami sed varázslással. Arról már nem is beszélve, hogy mennyivel jobb mondjuk egy változót AST alapján átnevezni, vagy megkérni egy darab kódot, hogy refactor to function...

/Ráadásul a hatékonyság mantrákat is időnként egy hangyafasznyit eltúlzottnak érzem, egy jó része olyan mikro lófasz, ami a gyakorlatban semmit nem számít. Annyira gyász mindegy, hogy hjkl, vagy nyilak, csak akkor számít, ha az egyikbe beletörik az agyad, a másik meg jön, de ez nem azért van, mert az egyik sokkal jobb, hanem azért, mert az egyiket te sokkal lassabban csinálod, mint az, akinek az rögzült./

Pedig mikor vi/vim-mel dolgozol, akkor bizony objektumokon hajtasz végre sed/ed-szerű parancsokat, csak interaktív, és azonnal látod a szövegben a művelet utáni eredményt, ott a képernyőbufferen. Míg sed-nél vakon kell ezeket megfogalmaznod, a parancssori paraméterként.

A h/j/k/l vs. nyilak csak a jéghegy csúcsa. A hjkl-t a kezdők használják inkább, haladó vi/vim-es mindjárt szavanként, mondatonként, bekezdésenként/függvényenként, adott sorra, százalékhoz, f/F-fel ritka karakterhez ugorva pozicionál, és ezekre az objektumokra fogalmaz meg parancsokat, nem nagyon használja a hjkl-t, ha nem muszáj.

Másrészt a hjkl, normál módnak akkor látod meg az értelmét, ha megtanulsz vakon, 10 ujjal gépírni, akkor jössz rá, hogy az a lényege, hogy ne hagyd el az alfanumerikus részt, ne kelljen egérért, kurzornyilakért, Home/PgDn, F1-F12-ért, stb.-ért kinyúlni, mert onnan vissza is kell találni gépírástartásba. Tehát az lenne az egész filozófiájának a lényege, hogy az egyik módjában szöveget tudj begépelni, a másik módjában (normál mód), egy beragadó Ctrl Lock-szerű megoldással meg szintén azonos tartásban gépírva tudj parancsokat bevinni. Mai napig sok ember használ 60%-os billentyűzetet, amin se kurzormozgató rész nincs, se numpad, de még gyakran funkcióbillentyű-sor se.

Harmadrészt a hjkl nem csak azért került oda, mert Bill Joy ADM3 terminált használt a vi írásakor, persze azért is, hanem az ADM3 terminál tervezői is azért tették oda a hjkl-re, mert az a gépírási alapsorra esik, és azon belül is az erősebb, dominánsabb, jobb kéz ujjai alá. Nem véletlenül, találomra lett ez eldöntve, hogy valaki elfingotta magát, hogy legyen xyzw.

Persze csak tőled függ, pl. néhány FPS gamer bedrótoz magának más programokban is W/A/S/D mozgást, ez ugyanaz, mint a hjkl, csak másik sémára megy. WordStar-logikát követő text editoroknál meg a Ctrl+ E/S/D/X és körülötte a Ctrl+ W/R/A/F/Z/C sémát használják, amik gyémántalakot formáznak. Ez mondjuk kevésbé hatékony, mert nyomva kell tartani a Ctrl-t, onnan nyújtózni másik billentyűkre, és emiatt a gépírást is benyomorítja kicsit.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Pedig mikor vi/vim-mel dolgozol, akkor bizony objektumokon hajtasz végre sed/ed-szerű parancsokat, csak interaktív, és azonnal látod a szövegben a művelet utáni eredményt, ott a képernyőbufferen. Míg sed-nél vakon kell ezeket megfogalmaznod, a parancssori paraméterként.

A h/j/k/l vs. nyilak csak a jéghegy csúcsa. A hjkl-t a kezdők használják inkább, haladó vi/vim-es mindjárt szavanként, mondatonként, bekezdésenként/függvényenként, adott sorra, százalékhoz, f/F-fel ritka karakterhez ugorva pozicionál, és ezekre az objektumokra fogalmaz meg parancsokat, nem nagyon használja a hjkl-t, ha nem muszáj.

Mint említettem, értem a vit, tudom is használni, a hjklt csak azért hoztam fel, mert az szokott lenni a szokásos példa (eggyel lejjebb be is hoztad, pontosan megmagyarázva, hogy mert úristen el kell nyúlni tőle. Erre mondtam, hogy a gyakorlatban ez szerintem nem érdekes, vagy legalábbis csak akkor, ha téged zavar, mert megakaszt. Akit meg nem, az kb ugyanúgy halad másképp is.)

Azt nem vagytok képesek felfogni, hogy nem az a baj, hogy nem tudjuk használni, hanem az, hogy ez nem mindenkinek hatékony. Én tök értem a struktúrát, már vagy háromszor megtanultam normálisan, egész egyszerűen én képtelen vagyok zsigerből ennyi mindent megjegyezni, megakaszt, hogy most mi a picsa is kell, ha bracketig akarok, meg nézzem a számokat baloldalt... hiába lenne elvileg hatékonyabb, nekem mégis jobb, ha kicsit kevesebb eszközből kicsit jobb visual guideinggal (néha sokkal, a multi cursor nekem sokkal  jobb) tudom megoldani, amit akarok, mert nem akasztja meg az agyamat. És ha nem tudom mit kell nyomni, akkor előveszem a command palettet, simán beírom, hogy kb mit szeretnék, kiválasztom a szűrt listából, és voila. Ez se akaszt meg, pont azt csinálom, mint kb minden program indulásakor. Papíron kevésbé elegáns bizonyára, de az én agyamnak sokkal hatékonyabb. És hiába magyarázod, hogy dedede a vim a hatékony, mert nem kell levenni a kezed, meg tök logikus minden, meg tudom is én, mert nem érted, mi a baj.

Pedig abszolválható. Az a titka, hogy sokat kell használni, meg nem szabad vegyíteni, ha pl. vi/vim-et használsz, akkor nem szabad más text editorokkal csalni, hogy néha napján itt-ott egy kis zug VSCode, Sublime, meg ez-meg-az, mert szebb, jobban esik, stb., azért nem fogsz fejlődni, azért nem jegyzed meg a parancsokat, billentyűket. Igényel egyfajta megszokást, meg intenzív használatot, hogy csak azt használd, míg rááll az agyad, megszokod. Úgy valóban nehezebb, ha egy seggel több bringát is meg akarsz ülni.

Tény, hogy főleg eleinte, míg nem zsigerből meg izommemóriából megy, addig kell hozzá egy kis mentális overhead, nem is laikusoknak való emiatt. De ez nem csak a vim-re igaz, hanem a legtöbb TUI, CLI, keyboard driven megoldásra, hogy fejben kell tartani billentyűket, parancsokat, kapcsolókat, trükköket, viszont ha ez megy valakinek, akkor viszont hatékonyabb, gyorsabb workflow-t tesz lehetővé, mint a normi, GUI-s, egérrel kattintok ikonokra, menükre, meg kurzornyilazok, kézzel méretezek át ablakokat, stb. című felhasználás esetén. Tény, hogy nem való mindenkinek, de pl. a hozzád hasonló veteránoknak sima ügynek kéne lennie.

A másik előnye annak, ha ezt a vi, ed stílusú szerkesztést, parancsokat megtanulod, hogy unixlike rendszereken, meg programoknál univerzálisak, ha megtanulod, akkor jobban megy, zsigerből használod a sed-et, jobban érted a grep-et, illetve gördülékenyebben használod a vi-os billentyűket is támogató megoldásokat, less, info, bat, readline, stb.. Tehát a munkát nem csak egyetlen nyomorult text editor kedvéért teszed bele, hogy aztán te is villoghass vele, hogy vi/vim-sznob, meg Arch-btw/Gentoo huszár vagy, hanem egy univerzális és nagyon hatékony ökoszisztéma kedvéért.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Pedig abszolválható. Az a titka, hogy sokat kell használni, meg nem szabad vegyíteni, ha pl. vi/vim-et használsz, akkor nem szabad más text editorokkal csalni, hogy néha napján itt-ott egy kis zug VSCode, Sublime, meg ez-meg-az, mert szebb, jobban esik, stb., azért nem fogsz fejlődni, azért nem jegyzed meg a parancsokat, billentyűket. Igényel egyfajta megszokást, meg intenzív használatot, hogy csak azt használd, míg rááll az agyad, megszokod. Úgy valóban nehezebb, ha egy seggel több bringát is meg akarsz ülni.

Ne haragudj, de nem érted. Nem tudom megerőszakolni az agyamat. Legalább 15 éve használok vimet, napi rendszerességgel, van amikor kifejezetten extenzíven, megtanultam már a parancsokat sokszor, ha egy kicsit is kiengedem, akkor a legtöbb nagyon-nagyon max 1 hónap alatt elmúlik a fejemből az extra layer, ami mondjuk hatékony kódoláshoz kell, aztán bámulhatom megint a cheat sheatet. Visszaszedni meg pontosan tudom, hogy nagyon nagyon minimum pár nap, aminek minden egyes percében meg fogok akadni, és kurva szar lesz.

Ehhez képest tudod mennyi volt mondjuk atom után eljutni addig a vscoddeal, hogy ne fájjon? Mondjuk úgy fél óra.

Továbbá én nem akarom exkluzívan használni, egy köbvödör más helyre írok textet, bizonyára majd direkt minden sarki lófaszhoz elkezdek vim módot keresni, vagy másolgatni (mondjuk ide).

Tény, hogy főleg eleinte, míg nem zsigerből meg izommemóriából megy, addig kell hozzá egy kis mentális overhead, nem is laikusoknak való emiatt. De ez nem csak a vim-re igaz, hanem a legtöbb TUI, CLI, keyboard driven megoldásra, hogy fejben kell tartani billentyűket, parancsokat, kapcsolókat, trükköket, viszont ha ez megy valakinek, akkor viszont hatékonyabb, gyorsabb workflow-t tesz lehetővé, mint a normi, GUI-s, egérrel kattintok ikonokra, menükre, meg kurzornyilazok, kézzel méretezek át ablakokat, stb. című felhasználás esetén. Tény, hogy nem való mindenkinek, de pl. a hozzád hasonló veteránoknak sima ügynek kéne lennie.

A másik amit nem értesz, hogy neked tesz gyorsabb workflowt lehetővé. A szerinted normi eszközökkel is lehet bőven hatékonynak lenni. csak azt a te agyad nem szereti. (Sőt, volt már párszor olyan az életemben, amikor ültem és néztem a vi guru kollágát, ahogy igen nagy medzsikelve adott elő valamit, amit egyébként én különösebb csinadratta nélkül sokkal gyorsabban megcsináltam volna). Én nem érzem, hogy ne lennék velük elég hatékony, és hogy az írásom sebessége lassítana. Cserébe a ritkábban használt ésvagy bonyolultabb dolgokat is tudom olyan tempóban csinálni, hogy nem akasztanak meg, mert van guidance a folyamat közben. És nem csak a szerkesztésre, hanem egy csomó minden másra is abban a workflowban.

Nem azon múlik ez, hogy ki mennyire veterán, hanem azon, hogy neki hogy kényelmes dolgozni. A vim nagyon hatékony eszköz annak, akinek ez a fajta logika adja a flowt, de messze nem az az abszolút szent grál, aminek elő szokás adni. (Sőt, pont kódoláskor vastagon elő tudnak ám azért jönni a limitációi). Nem lesz senki attól kevésbé jó unixos, hogy nem a vira esküszik.

A másik előnye annak, ha ezt a vi, ed stílusú szerkesztést, parancsokat megtanulod, hogy unixlike rendszereken, meg programoknál univerzálisak, ha megtanulod, akkor jobban megy, zsigerből használod a sed-et, jobban érted a grep-et, illetve gördülékenyebben használod a vi-os billentyűket is támogató megoldásokat, less, info, bat, readline, stb.. Tehát a munkát nem csak egyetlen nyomorult text editor kedvéért teszed bele, hogy aztán te is villoghass vele, hogy vi/vim-sznob, meg Arch-btw/Gentoo huszár vagy, hanem egy univerzális és nagyon hatékony ökoszisztéma kedvéért.

Remekül tudok mindenféle command line dolgokat használni, oda nem kell az extra képesség, soron belül vagyunk. A grepet meg a sedet meg egyébként is tudom, köszi, nehogy már az is a vi miatt legyen, fordítva tetszik ülni a lovon. :)

+1

En nem tudom, itt kinek mi a munkaja, de az IT-ben nagyon keves olyan munkakor jut eszembe, ahol a gepeles/szovegszerkesztes sebessege lenne a teljesitmeny meroszama. Nem attol leszek pl. hatekonyabb szoftverfejleszto, hogy gyorsabban tudok kodot irni vimmel, hanem peldaul hogy hogyan tud az adott IDE aszinkron kodot debuggolni, vagy tud-e dependency graph-ot rajzolni a domain modellre.

Igaz ez egy vicc, de azért operációs rendszertől messze van. Igen, nagyon sok dolgot meg lehet vele csinálni.

Mondjuk kíváncsi lennék egy erőforrás összehasonlításra a VS Code-al. Azt is szeretem, de csak Windows környezetben használom. Mondanám, hogy a modern kor Emacs-e. Nagyon jól testreszabható, sok kiegészítő érhető el hozzá, amivel szinte bármit lehet csinálni.

Ezek a nagy text editorok és IDE-k mind interpreter framework-ök, valami scriptnyelvre épülnek. Emacs Elisp-re épül, az Atom és VSCode Electron/JS-re, az IntelliJ, Eclipse, NetBeans és Android Studio Java-ra, a PyCharm, Jupyter Python-ra, a vim-nél ott a vimscript, neovim vimscript/Lua, micro esetén Lua, Sublime-nál Python, stb.. UltraEdit, Kate és Gedit is fogad JS plugineket, a JED meg S-lang-ra épül. Régebben a Xedit volt még olyan, ami Rexx-re épült.

Emiatt ezek nem csak text editorok, hanem mindent le tudsz bennük programozni, új funkciókkal tudod bővíteni, plugint hozzáadni, végtelen lehetőség van bennük, ami a szöveg szerkesztésén is jóval túlmutat, lényegében húznak egy komplett OS felé.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Gondolataim ezzel a szösszenettel kapcsolatban:

- Javát szkript nyelves dolgok között sorolni... facepalm - de értem a felsorolást.

- Kb 20 éve se volt sok teteje már egy ezredik sima szövegszerkesztőt csinálni, a JS-nek "köszönhetően" láttunk egy kisebb burjánzást, de szerencsére tisztul a kép.

- Van az a (szar) vicc az emacs-ről, de valójában és technikailag közelében sincs egy oprendszernek, max egy héj (burok :D) vagy felhasználói felület tud lenni. Szerintem ne gondoljunk rájuk úgy. :)

( golgota | 2023. 08. 20., v – 13:21 )

ehh, higul a szakma, mikor mar a vscode meg a notepad++ vezet :D

Mindenki a kikapcsolhatatlan telemetriával riogat, de még soha nem láttam bizonyítékot arra, hogy `telemetry.telemetryLevel: off` esetén tényleg továbbra is gyűjt metrikátat. Az általad linkelt oldal sem ír semmi konkrétumot, csak hogy bizonyos extensionökben nem lehet a telemetriát kikapcsolni, de szerintem az már nem róható fel a vscode-nak, hogy a tőle független extensionök mit csinálnak.

Nem olvastad végig cikket. A telemetry.telemetryLevel: off beállításon kívül még több dolog is van, amit érdemes kikapcsolni, ha nem akarod, hogy az ms profilozzon téged (crash reports, online services, auto update, stb). Minimális guglizással találtam arról fórumszálat a redditen, hogy az illető alaposan megnézte, hogy ha kikapcsolod a fent említett beállítást, mit küld el a vscode: azt küldi el, hogy kikapcsoltad a telemetriát. Azonosítható módon. Az én olvasatomban ez már telemetria...

Mellesleg nézz rá a vscode licenszre, bekezdés 2a:

Data Collection. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the product documentation located at https://code.visualstudio.com/docs/supporting/faq#_how-to-disable-telemetry-reporting. There may also be some features in the software that may enable you and Microsoft to collect data from users of your applications. 

Különösen ez szép:

You may opt-out ... but not all

A GDPR-konformitás is kérdőjeles: arra hivatkoznak, hogyha nem használsz logint a rendszerbe, akkor nem nézheted meg/töröltetheted a rólad készült profilt/adatokat, mert anonim vagy... miközben az elsődleges hálókártyád MAC címét használják fel mindenhol, azaz rohadtul beazonosítható vagy (hacsak nem változtatod a MAC címet állandóan). Valszeg nem illegális a dolog, amit csinálnak, de bakker, eléggé gusztustalan húzás. Profilozáshoz mindenképp elég, és innen már összekötni egy létező loginnal sem nehéz...

A C# pluginban meg nem lehet kikapcsolni, és jó eséllyel a többi ms által készített pluginben sem. Amik nem függetlenek tőlük.

Elolvastam a licenszet is, és az a gyanúm, hogy annak a szövegezése nem feltétlenül mérvadó abban, hogy valóban mit tesz a VSCode, egyszerűen csak megengedőbb, mint amennyire feltétlenül szükséges. Amúgy a linkelt oldal pedig ezt írja: 

How to disable telemetry reporting

VS Code collects usage data and sends it to Microsoft to help improve our products and services. Read our privacy statement and telemetry documentation to learn more.

If you don't want to send usage data to Microsoft, you can set the telemetry.telemetryLevel user setting to off.

From File > Preferences > Settings, search for telemetry, and set the Telemetry: Telemetry Level setting to off. This will silence all telemetry events from VS Code going forward.

A lényeg a végén van, eszerint ez a beállítás mindent telemetriát kikapcsol.

 

A telemetry.telemetryLevel: off beállításon kívül még több dolog is van, amit érdemes kikapcsolni, ha nem akarod, hogy az ms profilozzon téged (crash reports, online services, auto update, stb).

Én konkrétan a telemetriáról beszéltem, de igen, ezt mind ki lehet szintén kapcsolni (a crash reportot pl ugyanaz a telemetry kapcsolóval lehet állítani) nyilván annak az árán, hogy bizonyos funkciók elérhetetlenek lesznek.

 

Minimális guglizással találtam arról fórumszálat a redditen, hogy az illető alaposan megnézte, hogy ha kikapcsolod a fent említett beállítást, mit küld el a vscode: azt küldi el, hogy kikapcsoltad a telemetriát.

Az a thread 6 éves, még a beállítások neve is megváltozott azóta. Nem vagyok benne biztos, hogy továbbra is ez a helyzet, ezért lett volna jó, ha O'Leary ír valami konkrétat, mert azért az ilyen állításokat nem ártana alátámasztani valamivel.

 

A C# pluginban meg nem lehet kikapcsolni, és jó eséllyel a többi ms által készített pluginben sem. Amik nem függetlenek tőlük.

Nem azt mondtam, hogy az MS-tól független, hanem a VSCode-tól. De amúgy az extension a VS Codiummal is ugyanúgy telemetriázni fog, vagy bármilyen editorral ami a VSCode extension modeljét használja (pl. Eclipse Theia).

Eddig a gedit pont eleget tudott nekem a legtöbb felhasználáshoz. Ezért ebből a listából azt jelöltem be. A kate egy kicsit többet tud, de valamiért ritkábban indítom el mégis. Viszont az újabb Ubuntun lévő gedit verzió sokkal bénább lett, mint az előző változat volt. Ez is egy olyan program, amit visszafejlesztenek. Azt hiszem, hogy lettek funkciók, amikhez eddig volt gyorsbillentyű, most meg már nincsen, vagy csak nem tudok rájönni, hogy mi az. Egyelőre csak egy gépen van ez az új változat, de ha beszivárog a fő gépemre, akkor le fogok szokni róla. Hasonlóan a terminált is elrontották, nem ugrik be, hogy mi, de valami nagyon hiányzik, ami előtte volt.

Legtöbbször Eclipse alól szerkesztem a fájlokat, de ha mégsem abból, akkor gedit, vagy kate. Utoljára veszem elő a vi-t, de azt főleg csak akkor használom, ha terminálon be kell jelentkezni valahová és max 1-2 sort kell átírni.

Ez az egyik baj ezekkel a DE-khez készült GUI editorokkal, hogy állandóan visszafejlesztik, átvariálják. Ezt én is megszívtam anno, mikor a Kate4-et a KDE5-höz átírták Kate5-höz, és csak lassan kerültek bele vissza a feature-ök. Akkor sokáig kellett text editort keresnem, míg találtam másikat. Pedig sokat kibróbáltam, notepadqq, Geany, Commodo Edit, gedit, végül egy hosszabb időre a SciTe-nél kötöttem ki, ami Scintilla-alapú, ahogy a Notapad++ is. Innen már csak vim-re váltottam, onnan meg neovim-re.

Ma már persze nagyobb a választék, meg ott a VSCode, plusz azóta megtanultam a terminált, meg TUI-s szövegszerkesztőket használni, így már nem nagy érvágás. A notepadqq is használhatóbb állapotban van, mint 10 éve volt. Szóval van bőven alternatíva. De a vi/vim/Emacs az kb. örök, sose pusztulnak ki, ha a fejlesztésük esetleg valami csoda folytán abbamaradna, valaki továbbviszi ezeket forkként. Plusz ezek nem csak Windows, Linux alatt mennek, hanem BSD-ken, régi Unixokon, stb. is, még DOS-ra is elérhetők, igaz arra csak régi verzióként, meg GUI sem kell nekik, mennek tty-ban, SSH és soros portos konzolon, stb..

Régen még használtam speciális IDE-ket és editorokat, pl. TeXworks, TeXstudio, ezeket LaTeX-hez, Code::Blocks-ot C-hez, stb., ma már ezeket se használnám, a (neo)vim-et veszem elő mindenre, teljesen mindegy, hogy egyszerű szöveg, konfigfájl, markup vagy programkód, jegyzetelés vagy akármi, nincs kivétel. Ezzel sokkal minimalistább és egységesebb a workflow-m. Pár hete a man pages-hez is ezt állítottam be pager-nek. Vifm-ből meghívva tömeges fájl/mappaátnevezésre is használom, meg a jelszókezelő scriptem is vim-et használ. Be is vált mindenhez is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( nagyjoco | 2023. 08. 20., v – 20:27 )

Döbbenetes, hogy vannak emberek, akik nem vimet használnak. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Azt én is használom, de nem jön be, nekem túl puritán, az egy szintű undo, meg hogy nincs benne rendes backspace funkció (nem törli, amit beírtam, csak a kurzor megy vissza, és ha kilépek insert módból, csak akkor tűnik el), meg csak az insert pontig töröl, stb.. A sima, vanilla vi-nál vitathatatlanul jobb, de a rendes vim-et nem tudja pótolni. Azért futok vele köröket, de nem bírok rá fő text editorként átállni. Addig meg marad a neovim, már csak kíváncsiságból is, hogy a rendes vim-hez képest mit hoznak ki belőle, meg a legtöbb fejlesztő is emögé sorakozott be.

Az ed-et is megtanultam pedig használni, de hát az is vicc fő text editornak. Persze az ed teletype-ra való, nem képernyőre.

Plusz bináris fájlokhoz hex editorként meg a bvi-t használom, ez is vi-klón. Kicsit együgyű, de használható.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( SPYFF v | 2023. 08. 21., h – 08:32 )

Szerkesztve: 2023. 08. 21., h – 08:32

Nagyjából 5 év vim után váltottam neovim-re fél éve (+lazyvim bootstrap +pár másik konfig/plugin). Kifejezetten élmény vele a programozás.

( arpi_esp v | 2023. 08. 21., h – 09:51 )

Szerkesztve: 2023. 08. 21., h – 09:52

ha a vi nem "egyszerű szövegszerkesztők" akkor az mcedit miert az? bar kilepni tenyleg egyszerubb belole :)

Terminálból azért kilép azokra is, tty-ban valóban nem. De ez nem is baj, mert aki így akar kilépni belőle, annak nem való, mert nem érti a lényegét. A vi/vim-nek az a lényege, hogy nem egerezik valaki, meg nem használ az alfanumerikus részen kívül egy billentyűt sem, magyarán se kurzormozgatós, se Home/End/PgUp, stb., se F1-F12, se egyéb, mert ezek mind kívül esnek az alfanumerikus részen, ahol a gépírástartást használják jellemzően.

Az Alt+F4-gyel meg az is a baj, hogy sok billentyűzeten az F4 eleve módosító vagy layer-váltó billentyűre jön elő, főleg a mini-billentyűzeteknél (meg régi terminálokon sincs), meg tornagyakorlat, hogy az Alt-ot lenyomva tartva el kell nyújtózni az F4-ig. A vi/vim-nek pont az a lényege, hogy egy billentyűvel módot váltasz (ezt tekintheted beragadó Ctrl-nak, CtrlLock-nak metaforikusan, annak ellenére, hogy ez Esc végzi el ezt a feladatot), és nem tartod lenyomva, ezáltal felszabadul az összes ujjad.

A tutorialok se jók mert az :wq és :q! megoldásokat ajánlják, mikor erre sokkal gyorsabb és jobb vim-nél a ZZ és ZQ, vi-nál alapból nincs ZQ, de nvi-ban, elvis-ben, stb. beállítható. Bár kinek mi, mert a ZZ és ZQ-nál nyomva kell tartani ugyebár a shiftet (Caps Lock nem játszik, mert arra egy rendes vim-es az Esc-et drótozza rá), ami megint kicsit megszegi az alapelveket, míg a :wq, :q, :q! esetén meg csak a : karakterhez kell shiftet nyomni, a többi részéhez nem. A :w, :wq, :q-nak az az előnye még, hogy az ed, ex alatt is működik. El lehet rajta vitatkozni.

Olyan értelemben a vi mindenképp egyszerű, hogy 260 KiB-os, függőségek nélküli, tty-ban is működő bináris, se színezés, se pluginek, se semmi nincs benne, amivel túlzottan bonyolítani lehetne. A .exrc-ben, .nexrc-ben lehet konfigolni, meg billentyűkre makrókat drótozni, de az még nem plugin.

Az is igaz, hogy kinek mi a legjobb text editor, az megszokás kérdése is, ki milyen modellt szokott meg. Ha a hagyományos IBM/CUA/MS/Borland rendszerű Ctrl+A/C/V, kurzormozgatós, Alt+Q/S (notepad) módszerűt, akkor inkább micro, nice editor, mcedit, stb. jobb lehet, ha a WordStar-nak a gyémántkiosztását (Ctrl+E/S/X/D és Ctrl+W/R/A/F/Z/C), akkor a JED, Joe, ha az Emacs Ctrl+akármi+akármi akkordokat szokta meg, akkor Emacs, uemacs, Joe, JED, stb., ha a Pine, Alpine szerkesztőjét, akkor pico, nano, micro, Joe, stb.. Vannak, akik az aee és ee-re esküsznek. Megint más rendszerűek a régi IBM text editorok, PE, PE2, poe, pe32, pe64, és klónjaik, azoknak is egész más a billentyűkiosztásuk. Épp így a vi is egy családot alkot: vi, vile, elvis, vis, stb., és a vim is külön család már: vim/neovim, de még a modális editorok is külön csoport, ebbe tartozik még a Kakoune, Helix is. Aki egerezni szeret, az gyakran használja a Plan9-os editorokat, sam, acme.

A WordStar, Emacs, vi/vim család kiemelkedik eleve, mert ezeknek a billentyűit több alkalmazás is támogatja, amik nem szövegszerkesztők, de lehet bennük valamennyire szerkeszteni, vagy tartalomban navigálni. A WordStar már nem gyakori, bár a régi Borland termékek támogatták, meg a Joe/JED, de pl. Emacs és vi billentyűket a mai napig nagyon sok program támogat, Bash/readline, zsh, less, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

1. Gondoltam, de azért leírtam a komoly részét is.

2. Máskor legyél pontosabb, mert nem lehetett érteni, hogy a vi-ra vagy az mceditre érted. mceditet én is használgattam egy időben, végül is túlélhető, főleg, ha rendesen be van konfigolva, de nem a kedvencem.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

vim(VimL), neovim(lua)-t lehet scriptelni, rengeteg kiegészítő van hozzá(autocomplete, GitHub copilot, Multiple cursors, stb), majdnem olyan szintre fel lehet hozni mint egy PyCharm. Csak nekem a kezelése megszokhatatlan. Ha jól tudom ilyesmit nem lehet csinálni mondjuk egy mcedit-tel.

( YleGreg | 2023. 08. 22., k – 07:52 )

Sublime text for president mert az egyidejuleg hasznalhato tobb kurzor, melyek mindegyike sajat vagolappal rendelkezik baromi hasznos amikor kicsit is favagos, vagyis sok egyezoseget mutato szoveggel (adatokkal, listakkal, blokkokkal) dolgozok.

Es Linux es Windows alatt pont ugyanugy mukodik, nincs szukseg atszokasra.

( msandor v | 2023. 08. 29., k – 18:05 )

Korábban Atom, miután megdöglött, már a Pulsart használom. Mondjuk ez desktop app, szerveren vi/nano/mcedit (ami van).

( Raynes v | 2023. 09. 09., szo – 18:27 )

Szerkesztve: 2023. 09. 09., szo – 18:35

Szerk. inkább blogba írom.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”