Il n'existe actuellement aucun moyen direct de réinitialiser la liaison d'une clé à sa valeur par défaut. l'initialisation des liaisons par défaut (in key_bindings_init()
) est effectuée une fois lorsque le serveur tmux démarre (in server_start()
), et il n'existe aucun mécanisme permettant de réinitialiser une clé unique.
Pour le scénario souhaité dans lequel vous voulez que l'acte de sourcing de votre fichier de configuration rétablisse une liaison par défaut précédemment remplacée par une liaison personnalisée qui a depuis été supprimée de votre fichier de configuration, la méthode que vous avez conçue est raisonnable (bien que malheureusement prolixe): unbind-key -a
, puis rétablissez toutes les liaisons «par défaut», puis établissez vos liaisons personnalisées (dont certaines peuvent remplacer une liaison «par défaut»).
Les liaisons actuelles d'un serveur peuvent être extraites avec la list-keys
commande * ; cela peut aider à générer / maintenir votre .tmux.reset.conf
fichier proposé , mais vous avez besoin d’un moyen d’extraire les liaisons par défaut , pas les liaisons actuelles .
* Il y a des situations où la sortie list-keys
est pas directement utilisable: la liaison pour virgule a besoin de son point - virgule échappé avec une barre oblique inverse pour l' empêcher d'être interprété comme un tmux séparateur de commande, et toutes les liaisons qui ont des arguments qui ont utilisé des guillemets doubles à l' intérieur unique les guillemets (aucune des liaisons par défaut ne sont comme celle-ci) apparaîtront sous forme de guillemets doubles à l'intérieur doubles à l' doubles qoutes.
Pour obtenir les liaisons par défaut, vous avez besoin d'un serveur temporaire avec une configuration minimale (c'est-à-dire sans liaisons personnalisées) afin de pouvoir capturer sa list-keys
sortie. Il n’existe aucune limite quant au nombre de serveurs tmux que vous pouvez exécuter, mais chacun doit utiliser un chemin de socket différent; les -L
et -S
tmux options peuvent être utilisées pour spécifier un nom de socket (en $TMPDIR/tmux-$UID
cheminServeur socket complet Donc, pour parler (ou commencer) un nouveau serveur sur un socket nommé. temp
, vous pouvez utiliser ceci:
tmux -L temp …
Pour vous assurer qu'il n'utilise pas votre .tmux.conf
, vous utilisez -f
pour lui dire de lire /dev/null
(un fichier spécial toujours vide):
tmux -f /dev/null -L temp …
Remarque : cela n’empêche pas le traitement des/etc/tmux.conf
, si un tel fichier existe; le chemin d'accès à ce «fichier de configuration système» est codé en dur et il n'y a pas d'option pour le contourner (à moins de corriger le code).
Normalement, vous avez besoin d'une new-session
commande pour démarrer le serveur, mais nous ne voulons pas de sessions, mais simplement d'un serveur initialisé à interroger. La start-server
commande ne fait que cela: démarre un serveur sans créer de session.
tmux -f /dev/null -L temp start-server …
Maintenant, il suffit d’ajouter notre commande «query» ( list-keys
dans ce cas):
tmux -f /dev/null -L temp start-server \; list-keys
Remarque : le point-virgule doit être échappé ou cité pour empêcher le shell de le traiter comme un séparateur de commandes shell, car nous souhaitons que ce soit un séparateur de commandes tmux .
Comme il n'y a pas de session à gérer, le serveur se ferme automatiquement une fois l'exécution de la list-keys
commande terminée .
Vous pouvez donc utiliser une commande comme celle-ci pour générer l'essentiel de votre travail .tmux.reset.conf
sans avoir à vous soucier de la suppression temporaire de votre .tmux.conf
fichier (pour vous permettre de voir uniquement les liaisons par défaut) et sans avoir à arrêter aucun serveur existant.
Si la run-shell
commande était synchrone, vous pouvez intégrer un appel comme celui-ci dans votre fichier de configuration (capture dans un fichier temporaire que vous traiteriez ensuite source-file
) au lieu d'avoir un fichier statique (votre .tmux.reset.conf
). Cela vous permettrait de toujours utiliser les liaisons par défaut de votre version actuelle de tmux (les liaisons par défaut changent de temps en temps). Hélas, l'achèvement de la run-shell
commande est actuellement asynchrone par rapport aux commandes suivantes (les commandes après l' run-shell
exécution d' une commande sont généralement exécutées avant que le processus généré par run-shell
ait eu la chance de se terminer).