Atom – wybór najlepszych rozszerzeń popularnego edytora dla programistów

Edytor został napisany we frameworku Electron, który, poza wieloma zaletami ma tę wadę, że jest ociężały. Atom demonem prędkości nie jest. Uruchomienie programu może trwać nawet kilka sekund, co w przypadku edytora, który może być traktowany jako podręczny, staje się wiecznością. Z tego względu wśród wbudowanych pakietów znajduje się TimeCop – miernik, który pokazuje, ile czasu potrzebują na start poszczególne elementy. Przyda się on na pewno po zainstalowaniu pewnej liczby pakietów, kiedy da się zauważyć spowolnienie programu. Warto wtedy zajrzeć do TimeCopa i… wyłączyć to, co nie jest aktualnie potrzebne. Z mojego doświadczenia wynika, a używam Atoma intensywnie od ponad roku, że pakiety bywają instalowane na potrzeby chwili, a potem tylko spowalniają edytor.

Instalowanie pakietów w Atomie jest niezwykle proste: wystarczy otworzyć preferencje, wybierając z menu Edit polecenie Preferences, a następnie kliknąć Install w panelu po lewej stronie.Dostępna jest zawsze aktualna lista pakietów. Można ją przeszukiwać, wpisując poszukiwaną frazę w polu na górze okna programu. Bywa, że jedne pakiety są zależne od innych – instalując je z poziomu Atoma, zawsze zainstalujemy wszystkie zależności. Jeśli są one potrzebne, pojawi się pytanie, czy zainstalować dodatkowe oprogramowanie, a jeśli wyrazimy zgodę, zależności zostaną uzupełnione.

Dla fanów konsoli jest jeszcze inna droga. Razem z edytorem jest instalowany jego konsolowy manager pakietów – Atom package manager, czyli apm. Jego obsługa jest taka sama w Linuksie i w Windows: najważniejsze funkcje to update, upgrade, install i uninstall (w kolejności, w jakiej są używane). Jeśli ktoś jest ciekawy innych opcji, dotyczących m.in. budowania pakietów, zależności, listy pakietów itp. - dostępna jest komenda apm help, która wyświetla skróconą listę poleceń, apm help wyświetla poszerzony opis wybranego polecenia.

Najbardziej popularne pakiety można znaleźć w artykułach takich jak „Top 5”, „Top 10” albo „Must have”. Są oczywiście potrzebne. Jednak my chcemy przedstawić kilka takich, które rzadko pojawiają się na wymienionych wyżej „listach przebojów”, a z praktyki wielomiesięcznego intensywnego używania edytora wynika, że są potrzebne, a nawet niekiedy niezbędne w pracy programisty czy webdewelopera. Przy każdym pakiecie podaliśmy, o ile spowolni on start programu.

Pakiety są przez społeczność rozwijane, poprawiane są błędy. Warto więc śledzić te zmiany. Dlatego też pierwszym pakiety, którego zainstalowanie polecamy, jest auto-update-plus.

Sprawdzi on za nas, czy są nowsze wersje pakietów, a jeśli tak – ściągnie i zainstaluje. Użytkownik jest informowany o tym fakcie za pomocą systemowego powiadomienia, niezależnie od tego, w jakim systemie operacyjnym pracuje.Można wybrać pakiety, które są śledzone oraz te, których śledzić nie chcemy. Domyślnie sprawdzanie odbywa się raz na 360 minut (6 godzin), ale można to zmienić według uznania.

100 dodatkowych milisekund do startu systemu.

Aż dziw, że tak mało artykułów wspomina o tym dodatku. Pakiet autocomplete-paths pozwala na automatyczne uzupełnianie ścieżek wpisywanych w edytowanym dokumencie. Wielokrotnie przy tworzeniu stron czy programów trzeba podać ścieżkę do pliku np. biblioteki czy arkusza css. W takim przypadku autocomplete-paths podpowie ścieżkę. Jest ona wyświetlana w menu pod kursorem i można ją wybrać za pomocą klawiszy kursora.

32 dodatkowe milisekundy do startu.

Innym dodatkiem związanym z plikami jest pakiet open-this. Pozwala on wczytać do edytora plik, którego nazwa (i ścieżka) znajduje się pod kursorem. Doskonale radzi sobie zarówno ze ścieżkami bezwzględnymi, jak i względnymi. Plik można wczytać do nowej zakładki równolegle do bieżącej, do zakładki po prawej stronie, a także do zakładki poniżej – w tych przypadkach edytor automatycznie jest dzielony zgodnie z wyborem użytkownika.

Brak niestety możliwości konfiguracji pakietu z poziomu interfejsu graficznego. Nie dodaje on automatycznie skrótów klawiszowych – trzeba wejść do jego konfiguracji, skopiować skróty, wypisane w dolnej części i wkleić je do pliku keymap.cson (jeśli ktoś go jeszcze nie ma – trzeba go stworzyć). Autor proponuje różne skróty dla użytkowników różnych edytorów, którzy przesiedli się na Atoma. Mimo tych braków pakiet jest zdecydowanie wart polecenia – potrafi ogromnie oszczędzić czas przy projektach składających się z wielu plików.

2 dodatkowe milisekundy do startu.

To zdecydowani faworyci w tym zestawieniu. Podstawowym pakietem jest split-diff. To narzędzie podobne do Melda czy Diffuse – dwa okna obok siebie, dwa dokumenty, które trzeba porównać i zaznaczone kolorem zmiany. Pakiet jest konfigurowalny: może pomijać różnice w spacjach, pokazywać różnice na poziomie linii lub słów, może nawet wyłączyć na czas porównania zawijanie wierszy, które zostanie przywrócone po wyłączeniu jego działania. Istnieje również możliwość automatycznego wyłączenia wszystkich elementów zabierających miejsce na ekranie – kto porównywał kod dwóch wersji programu wie, jak długie potrafią być linie… Dwa porównywane panele są przewijane synchronicznie – można ustawić oba kierunki albo tylko pion lub poziom.

A to, co jest w tym pakiecie najlepsze to fakt, że jeśli w jednym pliku brakuje kilku linii, które są w drugim, potrafi (w miarę) inteligentnie rozsunąć linie, tak, by pozostałe, pasujące do siebie, były na tym samym poziomie. W porównaniu na przykład do Melda – zdecydowanie lepsza opcja.

Drugim elementem tego duetu jest minimap-split-diff. Jest to uzupełnienie poprzedniego, powodujące, że na minimapie pokazane są miejsca, w których są różnice między plikami. Niezwykle przydatny dodatek, który pozwoli uniknąć żmudnego przewijania pliku w poszukiwaniu kolorowych linii – można skoczyć od razu tam, gdzie wymagana jest interwencja.

Spit-diff: 14 dodatkowych milisekund do startu. Minimap-split-diff: 6 dodatkowych milisekund do startu.

Atom nie byłby Atomem bez gita (prawdę powiedziawszy, niczym by nie był bez gita), a git nie byłby gitem bez branchy i commitów. Można się w tym łatwo pogubić, choć są do tego narzędzia graficzne takie jak git-gui. Dlaczego by jednak nie obejrzeć historii repozytorium bezpośrednio w edytorze? Do tego posłuży pakiet git-log, który w graficznej postaci przedstawi historię commitów, pozwoli podejrzeć, jakie pliki były zmienione. Niestety, brak diffa i podglądu zawartości zmienionych plików. Jednak możliwość podglądu historii repozytorium bezpośrednio w trakcie pracy nad projektem jest warta uwagi.

3 dodatkowe milisekundy do startu.

Wszystkie przedstawione powyżej pakiety dodają łącznie 157 milisekund do startu edytora, a jeśli zrezygnuje się z automatycznej aktualizacji pakietów (w końcu edytor sam informuje o aktualizacjach, tyle że wtedy trzeba tę aktualizację „przeklikać”) to mamy mnóstwo ciekawych możliwości w zamian za… 57 milisekund. Myślę, że to poświęcenie zdecydowanie się opłaca.