Obecnie nie ma bezpośredniego sposobu, aby zresetować powiązanie klucza z domyślnym; inicjalizacja domyślnych powiązań (in key_bindings_init()) odbywa się raz, gdy serwer tmux uruchamia się po raz pierwszy (in server_start()), i nie ma mechanizmu do resetowania pojedynczego klucza.
W pożądanym scenariuszu, w którym chcesz, aby proces pozyskiwania pliku konfiguracyjnego ponownie ustanowił domyślne powiązanie, które zostało wcześniej zastąpione niestandardowym powiązaniem, które zostało później usunięte z pliku konfiguracyjnego, opracowana metoda jest rozsądna (choć niestety pełna): unbind-key -a , następnie przywróć wszystkie „domyślne” wiązania, a następnie utwórz własne wiązania (niektóre z nich mogą zastąpić „domyślne”).
Bieżące powiązania serwera można wyodrębnić za pomocą list-keyspolecenia * ; może to pomóc w generowaniu / utrzymywaniu proponowanego .tmux.reset.confpliku, ale potrzebujesz sposobu na wyodrębnienie domyślnych powiązań, a nie bieżących .
* Istnieją sytuacje, w których dane wyjściowe list-keysnie są obecnie bezpośrednio użyteczne: wiązanie średnika wymaga, aby jego średnik uciekł odwrotnym ukośnikiem, aby zapobiec interpretacji go jako separatora poleceń tmux oraz wszelkich powiązań, które miały argumenty wykorzystujące podwójne cudzysłowy wewnątrz pojedynczego cytaty (żadne z domyślnych powiązań nie są takie) pojawią się jako podwójne cudzysłowy wewnątrz podwójnego qoutes.
Aby uzyskać domyślne powiązania, potrzebujesz tymczasowego serwera z minimalną konfiguracją (tj. Bez niestandardowych powiązań), abyś mógł przechwytywać jego list-keysdane wyjściowe. Nie ma ograniczeń co do liczby serwerów Tmux , które możesz uruchomić, ale każdy z nich musi używać innej nazwy ścieżki gniazda; te -Li -S tmux opcje mogą być wykorzystane, aby określić nazwę gniazda (w $TMPDIR/tmux-$UIDlub pełną ścieżkę gniazdo tak, to do rozmowy (lub uruchomić) nowy serwer o nazwie gniazda. temp, należy użyć tego:
tmux -L temp …
Aby upewnić się, że nie używa twojego .tmux.conf, możesz -fpowiedzieć mu, aby przeczytał /dev/null(specjalny plik, który jest zawsze pusty):
tmux -f /dev/null -L temp …
Uwaga : nie uniemożliwia to przetwarzania/etc/tmux.conf , jeśli taki plik istnieje; ścieżka do tego „pliku konfiguracji systemu” jest zakodowana na stałe i nie ma możliwości ominięcia go (bez łatania kodu).
Zwykle potrzebujesz new-sessionpolecenia, aby faktycznie uruchomić serwer, ale nie chcemy żadnych sesji, tylko zainicjowany serwer do zapytania. start-serverKomenda właśnie to robi: uruchamia serwer bez tworzenia sesji.
tmux -f /dev/null -L temp start-server …
Teraz wystarczy dołączyć nasze polecenie „zapytanie” ( list-keysw tym przypadku):
tmux -f /dev/null -L temp start-server \; list-keys
Uwaga : średnik musi być poprzedzony znakiem zapytania lub cudzysłowem, aby powłoka nie traktowała go jako separatora poleceń powłoki, ponieważ chcemy, aby był tmux separatorem poleceń .
Ponieważ nie ma żadnych sesji do utrzymania, serwer zakończy działanie automatycznie po zakończeniu działania list-keys polecenia.
Możesz więc użyć takiego polecenia, aby wygenerować większość .tmux.reset.confbez konieczności tymczasowego usuwania .tmux.confpliku (aby zobaczyć tylko domyślne powiązania) i bez konieczności zamykania istniejących serwerów.
Jeśli run-shellpolecenie było synchroniczne, możesz osadzić takie wywołanie w pliku konfiguracyjnym (przechwytywanie do pliku tymczasowego, który następnie przetworzyłbyś source-file) zamiast mieć plik statyczny (twój .tmux.reset.conf). Pozwoliłoby to zawsze używać domyślnych powiązań z bieżącej wersji tmux (domyślne wiązania czasami się zmieniają). Niestety, wykonanie run-shellpolecenia jest obecnie asynchroniczne w odniesieniu do kolejnych poleceń (polecenia, które pojawiają się po run-shellpoleceniu, zwykle są uruchamiane, zanim proces spawnowany run-shellmiał szansę zakończyć).