*os_win32.txt* Pour Vim version 6.1. MANUEL de RÉFÉRENCE VIM - par George Reilly *win32* *Win32* *MS-Windows* Ce fichier documente les particularités de la version Win32 de Vim. La version Win32 de Vim fonctionne aussi bien sur Windows NT que sur Windows 95. Il existe à la fois une version console et une version IHM graphique. Il existe aussi une version IHM graphique utilisable dans le sous-système Win32s de Windows 3.1[1]. Vous pouvez également utiliser la version DOS 32 bits de Vim à la place. Voir |os_msdos.txt|. 1. Problèmes connus |win32-problems| 2. Démarrage |win32-startup| 3. Restaurer le contenu de l'écran |win32-restore| 4. Utiliser la souris |win32-mouse| 5. Travailler sous Windows 3.1 |win32-win3.1| 6. Mini FAQ Win32 |win32-faq| De plus, il existe des éléments communs aux versions Win32 et DOS : Emplacement des fichiers |dos-locations| Utiliser les contre-obliques |dos-backslash| Mappages standards |dos-standard-mappings| Rendu à l'écran et couleurs |dos-colors| Formats des fichiers |dos-file-formats| Commande :cd |dos-:cd| Interrompre |dos-CTRL-Break| Fichiers temporaires |dos-temp-files| Options par défaut du shell |dos-shell| IHM graphique Win32 |gui-w32| Contributeurs : La version Win32 a été écrite par George V. Reilly . Le premier portage pour Windows NT a été réalisé par Roger Knobbe . La version IHM graphique a été réalisée par George V. Reilly et Robert Webb. Pour compiler Vim, consultez src/INSTALL.pc. *win32-compiling* ============================================================================== 1. Problèmes connus *windows95* *win32-problems* Il existe quelques problèmes connus avec l'exécution de Vim dans une console sous Windows 95. À notre connaissance, c'est également le cas avec Windows 98 et Windows ME. Commentaire d'une personne travaillant chez Microsoft : "Win95 console support has always been and will always be flaky." (« Le support de la console sous Win95 a toujours été et sera toujours farfelu. ») 1. Le support des touches mortes ne fonctionne pas. 2. Le redimensionnement de la fenêtre avec ":set columns=N lines=N" fonctionne, mais l'exécution de commandes externes PEUT PROVOQUER LE BLOCAGE OU LE PLANTAGE DE VOTRE SYSTÈME. 3. Le rafraîchissement de l'affichage est lent, à moins que vous ne donniez à 'columns' et 'lines' des valeurs non-DOS. Mais le problème 2 survient alors ! Si cela vous dérange, utilisez la version MS-DOS 32 bits ou la version graphique Win32. Lors du complètement du nom d'un fichier, Vim trouve aussi la correspondance pour le nom court du fichier. Mais il trouvera et utilisera le nom long de toute façon. Par exemple, si vous avez un nom de fichier long "ceci_est_un_essai" avec le nom court "ceci_e~1", la commande ":e *1" lancera l'édition du fichier "ceci_est_un_essai". ============================================================================== 2. Démarrage *win32-startup* RÉPERTOIRE COURANT *win32-curdir* Lorsqu'il est lancé avec un seul nom de fichier en argument, et que son chemin est complet (il commence par "x:\"), Vim suppose qu'il a été lancé depuis l'explorateur de fichiers et fixera le répertoire courant à l'emplacement de ce fichier. Pour éviter cela lorsque vous tapez une commande pour lancer Vim, utilisez une oblique « normale » plutôt qu'une contre-oblique. Exemples : > vim c:\texte\fichiers\toto.txt Ceci changera le répertoire courant en "C:\texte\fichiers". > vim c:/texte\fichiers\toto.txt Ceci utilisera le répertoire courant actuel. OPTION DU TERMINAL *win32-term* Le seul type de terminal supporté par la version Win32 est "win32". C'est un terminal interne. Si vous fixez 'term' sur quoi que ce soit d'autre, vous obtiendrez probablement un comportement très bizarre de Vim. C'est pourquoi Vim ne cherche pas à récupèrer de valeur par défaut pour 'term' depuis la variable d'environnement "TERM". ============================================================================== 3. Restaurer le contenu de l'écran *win32-restore* Quand 'restorescreen' est activé (c'est le cas par défaut), Vim rétablit le contenu original de la console quand vous quittez ou lors de l'exécution de commandes externes. Si cela n'est pas ce que vous voulez, utilisez ":set nors". Voir |'restorescreen'|. ============================================================================== 4. Utiliser la souris *win32-mouse* La version Win32 de Vim supporte l'utilisation de la souris. Si vous avez une souris avec 2 boutons, le bouton du milieu peut être émulé en pressant les boutons gauche et droit simultanément. NOTE : Dans l'IHM graphique Win32, si le menu contextuel du bouton droit de la souris est activé (voir 'mousemodel'), presser d'abord le bouton gauche peut provoquer des erreurs. Voir |mouse-using|. Si la souris ne fonctionne pas, essayez de désactiver la fonctionnalité "Mode d'édition rapide" de la console. ============================================================================== 5. Travailler sous Windows 3.1 *win32-win3.1* *win32s* *windows-3.1* Il existe une version particulière de gVim qui fonctionne sous Windows 3.1 et 3.11. Vous aurez besoin du fichier gvim.exe qui a été compilé avec Visual C++ 4.1. Pour faire fonctionner la version Win32 sous Windows 3.1, vous devez installer Win32s. Il est possible que vous l'ayez déjà installé avec une autre application Win32. Si Vim ne semble pas fonctionner correctement, récupérez la dernière version : 1.30c. Vous pouvez la trouver sur : http://support.microsoft.com/download/support/mslfiles/pw1118.exe (Avec un peu de chance, Microsoft ne l'aura pas déplacé à nouveau !) La raison d'avoir deux versions de gvim.exe est que la version Win32s a été compilée avec Visual C++ 4.1. C'est la dernière version de VC++ qui supporte les programmes Win32s. VC++ 5.0 est meilleur, il donc est utilisé pour la version Win32. Ceci mis à part, il n'y a pas de différence entre ces programmes. Si vous êtes dans un environnement hétérogène, vous pouvez utiliser indifféremment gvim.exe pour Win32s. La version Win32s fonctionne de la même manière que la version Win32 sous 95/NT. Avec la version Win32s, les différences suivantes s'appliquent : - Vous ne pouvez pas utiliser les noms de fichiers longs, car Windows 3.1 ne les supporte pas ! - Lors de l'exécution d'un commande externe, aucun code de retour n'est renvoyé. Après un ":make", vous devez faire le ":cn" vous-même. ============================================================================== 6. Mini FAQ Win32 *win32-faq* Q. Pourquoi la version Win32 de Vim rafraîchit l'écran si lentement sur Windows 95 ? R. Le support de la console pour les applications Win32 est très bogué sur Windows 95. Pour une raison inconnue, le rafraîchissement de l'écran est très lent quand Vim fonctionne dans l'une des résolutions standards (80x25, 80x43 ou 80x50), et la version DOS 16 bits rafraîchit l'écran bien plus rapidement que la version Win32. Toutefois, si l'écran est basculé dans une autre résolution, par exemple avec ":set columns=100 lines=40", le rafraîchissement devient à peu près aussi rapide que celui de la version 16 bits. AVERTISSEMENT : Modifier 'columns' peut faire planter Windows 95 lors du rafraîchissement de la fenêtre (plaintes --> Microsoft). Puisque cela fonctionne presque, cela n'a pas été désactivé, mais restez prudent si vous changez 'columns'. Changer la résolution de l'écran rend l'affichage plus rapide, mais amène de nouveaux problèmes. Les commandes externes (par exemple, ":!dir") peuvent provoquer le blocage de Vim quand l'écran est dans une résolution qui n'est pas standard, en particulier quand 'columns' est différent de 80. Il n'est pas possible à Vim de remettre de manière fiable la résolution de l'écran à la valeur qu'elle avait au démarrage, avant l'exécution des commandes externes. Donc, si vous changez les nombres de lignes ('lines') ou de colonnes ('columns'), soyez très, très prudent. En fait, Vim ne vous permettra pas d'exécuter des commandes externes lorsque 'columns' est différent de 80, car la probabilité d'un blocage est trop importante. Aucun des problèmes ci-dessus n'existe sur Windows NT. Le rafraîchissement de l'écran est rapide, quel que soit le nombre de lignes ('lines') ou de colonnes ('columns') de la fenêtre, et les commandes externes ne provoquent aucun blocage. Q. Du coup, si le rafraîchissement est si lent avec la version Win32 sur Windows 95 alors que la version DOS 16 bits est bien plus rapide, pourquoi voudrais-je utiliser la version Win32 ? R. Premièrement, la version Win32 n'est pas si lente que cela, en particulier quand l'écran est réglé sur un nombre de lignes et de colonnes non standard. Deuxièmement, la version DOS 16 bits souffre de limitations sévères : elle ne permet pas de faire des changements importants et ne reconnaît pas les noms de fichiers longs. La version Win32 n'a pas ces limitations et est globalement plus rapide (vrai également pour la version DOS 32 bits DJGPP de Vim). La version Win32 est plus intelligente dans sa manière de gérer l'écran, la souris et le clavier que ne l'est la version DJGPP. Q. Et la version DOS 16 bits par rapport à la version Win32 sur NT ? R. Il n'existe aucune bonne raison d'utiliser la version DOS 16 bits sur NT. La version Win32 rafraîchit l'écran aussi rapidement que la version 16 bits sur NT. Tous les inconvénients cités ci-dessus s'appliquent. Enfin, les applications DOS peuvent mettre plus de temps à démarrer et fonctionnent plus lentement. Sur les plates-formes non Intel, la version DOS est pratiquement inutilisable du fait de sa lenteur, parce qu'elle fonctionne au sein d'un émulateur 80x86. Q. Comment puis-je changer la police ? R. Dans le version IHM graphique, vous pouvez utiliser l'option 'guifont'. Dans la version console, vous devez changer la police de la console. Vous ne pouvez pas le faire depuis Vim. Q. Quand je change la taille de la fenêtre de la console avec ":set lines=N" ou équivalent, la police change ! (Win95) R. La police de la console est fixée sur "Auto" dans les propriétés de Vim (ou dans celles de votre Invite de commande MS-DOS). Cela demande à Win95 de déterminer la meilleure police possible (pas toujours pertinent). Donnez une police explicite à la place. Q. Pourquoi ne puis-je pas coller du texte dans Vim sous Windows 95 ? R. Dans la boîte de dialogue des propriétés de la fenêtre MS-DOS, allez à "MS-DOS Prompt/Misc/Fast pasting" XXX et assurez-vous qu'il n'est PAS activé. Vous devriez également saisir ":set paste" dans Vim pour éviter des effets inattendus. |'paste'| Q. Comment puis-je taper des touches mortes sur Windows 95, dans la version console ? (Une touche morte est une touche avec un accent, par exemple grave, aigu, ou tréma, qui ne produit pas de caractère par elle-même mais qui, suivie d'une autre touche, produit un caractère accentué, comme 'e' accent grave, 'i' tréma, 'n' tilde, ainsi de suite. Très utile pour la plupart des langues européennes. L'agencement des claviers en langue anglaise ne propose pas de touches mortes, à notre connaissance.) R. Vous ne pouvez pas. Les routines d'entrée du mode console ne fonctionnent pas correctement sous Windows 95, et je n'ai pas réussi à trouver une solution. Voici les mots d'un « développeur senior » de Microsoft : « Le support de la console sous Win95 a toujours été et sera toujours farfelu. Cette absurdité est inévitable parce que nous sommes coincés entre le monde des programmes résidents MS-DOS pour le clavier, tel que KEYB (qui veux trafiquer les données ; important pour l'internationalisation), et le monde Win32. Donc les touches qui « n'exitent pas » dans le monde MS-DOS (comme les touches mortes) ont une existence très ténue dans le monde console Win32. Les touches qui réagissent différement entre les mondes MS-DOS et console Win32 (par exemple Verr Maj) auront un comportement farfelu. Ne parlons même pas des problèmes liés à l'agencement de claviers selon la langue... » Vous devriez pouvoir contourner ce problème en utilisant le mécanisme des digraphes. |digraphs| La meilleure solution est d'utiliser la version IHM graphique Win32 gvim.exe. Sinon, vous pouvez essayer l'une des versions DOS de Vim où les touches mortes sont signalées opérationnelles. Q. Comment puis-je taper des touches mortes sur Windows NT ? R. Les touches mortes fonctionnent sur NT 3.51. Utilisez-les comme vous le feriez dans toute autre application. Sur NT 4.0, vous devez vous assurer que la région linguistique par défaut (qui est définie dans la partie Clavier du Panneau de configuration) est la même que la région linguistique actuellement utilisée. Sinon, le code NT s'embrouille et plante ! Ce problème est dû à NT 4.0, ce n'est pas vraiment un problème Vim. Q. J'utilise Vim pour éditer un fichier situé sur un serveur de fichiers Unix NFS par le biais d'un lien symbolique. Quand j'écris le fichier, Vim n'écrit pas « à travers » le lien ; Au lieu de cela, il efface le lien et le remplace par un nouveau fichier. Pourquoi ? R. Sur Unix, Vim s'attend à trouver des liens (symboliques ou physiques). Une copie du fichier original est réalisée puis le fichier original est écrasé. Ceci assure que toutes les propriétés du fichier restent les mêmes. Sur les systèmes non-Unix, le fichier original est renommé et un nouveau fichier est écrit. Seuls les bits de protection sont positionnés comme pour le fichier original. Toutefois, cela ne fonctionne pas correctement lorsque l'on travaille sur un système de fichiers NFS monté localement, où les liens et d'autres choses existent. La seule manière de corriger ceci dans la version actuelle est de ne pas créer de fichier de sauvegarde, avec ":set nobackup nowritebackup". Voir |'writebackup'|. Q. Comment puis-je faire pour voir la sortie de ":make" pendant qu'il est en cours ? R. En fait, vous devez ajouter le programme "tee", qui copie ce qu'il reçoit (la sortie de make) sur la sortie standard stdout et dans le fichier d'erreurs. Vous pouvez trouver une copie de tee (et de nombreux autres outils GNU) sur : ftp://ftp.cc.utexas.edu/microlib/nt/gnu Sinon, essayez la dernière version Cygnus des outils GNU, disponible sur : http://www.cygnus.com/misc/gnu-win32 Vous trouverez également des choses intéressantes sur le site Virtual Unix de Chris Szurgot, http://www.itribe.net/virtunix. Microsoft dispose de quelque outils similaires à ceux d'Unix sur : http://www.microsoft.com/ntserver/tools/Maintnce.htm Lorsque que vous aurez obtenu une copie de tee, vous devrez ajouter > :set shellpipe=\|\ tee < à votre fichier "_vimrc". Q. J'enregistre des fichiers sur une machine distante qui fonctionne avec VisionFS, et des fichiers disparaissent ! R. VisionFS ne gère pas certaines extensions de fichiers formées d'un point ('.') suivi de trois lettres. SCO affirme que ce comportement est requis pour la compatibilité ascendante avec les environnements DOS/Windows 16 bits. Les deux commandes ci-dessous mettent ce comportement en évidence : > echo Bonjour > fichier.bat~ dir > fichier.bat < Le résultat est le suivant : la commande "dir" met à jour le fichier "fichier.bat~", au lieu d'en créer un nouveau. Ce même comportement a lieu dans Vim lors de l'édition d'un fichier existant "toto.bat", car le comportement par défaut de Vim est de créer un fichier temporaire avec un caractère '~' ajouté à la fin du nom. Lors de l'enregistrement du fichier, il se retrouve effacé. Solution : Ajouter cette commande à votre fichier "_vimrc" : > :set backupext=.temporaire Q. Comment puis-je changer la fréquence de clignotement du curseur ? R. Vous ne pouvez pas ! C'est une limitation de la console NT. NT 5.0 est signalé comme étant capable de changer la fréquence de clignotement du curseur pour toutes les consoles à la fois. *:!start* Q. Comment puis-je lancer une commande externe ou un programme de manière asynchrone ? R. En utilisant ":!" pour lancer une commande externe, vous pouvez la démarrer avec "start" : > :!start winfile.exe < L'utilisation de "start" indique à Vim de ne plus basculer sur un nouvel écran, ouvrir une nouvelle console, ou attendre que le programme se termine ; cela indique que le programme que vous lancez n'affecte pas les fichiers en cours d'édition. Les programmes commençant par ":!start" ne récupèrent pas les descripteurs de fichiers ouverts de Vim, ce qui signifie qu'il n'est pas nécessaire qu'ils soient terminés avant Vim. Pour éviter ce cas particulier, utilisez ":! start". Q. J'utilise Win32s, et quand j'essaye de lancer une commande externe telle que "make", Vim n'attend pas qu'elle soit terminée ! Au secours ! R. Le problème est qu'une application 32 bits (Vim) ne peut pas recevoir de notification de la part de Windows qu'une application 16 bits (votre session DOS) est terminée. Vim dispose d'une solution de contournement pour ce problème, mais vous devez paramétrer vos commandes DOS pour qu'elles fonctionnent dans une fenêtre plutôt qu'en plein écran. Pour cela : 1° Ouvrez l'éditeur PIF (dans le groupe Programmes principaux) ; 2° Ouvrez le fichier "_default.pif" situé dans votre répertoire Windows ; 3° Changez l'option d'affichage de "Plein écran" à "Fenêtre" ; 4° Enregistrez puis sortez. Pour vérifier, démarrez Vim et tapez > :!dir C:\ < Vous devriez voir une fenêtre DOS apparaître brièvement avec la liste des fichiers du répertoire. Q. J'utilise Vim sous Win32s et NT. Sur NT, je peux demander à la console de faire 50 lignes par défaut, pour obtenir un shell de 80x50 caractères lors d'un ":sh". Puis-je faire la même chose sur Win3.1x, ou suis-je coincé en 80x25 ? R. Éditez le fichier "system.ini" et ajoutez "ScreenLines=50" dans la section [NonWindowsApp]. L'invite de commande DOS et les commandes externes DOS fonctionneront à présent dans une fenêtre de 50 lignes. vim:tw=78:fo=tcq2:ts=8:ft=help:norl: