Hello,
Une idée comme ça :
Quand le porte-plume est en mode « full screen » synchroniser la prévisualisation sur la position du curseur dans le texte.
Cela permet, quand on rédige un long texte, de pas chercher partout ou ce trouve la modification qu’on est en train de faire.
Après, j’ai pas regardé le code, mais j’imagine que cela dois être possible 
Phenix a écrit le 01/03/2016 21:13 :
Hello,
Une idée comme ça :
Quand le porte-plume est en mode "full screen" synchroniser la
prévisualisation sur la position du curseur dans le texte.
Cela permet, quand on rédige un long texte, de pas chercher partout ou
ce trouve la modification qu'on est en train de faire.
Après, j'ai pas regardé le code, mais j'imagine que cela dois être
possible 
Il y a http://wiki.txt2tags.org/demos/txt2tagsjs/txt2tagsjs-gui.html qui scrolle de concert.
Mais c'est pas forcément pile-poil en face.
Voir la discussion en cours ici :
http://thread.gmane.org/gmane.comp.web.spip.devel/66939
--
RealET
Hop,
Le 01/03/2016 21:13, Phenix a écrit :
Hello,
Une idée comme ça :
Quand le porte-plume est en mode "full screen" synchroniser la
prévisualisation sur la position du curseur dans le texte.
Cela permet, quand on rédige un long texte, de pas chercher partout ou
ce trouve la modification qu'on est en train de faire.
Après, j'ai pas regardé le code, mais j'imagine que cela dois être
possible 
Je ne sais plus si je le sujet a été abordé sur les listes, mais ce n'est pas simple à implémenter. En effet, le bloc de prévisu affiche le rendu de l'insertion des modèles (images, lecteur multimédia, formulaire, etc) et on ne peut pas toujours présumer de leur hauteur.
++
b_b
Le 02/03/2016 09:30, Bruno Bergot a écrit :
Je ne sais plus si je le sujet a été abordé sur les listes, mais ce
n'est pas simple à implémenter. En effet, le bloc de prévisu affiche le
rendu de l'insertion des modèles (images, lecteur multimédia,
formulaire, etc) et on ne peut pas toujours présumer de leur hauteur.
Bah y a pas à présumer de la hauteur, je suppose que ça se base sur les débuts de chaque blocs importants (titres, p, etc) mais surtout : ya pas à l'implémenter soi-même. Tous les éditeurs Markdown "côte à côte" le fond déjà… (les web et pas web), donc je suppute qu'il doit y avoir des choses à copier-coller.
--
RastaPopoulos
Le 02/03/2016 11:45, Cédric Morin a écrit :
Yaka
Essentiellement deux approches :
- Une approche très simpliste : on considère que sur du fullscreen, l'approche simple de s'occuper juste de la proportion suffit : si c'est 30% d'un côté, on met pareil de l'autre. Cela pose problème comme dit précédemment lorsqu'il y a beaucoup d'images ou formulaires dans un même document. Mais tout le monde n'a pas des contenus comme ça, et on peut considérer que ce n'est pas la majorité des contenus. Alors on peut se dire que c'est mieux cette synchronisation qui ne couvre pas tout les cas, que pas de synchronisation du tout ! Dans Ghost ils utilisent ça il me semble.
Dans ce cas de figure il pourrait y avoir un bouton activer/désactiver la synchronisation, pour être sûr de ne pas gêner les cas en problème.
- L'autre approche est d'utiliser des marqueurs et/ou d'utiliser les zones importantes (titres, paragraphes, etc). Mais dans ce cas, obligatoirement : le côté éditeur de texte DOIT être scanné aussi. Donc cette approche ne pourra jamais se faire tant qu'on a pas encore changé d'éditeur : par exemple pour CodeMirror comme je le proposais dans l'autre fil de discussion. Car dans ce cas, la partie éditeur est aussi scannée et modifiée, avec des classes CSS ajoutées, etc. Dans ce cas là il est alors imaginable de détecter et faire correspondre les titres, images, formulaires, des deux côtés.
Cette conversation entre gens de Ghost et de Discourse est utile sur le sujet :
https://meta.discourse.org/t/syncing-the-editor-viewport-scroll/13249
Et https://stackedit.io ont eux bien implémenté la deuxième méthode, plus complexe, qui scanne des deux côtés.
--
RastaPopoulos