Dans mon cas :
- j'ai la chance d'avoir des utilisateurs obéissants et de bonne volonté à défaut d'être geek,
- ils savent qu'ils n'ont aucune chance de repasser à Word ou LibreOffice (ils ont eu une phase transitoire avec LO, et leur réaction face à Markdown a été unanime : c'est toujours mieux que LO),
- un éditeur WYSIWYG (style Word) pourrait très bien être castré pour se limiter à un sous-ensemble simple et donc obtenir un rendu homogène ( https://ckeditor.com/docs/ckeditor5/latest/examples/builds/document-editor.html ),
- il est illusoire d'utiliser git sur du Markdown et espérer avoir en permanence du texte valide lors d'une fusion (des étoiles ou des underscores sur deux lignes différentes, par exemple) — on se retrouve à égalité avec du HTML à ce niveau : de toute façon, si tu ne peux pas garantir que la transformation vers le produit final est viable, on se moque de pouvoir faire un diff.
[^] # Re: Markdown...
Posté par flan (site web personnel) . En réponse au journal Gestion de documentation. Évalué à 2.
Dans mon cas :
- j'ai la chance d'avoir des utilisateurs obéissants et de bonne volonté à défaut d'être geek,
- ils savent qu'ils n'ont aucune chance de repasser à Word ou LibreOffice (ils ont eu une phase transitoire avec LO, et leur réaction face à Markdown a été unanime : c'est toujours mieux que LO),
- un éditeur WYSIWYG (style Word) pourrait très bien être castré pour se limiter à un sous-ensemble simple et donc obtenir un rendu homogène ( https://ckeditor.com/docs/ckeditor5/latest/examples/builds/document-editor.html ),
- il est illusoire d'utiliser git sur du Markdown et espérer avoir en permanence du texte valide lors d'une fusion (des étoiles ou des underscores sur deux lignes différentes, par exemple) — on se retrouve à égalité avec du HTML à ce niveau : de toute façon, si tu ne peux pas garantir que la transformation vers le produit final est viable, on se moque de pouvoir faire un diff.