Jaki konkretny wzrost produktywności zapewnia Vim / Emacs w porównaniu z edytorami tekstu GUI?

To nie jest pomyślane jako troll, przynęta na płomień ani nic w tym stylu. Używam Vima jako mojego ulubionego edytora konsoli od kilku miesięcy (do edycji plików konfiguracyjnych na moim terminalu), ale nie sądzę, żebym mógł to znieść dla mojej normalnej, codziennej pracy związanej z pisaniem aplikacji internetowych , co robię za pomocą edytora tekstu GUI (który nie jest ważny).

Czuję, że mój edytor tekstu GUI może zrobić wszystko, czego potrzebuję do mojej pracy. Ma przyzwoite wyszukiwanie / zastępowanie z historiami automatycznego uzupełniania dla obu. Posiada podświetlanie składni, numerację wierszy, interfejs z zakładkami, łatwe kopiowanie i wklejanie, itp. Jedyne, czego brakuje w moim obecnym edytorze, to dopasowywanie wyrażeń regularnych, ale jest wiele edytorów tekstu GUI, które będą wyszukiwać / zastępować wyrażenia regularne.

Biorąc pod uwagę to, co właśnie powiedziałem, jakie zalety produktywności ma Vim (a nawet Emacs) w porównaniu z edytorem tekstu GUI, poza tym, że jest zainstalowany na każdym komputerze. Chciałbym konkretnych zadań, które są lepsze / szybsze na Vim / Emacs lub po prostu nie są możliwe z istniejącymi edytorami tekstu GUI.

Dla Vima:

• Vim ma lepszą integrację z innymi narzędziami (polecenia powłoki, skrypty, kompilatory, systemy kontroli wersji, ctagi itp.) Niż większość edytorów. Nawet coś prostego, np. :.!Przesłanie wyjścia polecenia do bufora, jest czymś, czego nie znajdziesz w większości edytorów GUI.

• Interfejs z zakładkami nie jest tak przyjemny jak interfejs "okienkowy", który daje ci Vim / Emacs. Możesz zobaczyć dwa lub więcej plików w tym samym czasie obok siebie. Im więcej widzisz na ekranie, tym bardziej uwalniasz umysł do myślenia o swoim problemie, zamiast zajmować się mentalnym księgowaniem nazw zmiennych i sygnatur funkcji.

• Nie lekceważ potęgi wyrażeń regularnych Vima. Istnieje wiele rozszerzeń specyficznych dla Vima, które pasują do określonej kolumny, znacznika, pozycji kursora, pewnych klas znaków (słowa kluczowe, identyfikatory) itp.

• Zintegrowane diffi grep(niezależne od platformy, więc nie musisz pobierać i uczyć się nowego narzędzia za każdym razem, gdy zmieniasz komputer).

• Tryb bloku wizualnego (do edycji kolumn) to coś, czego wielu redaktorom brakuje, ale nie mogę bez tego żyć. Zszokowałem i zadziwiłem ludzi w pracy, używając tylko tego, dokonując kilku zmian za pomocą kilku naciśnięć klawiszy, które ktoś spędziłby w innym przypadku, robiąc ręcznie przez dziesięć minut.

• Wiele rejestrów kopiuj / wklej. Kiedy masz tylko jeden, w końcu przechodzisz przez dziwne skrzywienia, aby uniknąć uderzania w schowek. Nie powinieneś.

• System cofania / ponawiania Vima jest nie do pobicia. Wpisz coś, cofnij, wpisz coś innego i nadal możesz odzyskać pierwszą rzecz, którą wpisałeś, ponieważ Vim używa drzewa cofania zamiast stosu. W prawie każdym innym programie historia pierwszego wpisanego tekstu ginie w takiej sytuacji.

• Poruszanie się, kopiowanie, wklejanie i usuwanie tekstu jest w Vimie niesamowicie szybkie. Polecenia są proste, pojedyncze naciśnięcia klawiszy i można je komponować. Dodaj wszystkie razy, gdy wykonujesz staranne, pracochłonne podświetlenie myszy i Ctrl-X, a następnie zamień je wszystkie nada( (usuń zestaw pasujących parens i wszystko w nich). Oszczędza więcej czasu, niż myślisz

• Drobne rzeczy, takie jak *szukanie słowa pod kursorem, .powtarzanie polecenia lub %przeskakiwanie między otwierającym a zamykającym paskiem. Zbyt wiele z nich, by je wymienić.

• Wbudowany język skryptowy oraz potężne możliwości mapowania klawiszy i makr, dzięki czemu edytor można rozbudowywać w dowolny sposób. Mnóstwo skryptów już napisanych i do pobrania.

Jeśli przyjrzysz się wystarczająco uważnie, zauważysz, że nawet funkcje, które mają inne edytory, Vim często radzi sobie lepiej. Wszystkie edytory mają podświetlanie składni, ale Vim ma plik składni dla prawie każdego formatu pliku pod słońcem, często z wieloma opcjami konfiguracyjnymi, a napisanie własnego jest łatwe. Wiele edytorów obsługuje różne kodowania plików OK, ale Vim oferuje bardzo specyficzne i niezawodne sposoby ustawiania kodowania plików i konwersji między nimi. Pierwszą rzeczą, która zrobiła na mnie wrażenie w Vimie, jest to, jak doskonale radzi sobie z opcjami wcięć tabulacji / spacji i podziałami linii w systemie Unix / DOS w porównaniu z innymi edytorami, z którymi miałem wtedy problemy.

Wiele z tych punktów odnosi się równie dobrze do Emacsa (na różne, ale zwykle równie potężne sposoby).

(vim to moja trucizna; jestem pewien, że emacs oferuje podobne korzyści)

Największy zysk: brak konieczności dotykania myszy.

Dla mnie najłatwiejszą rzeczą jest przeskoczenie do przodu (lub tuż przed) do określonej litery lub kombinacji liter albo cofnięcie się za pomocą kilku naciśnięć klawiszy. Przeskoczenie do przodu o ten sam warunek dwa lub dziesięć razy jest po prostu kwestią poprzedzenia go liczbą.

Jeśli chcesz powtórzyć edycję, przeskakujesz do tego miejsca (2-3 naciśnięcia klawiszy), a następnie naciskasz „”. aby powtórzyć ostatnią edycję. Przeskakiwanie do przodu (lub do tyłu) jest łatwiejsze - jedno naciśnięcie klawisza - jeśli jest to ten sam warunek wyszukiwania.

Zasadniczo przy niewielkim czasie realizacji możesz nauczyć się dziesięciu lub dwudziestu skrótów klawiaturowych, co oznacza, że ​​nie musisz ciągle ruszać ręką, aby chwycić mysz. To daje trzy lub cztery razy więcej ruchów / poleceń edycyjnych, niż gdybyś musiał ciągle chwytać mysz.

Po kilku dniach będziesz się marudzić za każdym razem, gdy będziesz musiał sięgnąć po mysz (lub uderzyć <Down>15 razy), gdy jesteś w edytorze GUI.

Zawsze się zastanawiałem, dlaczego niewielu ludzi gaga nad Vimem. Zobacz film przedstawiający zaawansowanego użytkownika Vima w akcji:

https://www.youtube.com/watch?v=FcpQ7koECgk

Jeśli Twój obecny redaktor może robić to, co robi, nie ma potrzeby się zmieniać! :)

Przeczytaj również ten http://www.viemu.com/a-why-vi-vim.html

Po obejrzeniu filmu i przeczytaniu tego artykułu nie miałem innego wyjścia, jak tylko zacząć uczyć się VIM. Minął już prawie rok, odkąd przeszedłem na VIM i nie wyobrażam sobie niczego innego.

Myślę, że jedną z prawdziwych możliwości dedykowanego edytora tekstu jest edycja makr. Powtarzanie jest bolesne dla wielu programistów, a pisanie poprawnych makr może być bardzo zabawne. Jeśli nie robisz wszystkiego za pomocą klawiatury, tworzenie makr będzie wymagało dodatkowego zestawu poleceń, a nie korzystania z tych, których już używasz.

Jestem pół-kompetentny w skrótach klawiszowych vi, ale ogólnie wolę Emacsa. Powodem, dla którego ci redaktorzy mają tak zagorzałych zwolenników, jest to, że model edycji, który zapewniają, jest potężniejszy niż nowsze systemy, dlatego zapewnienie „skrótów klawiszowych vi” lub „skrótów klawiszowych emacs” nie wystarczy, nawet jeśli nie używasz żadnych funkcji rozszerzeń lub dostosowania dla emacs lub vi.

Opowiem o modelu Emacsa tylko dlatego, że rozumiem go najlepiej. W dzisiejszych czasach powszechny model edycji tekstu obejmuje bufor tekstu, w którym tekst można wstawiać, usuwać, zaznaczać i wycinać / kopiować / wklejać do schowka systemowego.

Oczywiście bufory Emacsa mogą obsługiwać te operacje. Oprócz śledzenia pozycji kursora dla każdego okna, w którym są one widoczne, śledzą również „znaki” w nich wykonane. Tekst pomiędzy „punktem” (pozycją kursora) a „znacznikiem” nazywany jest „regionem” i z grubsza odpowiada selekcji w głównych edytorach.

Różnica polega na tym, że Emacs śledzi kilka ostatnich miejsc, w których został ustawiony znak w pierścieniu oznaczeń, i możesz wrócić do nich za pomocą naciśnięcia klawisza (lub dwóch, w zależności od konfiguracji). Uważam to za niezwykle przydatne, zwłaszcza że wiele poleceń Emacsa, które zmieniają lokalizację w buforze, ustawia znak w starej lokalizacji. Przykładem jest sytuacja, gdy edytuję moduł Pythona i muszę dodać instrukcję importu na początku pliku. Naciśnięcie klawisza do przejścia na górę bufora (Alt- <) ustawia znak. Dodaję oświadczenie o imporcie. Naciskam Ctrl-u Ctrl-Spacja i wracam do miejsca, w którym zacząłem. Mogę to robić dalej, aby wrócić do poprzednich pozycji. (Może musiałem zaznaczyć jakiś tekst podczas dodawania tej instrukcji importu).

Inną (i bardziej znaną) różnicą w Emacs jest pierścień zabijania. Większość naciśnięć klawiszy służących do usuwania tekstu z bufora zapisuje tekst do pierścienia zabijania, który można następnie przywołać za pomocą polecenia „yank” (Ctrl-y). Podstawową cechą jest to, że kolejne polecenia yank pobierają starszy, zabity tekst. Możesz więc zabić kilka sekcji tekstu z rzędu, a następnie odzyskać je po kolei. Możesz także przechodzić przez pierścień zabijania za pomocą Alt-y po szarpnięciu, usuwając pobrany tekst i wstawiając następny wpis do pierścienia.

Emacs miał te cechy w 1978 roku. Jedynym innym głównym systemem, który je w jakimkolwiek stopniu zaadoptował, jest NeXTStep (obecnie odziedziczony przez Cocoa). Inne narzędzia zapewniają więcej funkcji do określonych zadań, mogą być rozszerzone w językach o wiele łatwiejszych w użyciu niż Emacs Lisp i mają ładniejsze interfejsy wizualne ... ale Emacs jest lepszy w edycji tekstu. Dlatego, kiedy już wiesz, jak go używać, tak trudno jest rzucić.

Nie jest to do końca konkretne zadanie, ale dla osób, które mogą nawet cierpieć na RSI, fakt, że Twoje dłonie nigdy nie opuszczają klawiatury w vimie, jest prawie bezcenny. Skończyło się na tym, że w pracy straciłem mysz, ponieważ pozwoliło mi to mniej poruszać ręką, aby sięgnąć po mysz (moja klawiatura w domu nie ma klawiatury numerycznej, więc mogę ją trzymać po prawej stronie).

Inną małą korzyścią było to, że IIRC, oryginalne vi zostało zaprojektowane w celu przyspieszenia edycji plików przez strasznie wolne połączenie zdalne. To prawda, że ​​dziś nie zdarza się to prawie tak często, ale jeśli masz wolne połączenie, powodzenia w uruchamianiu edytora tekstu gui i jego responsywności.

Dla mnie najważniejsza jest produktywność

• Z klawiatury mogę zrobić prawie wszystko.
• Potężne makra.
• W mojej 20-letniej karierze z 9 systemami operacyjnymi podstawowe ustawienia klawiatury nie uległy zmianie. Mogę wskoczyć na prawie każdy system i już znam się na edytorze.
• Prawie każda funkcja, której możesz potrzebować w edytorze tekstu, została już dodana.

Jedną rzeczą, którą naprawdę lubię w vimie, jest komenda „repeater”. Zasadniczo, naciskając .w trybie poleceń, powtarza ostatnią czynność. To tylko jeden przykład naprawdę fajnych funkcji, które mają "programistyczne edytory tekstu", których często nie mają GUI.

Z mojego doświadczenia wynika, że ​​główne korzyści w zakresie produktywności, które zapewniają vim i emacs (sam jestem vimem, ale emacs jest z pewnością podobny) to:

• Państwo może mieć te cechy, które zapewniają nowoczesne IDE (jak jeden wciśnięcia klawisza edit-build-uruchamianych cykli i inline dokumentacji i zakończenia zakładka i etażerka), ale nie muszą . Wzrost produktywności? Widzisz tylko tyle, ile chcesz. Z mojego doświadczenia wynika, że ​​IDE nie zwiększały produktywności ludzi, także dlatego, że pokazywały zbyt dużo informacji (wszystkie rodzaje przeglądarek). Ta „dodatkowa porcja mocy, kiedy jej potrzebujesz - ale nie wcześniej” to całkiem spory wzrost produktywności IMHO.

• Edytory cieszą się dużą popularnością wśród programistów, co oznacza, że ​​dostępne są ogromne repozytoria skryptów, książek i grup użytkowników.

• Z mojego doświadczenia (mogę tu mówić tylko w imieniu vima), przeciętny użytkownik vima jest dość dobrym inżynierem oprogramowania. Nie wiem, dlaczego tak jest (a może po prostu mam szczęście), ale może ludzie, którzy pokonali barierę przyzwyczajania się do `` starego '' narzędzia, takiego jak emacs lub vim, mają odpowiednie poświęcenie (i kontakt z innymi ludźmi w ten sposób ). Może to pośredni efekt działania tych redaktorów, ale spędzanie czasu z innymi osobami vim (lub emacs) na np. IRC okazało się całkiem interesujące, ponieważ te same osoby interesowały się również wszelkiego rodzaju zagadnieniami inżynierii oprogramowania (lub informatyki) . Wydaje się, że redaktorzy ci przyciągają pewien rodzaj osobowości. :-)

„Wzrost produktywności”, jaki uzyskuję dzięki używaniu lekkiego klonu emacsa dla małych programów, polega na tym, że uruchamia się jak błyskawica. Zwykle mogę uruchomić program szybkiego testu w C #, zanim Visual Studio zakończy ładowanie rozwiązania „piaskownicy”.

Oczywiście mógłbym po prostu zostawić otwarte Visual Studio (lub inny otwarty VS, jeśli pracuję w tym czasie), ale wtedy zostałby wymieniony, gdybym pozostawił go bezczynny przez chwilę itp.

W przypadku czegokolwiek znaczącego rozmiaru - lub jeśli nie znam interfejsu API, którego używam całkiem dobrze - IDE jest rozwiązaniem, które jest rozwiązaniem, IMO.

Używam gvim dla Windows, więc technicznie jest to edytor tekstu GUI, ale to jest vim ...

Jeśli chodzi o poprawę produktywności, znajduję:

1. Nigdy nie muszę używać myszy, dlatego jestem szybszy.
2. wyszukiwanie, zamienianie, kopiowanie / wklejanie itp. są szybsze dzięki przypisaniom klawiszy vim w porównaniu z ruchami myszy (po pokonaniu krzywej uczenia się)
3. Jak wspomniano w poprzednich komentarzach, wskaźniki RSI są znacznie zmniejszone. Moje nadgarstki mi podziękowały, odkąd przeniosłem się do Vima.
4. jest lekki i szybki

Wiesz, w przypadku vi myślę, że sprowadza się to do posiadania trybu wstawiania i poleceń. Chociaż może się to wydawać powrotem do czasów, gdy nie można było polegać na kursorze lub klawiszach specjalnych, tak naprawdę oznacza to, że wiele potężnych poleceń dotyczących ruchu i manipulacji tekstem to minimalna liczba naciśnięć klawiszy. W produktywnym kodowaniu nie chodzi o masowe wprowadzanie tekstu (domyślne w „nowoczesnych” edytorach), ale na masowe wprowadzanie tekstu, po którym następują znaczne drobne poprawki i jeszcze dłuższe okresy przeglądania.

To wysunęło się na pierwszy plan, gdy używałem vi w sieci kampusu o dużym opóźnieniu. Możesz łatwo uzyskać 10 lub 15 znaków przed odpowiedzią. Dzięki vi mogłem wygodnie przewidzieć, gdzie te polecenia mnie zostawią i być w stanie pracować z niemal normalną prędkością. Ta pokręcona wiedza jest ciągłą korzyścią w normalnych warunkach - mniej wizualnej siły mózgu poświęconej ciągłej graficznej informacji zwrotnej.

Powszechne akceleratory wyszukiwania * i # są świetne do przeglądania kodu. Znak% dla dopasowania nawiasów jest niezwykle przydatny. Jasne, prawie nie wydaje się dużo w porównaniu do ctl-], ale połowa naciśnięć klawiszy się sumuje.

Osobiście używam winvi, który dodaje kilka dużych rzeczy, które na pewno ma również vim. Szybki skok w tryb szesnastkowy rozwiązuje wiele problemów z tekstem „o co do diabła się dzieje”. A całkowicie elastyczna obsługa końcówek linii to dar niebios, który stał się oczekiwaną funkcją dla edytora tekstu. Wreszcie może otworzyć dowolny plik bez względu na zawartość. Sprowadza się to do elitarnej umiejętności hakerskiej pierwszego rzędu.

W systemie Unix można szybko przechwytywać dane wyjściowe programu lub nawet filtrować sekcje pliku za pomocą poleceń zewnętrznych. Niezwykle potężna, ale myślę, że funkcja nie jest w pełni wykorzystywana.

Często używam Vima. Nie zastępuje jednak dla mnie UltraEdita . Ponieważ wymieniono wiele pozytywów, myślę, że pójdę pod prąd i wypiszę kilka niedogodności związanych z Vimem.

• Słaba obsługa FTP. „Sortuję” wiele witryn i brak możliwości łatwego przeglądania i edytowania plików na zdalnym serwerze FTP jest dla mnie dużym brakiem. NWRead nie jest wystarczająco dobry.
• Dziwność konsoli odziedziczona po ogólnych problemach z terminalem, które wydają się nękać Linuksa. Zwykle używam PuTTY do łączenia się z moim Linuksem (z systemem Ubuntu) iz jakiegoś powodu klawisze strzałek mapują A / B / C / D w trybie wstawiania (i wszystkie problemy z obsługą kolorów). W gVim, ctrl-tab może być odwzorowany na "bn" easy, ale nie w trybie konsoli, takich problemów jest mnóstwo.
• Opcje wyszukiwania / zamiany są bardzo słabe, jeśli chodzi o interfejs. Konieczność wpisania całości do jednej linii nie wystarczy. Czuję, że znacznie bardziej rozbudowany dialog w, powiedzmy, UltraEdit daje mi znacznie więcej mocy w końcu, nawet jeśli faktyczna obsługa wyrażeń regularnych może być znacznie słabsza.
• Zbyt silne uzależnienie od amerykańskich układów klawiatury. Wiele klawiszy, które są używane do podstawowych funkcji, takich jak `, nie drukuje na moim duńskim układzie klawiatury (i są rozmieszczone w arkuszu, tak samo jak $ i wiele innych). Sprawia, że ​​korzystanie z niektórych funkcji jest dość niewygodne.

Pulpit zdalny pokazuje szybko tylko natywną aplikację Windows. Próbowaliśmy używać Eclipse do programowania pod unixem. I wiesz co? To nie było nawet możliwe.

Drugim powodem jest to, że możemy rozszerzyć nasze Vims i Emacs, aby wykonywać wszystkie zadania specyficzne dla projektu z przeglądania bazy danych w specjalny sposób, aby podświetlać i automatycznie uzupełniać nasz własny metajęzyk.

Powiedziałbym, że jedną z największych zalet jest rozszerzalność edytora vimów. Jeśli chcę, aby coś działało z CVS, mogę wziąć wtyczkę CVSMenu i dodać ją do mojego edytora, aby uzyskać tę funkcjonalność.

To samo z podświetlaniem składni, zachowaniem z określonymi plikami, itp. W vimie można dostosować różne rzeczy.

Nie jestem pewien, czy możesz to zrobić tak łatwo w edytorach graficznych.

Nagrywanie i odtwarzanie w VIM jest niewiarygodnie niesamowite, czego raczej nie znajdziesz w narzędziach opartych na GUI.

Również automatyczne zwiększanie / zmniejszanie daje możliwości generowania danych bez konieczności pisania dla nich programów.

Przez lata byłem zdezorientowanym użytkownikiem Emacsa. Ale tak naprawdę nigdy się w to nie wdałem. Potem zacząłem uczyć się Clojure (mój pierwszy Lisp) i odkryłem ParEdit.

I to mnie rozwaliło.

(Zobacz tutaj kilka przykładów: https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit to najbardziej niesamowite doświadczenie edycyjne, jakie kiedykolwiek miałem. Nic innego się nie zbliża. Lisp nie jest już niezręcznym językiem do pisania, zmuszając mnie do martwienia się o balansowanie wieloma irytującymi, głupimi nawiasami. Dzięki ParEdit spójna struktura Lisp staje się ogromnym bonusem do pracy, ponieważ te same transformacje drzew - siorbanie, barfing, dzielenie i łączenie - działają wszędzie, zarówno w strukturach kontrolnych, jak i strukturach danych. A ParEdit zapobiega popełnieniu głupich błędów. Popełnianie błędów składniowych staje się prawie niemożliwe.

I w przeciwieństwie do Eclipse, nie jest to żmudne sprawdzanie w czasie rzeczywistym, które zawsze działa w tle, spalając mój procesor. To nic nie kosztuje ... ParEdit po prostu dokonuje prawidłowej zmiany strukturalnej, kiedy o to poproszę.

(Ogólnie Emacs jest tak szybki, jak powinien. W przeciwieństwie do Eclipse, które przypomina pisanie w kleju).

Następną rzeczą, jaką odkryłem, był Yasnippet ( http://emacswiki.org/emacs/Yasnippet ). Po raz kolejny czegoś takiego wcześniej nie użyłem. Nie jest to zwykłe makro do dodania standardowego schematu, ale dynamiczna, nawigacyjna forma

Ostatnią przyjemnością jest uświadomienie sobie, że jeśli sam chcę to rozszerzyć, aby mieć więcej tych narzędzi zwiększających produktywność na wysokim poziomie, mogę pracować z samym Lispem.

(Moje doświadczenie to kilka lat z Visual Studio i innymi IDE, potem 15 lat z Vimem i ostatnie 6 miesięcy z Emacsem.)

Długowieczność - Vim / Emacs to FOSS i istnieją od dziesięcioleci. Ich użycie nie spadnie, a ich funkcje nie będą się zbytnio łamać / znikać / zmieniać, więc możesz polegać na budowaniu całego rdzenia narzędzi kariery wokół opanowania tylko jednego edytora.

Zdalny / wszechobecny dostęp w terminalach - chociaż oba mają doskonałe systemy do edycji zdalnych plików, możesz je również zainstalować w dowolnym systemie, do którego kiedykolwiek się zalogujesz.

Rozwój oparty na REPL - oba mają tryby SLIME w różnych formach, które integrują każdy typ REPL, z którym pracujesz. Np. Nigdy nie spotkałem się z iteracyjnym rozwojem tak potężnym, jak ten oferowany przez CIDER .

Linting - dowolny język, którego używasz, prawdopodobnie ma pewne narzędzia do lintowania , niezależnie od tego, czy są wbudowane w kompilator, czy narzędzie zewnętrzne. Te integrują się bezproblemowo z Emacs / Vim, pokazując błędy w kodowaniu niemal w czasie rzeczywistym.

Gramatyka poleceń mnemonicznych - chociaż nauka obu zajmuje trochę czasu, te edytory oferują słynne sprytne systemy dostępu - a nawet zapamiętywania - tysięcy poleceń za pomocą kilku naciśnięć klawiszy i kombinacji klawiszy. Mogą one całkowicie wyeliminować potrzebę używania myszy, jeśli masz na to ochotę.

Wbudowane systemy pomocy - dokumentacja offline wielu języków i ich interfejsów API jest często stosowana w tych edytorach i jest dostępna w podobnie prosty sposób jak w rozległych i wszechstronnych systemach pomocy, które zawierają. W większości popularnych języków dodano automatyczne uzupełnianie. Ponadto istnieje bogata pomoc w dyskusji na praktycznie każdy temat pomocy.

Nawigacja - tagi, polubienia paredit, znaczniki, okienka, tabulatory, skoki w vim-rails i wiele innych wbudowanych.

Menedżerowie pakietów / repozytoria - Emacs ma kilka (elpa, melpa, marmolade), a Vima też są dobre (vundle, patogen itp .). Nie znam żadnych społeczności wokół IDE, które oferują coś podobnego do tych. Widzę ponad 5000 paczek z package-list-packages.

Poza samą edycją - Emacs posuwa się najdalej dzięki możliwości czytania wiadomości, przeglądania Internetu, zarządzania pocztą e-mail, edytowania arkuszy kalkulacyjnych, tworzenia prezentacji i organizowania wszystkiego.

Zintegrowane wszystko inne - debuggery, synchronizacja przeglądarki, kompilacja, powłoki, uruchamianie testów.

Nieskończenie konfigurowalny - Elisp to bardzo potężny język do rozszerzania / modyfikowania Emacsa. VimL jest odpowiednikiem Vima. O obu są napisane książki. Dostosuj motywy i zachowania kolorów do swojej radości!

Zaletą wszystkich edytorów konsolowych nad edytorami GUI jest to, że można je uruchomić w multipleksorze terminala, takim jak screen lub tmux . Dlaczego to jest dobre?

• Szybsze jest przełączanie się z jednej konsoli multipleksera terminala na inną niż przełączanie się z jednej konsoli GUI na inną za pomocą myszy, a nawet alt-tab. Dzieje się tak, ponieważ konsolom można nadawać nazwy i przełączać się na nie, wpisując kilka znaków nazwy.
• Jeśli sesje edytora znajdują się w konsolach terminala multipleksora, możesz uzyskać do nich dostęp z dowolnego komputera. Jeśli muszę wykonać jakąś pracę w domu, mogę ssh do mojego pudełka, podłączyć już działający multipleksor terminala do mojej sesji ssh i być dokładnie tam, gdzie skończyłem, kiedy skończyłem pracę.

Ponieważ vim / emacs są często używane przez programistów i jako użytkownik C # od 2003 r., Z tego uprzedzenia pov można to zrobić w inny sposób niesprawiedliwe porównanie (innym może być VS C ++ z Visual Assist X vs C ++ w vim / emacs):

Dla C # i Visual Studio:

1. Właśnie policzyłem liczbę naciśnięć klawiszy dla tej linii:

       public List<string> Names = new List<string>();
   //  3      3    3      1111111111111            211   =3+3+3+8+5+2+1+1 = 26 keys strokes + 3 uses of Shift while typing the line above in VS C# 2013 vs 47 key strokes for non-IntelliSense IDE's
   //                              (IntelliSense offers the List<string> because that's what you're likely after here but you can type something else if you want)
   // https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction explains on how this is impl. for C#. In C++ I've heard of 3rd party VS plugin that improves or replaces the VS C++ auto-complete

2. Czytałem o funkcji emacsa do skoków w kodzie. Nie sądzę, że ma dokładnie taką funkcję. Ma jednak podobną funkcję. Oto wada VS. Jest wiele drobnych funkcji, ale z czasem przestają działać. Ostatnio sprawdzałem, że funkcja przeskoku nie działa, ale to było kilka lat temu. VS wprowadził nową funkcję graficznego skoku, z której korzystałem. Wymaga myszy lub dotyku.

3. Oto gdzie wygrywa emacs / vi. Jeśli musisz dużo przeskakiwać w kodzie, funkcje VS do tego nie istnieją lub nie zostały wystarczająco przetestowane.

Problem z nawigacją GUI za pomocą myszy polega na tym

a) Podobnie jak siedzenie w bardzo statycznej pozycji może być złe, jeśli tak, myszy mają również tendencję do ustawiania palców w pozycji statycznej. Ból nadgarstka ustąpił po zmianie na trackball. Najpierw wypróbowałem mysz pionową, ale nic to nie rozwiązało.

b) Moja idealna klawiatura miałaby 2 rzędy klawiszy funkcyjnych, bez klawiatury numerycznej, więc mógłbym umieścić trackball bliżej, dzięki czemu odległość skoku byłaby bardziej znośna.

Ostatecznie jednak, jeśli chcesz przeskoczyć między kilkoma określonymi miejscami, jasne jest, że „pierścień zaznaczania” jest bardziej skuteczny. VS ma coś podobnego ... ostatnio go używałem, po prostu nie działało niezawodnie ...

c) i prawdopodobnie jest mnóstwo drobnych funkcji, które psują się z każdą wersją, więc jest to wada VS.

Rozwiązanie tego problemu „zamkniętego źródła”: napisz cały VS w języku C #, a następnie zezwól na modyfikowanie / edytowanie skompilowanego kodu (w czasie wykonywania, zapisując zmiany jako łatkę, która jest opcjonalnie ładowana przy następnym uruchomieniu) bez zwalniania źródła. Można to zrobić, nakazując dekompilatorowi wyjście kodu w takiej postaci, w jakiej był przy wejściu. 180 stopni od sposobu działania kompilatorów natywnych. Plik binarny staje się wtedy kodem źródłowym, a plik wykonywalny zamiast tego bałaganu plików .cs i .exe itp. Istnieją narzędzia innych firm, które już prawie to potrafią, więc "modyfikowanie" C # exe jest raczej trywialne, ale proponuję wziąć to do logiczny wniosek: uwzględnij nawet komentarze w plikach .exe i .dll. Pliki nadal będą niewielkie w porównaniu do skompilowanych aplikacji C / C ++. Optymalizacja? Możesz również dołączyć wstępnie zoptymalizowany kod. Kiedy modder modyfikuje exe, gdy aplikacja jest uruchomiona, niezmodowany „AST” i towarzyszący mu zoptymalizowany plik binarny są ponownie podłączane. Taki sam pomysł jak w kompilatorze C #, ale kontynuowany. Następny krok: Napisz cały system operacyjny w tym języku, aby nawet gdy system Windows był zamkniętym źródłem, można go było w trywialny sposób zmodyfikować, ponieważ kod źródłowy jest dostarczany z każdym plikiem binarnym. Bez konfigurowania środowisk, kompilowania, linkowania. Po prostu zmodyfikuj system operacyjny, gdy jest uruchomiony. Ścisła analogia: jeśli napisałeś przeglądarkę internetową w Common Lisp, możesz edytować przeglądarkę internetową bez jej zatrzymywania i tworzyć strony internetowe w tym samym języku, co przeglądarka. można go w trywialny sposób zmodyfikować, ponieważ kod źródłowy jest dostarczany z każdym plikiem binarnym. Bez konfigurowania środowisk, kompilowania, linkowania. Po prostu zmodyfikuj system operacyjny, gdy jest uruchomiony. Ścisła analogia: jeśli napisałeś przeglądarkę internetową w Common Lisp, możesz edytować przeglądarkę internetową bez jej zatrzymywania i tworzyć strony internetowe w tym samym języku, co przeglądarka. można go w trywialny sposób zmodyfikować, ponieważ kod źródłowy jest dostarczany z każdym plikiem binarnym. Bez konfigurowania środowisk, kompilowania, linkowania. Po prostu zmodyfikuj system operacyjny, gdy jest uruchomiony. Ścisła analogia: jeśli napisałeś przeglądarkę internetową w Common Lisp, możesz edytować przeglądarkę internetową bez jej zatrzymywania i tworzyć strony internetowe w tym samym języku, co przeglądarka.