Használod-e a Micro nevű konzolos szövegszerkesztőt?

Szerszám

A Micro nevű, szintakszis színezős, szín témákkal rendelkező (pl. solarized, atom) Go nyelvben írt apró editor, egyetlen fájlból áll. 

Billentyűzet kombinációi windowsos hagyományokat követnek, pl. ctrl+q kilépés ctrl+s mentés, ctrl-c, v, x vágólap. Tudása szerteágazó, ha pl. Python forráskód van nyitva és van linter telepítve a rendszeren akkor linteli a háttérben a forráskódot és megjelöli a problémás sorokat.

Igen
5% (13 szavazat)
Nem
94% (245 szavazat)
Egyéb, leírom ...
1% (2 szavazat)
Összes szavazat: 260

( Polesz v | 2020. 12. 29., k – 17:24 )

Ha már micro, akkor az e3 még pofásabb:

-rwxr-xr-x 1 root root  13250 Dec 29 17:17 e3
lrwxrwxrwx 1 root root      2 Dec 29 17:17 e3em -> e3
lrwxrwxrwx 1 root root      2 Dec 29 17:17 e3ne -> e3
lrwxrwxrwx 1 root root      2 Dec 29 17:17 e3pi -> e3
lrwxrwxrwx 1 root root      2 Dec 29 17:17 e3vi -> e3
lrwxrwxrwx 1 root root      2 Dec 29 17:17 e3ws -> e3

( transitive | 2020. 12. 29., k – 18:55 )

Igen, használom: mostantól, Kate helyett, programozáshoz. Remélem beválik...

( GerzSonka | 2020. 12. 29., k – 23:09 )

Most hallok róla életemben először. Visszatérve szabiról mindenképp ki fogom próbálni.

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( carlcolt | 2020. 12. 30., sze – 17:52 )

Tovabbra is a gtk+-os medit a kedvenc, az az egyetlen ok, hogy nem tudtam vimre anno teljesen atszokni.

Kar, hogy nincs macOS-re, es akarhogy probaltam nem birtam leforditani. :/

( bucko | 2020. 12. 30., sze – 18:08 )

Még windows alatt is vi/vim az alapértelmezett. Színez az is.

Ennyit a windowsos hagyományok követéséről. ;)

( Raynes v | 2020. 12. 31., cs – 01:05 )

Nem használom, mert vim-ezek, illetve mostanában inkább neovim-ezek helyette (Windows alatt GVim), de ismerem a Micro-t és egy nagyon jó cucc. Nagyon ajánlom annak, aki jó szövegszerkesztőt keres, de nem tudja, vagy nem akarja a vim/Emacs valamelyikét megtanulni. Már ajánlottam egy másik fórumon is pár embernek, nagyon rá is kattantak. Én magam a DistroTube YouTube-os csatornán hallottam róla.

“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.”

Én használom és az általad említett okból. Nekem csak config fájlok szerkesztéséhez kell. Nem programozok. Csak néha script. Ehhez teljesen jó. Próbálkoztam több félével, de mindig visszatértem rá. Ami még tetszett az az amp, de a micro-hoz képest egy bloat. De a koncepció érdekes.
A micro-n kívül még az mg van fent a gépen, ha valami gáz lenne.

Mi a tapasztalatod a neovimmel: jobb mint a „közönséges” vim vagy rosszabb, érdemes-e telepíteni ha a régi vim fenn van; kompatibilis-e vele teljesen, megy-e X alatti terminálemulátorban is zökkenőmentesen, UTF-8 "kompatibilis"-e, stb? (Kizárólag az érdekel, Linux alatt hogy müxik, a Win alatti tapasztalatok nem izgatnak).

Bevallom ugyanis, én még nem próbáltam...

Eddig jók a tapasztalataim neovim-mel. Simát ette a sima vim konfigját, nem volt vele bug, minden ment, UTF-8-cal is kompatibilis. Kicsivel kevesebb memóriát használ, igaz csak elenyésző % különbség. Én nem is ezek miatt használom, hanem plugineknél tud többszálúságot, meg szabadabb a fejlesztése, mint a sima vim-nek. A sima vim-mel ugyanis az a baj a régi, átláthatatlan kódbázisán kívül, hogy egy emberes projekt, vagyis sokan dolgoznának bele, de Molinaar nem enged be egy csomó új feature-t, elveti a commitokat, nem veszi fel release-be, nagyon a saját feje és saját preferenciái után megy, nagyon konzervatív ürge, zsarnokként uralja az egész projektet, ami így lassan fejlődik. Ezt elégelték meg a fejlesztők, és alapították meg inkább a neovim projektet, hogy az ötleteket szabadabban lehessen implementálni, és demokratikusabb legyen a fejlesztés. Egyelőre még túl nagy különbség nincs a két projekt között, annyi, hogy a neovimnek modernebbek a defaultjai, meg tud több szálon futást, és Lua scriptezést is kezel, nem csak vimscriptet ez pedig a pluginek írását könnyíti meg. Mindenképp adj neki egy esélyt, kockázata nincs, mert vim mellé is telepíthető a neovim, párhuzamosan használható, külön konfigfájlokkal mennek, így egymást nem zavarják, tudod tesztelni őket párhuzamosan, veszteni valód nincs. Anno a vim-mel sem volt soha bajom, sose bugzott, nem lassult be, úgyhogy nem emiatt dobtam, hanem inkább a Lua scriptelhetőség fogott meg, meg hogy támogatni tudok vele egy demokratikusabb, közösségi fejlesztést, amit fontosnak tartok.

Vagyis két hátrányát tudok írni az neovimnek, ezek az egyik, hogy luajit-et behúzza függőségnek, másik, hogy windowsos támogatása még tudtommal nincs, míg sima vimnél ott a GVim. De ezek egyike sem olyan nagy érv szerintem.

“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.”

Köszi az átfogó elemzést! A másikkal kiegészítve teljes a kép.

Számora az csapódik le, hogy a neovim kerülendő, mint a kutyaszar. Természetesen, ha majd kernelt szeretnék írni egy szövegszerkesztőben - és futtatni is - akkor a neovim lesz ez elsődleges eszköz. De addig nem.

Más szavakkal megfogalmazva: Ha rossz a fehér csoki, akkor próbáld meg nem barna csokiként enni!

De van a konzervatív zsarnokra is egy jó történet: Kollégám belevettette magát az xml-be, de annyira, hogy levelezni kezdett a gcc fejlesztőivel.

Kérdés: - Tudjátok, hogy a Windows alatt rossz az xml kezelés?

Válasz: - Tudjuk, de nem merünk hozzányúlni, mert jól működik.

Nem tudom mit értesz azon, hogy másikkal. Az a linkelt hozzászólásom a Micro-ról szól, nem a vim-ről. Amúgy kernelt is lehet sima vim-ben írni, Linus Torvalds, meg Greg Kroah-Hartmann is abban tolja. Persze, nem rábeszélni akarlak, mert a te döntésed, csak nem tudom honnan vontad le a következtetést, hogy kutyaszar.

Én ezt megértem, hogy a fejlesztőket frusztrálja, hogy emelnének be új feature-öket, kód is meg van hozzá írva, erre egy egyszemélyi vezető mindig eldönti, hogy nem lesz belőle semmi. Én ezt a törekvést nagyon támogatom, hogy valaminek a fejlesztése szabadabb legyen.

“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.”

Igen, több szövegszerkesztőről írtál. Mindegyik hozzászólásod azt erősítette meg bennem, hogy ezek nem kellenek.

Sajnos, a fórum egy különleges irodalmi stílus, amikor az emberek szem nem áll rá az értő olvasásra. :-DDDDDD

Amúgy kernelt is lehet sima vim-ben írni, Linus Torvalds, meg Greg Kroah-Hartmann is abban tolja.

Tényleg nem volt szmájli. ;)

Természetesen, ha majd kernelt szeretnék írni egy szövegszerkesztőben - és futtatni is - akkor a neovim lesz ez elsődleges eszköz. De addig nem. :-DDDDDD

Szerintem Linus Torvalds a bármivel is írt kernelét nem futtatja a szövegszerkesztőben. Ez egy tréfás és egyben abszurd utalás arra, hogy ezek a szövegszerkesztők annyira túlfejlettek, hogy kell a kutyának.

Már a vi is annyi mindet tud, hogy az emberek 100%-a ki sem tudja használni. A vim - ami már pluginolható - már eléggé túlfejlett, de javarészt kompatibilis. Én azt szeretem, ha becsukott szemmel tudok kezelni egy munkaeszközt. Ha az egyszemélyi vezető támogatja az állandóságot, az csak jó lehet. Van fejlesztői szabadság, vannak jó-rossz ötletek, de a repülő és tengeralattjáró autó nem túl elterjedt. ;) Biztosan elfogult vagyok, mert bár csinálok bonyolult dolgokat, de az nem IDE vagy szövegszerkesztő szintjén dől el. Bizonyára C# projekt esetén nem a vi(m) lenne a kedvencem.

Sajnálatos tapasztalatom, hogy a "továbbfejlesztés" (haladjunk a korral! és szabadság!) az esetek többségében funkcióvesztésssel, de minimum sérüléssel jár. Pedig az eredeti entitás jól ki volt találva, csak a haladószellemű fejlesztők nem tisztelték, értékelték vagy értették a lényeget.

Ilyenkor szoktam példaként emlegetni a Norton Commandert. (Ami a ma használatos DOS/Windows/Linux fájlmenedzserek őse.) Azt a hülye is tudja, hogy F5=copy. Nem csak ezért, de szerintem aki ilyeneket használ, az pont nem ért hozzá. Azok a fájlmenedzserek, ahol c=copy szépen elhaltak, mert a használóik még a copy parancsot sem ismerték.

Persze ez csak az én véleményem.

Hát nekem nem kellenek, elég a vim vagy annak valami klónja, de ha valami limitált rendszeren csak vi van, azzal is jól elvagyok nagyrészt. De látod, másnak van igénye másra, azért létezik az Emacs egy csomó kiadásban, Micro, és még egy rakat, JOE, JED, e3, ee, ne, stb.. Ezek mindegyike más-más filozófiát képvisel (modális, chord, hagyományos, wordstar-os), különböző mértékben és különböző scriptnyelveken bővíthetők, eltérő pluginek érhetők el rájuk. Nyilván neked nem kell mindegyiket használni, találsz magadnak egyet, azzal elleszel. Másnak, akiknek az nem jó, tud más alternatívákból választani. Pont ez a lényege a Unixnak, Linuxnak, free és opensource szoftvernek, mindenkinek mindenféle felhasználáshoz próbálnak alternatívát kínálni, és nem az van, ami Windowson, hogy egy megoldás van lenyomva mindenki torkán (bár azért ott is van sok alternatíva, sajnos szinte egyik se terminálos).

Kernelt senki nem futtat vim-ből. De nagyobb projekteket fejlesztők már panaszkodnak, hogy a vim belassul, mikor több plugin is fut, meg fordításra kell várni, és addig a vim, mivel egyszálú leakad. Nyilván a neovimnek nem ez az egyetlen értelme, hogy ezt kiküszöbölje, meg kernelt futtassál benne, ez csak egy motiváló tényező volt a többi között.

Amiért igazából hozzászólok ilyen hosszú idő után: beleütköztem egy neovim bugba, bár állítólag inkább a Termite terminál bugja, de jelentették ugyanezt a hibát Kitty, Alacritty, urxvt alól is, nálam előjött Archon, Artixon, Openbox, dwm alatt is, picom kompozitorral és anélkül is. A lényege, hogy az nvim nem mindig kapja meg a termináltól a SIGWINCH szignált, ezért nem jól méretezi magát a futó terminálablakhoz, annak felét foglalja el. Nem minden indulásnál történik meg. Majd próbálom st-vel is, addig azt a workaroundot léptem rá, hogy a ~/.config/nvim/init.vim konfigfájlba betettem egy automatikusan lefutó autocmd VimEnter * sorral egy a neovim megnyitásakor automatikusan végrehajtódó shellparancsot, ami !pkill -28 nvim kiadásával kiküldi még egyszer az illető szignált, így azonnal a jó méretre ugrik. Kicsit hack-kes, de átmenetileg megfelelő. Ha viszont nem tudom tartósan megoldani, dobni fogom a neovim-et. Nem is az nem tetszik, hogy bug van benne, hanem relatíve régi, 2.x-es verzió óta fel-fel bukkan, és a fejlesztők inkorrekt módon a terminálokat hibáztatják, állítják, hogy nem az ő szoftverük hibás. Én meg állítom, hogy igen, mert más terminálos progikkal nincs ilyen gond, meg az nvim-mel sem mindig, random csinálja, ha a terminál lenne bugos, akkor nem néha fordulna elő. Ezzel behúztak nálam egy elég negatívat. Még egyszer: nem az a baj, hogy bug van, az minden szoftverben előfordulhat, hanem hibás hozzáállás miatt régóta nem javítják. Holott az ő érdekük lenne, hogy aki korai adopter, az meg legyen elégedve, és ne tartsák távol a vim-ről áttérőket. Nem olyan elterjedt szoftver ez, hogy nekiálljanak ilyenen makacskodni. Molinaar megteheti a vim-nél, hogy makacskodik, meg egyszemélyi vezetőzik, és antidemokratikus alapon fejleszt, mert a vim már ismert lett általa. Ezt a neovimesek még nem mondhatják el magukról.

“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.”

OK, belátom öreg vagyok és vaskalapos. Mentségem csak annyi, hogy akkor kezdtem el junikszolni, amikor az embargó megszűnt. Akkoriban a commander és system management tool és sok minden más is a vi volt. Aztán mégis túléltem és itt vagyok. ;)

Azóta is olyan tool maradt, amit csak használni kell, gondolkodni felesleges. Kicsi, gyors és megbízható. Megy terminálon (ma már nincs, de lehet műhód), és megy dumb terminálon is. Egyszer jártunk úgy, hogy "ki kellett igazítani" a budapesti telefonkönv inputját. Akkor sem gondolkodtunk. Ez is egy tipikus példa a hencegő mondásomra: Ezt csináld utánam Windows alatt! :-D

Kernelt senki nem futtat vim-ből.

Továbbra is fenntartom, hogy amire ezt írogatod, az tréfa volt.

De nagyobb projekteket fejlesztők már panaszkodnak, hogy a vim belassul, mikor több plugin is fut, meg fordításra kell várni, és addig a vim, mivel egyszálú leakad.

Látatlanban mondom, ez egy tipikus eset, amikor arra használnak valamit amire nem való. A vi(m) képes támogatni a programozót, de ez már egy IDE szintű módosítgatás. Bár láttam már néhány egyszálú megoldást, amit pont azért írtak meg úgy, hogy gyorsabban fusson. (Most jut eszembe, én is írtam ilyet.)

Pont ez a lényege a Unixnak, Linuxnak, free és opensource szoftvernek, mindenkinek mindenféle felhasználáshoz próbálnak alternatívát kínálni, és nem az van, ami Windowson, hogy egy megoldás van lenyomva mindenki torkán (bár azért ott is van sok alternatíva, sajnos szinte egyik se terminálos).

Mindemellett a free és opensource igen gyakran kaotikus és sok a befejezetlen hattyúdal. A Windowson meg előfordul egy csomó olyan dolog, ami liuxon nincs vagy a nagy szabadság miatt rosszul működik. (Ne értsd félre: Nem szeretem, csak használom.)

Ami biztos: Bármilyen rendszeren csak a vi(m) a szövegszerkesztő.

A vim egyedülálló tartozéka pedig az xxd.

Sok befejezetlen hattyúdal minden szoftverkategóriában van. Sőt egy csomó OS, prognyelv is befejezetlen hattyúdal.

Javítom magam, Torvalds nem vim-et használ, hanem uemacs-et, ami egy 1985-ös MicroEmacs forkja, és nem teljes értékű Emacs, hanem csak egy nanónál alig többet tudó valami, lisp sincs mögötte. Az oka pedig egyszerű konzervativizmus, mikor elkezdett fejleszteni, akkor még az Emacs-et ismerte, de az nem futott jól a 386-osán, meg nem vette be a finn karakterket, ezért az uemacset használta helyette, mint pehelysúlyú alternatíva. Ezt annyira megszokta, hogy a mai napig ennél maradt, saját maga tartja fent. Kipróbáltam, kernel git-tárolójából leklónozható, könnyen fordul, egy gcc -Os és binary strip után egy ~118 KB-os terminálos progi. vi-nál, nano-nál nagyobb, vim-nél és Emacs-nél kisebb, nem csak fájlméretben, funkciókra is. Nekem nagyon kényelmetlennek tűnik, szinte borzasztó, hogy egy komoly ember ilyen komoly megaprojektet ilyen primitív eszközben fejleszt. De ha ezt szokta meg, ez áll neki kézre, akkor ez. Szerkeszteni biztosan lehet ezzel is, kérdés mennyire hatékony ténylegesen.

A másik, hogy mostanában szoktam olvasgatni a texteditors.org-ot. Ez egy régi oldal, ami összeszedi a valaha volt összes text editort, és jegyzékbe állítja, csoportosítja őket filozófia, családfa, OS-ek szerint. Kicsit elavult oldal, sok új szerkesztő nem szerepel benne, de pl. ez az uemacs sincs benne. Találni viszont benne gyöngyszemeket.

Például a Zed editor. Multiplatformos, zárt, terminálos, WordStar-filozófiájú szerkesztők közé tartozik. Kb. 40 éves, komplexitását mutatja, hogy DOS 2.10 alatt is elfut 256 KB RAM-ból, de vannak klasszikus unixos verziók is belőle. A szerzője fejlesztőcégként még mindig mögötte van, az eredeti, több évtizedes weboldallal, ami a kora 90-es évek stílusát idézi, statikus weboldal, stíluslap nélkül, de azért át van téve .php-re, hogy lássák halad a korral, LOL. De a java most jön: 50 GBP-ért adja, de még +10% átváltási díjat (csak ha nem fontban rendeli valaki), +17,5% angol áfát felszámol, és ha lemezen kell, akkor +5 GBP postázási díjat a „lemez”-ért. Cserébe viszont a program összes verzióját megkapja valaki, összes platformra, forráskóddal együtt. Gondolom floppy-t ért lemezen. Valami öreg, nyugdíjas fejlesztő lehet, arany pofának tűnik ezekkel a 30 éve elavult attitűdjeivel, és benyögéseivel (pl. aggódik, hogy a £ jel sok böngészőben nem jelenik meg jól). Vállal egyéni megbízásokat is, egyszerűbb projekteknél 5000 font körül díjért. Jót mulattam rajta, egyszerre aranyosan amatőr, naiv, és hihetetlen konzervatív, szinte dinoszaurusz szintje, látom magam előtt, hogy otthon még mindig egy régi Pentium 1-2-t használhat, valami régi unixlike rendszerrel, CDE/Motif-fal és egyebekkel. Még azon is gondolkodtam, hogy poénból meg kéne rendelni, de ahhoz 28k HUF-ért túl drága, pont egy olyan projekt, amit egy ismert youtube-er bevállalhatna, és videót csinálhatna róla mások szórakoztatására.

“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.”

Rendben van, de befejezetlen programmal igen gyakran nem lehet dolgozni.

Ugyanez igaz lehet a "továbbfejlesztett" programokra is. Szélsőségesen szkeptikus véleményem szerint (és az ifjú titánok miatt) továbbfejlesztéskor általában funkcióvesztés lép fel. Tetszik a "konzervativizmus" és Torvalds hozzáállása. Arról nem is beszélve, hogy jóval fiatalabb, mint én. ;) Amikor még ifjú titán voltam, győzködtem az öregeket, hogy használjanak WordStar-t. Amitre azt felelték, hogy nem bírják/nincs idejük megtanulni. Ezért napok mentek el egy-egy nagyobb dokumentum vagy forráskód átírogatásával.

A hatékonyság más kérdés. Szerintem egy csomó Windows alapú szövegszerkesztő létezik, aminél a vi ezerszer hatékonyabb. Ráadásul programozóknak készült, csak ki kell használni a lehetőségeket. Ha nagy és bonyolult projektben dolgozol többedmagaddal, akkor egy erre kialakított IDE a megoldás, de  egyszerűbb esetekben felesleges. (Ahogy Columbo felügyelő mondja: A feleségemnek is van egy kocsija, de azzal csak bevásárolni lehet.) És jön a bunkócsapás: Tudsz-e gépírni? És a szövegszerkesztőt használók 99,9 százaléka? Akkor melyik szövegszerkesztő hatékonyabb? Olyan, mintha két jogosítvánnyal nem rendelkező, vezetni sem tudó fickó vetélkedne, hogy melyiküknek gyorsabb az autója. ;) Láttam olyan ügyvédi irodát, ahol kötelező szabályt vezettek be: Gépírni úgy sem tudsz, ezért az egér bal oldalon, jobb kézzel meg sasolhatsz.

A WordStar azért jelentős, mert az volt az első valamire való szövegszerkesztő crossassemblerrel áttuszkolva pc platformra. Az akkori időkben tényleg egy ultimate konfigurálási lehetőségekkel rendelkezett. Volt benne egy csomó patch lehetőség és egy csomó luk a pár soros assembly betéteknek is. Általában két verziót készítettük belőle: dokumentum és text. Ha jól emléxem, még 48k-s CP/M-en is ment, amihez persze kellett néhány overlay. Akkoriban nem "konzolos" programok voltak, hanem több oldalon felkínált terminálok közül kellett választani. Persze a WordStar sem igazi szövegszerkesztő, hanem egy irodai programcsomag része. (CalcStar, SpellStar, MailMerge)

Láttam egy klónját SCO-n, amiből még levelet is lehetett küldeni.

Én sose használtam WordStart, csak Wordperfect-et, Norton Commander editorát, pe2, CONTEXT (ez a nagy fokú névbeli hasonlóság ellenére nem azonos a windowsos ConTEXT editorral), Borland IDE-k editorát, néha MS-DOS editort akkoriban. A WordStar-os billkombók kényelmetlennek tűnnek, de mai napig vannak hívei, sok klónja van (lásd a linkelt texteditors oldalon a WordStar family-t. Klónt úgy értve, hogy nem programcsomag része, csak a menü és billkiosztását imitálja különböző fokban. Aki akkoriban nem volt benne, annak semmi csábító nincs benne, de akik azt tanulták meg először, azok a mai napig ragaszkodnak hozzá.

vi-vim-nek és klónoknak meg nem maga az editor funkcionlitása a lényege, hanem a modális-gépírós filozófia, ami annyira hatékony, hogy más programoknál is használom, tilingWM-ek, zathura, Vifm, böngészőben Tridactyl plugin, és még egy csomóban. Tehát nem maga az editor részük annyival hatékonyabb, hanem az egésznek a filozófiája teszi azzá. Már ilyen egérért és kurzormozgató billentyűkért, meg tartsuk állandóan nyomva a Ctrl-t típusú hagyományosabb módszertanhoz már nem is térnék vissza semmi pénzért, teljesen mindegy, hogy milyen extrákat tud.

Egyébként igen, tudok gépírni, és nagyon ajánlom mindenkinek, hogy tanulja meg. Az egyik legjobb befektetés, ami egy életen át megtérül, akkor is, ha nem titkárnő vagy coder valaki. Sőt, a vi/vim akkor a leghatékonyabban kihasználható, ha valaki tud. És fontos megjegyezni, hogy itt most gépíráson nem a viharütemben 1-2 ujjal, a billentyűket nézve kalapálok stílusú egyéni módszereket értem, hanem a teljesen vakon, 10 ujjal történő, szabályos gépírást, az mindegy, hogy kötött vagy lebegő tartásban, mekkora sebességgel, csak szabályos legyen, és ne nézze az ember a billentyűket. Ugyanis a legtöbb ember azt hiszi, hogy a gépírásnak a sebesség a lényege, közben meg nem, hanem a hatékonyság, energiaspórolás, meg hogy a figyelemnek nem kell állandóan a billentyűzet és a képernyő között cikáznia, hanem a billentyűket nem nézve, minden ujjat kihasználva, izommemóriából lehet dolgozni. A hagyományos, billentyűket néző kopácsolás azért nem hatékony, mert szétfárasztja a figyelmet, tönkreteszi a szemet, hogy állandóan cikáznia kell a figyelemnek a billentyűk és a képernyő között, állandóan szinkronizálva a tartalmat a kettő között, ettől fárad le az ember, meg vörösödik ki a szeme. Ezt a fáradtságot lehet megspórolni.

“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.”

Fogadd elismerésem! Én mindig lusta voltam, bár egyszer láttam egy gyors- és gépíró füzetet. ;)

A gyengeségemet azzal pótolom, hogy csak us billentyűzettel és repülőékezettel írok vagy 35 éve. Ritkán "jutok hozzá", de a kedvencem a fordított L alakú enter és jobb és bal oldalon a \ és /. Mindig olyan map-et készítek, hogy "ami rá van írva", illetve "jobbkezes" ékezetekkel. A gépírásnak az a rákfenéje számítógépen, hogy mindig variálnak + a laptopok sem egyformák. Ez csak egy apró magyarázat a nemtanulásra. ;)

Az igazi kedvencem a 84 gombos, mert ott nem kell az ESC és Fn megnyomásakor "felnyúlni" mindenen keresztül. Az igazi gépíró talán adatrözítéskor sem használja a numpadot, ezért (is) az antiergonómikus nyilas részre sem találok értelmes magyarázatot. Azt hiszem, ezek is a gépírós filozófia részei lehetnek.

A WordStar sem használ különleges billentyűket, de a sok-sok gombnyomás igen unalmas a vim-hez képest. Ha nem használtad, akkor lemaradtál arról az élményről is, amikor a szekvencia elején bejön a floppiról a másik menü. ;) Persze még a CP/M korában olyan billentyűzetek voltak, amire az ábc is alig fért rá. ;) Az újabb, minden emulációt és az öszes compose módot tudó (valódi) terminálok csöppet sem üdítő módon keverik a régi időket.

Halkan megjegyzem: Van aki bélyeget gyűjt, van aki szövegszerkesztőket. :-D

Nem méltó elismerésre. Nem egy nagy szám tudás, ingyen, netes anyagokból, otthon, intézményes képzés nélkül is meg lehet tanulni. Csak egy kis fegyelem és szorgalom kérdése. Nem is nehéz, az a trükkje, hogy az elején frusztráló, hogy lassabb ír az ember, idegen érzés neki, nem nézhet le a billentyűkre, magatehetlennek érzi az ember magát, olyan kényelmetlen, mintha az orrával kéne gépelni, de ez idővel jobb lesz. És nem lesz gyengeség, nem kell repülőékezetekkel trükközni. Az Esc-et meg át lehet drótozni másra, vim-en belül is, meg az OS-ekben be lehet állítani, hogy mondjuk a Caps Lock helyén Esc legyen, akkor az alapsor mellett van kapásból, ahonnan a gépírási alaptartás is kiindul, nem kell hozzá kinyúlkálni, és 84 gombos billentyűzet sem kell. Sőt, ezért is van az Esc használva erre, mert a vi szerzőjének a terminálos billentyűzetén ott volt a Q billentyű mellett, ha nem is alapsorban, de közel az alapsorhoz. Meg ezért volt régen a Ctrl is az alapsor mellett, ezért használja intenzíven az Emacs is, aki azt használ, annak meg a Ctrl-t érdemes a Caps Lockra drótoznia.

Beállítani se nehéz, nálam egy sor az ~/.xinitrc fájlból hívva:
setxkbmap -option kpdl:dot,grp_led:caps,grp:alt_space_toggle,caps:escape hu,us

De nem csak X alatt működik, SwayWM alatt, ami waylandes kompozitor, a konfigfájlban:
xkb_layout hu,us
xkb_options kpdl:dot,grp_led:caps,grp:alt_space_toggle,caps:escape

Windows alatt kicsit nehezebb belőni, registry hack kell hozzá. Igaz ebben a beállításban nem csak a Caps Lock Escre cserélése van, hanem az is, hogy Alt+Space-re váltson elsődleges magyar és másodlagos amerikai kiosztás között, a Caps Lock LED-jét kapcsolja be US kiosztásnál, magyarnál ki, és a numerikus billentyűzeten a tizedesvessző helyett HU kiosztáson is tizedespotot használjon (ugyanis használok olyan matekszoftvereket, calc arbitrary calculator, Python, Octave), amik lokalizációtól függetlenül csak tizedesponttal kezelik a nem egész számokat. Tehát a dolog szépsége, hogy mindenhol megy, egyszer kell belőni, nem kell hozzá semmilyen szutykot feltelepíteni, még ilyen kiosztáskezelő és -kijelző service-nek sem kell fusson.

A másik, amit érdemes beállítani vi/vim-nél, hogy a billentyűzet ismétlési sebessége és latency-je kisebb legyen. Általában a default latency 500-600 ms között van, az ismétlési sebesség meg 25 karakter/másodperc. Ezeket érdemes módosítani, nálam 280 ms (hamarabb elkezd a lenyomott billentyű aktiválódni), és 50-60 karakter/mp. az ismétlési sebesség (egyes gépeimen más-más érték van beállítva billentyűzet függvényében). Ez az jelenti, hogy a billentyűzetem érzékenyebb és gyorsabban ismétli a karaktereket. Ez mindenkinek egyénfüggő, billentyűzetfüggő, hogy mik a jó értékek, de a defaultot megéri átállítani. Túl gyors értékeket sem szabad megadni, mert az bugokhoz és frusztrációhoz fog vezetni, pl. progik több példányban indulnak, egy gombnyomásra több karakter jelenik meg, túllő a navigáció a szövegben, játékok irányítása fura lehet, szóval ésszel kell állítgatni, apró lépésekben.

A gépírásnak egy másik előnye, hogy a billentyűzet is mindegy lesz, magyar, német, brit, francia, orosz vagy akármi, csak ISO legyen. Mivel nem nézel le, mindegy mi van a billentyűkre írva, OS-ből változatható a kiosztás. Plusz az ember billentyűzetei gépírva a végtelenségig tartanak, korábban 3-5 évente szétkopácsoltam, elkoptattam egy billentyűzetet, gépírva örökké tartanak, mivel csak tapintom a billentyűket, nem kalapálom őket. Persze az is igaz, hogy eleve vigyázok is rájuk, nem tárolók italt mellette, ami véletlenül felverve beleömölhet, a ritkán használt gépeknél takaró (vagy lecsukott laptopfedél) van a billentyűzeten, hogy a por ellen védje, nem a klaviatúrán vezetem le a mérgem, 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.”

Az Esc-et meg át lehet drótozni másra, ...  meg az OS-ekben be lehet állítani,

Megnéztem: Nálam is így van. ;)

Linux/unix alatt nem túl nagy gond a billentyűzet.

Windowson meg a Microsoft Keyboard Layout Creator és a Key Tweak mindent lefed. Az első egy szabványos drivert állít elő, amit az en/hun stb. helyett lehet felrakni. A második meg megcsinálja a registry hack-et. Ami nem is hack, mert a Windowson ez a normális config lehetőség. ;)

Azért én szerettem a több kilós billentyűket. Azokban még volt vas! Elvégre az írógép sem zuhan le az asztalról, ha véletlenül megbököd. Gondolkodom egy százas szögön... ;)

Alapvetően nekem sincs bajom a régi módi mechanikus tank billentyűzetekkel, anno én is használtam Model F-et, Model M-et, szerettem. De ma már hiányozna róluk a Win/Super módosítóbillentyű (Model F-ről az F11-F12 is), meg idegesítene, hogy hangosak. De a mai napig ellennék azokkal is. Sose voltam billentyűzetsznob, használtam, ami volt, ami a géppel jött, ha mechanikus kapcsolós, akkor azt, ha gumidómos, akkor azt, ha süllyesztett, laptopos billentyű, akkor azt, egyedül csak túl ergya ne legyen, ilyen 1-2 ezer forintos vacak, amin nem érzékelnek a billentyűk, meg ne ilyen feltekerhető, kakaóbiztos gumibillentyűzet legyen, meg ZX Spectrum-szerű membránnyomorékság, mert azok tényleg használhatatlanok.

Most is használok mindenféle billentyűzetet, a ThinkPad X220 hagyományos TP billentyűzete, asztali gépen HyperX Alloy (barna Cherry MX kapcsolókkal), Ideapad 15ARE05 gumidómos süllyesztett billentyűzete, stb.. Alapvetően bármit megszokok, ami nem teljesen használhatatlan és ISO kiosztás, és mondjuk nincs baja játékok alatt a WASD felállással. A DOS korszakban, meg még kicsit utána az US ANSI kiosztást preferáltam, akkor főleg a programozás miatt.

“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.”

( hajbazer v | 2020. 12. 31., cs – 11:34 )

Szóval ha Go-ban írnak meg egy terminálos alkalmazást C helyett, akkor lehet modernnek™ nevezni. Értem.

Nem, a Micro nem azért modern, mert Go-ban írták, hanem mert a régi pico, nano ágat fejlesztették fel egy olyan szintre benne, hogy megállja a helyét vim, Emacs, és modern IDE-kkel szemben is, scriptnyelven pluginelhető, ennek ellenére erőforrásból se kér sokat.

Őszintén szólva a Go-s progikat én se annyira szeretem, de csak hogy perspektívába helyezzük, messze nem is utálom annyira, mint a Rust, .NET, webes, electronos, nodeJS-es szutykokat. Valóban fura, hogy a Go-t erőltették, és nem C-ben írták, amit én is jobban preferálok, de ez nem sokat von le az értékéből, használhatóságából. Ha a fejlesztő ezt ismeri, ezt látja jónak, akkor nem lehet beleszólni. Ha annyira nem tetszik, forkold a forrást, és fejleszd le C-ben.

“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.”

hanem mert a régi pico, nano ágat fejlesztették fel

Nem fejlesztettek fel semmit. Újraírták, egy trendbuzi nyelven. Elég nagy különbség.

ennek ellenére erőforrásból se kér sokat

Azért majd hasonlítsd össze egy jó öreg P3-on a vim-mel. Mert a kvantumprocesszoros 12 éves netbookjaidon nyilvánvalóan ez is ugyanolyan gyors™, mint amennyire a Gtk3 bloated pixmap-kizárólagossága gyorsabb™ és kevesebb™ CPU-t zabál a Windows XP GDI-rajzolásánál.

Ha annyira nem tetszik, forkold a forrást, és fejleszd le C-ben.

Legalább a szokásos közhely nem maradt ki.

Nem, nem csak újraírták, hanem egy csomó mindennel többet is tud, a nano, pico nagyon szerény tudású, ott az volt a lényeg, hogy a minimumra mentek rá hogy Windows Notepad szintű valamit kapjanak (bár a nano azért többet tud a Notepadnél). Nyugodtan telepítsd fel P3-asra a Micro-t, nem kéne lassabbnak lennie, mint egy vim-nek. Lehet talán kicsivel több memóriát kér, de nem vészesen, mindkettő lényegében terminálos/konzolos program, text user interface-szel. Azt garantálom neked, hogy bármelyik windowsos szövegszerkesztőnél kevesebb erőforrással beéri, az ilyen electronos meg javas monstrumokhoz (Atom, Visual Studio Code/ium, Netbeans, Eclipse és társai) képest meg szinte semmit nem eszik.

Mondom, a Go-ért én se vagyok oda, már elvi szinten sem, de abból nem fogsz semmit érzeni, hogy Go-ban írták, ha már binárisként használod egy átlag Linux disztrón. Az csak akkor ciki, ha forráskódból forgatod, és a kódfordításhoz behúzza a 120 megás go csomagot, ami 560 mega telepítve. Akkor meg még cikibb, ha forráskód alapú disztrón csinálod, pl. Gentoo, ahol nem csak hogy kell a fordításhoz a Go, de még előtte a Go-t is le kell forgatni forráskódból, ahhoz meg az llvm-et, és egy rohadt hosszú fordítási procedúra, főleg, ha a géped gyengébb. Na, akkor iszonyat gáz, ilyenkor szoktam én is a Go-sok meg a Rust-osok jó édes női felmenőjét elszidni sorban. Ez normálisan, C-ben írt projektekkel nincs így, mert a gcc már általában készen, bináris formában jön a forráskódos rendszereken is. Forkolni meg mindig szabad, nem közhely. Erről szól a szabad nyílt forráskodó szoftver, nem tetszik forkolod, lásd épp ebben a témában feszegetett vim-neovim szembenállást, annál is pontosan ez történt.

Ráadásul Go-s forráskódot relatíve egyszerűen kéne lennie átírni C-re, mivel elég hasonló a két nyelv. Nem ugyanaz a kettő, nyilvánvaló, de nagy fokú a hasonlóság.

Ha meg nem csak a szád nagy, és tényleg a legsoványabb text editor kell a P3-adra, akkor vagy ed vagy klasszik vi. Az egyik egy 54, a másik egy kb. 74 KB-os bináris, nem igényelnek semmilyen függőséget és library-t. Ezek egy 1970-es évekbeli 16 bites unixos gépeken is elmentek pár KB memóriából, egy P1-nek sem tétel egyik se, nem hogy egy P3-nak.

“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.”