A partir du moment où ton type de fichier est coloré, tu n'a rien d'autre à faire que d'appeler TOhtml dans mes souvenirs.
La conversion en html a bel et bien lieu, mais elle ne tient pas compte des balises spécifiques de Markdown, du moins chez moi.

Je vais essayer aussi de consulter des gens qui utilisent le fichier de syntaxe pour Vim que Ben Williams a écrit pour la coloration et je vous reviens si je trouve quelques chose d'utile :

http://www.vim.org/scripts/script.php?script_id=1242
Je viens de télécharger cet addon et il est fort bien fait. Je peux enfin mettre ma souris dans la poubelle... sauf pour le flash... et... toutes les choses stupides qui demandent l'usage d'une souris.
bah sinon

:!pandoc %

Qu'est-ce qu'il te faut de plus ?
15 jours plus tard
Je suis bluffé. J'étais persuadé qu'il avait déjà été signalé.
NERDtree est effectivement un plugin assez connu et apprécié de beaucoup. Maintenant, je préfère les solutions à base de complétion automatique.
Et il remplace aussi l'explorateur par défaut, il suffit de faire "vim répertoire" pour s'en convaincre 🙂

Tu as un exemple d'outil de complétion ? Avec signets sur les répertoires ou tu pensais à autre chose ?
Excellent, vous parler de NERDTree que je viens de découvrir.

Voici les principales commandes si cela peut servir quelqu'un 🙂
o.......Open files, directories and bookmarks....................|NERDTree-o|
go......Open selected file, but leave cursor in the NERDTree.....|NERDTree-go|
t.......Open selected node/bookmark in a new tab.................|NERDTree-t|
T.......Same as 't' but keep the focus on the current tab........|NERDTree-T|
i.......Open selected file in a split window.....................|NERDTree-i|
gi......Same as i, but leave the cursor on the NERDTree..........|NERDTree-gi|
s.......Open selected file in a new vsplit.......................|NERDTree-s|
gs......Same as s, but leave the cursor on the NERDTree..........|NERDTree-gs|
!.......Execute the current file.................................|NERDTree-!|
O.......Recursively open the selected directory..................|NERDTree-O|
x.......Close the current nodes parent...........................|NERDTree-x|
X.......Recursively close all children of the current node.......|NERDTree-X|
e.......Edit the current dif.....................................|NERDTree-e|
J'ai remarqué, un truc assez bluffant sur cette extension.
Etape 1 J'ai ouvert un fichier A en double cliquant dessus (ou la touche "o").
Etape 2 J'ai modifié le fichier A sans l'enregistrer.
Etape 3 J'ouvre un autre fichier, le fichier B. Le fichier A que j'avais modifié, a disparu de mon écran.
Etape 4 Je réouvre le fichier A, et ohh comme par micracle, il réapparait avec mes modification.

J'ai donc l'impression, que NERDTree, garde le fichier en mémoire ses anciens fichiers lorsque l'on ouvre un nouveau.

Question 1 :
Comment peux t-on accéder aux anciens fichier ? J'ai essayé la commande :n et :N mais cela ne fonctionne pas.
Bon, je pense que j'ai trouvé la réponse en parcourant les 6 première pages..

En fait, il faut jouer avec le buffer.
NERDTree conserve les fichiers dans le buffer. 
:ls pour avoir la liste des buffer utilisé
:bN (ou N est le numéro du buffer) pour acceder à un buffer
ou en plus pratique
:bn pour passer au buffer suivant
Re-kikou !
J'ai une petit question sur split. J'aimerai voir apparaître sous mon code le résultat d'une commande (perldoc). 
 ________________
|      code      |
|----------------|
|    perldoc     |
 ----------------
Je suis sûr d'avoir vu ça quelque part mais je ne le retrouve pas ...
Bon pour perldoc j'ai trouvé un plugin mais j'aimerais bien quelque chose de plus générale, si je veut par exemple afficher la console elle-même, un peu comme geany qui intègre une console en bas de page, emacs aussi je crois qu'il le fait.
chimay a écritTu as un exemple d'outil de complétion ? Avec signets sur les répertoires ou tu pensais à autre chose ?
Je pensais à des plugins comme searchInRuntime (que je maintiens) ou comme fuzzyfinder ou lookupfile. Avec eux, tu n'as plus besoin de connaitre le nom du répertoire où se trouve tes fichiers.
Selon l'approche choisie par le plugin, la recherche du fichier se fera au travers des fichiers de tag, ou de l'option &path (qui liste les répertoires où chercher des fichiers), voire les deux.

Avec ceci, il n'y a plus besoin d'explorer quoique ce soit. Il suffit de connaitre des morceaux du nom du fichier qui nous intéresse pour l'ouvrir. Le seul hic est la nécessité de connaitre ce morceau du nom.



@Chibie, vim ne permet pas d'avoir une fenêtre shell dans un split. Si tu utilises le mode console, utilise plutôt screen. Telle est la philo unix: des outils dédiés qui collaborent.
Toutefois, il existe un plugin reposant sur du python embarqué pour disposer d'une console dans un split.
Sinon, tu peux jouer avec &makeprg et ":new" + ":r!./tonexe" pour charger le résultat d'un programme externe dans un split -- pour le faire de manière asynchrone, cela demande quelques bidouilles dont je crois avoir déjà parlé ici.
ils sont fantastiques, décidément plus on creuse plus on se rend compte de l'immensité de la chose ...

quelques maps vite fait sur ces plugins, j'ai noté qu'il faut un ./ au début des fichiers quand on cherche dans le path :
" FuzzyFinder

nnoremap <F2> :FuzzyFinderFile<cr>
nnoremap <F3> :FuzzyFinderDir<cr>
nnoremap <F4> :FuzzyFinderMruFile<cr>
nnoremap <F5> :FuzzyFinderMruCmd<cr>

" SearchInRuntime

nnoremap <F6> :SearchInVar &path :e<space>./
nnoremap <F7> :SearchInVar &path :tabe<space>./
Sinon, concernant l'historique des commandes, ça marche comme en tcsh (?) ou avec un zsh bien configuré (*), on tape le début d'une commande ex (:bla), puis les fléches haut/bas parcourent l'historique qui correspond au début déjà écrit (:blabla1 et :blabla2 par exemple)

Géant, jamais travaillé aussi vite :cool:

(*) un peu HS mais bon, comme c'est lié et fort pratique :
# Flèches pour rechercher dans l'historique

bindkey '^[[A' history-beginning-search-backward # PgUp
bindkey '^[[B' history-beginning-search-forward # PgDn
dans le zshrc
Luc Hermitte a écrit
chimay a écritTu as un exemple d'outil de complétion ? Avec signets sur les répertoires ou tu pensais à autre chose ?
Je pensais à des plugins comme searchInRuntime (que je maintiens) ou comme fuzzyfinder ou lookupfile. Avec eux, tu n'as plus besoin de connaitre le nom du répertoire où se trouve tes fichiers.
Selon l'approche choisie par le plugin, la recherche du fichier se fera au travers des fichiers de tag, ou de l'option &path (qui liste les répertoires où chercher des fichiers), voire les deux.

Avec ceci, il n'y a plus besoin d'explorer quoique ce soit. Il suffit de connaitre des morceaux du nom du fichier qui nous intéresse pour l'ouvrir. Le seul hic est la nécessité de connaitre ce morceau du nom.
whaaaou, cela a l'air d'etre puissant. Sympa Luc de faire partager ton plugin

J'ai voulu l'essayé mais je n'arrive pas à l'utiliser. Je ne sais pas si c'est au niveau de l'installation ou de l'utilisation

Ma procédure d'installation
J'ai déposé ton fichier searchInRuntime.vim dans mon répertoire plugin puis j'ai redémarrer gvim. Je n'ai pas installé ton extension d'autoload hl_vim. J'ai vu que tu n'y avais pas fais mention sur ta page sur vim.org. Je pense que cela doit etre falcutatif

Utilisation
En mode commande, j'ai fais un 
:SearchInPATH Antidote.ini  :e 
puis un 
:SearchInPATH Antidote.ini  :sp
mais cela ne m'ouvre toujours rien

Le fichier est bien présent dans C:\WINNT\Antidote.ini (ehhh, oui je suis sous Windows chez moi pour le moment 😉 )
et bien sur le répertoire C\WINNT est bien dans la variable PATH (j'ai fais une verification sous DOS avec un echo %PATCH%)

Ou ai je fauté d'après toi ?
(*) un peu HS mais bon, comme c'est lié et fort pratique :

Code:

# Flèches pour rechercher dans l'historique

bindkey '^[[A' history-beginning-search-backward # PgUp
bindkey '^[[B' history-beginning-search-forward # PgDn

dans le zshrc
Aaaaah, enfin !

Je l'avais perdu et je n'arrivais plus a le retrouver. Merci !
Les autoload plugins ne sont jamais facultatifs. Ce sont en gros des bibliothèques de fonctions.

Pour l'installation, il faut soit passer par le vimball, soit passer par svn. De plus SiR a une dépendance vers lh-vim-lib et elle n'est pas du tout facultative ; disons que la page sur vim.org est encore moins à jour que le vimball.

J'avais donnée plus d'explications sur l'installation par ici.

Par contre, à l'utilisation, c'est 1: commande, 2: fichier. Tu as inversé les deux arguments.
je crois qu'on en parle déjà quelque part mais j'ai dressé une liste :

ciw : change le mot sous le curseur
ciW : change le grand mot sous le curseur
cis : change la phrase sous le curseur
cip : change le paragraphe sous le curseur
ci( : change le texte entre ( )
ci[ : change le texte entre [ ]
ci{ : change le texte entre { }
ci< : change le texte entre < >
cit : change le texte entre les tags html

Autres variantes : vi* permet de passer en mode visuel et de sélectionner, yi* et di* et pas mal d'autres opérateurs fonctionnent aussi 🙂
Merci
Mais à quoi sert le 'i' ?
Personnellement, je fais toujours 'cw', etc...
Eventuellement, 'c3w' pour changer 3 mots d'un coup, etc...
Mais le 'i' ?
J'avais déjà du en parler. i c'est pour inner. -> inner {, inner ", ...
Cela marche pareil avec le a qui inclut le truc autour.
Et cela marche avec tous les opérateurs -> v, =, g?
Bref. ":h text-objects" pour la liste complète des choses sélectionnables en standard. Et ":h operator" pour les opérateurs standards qui s'y appliquent.

En non standard, il y a aussi i, et a, pour sélectionner des paramètres. (oui, c'est de la vile pub)

EDIT: dresser une liste complète n'a pas un grand intérêt vu qu'il y a 15 opérateurs et 20 façons de sélectionner ce qui est autour du curseur. Je ne parle même pas des simples déplacements.
Je vois... C'est de la bombe 😃
ahhhhhhh c'est a pour le contraire! je tentais o pour "outer" merci xD

merci encore monsieur gourou de vim 😃.