Quelles sont les utilisations pratiques du mode client-serveur?

Je sais que Vim autorise un mode serveur client ( :h clientserver): il est possible de le transformer en serveur qui obtiendra certaines commandes et les exécutera et en tant que client qui enverra les commandes au serveur.

Je comprends comment cela fonctionne, mais je ne peux pas imaginer une utilisation pratique de cette fonctionnalité: dans quels cas est-elle utile et quel flux de travail peut être créé à l'aide de cette fonctionnalité?

Ma question est donc simple: à quoi sert le mode client-serveur de Vim?

(Je souligne à nouveau que ma question n'est pas de savoir comment le faire fonctionner ou comment cela fonctionne, mais pourquoi l'utiliser.)

• Avant la fonction récente de canal / travail de Vim 7.4, la fonction client-serveur était le seul moyen de faire une compilation d'arrière-plan décente - sans aucune dépendance à Python. Nous commençons la compilation en tâche de fond, et lorsqu'elle se termine, elle notifie à vim, grâce au canal client-serveur, qu'elle est terminée.

• Il est également indirectement utilisé par des "plugins" comme pyclewn pour intégrer un débogueur dans vim. En fait, pyclewn utilise la fonctionnalité + netbeans (qui est construite au-dessus de + clientserver). D'autres projets notables utilisent cette interface netbeans pour intégrer vim à un IDE - voir :h netbeans-intro.

• Il est également utilisé par certains plugins de test comme vimrunner pour exécuter des tests dans Vim à partir de la ligne de commande. Je l'utilise pour tester mes plugins sur travis.

• Je me souviens aussi d'avoir synchronisé mes clics dans l'interface xdvi avec mon code source LaTeX grâce à + clientserver.

Mon utilisation de ceci est un peu plus simpliste (et peut-être banale) que celle de Luc Hermitte.

Si vous démarrez une instance de gvim avec ceci compilé dans (et il est, et est depuis longtemps, sur, par exemple, les principales distributions Linux comme Fedora et Debian), il démarre en mode serveur. J'ai mis l'accent sur "gvim" parce que ce que je vais décrire ne semble pas s'appliquer à une viminstance singulière dans un terminal GUI (bien que je suppose que ce pourrait être si vous utilisez le paramètre correctement).

Quoi qu'il en soit, vous pouvez ensuite ouvrir n'importe quel fichier de n'importe où dans cette instance de gvim avec gvim --remote [file path](sans --servernamespécification). J'en suis fan car je ne navigue pas beaucoup dans le système de fichiers directement avec vim; au lieu de cela, j'utilise un navigateur de fichiers orthodoxe (commandant de minuit) - ou plutôt, des tas d'entre eux ouverts à différents endroits, car ils mcsont légers et permettent à divers skins de schémas de couleurs de simplifier la différenciation entre eux (j'ai donc tendance à en avoir deux ou trois ouverts dans des espaces séparés). onglets dans au moins un terminal GUI). Cependant, je pense que le même principe s'appliquera à tout navigateur de fichiers qui vous permet une forme de raccourci clavier personnalisé avec laquelle vous pouvez vous associer gvim --remote %f. Dans mcJe l'ai dans le menu utilisateur, donc F2 + e et le fichier en surbrillance / sélectionné sont envoyés à l'instance gvim.

Cela s'améliore un peu: si vous ouvrez une deuxième instance de gvim, par exemple, sur le moniteur n ° 2 du même bureau, ou un bureau séparé, et peut-être un schéma de couleurs différent dans celui-ci, et cette fois donnez-lui une explicite --servername foo, vous pouvez envoyer fichiers à cette instance à la place avec:

 gvim --servername foo --remote [file path]

Quelque chose qui peut être utile ou non selon la portée de ce que vous faites, etc.

Développement embarqué. Souvent, dans le développement intégré, vous avez une prise IP, mais un espace limité sur le disque dur local, ou pas de mémoire non volatile, ou un certain nombre d'autres choses. Vous pouvez démarrer un serveur sur la carte intégrée, puis le client sur celui-ci sur votre ordinateur de développement et avoir toute votre configuration et balises installées localement.

J'ai écrit ma thèse de master en utilisant Vim, LaTeX et BibTeX. Pour gérer mes références BibTeX, j'ai utilisé un programme appelé JabRef . JabRef a une petite fonctionnalité intéressante où vous pouvez le connecter à une instance de serveur Vim, puis vous pouvez "pousser" la référence BibTeX de JabRef vers le document LaTeX que vous modifiez dans Vim.

Mon flux de travail est similaire à ce que Goldilocks a dit dans sa réponse. J'utilise la fonction de vim8 :terminalen combinaison avec l' --remoteoption. Je maintiens la disposition de 2 fenêtres dans vim. Code dans la fenêtre gauche et terminal à droite. J'utilise la bonne fenêtre (terminal) pour exécuter des compilations, naviguer dans le système de fichiers et ouvrir des fichiers dans l'instance actuelle de vim (à partir du terminal). Ce flux me permet de fonctionner avec très peu d'implication de souris.

J'utilise gvim et icewm (tout gestionnaire de fenêtres devrait le faire)

Démarrer une instance gvim

gvim somefile

Gvim intérieur, borne ouverte en séparation verticale

:botright vertical terminal
(or) short form
:bo vert term 
"botright" splits the window to right

Dans la fenêtre du terminal divisée

gvim --remote-send '<C-w><C-w>' --remote anotherfile

"--remote-send" will send Ctrl-W Ctrl-W to remote gvim instance(in our case, current instance) 
to put the cursor in the left window. Otherwise, the terminal split would be replaced by
'anotherfile' buffer.
"--remote" will open 'anotherfile' in left window.

Vous pouvez créer des alias pour ces longues commandes dans votre .zshrc / .bashrc et les raccourcir à votre guise.

Avec ce flux de travail, je quitte rarement mon instance gvim et utilise rarement la souris.