A GitHub befejezi az Atom kódszerkesztő fejlesztését az MS VS Code kedvéért

Szerszám

When we formally introduced Atom in 2014, we set out to give developers a text editor that was deeply customizable but also easy to use—one that made it possible for more people to build software. While that goal of growing the software creator community remains, we’ve decided to retire Atom in order to further our commitment to bringing fast and reliable software development to the cloud via Microsoft Visual Studio Code and GitHub Codespaces.

Részletek itt.

( trey | 2022. 06. 12., v – 10:18 )

Szerkesztve: 2022. 06. 12., v – 10:19

So, what happens now? GitHub is giving six months’ notice of Atom being discontinued to allow its users sufficient time to build their workflows elsewhere. On December 15, 2022, all Atom repositories will be archived. So it’s not the end just yet, but it’s close. In the time leading up to this date, GitHub will push reminders of the impending doom of its text editor just so you don’t forget.

trey @ gépház

( netrally | 2022. 06. 12., v – 12:05 )

Kiváló ügynök volt, de már nálam is egy ideje vscode van helyette és már nem mennék vissza.

( ibenny v | 2022. 06. 12., v – 12:10 )

Megszolgálta a magáét (ugye a VSCode alapját is ez adja/adta), jó szívvel fogunk emlékezni rá. :)

( gazsiazasz | 2022. 06. 12., v – 12:24 )

Ezt a vscode-ot meg atom-ot nem is kellett volna elkezdeni, már ott volt rég a sublime text.

Licence nem annyira izgalmas kérdés számomra.

Viszont a ST jól kezeli a 4K kijelzőket (gyors pl Intel GPU-val), amire ezen kívül csak az Xcode volt képes. Az összes többi általam használt szövegszerkesztő (most a terminál-osokoat ne vegyük ide)/IDE egy idő után idegesítő lassulást mutatott pl scroll-ozás, egyéb dolgok közben.

Egyébként kétség kívül egész jó koppintás lett a két másik editor, azon kívül hogy lassúak nagyon, meg akkor licensing témakörben verhetetlenek.

A Sublime Text, UltraEdit nem rossz text editorok, IDE-k, de az a bajuk, hogy zárt forráskódú, fizetős megoldások. Én meg ezeknek Linuxon meg a platformfüggetlenség, licenckérdés okán ellene vagyok. Nem vagyok programozó, de ezekkel én is kálváriát jártam régen. Windowson Notepad++-ot használtam, Linuxra váltva akkor még a notepadqq elég gyatra volt, így akkor Kate4-et használtam, de azt elcseszték az 5-ös verzióra, akkor sokáig nagy bajban voltam, használtam mindenfélét Komodo Edit, Atom, SciTe, próbáltam vim, Emacs, stb.-t, de egyiket sem bírtam megszokni, egyik sem tetszett. Mostanra újra feljött a Kate5, kikupálódott a notepadqq, tűrhető a VSCodium (ha valakit nem zavar, hogy Electron-alapú), jöttek új terminálos text editorok, pl. Kakoune, Helix, micro, de ezek akkor még nem játszottak.

Aztán sokadik nekifutásra, kín-keserv árán sikerült megtanulni a vim-et, és azóta csakis vim, jelenleg neovim. Nem csak ingyenes, és open-source, de minden platformra van, még BSD-re, DOS-ra is (bár DOS-on a hardver gyengesége miatt célszerűbb az elvis szerintem), megy grafikus felület nélkül is, akár egy tty-ból, SSH konzolban, stb.. Mivel pehelysúlyúbb, kisebb kódbázis, könnyebben portolják és forkolják, elmegy ergya gépeken is, sose hal/szűnik meg, plusz ha megtanulja az ember használni, akkor rászokik a modális vi/vim filozófiára, ami nagyon hatékony, és egy csomó másik szoftverben is tud használni (ha pl. egy disztrón vagy szerveren alap telepítésben csak vi van, akkor nem veszik el, plusz a vi/vim-es billentyűk használhatók WM-ekben, Zathura, htim/htop-vim, mutt/neomutt/aerc, Vifm/ranger/lf, imv/sxiv, less - ebbe eleve bármit be lehet pipe-olni, interaktív shellek, pl. dash, bash, zsh, fish és readline-os programok vi-módjai, utóbbiból nagyon sok van, pl. python, calc, dc, bc, Octave, R, sdcv, csomó más interpreteres program, stb., illetve a böngészőkhöz is van vim-módos plugin, Vimium, Tridactly, és vannak vim-es billentyűket használó böngészők, qutebrowser, vimb, surf). Eleve csak a vim, less, readline (és fzf) lefedi a terminálos workflow-m 95%-át, mert ahogy írtam, egy csomó más program bepipe-olható ebbe, pl. a jelszókezelőm egy opengpg bepipe-olva less-be és vim-be, meg pl. vim-mel lehet parancssort szerkeszteni fc-vel, de még a visudo is támogatja (jó, ez bármit támogat, csak át kell állítani az EDITOR változóban, ugyanez igaz a sudoedit-re, és doaseditre). Még az Emacs, Sublime, VSCode, stb.-re is elérhető vim-plugin/mód. Sok olyan szoftver is van, ami alapból ugyan nem támogatja, de átkonfigurálható vim-es billentyűkre.

A másik előnye a vim-nek, hogy egy jó pluginnel akár fájlkezelőnek és terminál multiplexernek is jó (tab-okban és split-ekben lehet akár terminált is behívni, bár ezekre van jobb alternatíva, tmux, fájlkezelésre Vifm, lf), meg pager-nek (less és more helyett), tömeges fájlátnevezőnek, git kliensnek, meg amit akartok. Kicsit olyan mindenes, mint az Emacs, csak tetrisz, e-mailkliens, org mode, stb. nincs benne. Emacs se rossz választás, mert annak is kb. ugyanazok az előnyei, igazi mindenes, eleve komplett OS önmagában, multiplatformos, egy csomó program tud Emacs-billentyűkombókat kezelni (alapból a bash, zsh, stb. erre van beállítva). Ezek sose szűnnek meg, max. átalakulnak, ha ezek közül valamit az ember megtanul, az örökre hasznosítható tudás, nem kell sose felülni a jövőben a legújabb hype-vonatra, újra és újratanulva a dolgokat. Ha windowsos gép elé kell ülni, ott Gvim-et használok.

Meg ahogy észreveszem, sok minden egyéni tudáson múlik, nem az IDE-n és text editoron. Pl. Linus Torvalds 3. évtizede uemacs-et használ, ez egy minimalista terminálos Emacs-klón/fork, de sokkal kevesebbet tud, kb. a sima vi szintje, és mégis a fószer sok millió soros kernelprojektet visz vele, egy egyszerű monokróm terminálban használja, semmi kódszínezés, semmi language server és coc/telescope/fzf és lua/JS/Python funkció nincs benne, nincsenek hozzá pluginek, teljesen fapad text editor, valahol a nano és a vim között. Nem csak ő, egy csomó kernelfejlesztő vim-et használ, plusz elég sok unixos veteránt láttam már olyan fapad text editorokra esküdni fő munkaeszközként, mint a vi, nano, pico, ee, joe, jed, 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.”

ezek az egyszeru editorok arra jo hogy az /etc/akarmi fajlban atirj valamit. esetleg a forraskodban kicserelj egy typot. a komolyabb IDE-kben meg azert vannak jo ficsorok, amik hasznosak a fejleszteskor. persze nem kell hasznalni oket, de gyorsitanak a melon :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nekem meg olyan erzesem hogy te meg nagy tobbmillio soros c++ projektet nem nyitottal meg meg vim-ben. Amikor a ctag fajlt probalja hasznalni a vim es befagy az egesz, akkor meg kell kerdezni magadtol hogy a vim simogatasert fizetnek vagy a tulajdonkeppeni munkaert?

Raadasul amikor tobb nyelvben irt projekt kozott kell valtogatni akkor kulon kulon meg kell kuzdeni a vimmel hogy megfeleloen tamogassa. Idomiliomosoknak tokeletes elfoglaltsag egy lakatlan szigeten :)

nvim-ot használok, való igaz soha nem nyitottam meg többmillió sorost c++ projectet, így ezzel nem találkoztam, de nem csodálnám ha lenne rá megoldás, viszont az utolsóra van, és nem kell váltogatni semmit. Egyszer kell megtanulni használni, utána már a többi lesz az időrabló. Egyébként a kedvencem, hogy időrabló, ezt főleg a lusta kóderek nyögik be állandóan.

De ezzel azt állítod, hogy a coder hülye. Ez egyáltalán nem igaz, azért kell érteni hozzá. MInt ahogy a sima szakmunkás se hülye, neki is kell érteni hozzá. Attól még, hogy nem a legbonyolultabb munkafolyamatot végzi, még nem kell lenézni. Viszont itt szerintem jó, ha szorgalmas és nem kell még rugdosni is, mert azon a szinten azt hiszik, hogy a project bonyolultsági szintje egyenesen arányos a code sorok számával.

Most ezzel mi a bajod? Az implementáció után van az elkészült softweare. Nyilván itt arra kell gondolni, hogy jól implementálták, tehát arról meg szokás győződni, az esetek tulnyomó többségében tesztekkel. Ezután, persze üzemeltetni kell, a hibákat javítani...stb, de az egy másik történet.  Az is természetes, hogy nem az van, hogy megvan a software és kalap kabát, hanem ehhez új szolgáltatásokat fejlesztenek, esetleg új verziót....stb, de az már egy következő fejlesztési ciklus. 

Az implementációba beletartozik a tesztelés. Az implementáció nem egyenlő a kódolással, az egy kicsit bővebb fogalom. 

ok, a fejlesztési folyamat végéről beszéltünk. 

Más kérdés, ha rendesen ellenőriznénk, akkor hibajavításra sem lenne szükség, de ezt értjük, hogy rengeteg dolog miatt nem megvalósítható. 

Mondjuk innentől ez szőrszál hasogatás, mert akkor ide lehet hozni a CI/CD problémát, hogy akkor most mikor van valami kész és mi nincs, meg lehet még millió kifogást hozni. 

Igen, én is így vagyok vele, hogy pl. a kódszínezést nem tudom elengedni, mert óriási segítség látni, ha egy " vagy (-et elfelejtett az ember lezárni, vagy valami ki van kommentelve. A language szerver is hasznos, főleg, ha az ember valami új nyelvben programozik, azonnal tudja mutatni függvény és objektumhívásoknál a paramétereket, lehetőségeket. Csak arra akartam rávilágítani, hogy ez szinten felül, amikor az ember már annyira tud programozni, ezek is feleslegesek lehetnek, mint biciklin a pótkerék.

Persze az is igaz, hogy az Atom-felhasználók nem lesznek bajban, vannak annyian, hogy valaki forkolja, tovább viszi, vagy nekik általában a VSCode(ium) is megfelelő alternatíva. Viszont én úgy vagyok vele, ha valamit megtanulok, akkor az hosszú időre szóljon. Most még Linuxot használva is elkezdtem olyanokon rugózni, mint a portolhatóság (emiatt váltottam vissza Waylandről X.org-ra), POSIX-kompatibilitás szkripteknél (bashizmusok és GNU toolok speciális kapcsolóinak a kerülése), meg igyekszek olyan programokat használni, amik BSD-ken is elérhetőek, hogy ha majd történik valami a Linuxszal, akkor is legyen hova váltani.

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

Minden tiszteletem a vim-nek, de ahogy elbandi irta, ezek felett eljart az ido es nem nagy projektre valok. DOS-on nottem fel, es mindig is szerettem a parancssort, de a nyakatekert es nem szabvanyos megoldasok inkabb kontraproduktivak.

Probaltam tobbszor is felkesziteni a vim-et cpp fejlesztesre, de remenytelen. Ha vegtelen idom lennek, akkor talan ujbol nekifognek.

Mikozben itt a VSCode es par klikkel mar egesz jol tamogat mindenfele programozasi nyelvet. Egy ideig en is ellenaltam fuj fuj ms, de aztan rajottem hogy nincs igazan alternativ fejlesztoi IDE a regi idokbol. Uj megoldasok persze vannak.

Ha lenne kenyelmes sok nyelvet tamogato cli IDE (mint a regi borland c IDE), akkor lehet hogy szivesebben dolgoznek azzal. De nincs.

A regi motorosok valoszinuleg ugyanazt csinaljak evtizedek ota. Nem igazan ugralgatnak nyelvek es frameworkok kozott, mikozben nagy projekteken dolgoznak. Igy persze elegge beleivodik az emberben az adott tool. De szerintem nem ez az atlag.

IT-ban nincsenek abszolut igazsagok. Van amikor az egyik jo, van amikor a masik, es van amikor valami teljesen mas mukodik jol. Az ilyen kijelentesek, hogy eljart felette az ido, meg csak egy dolog a jo, biztosan hibas.

Nem veletlen, hogy az MIT-n is vim-et es parancssort tanitanak.

https://www.youtube.com/c/MissingSemester

Igen, mert időtálló. Mert hiába jó a VSCode, aki hosszú távra tanul, felkészül, ha a MS azt is dobni fogja, meg ha valamelyik platformon nem menne, vagy még nem portolták át, stb.. A vim az meg egy olyan alap skill, hogy bárhol tudod használni. Sokan nem szeretik, félreértik. A vim sem nem IDE, sem nem text editor. Én text processornak hívom (figyelem, ez nem word processor, mint a WYSIWYG programok), ami azt jelenti, hogy a vi/vim valójában egy interaktív sed, amiben a szöveggel nem a hagyományos mozgok a kurzorral, kijelölök, stb. módban dolgozik az ember, hanem sed-hez hasonló szövegátalakító parancsokat nyomkod be. Ez először nagyon frusztráló, mert aki nem szokta meg, annak kontraproduktívnak, idegesítőnek tűnik, mivel nem dolgozhat vele, mint a hagyományosan megszokott editoroknál, meg meg kell szokni, hogy nem csak egyféle mód van, és tudatosítani kell, hogy mikor milyen módban van az ember, meg kell tanulni, fejben kell tartani egy csomó billentyűparancsot (persze azok automatizálódnak később izommemóriává alakulnak, mint a gépírás). Megint más, hogy a vim esetében pluginekkel és saját konfiggal beleprogramozhatók IDE-funkciók is, ha valaki IDE-re vágyik. A másik, ami miatt a vim-et nem tanulják meg, hogy sok kezdő ott elrontja vele, hogy próbálja hagyományos szövegszerkesztővé átkonfigolni (egér, kurzormozgató billentyűk, VSCode-os megoldások bedrótozása), de úgy meg egy szuboptimális hagyományos editor lesz belőle, és valójában az eredeti filozófiájából nem tanulnak meg semmit. Ezt a hibát én is elkövettem vele az első két próbálkozásnál.

Ugyanez igaz a parancssorra. A shell szabványosítva van, plusz minden rendszeren ott van, még olyan elvadultakon is, mint a Minix. Plusz csak az van, ha valahol olyan szerverrel vagy docker image-gel, vagy WSL-lel, headless eszközzel kell dolgozni, amelyiken nincs sem X-es grafikus felület, sem webfelület. Mert egy GUI-t meg webmint bárki meg tud tanulni, magától rá tud jönni, azt egyébként is feleslegesen tanítanák az MIT-n. Plusz a GUI mindig változik, rendszeren átdizájnolják, míg a szabvány shell mindig ugyanaz marad, és a shell nincs korlátozva, míg GUI-n csak azokat a beállításokat és funkciókat éri el az ember, amit bedrótoztak, hogy kattinthat rá. Plusz ez az a műfaj, amit az emberek maguktól nem tanulnának meg, mert nem vonzó, nem érdekes, elavultnak, nehezen használhatónak tűnik, és egyébként ez a fajta tudás, skill elsikkadna, amit szakembernél nem lehet megengedni. Ugyanezért tanítanak még most is shell scriptet, C-t, Lisp-et, Fortran-t, amiket sokan megint elavultnak, egzotikusnak, hülyeségnek tartanak.

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

( suckit | 2022. 06. 13., h – 11:38 )

Áh, bár az atom is egy fos (upgrade-ről upgrade elromlanak dolgok, ugyanez a csomagokra is igaz, QA semmi), azért még mindig ez állt leginkább kézre.

Most elcseszhetek napokat arra, hogy megnézzem mindazok, amiket megszoktam működnek-e vscode-ban. :(

( khiraly | 2022. 06. 13., h – 17:07 )

pedig hogy ment az igergetes, amikor az ms megvette a githubot, hogy ez semmi kihatassal nem lesz.

 

Amihez az ms hozzaer az megrothad.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( dyra | 2022. 06. 13., h – 22:58 )

Szerkesztve: 2022. 06. 13., h – 22:59

utálom az MS-et de ezt használom én is szinte mindig (LaTeX-nél nem, kisebb dolgokhoz meg nano mert az kéznél van szinte minden OS-en amivel dolgozom). Kismillió addon van hozzá és mindent is meg lehet vele csinálni. "Elkurvulunk" ahogy a megboldogult haverom mondaná. Ő nem használná csak azért mert MS :D Bocs tesó!

Senki nem is mondta, hogy rossz a VSCode. Ez az egyetlen veszélye, hogy MS-os, és tudjuk, hogy nekik milyen szokott lenni a hozzáállása, egy napon dobják azt is, aztán ott lesz az ember fia, ahol a part szakad. Plusz ugyebár Electron app, ami nem épp erőforrás-barát, más részről viszont multiplatform, meg böngészőbe is beköltöztethető. Más gond nem lenne vele, még LaTeX-hez is használhatod, csak akkor kézzel kell bedrótozni, hogy a .tex fájlokhoz hívja meg a parancssoros latex fordítód, az elkészült kimenetet meg tovább drótozhatod valami pdf vagy dvi viewer-be, egyes pdf nézőkben van kifejezetten synctex támogatás is (ráadásul semmit nem kell hozzá hekkelni extrában), amivel a kimenetben arra a részre ugrik, aminek a kódját épp szerkesztetted, így nem kell kézzel odatekerned, és ezek tudnak automatikus frissítést is, újrafordítod a doksit, és azonnal magától frissül a kimenet is a viewerben. Még az is megoldható, hogy hiba esetén az editor hagyja nyitva hibakimenetet, hogy lásd mik voltak benne az üzenetek.

Sokan hiszik rosszul, hogy LaTeX-hez, meg TeX-hez speciális editor kell, mint a TeXstudio, TeXmaker, stb.. Én pl. neovimben használom a plain XeTeX-et, pdf-et generálok, amit a synctex-képes Zathurával jelenítek meg.

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