Názory k článku
Lapce - rychlý editor v Rustu

No ze Atom ukoncili bolo len dobre. Bol to neskutocny bazmek. Sam o sebe ako tak fungoval ale stacili 2-3 pluginy a skoncil. UI mal o nicom, totalne neergonomicky a stabilita ci rychlost isla rapidne dolu. Na to ze to skoro nic nevedelo to bol riadne nestabilny kus sw. 2x v zivote som sa snazil presvedcit aby som ho pouzival ale nedalo sa to. Celkovo musim povedat, ze tieto novodobejsie nastroje su nekvalitne a radsej zostanem pri starsich, ktore mamu sice tiez svoje muchy ale aspon o nich clovek vie a vie ich vychytat.

Dobrý flamebait. Dobré textové editory tu s námi jsou pořád. Zejména Vi a jeho následovníci.

No ja pouzivam mcedit. A teraz mozte hodit kamenom :)

No ja tiez, na rychle upravy pri sprtani sa vo filesysteme asi to najlepsie.

take pouzivam mcedit pres ssh na local, pokud chci neco v grafice tak (v Xfce) vychozi MousePad (ma taby, automaticky uklada sezeni otevrenych souboru vcetne tech obsahu tech neulozenych): https://docs.xfce.org/apps/mousepad/start

A co latex?

LaTeX je v pohodě, pokud ho píšeš ve Vimu. :D

Vetsi frajerina je psat VIM v LaTeXu :-D

Kdo by jsi v dobe T602 pomyslel, z v budoucnu budou zapotrebi k provozu textoveho editoru specializovane graficke procesory… inu pokrok nezastavis…

Lapce mi funguje i bez nějaké drsné akcelerace. Mám integrovanou intel grafiku. Jakkoli beru, že T602 byl poměrně vydařený kousek (technicky), chtěl bys ho dnes používat?

Proč bych neměl chtít?

Protože jsou lepší alternativy a zadarmo?

Zadarmo? Mozna. Lepsi? No nevim. T602 slo provozovat na 20MHz stroji s min nez 1MB RAM. Ktery dnesni textovy editor s podobnou funkcionalitou to umi? Ze to neni zapotrebi? No neni, misto 20MHz CPU tady mame 5GHz CPU s ruznymi grafickymi chipy jenom k tomu aby to ve finale umoznovalo uzivateli napsat text. A ano, dnesni textove editory umi toho daleko vice na 200 nasobne rychlejsim CPU.

To je spis elektricky mlynek vs mlynek s turbinou a malym jadernym reaktorem.

Nekdo by mohl naprogramovat editor ktery by nevyzadoval k behu ten Cortex-A v RPi a bezel by jen z GPU, to bych asi ocenil-konecne by GPU melo nejake vyuziti.

"specializovane graficke procesory" nejsou nutně zapotřebí, jede to samozřejmě i s čistě softwarovou rasterizací (a pořád svižně). Když už ale nějaké to GPU máte, a ono vám to umí vykreslit snímek aplikace za třetinu µJ než CPU, tak proč to nevyužít, že? Zatímco T602 zabije polovinu baterie jen blikajícím kurzorem.

Tak bliknutí kurzoru jsou dva zápisy do řídicích registrů VGA + nějakých 14 zápisů do obrazové paměti. To celé opakovat 2x za sekundu, to dá i 286 na 8MHz naprosto bez problémů (ty procesory netopily, však neměly ani pasivní chladič).

Na první pohled ten tvůj přísvěvek působí, že má smysl, ale už na ten druhý ne. Naopak tenkrát bylo zřejmé, že CPU na to nemá a akcelerátor by tomu hodně pomohl. A je dobré si uvědomit, že textový režim na gfx kartách je v podstatě HW akcelerace a to bylo už tenkrát běžné.
Takže ten tvůj zpochybňovaný pokrok je naopak naprosto logický.

No, mam hodne velky problem nazvat textovy mod nejakou grafickou 'akceleraci', kdyz to je jen hloupy automat kombinujici data fontu s bg/fg. Asi kazdy zijeme v jinem svete, kdyz to srovnam s OpenGL, ktere ten editor pouziva.

Mel bych velky problem nazvat akceleraci i ten HW ("DMA") bytecopy mechanismus nad framebufferem, ktere mely prvni SUNy s M68k (bez textoveho modu).

Kazdopadne jsem nahlednul do zdrojaku toho editoru ... a jak to rict. Je to na hony vzdaleno memu stylu programovani. Kdyby takhle uvazovali lide v sedmdesaktach, tak nevznikly nikdy algoritmy typu Boyer-Moore (grep) a vyhledavame nejspis se slozitosti O(n*l) :-). Pozitivni je, ze stale jsou lide, kteri umi programovat a dokazou do minimalistickeho moderniho HW narvat neuveritelne veci (viz ruzne srandicky s ESP32).

Ale akcelerace nutně nemusí být kdovíjak vymakaná a v případě 2D ani většinou není. Podstatou je, že věci které by CPU řešilo pixel po pixelu se udělají efektivněji.
A zrovna ten textový režim je složitější, než třeba scroll nějakého bufferu...

To je jako porovnávat trakař a Teslu. Ano, nejprve někdo musle vymyslet kolo a pak trakař, a ty principy jsou pořád obsažené i v Tesle. A vedle nich další miliony vynálezů. A tesla toho umí mnohem víc, než trakař, ale když budete chtít odvézt pár polen z jednoho konce zahrady na druhý, nepovezete to Teslou, ale trakař na to poslouží velmi dobře. Ten, kdo vymyslel kolo, by pravděpodobně nedokázal zařídit výrobu Tesly, a ti, kdo zařídí výrobu Tesly, by nejspíš nevymysleli kolo. Každé je to úplně jiný typ dovednosti. A lidé toho typu, kteří vynalezli kolo nebo algoritmus Boyer-Moore, dnes vynalézají jiné věci – ale nevynalézají Boyer-Mooreův algoritmus, protože už je vynalezený, ani nepíšou textové editory v CGA rrežimu, protože by to dnes bylo k ničemu. Stejně jako ten, kdo vynalezl kolo, nevynalézal, jak nejlépe skočit z větve na větev, protože tou dobou už lidé chodili po zemi a nelezli po stromech.

Nevím, jestli teď nenapíšu něco šokujícího, ale optimalizací různých postupů a hledáním efektivních algoritmů se lidi zabývají dodnes. To není nic, co by bylo specifické pro doby, kdy si programátoři museli vystačit s PDP-11.

Ink: Přesně tak. Dokonce i řazení občas někdo vylepší.

Ale vždyť Boyer-Moore je O(n*l) ;) Jestli se vyplatí v porovnání s naivním hledáním je dost závislé na datech. A odhadovat to bez profileru (na moderním hardwaru) je takřka nemožné.
Programování pro moderní x86 je na hony vzdálené stylu programování ze 70. let a stylu pro minimalistický hardware, protože ten HW má občas až absurdně odlišné vlastnosti.

Všechno, co není obaleno v zatraceným Electronu, je dneska chválihodný počin.

Já si tu chybu opravil, ale někde se to potento...

Je to lepší než Kate? Ten mi zatím vyhovuje nejvíce.

Bude záležet na tom, kdy se bude dát v Lapce debugovat. Všechny ty editory jsou moc hezké, ale jakmile nebudu moci dělat základní debug bez ekcterního debuggeru, nedejbože remote... tak jsou všechny neovimy, kate a geany a ... ne moc k použití.

a jak často debuguješ? Na debugování mám raději specializované prostředí a běh pod drobnohledem, při psaní kódu mi to připadá jako zdržování.

Mi zase přijde jako zdržování pouštět specializované prostředí, když už jedno mám a mám v něm otevřené všechno co mě zajímá a je pro mě ergonomicky nastavené

problém debugování je, že to je vyloženě ruční čínnost (u velkých aplikací i extrémně zdlouhavá), spousta problémů vzniká až za provozu a potřebuji patřičně neočekávaný vstup, nelze snadno automatizovat. Naproti tomu laboratorní a analytické prostředí, různé hot seat mi dávají možnost aplikaci podrobit testování automaticky či poloautomaticky, lépe zaznamanet vstupy a lépe to celé uchopit, dají se takhle odhalit nekompatibility s nastavení OS, dead locky na databázi, různé race condition, to mi debugger nedává.

Co používáš?

Je to ve verzi 0.2.5. Nemá asi moc smysl porovnávat takový editor s prostředím starým spoustu let. Zatím je to zajímavé technologicky - postavené na Rustu, Druidu atd. Že bych tím nahradil Vim, Code a Clion, to by mě ani nenapadlo.

To GPU vykreslování, to ocení všichni co to někdy pustí ve virtuálu. I třeba u vscode to jde vypnout a nechat těch pár pixelů vykreslit CPU

Zajímavý editor ale já zůstanu u Emacsu

Koza žere i jablka :). Obojí jsou primárním určením textové editory a nevím, proč by se nedaly z hlediska používání srovnat.
To jak je který editor konkrétně implementován je samozřejmě zajímavé pro jeho vývoj a rozšiřování funkcionality, ale nic to nemění na tom primárním určení.
Např. VScode přeci také nepovažujeme za interpret TypeScriptu.

No, máte pravdu, není emulátor, je to operační systém.

Nejak ziju mozna v mylnem dojmu, ze na popularite nabyl Atom, Microsoft na to udelal klon ala VS code a po akvizici GitHubu Atom zarizli. Na Atomu jsem byl nekolik let, pak jsem presel na VS code, ale co mi do dnes vyrazne vadi je vyhledavani v textu i napric soubory, to mel Atom IMHO lepe (vsak sami reknete jak delate search & replace ve VS code, taky shift+tab na sipicku?).

Jinak myslim ze do WASI lze prelozit nove i Ruby - https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/

Btw. jsem Ruby vyvojar s mirnym presahem do spravy serveru a diky podobnym nazorum o Vimu jsem mu dal sanci, ale bohuzel to pouzivam tak malo, ze jsem to zapomnel. Takze pro primitivni editaci pouzivam Nano a kdyz potrebuji neco vic, poustim VS code v remote pomoci skriptu, ktery fungoval na Sublime i Atom - https://github.com/aurora/rmate.