Jak uruchamiać polecenia powłoki w Vimie, tak jak robi to Gary Bernhardt w swoich screencastach?
Oglądam screencasty Gary'ego Bernhardta Destroy All Software, a konkretnie A Compiler from Scratch . Tam wykonuje polecenia powłoki bez opuszczania Vima. Jestem prawie pewien, że tylko przy użyciu normalnej składni Vima, na przykład na znak 1 minut: :!chmod u+x compiler.rb. Jeśli zrobię to na moim komputerze, okno przełączy się na wykonanie polecenia powłoki, a następnie muszę nacisnąć Enter, aby wrócić do edytora. Wydaje mi się, że jest to normalne zachowanie Vima i innych osób już wcześniej o to pytało, ale nie sądzę, aby jakiekolwiek odpowiedzi działały tak, jak robi to Gary.
Spojrzałem na jego .vimrcplik, a konkretnie na ostatnią wersję przed przesłaniem screencasta, ale nie mogłem dowiedzieć się, co mógł zmienić, aby uzyskać zachowanie, którego szukam. Pobrałem go, ale nadal nie uzyskuję właściwego zachowania, więc oczywiście czegoś mi brakuje. Żadna z jego wtyczek nie wydaje się mieć z tym związku, więc w większości je ignorowałem.
Jestem prawie pewien, że nie szukam rozwiązania, które używa tmux lub rzeczy, takich jak :split, :term, :below terminal, lub :silent. Nie szukam też odpowiedzi, która używa czegoś innego niż Vim, uważam, że Gary używa tylko Vima i kilku wtyczek.
Oglądałem screencasty Gary'ego, w których konkretnie mówi o Vimie, ale nie odpowiedział na to pytanie (lub nie złapałem go), więc jeśli ktoś wymyślił, jak używać :! <shell command>bez opuszczania edytora tekstu, naprawdę byłbym wdzięczny, gdyby możesz mi pomóc rozwiązać ten problem. Przetestowałem opcje, o których wspomniałem wcześniej, zarówno na Macu, jak i na Linuksie, ale nic nie działało tak, jak bym chciał, i byłbym zadowolony z rozwiązania, które działa na obu platformach.
Odpowiedzi
Wideo szybko mija, ale wstrzymałem je i wydaje mi się, że widziałem, jak pisze:
:!chmod u+x %
Który następnie generuje ten wynik:
:!chmod u+x compiler.rb
[No write since last change]
"compiler.rb" 5L, 42C
Press ENTER or type command to continue
Tak, rzeczywiście, Vim ma zachęty do „Press ENTER” po komendzie jest kompletna, ale wydaje się on przycisnął ją tak szybko (może on oczekiwał go już? Czy może zaczął naciskając następujące polecenia?), Który wydaje się, że wiadomość była pominięty.
Istotne są tutaj dwa ustawienia, pierwsze, które uniemożliwiają przełączenie z alternatywnego ekranu podczas wykonywania polecenia, a drugie, aby automatycznie przeładować plik po zmianie przez polecenie zewnętrzne (nawet jeśli zmieniono tylko uprawnienia).
Patrząc na jego repozytorium dotfiles na GitHub, możemy faktycznie zobaczyć oba ustawienia w vimrc na dzień 2017-06-29 (czyli wtedy, kiedy to wideo zostało opublikowane).
- Skonfigurowanie Vima, aby nie przełączał się z alternatywnego ekranu, jest skonfigurowane za pomocą tego fragmentu :
" Prevent Vim from clobbering the scrollback buffer. See
" http://www.shallowsky.com/linux/noaltscreen.html
set t_ti= t_te=
- Konfigurowanie Vima do automatycznego ponownego ładowania pliku po wykonaniu zewnętrznej operacji z tym ustawieniem :
set autoread
Po włączeniu tych dwóch ustawień mogę prawie dokładnie odtworzyć ten sam efekt, z wyjątkiem tego, że nie otrzymuję [No write since last change]komunikatu. Nie jestem pewien, skąd to pochodzi, ponieważ o ile wiem, właśnie zapisał plik tuż przed chmodpoleceniem. (Jako dowód, wiersz statusu nie pokazuje [+]obok nazwy pliku, co oznaczałoby bufor, który został zmodyfikowany.)
Być może to coś innego z jego vimrc ... Teoretycznie powinno być możliwe pobranie go z GitHub i spróbowanie tego samego. Wygląda na to, że wideo używa Vima 7.4, więc może to być również jego częścią.
Wciąż patrząc na swoje repozytorium plików dotfiles na GitHub, wygląda na to, że wrócił do zezwalania Vimowi na przebicie bufora przewijania , więc zmienił zdanie w tej części.
Jeśli ta część nadal Cię interesuje, możesz rzucić okiem na wtyczkę vim-altscreen , która implementuje to zachowanie, z pewnymi kontrolkami wokół niego. Zobacz także dyskusję na temat pytania „Różnica między :!{cmd}i :w !{cmd}odnośnie alternatywnego ekranu” , w szczególności wyjątkową odpowiedź @ user938271 .