Voici comment je reproduis le comportement que j'observe.
Tout d'abord, j'entre cette commande:
echo aaaaa > a
vim a
Dans Vim, j'entre ces commandes:
:ls
:e #
:echo bufname('#')
Voici la sortie des trois commandes ci-dessus:
:ls
1 %a "a" line 1
:e #
E194: No alternate file name to substitute for '#'
:echo bufname('#')
La bufname('#')
commande ne produit aucune sortie.
Maintenant j'entre cette commande:
:bd #
Le tampon actuel est supprimé et il est remplacé par un tampon "[No Name]":
:ls
2 %a "[No Name]" line 1
Je m'attendais à obtenir l' E194
erreur lors de l'exécution :bd #
. Pourquoi at-il plutôt supprimé le tampon actuel?
J'utilise VIM - Vi IMproved 8.0
.
buffers
vim-windows
Apprenant solitaire
la source
la source
NVIM v0.3.0-dev
, j'ai vérifié.Réponses:
Preuve
Parce qu'il n'y a pas de fichier alternatif, vous exécutez simplement plain ol '
:bd
, supprimant le tampon actuel ... essayez-le sans#
et vous verrez que le résultat est le même. Une chose similaire se produit avec:buffer
,:sbuffer
et au moins quelques autres commandes qui acceptent#
comme argument: elles se comportent silencieusement comme si aucun argument n'était passé.Dans le même sens, si vous essayez de
:bunload #
vous obtenez cette erreur:E90: Cannot unload last buffer
. Exécutez:bunload
sans arguments et, encore une fois, vous obtiendrez le même résultat.Les documents
Nous avons donc des preuves qui
#
sont remplacées par "rien" (probablement une chaîne vide). Où allons-nous à partir d'ici? J'ai fouillé les fichiers d'aide pendant un certain temps en essayant de trouver la mention de ce comportement. Il n'y avait rien d'explicite mais:h cmdline-lines
dit (faites défiler une page ou deux) ...Je l'ai lu comme Vim mettant à
#
travers laexpand()
fonction (ieexpand('#')
) ou au moins le même code sous-jacent utilisé là-bas.:h expand()
dit:Sonne familier.
Le code
Maintenant, rien de ce qui précède n'est définitif ou ne donne une idée de pourquoi? donc j'ai passé plus de temps à creuser ... cette fois dans le code. Mon C est très rouillé et je n'ai pas de bons outils installés mais j'ai réussi à trouver une fonction qui fait une configuration pour
:bdelete
appelédo_bufdel()
. Cela envoie des arguments de ligne de commande parbuflist_findpat()
lesquels, s'il#
est rencontré, renvoie une valeurcurwin->w_alt_fnum
. C'est le "numéro de tampon" du tampon alternatif ... qui ne peut pas être une valeur positive dans notre scénario. (Il n'y a pas de vérification pour savoir si le fichier alt est valide / existe avant que cette valeur de retour ne soit sélectionnée.)Un retour en arrière dans
do_bufdel()
une vérification est effectué par rapport à cette valeur de retour pour un numéro de tampon inférieur à 0, auquel cas la boucle de traitement des paramètres est interrompue. Cela n'entraînerait aucun paramètre présenté au:bdelete
code de base ... ce qui correspond exactement à mes intuitions précédentes.Et après?
Il semble fonctionner comme prévu car je n'ai rien vu qui ressemblait à un bug clair. Peut-être un péché d'omission, cependant ... un cas d'angle qui a été négligé et n'a donc aucune manipulation gracieuse. Mais seuls les développeurs qui ont écrit cela savent avec certitude. La dernière étape serait donc d'essayer d'obtenir leur avis. Comme l'a dit Christian B., demander sur la liste vim-dev est la voie à suivre.
(Notez que
buflist_findpat()
est une fonction d'utilité de sorte qu'il ne nécessiterait pas un étirement de l'imagination de supposer que:bunload
,:buffer
etc. utilisent, aussi ... qui expliquerait leur comportement commun par rapport à#
.)la source