Bah faut toujours que j'arrive à installer le projet en local, comme d'habitude… sur Mac c'est la merde (et avec la beta d'El Capitan je sens que ça va être pire).
Vu que vous en parlez, j'en profite pour le signaler ! Personnellement, bien qu'étant l'auteur de la ZEP, je n'ai absolument pas les connaissances requises pour la développer et, je me suis beaucoup éloigné du développement du site ! Tout ça pour dire, que moi cette ZEP à vrai dire, je ne la suis plus que de plus ou moins loin et que donc, si un staff veut remanier la ZEP avec les derniers points discutés, ou avec ses propres idées, qu'il n'hésite surtout pas !
Bah faut toujours que j'arrive à installer le projet en local, comme d'habitude… sur Mac c'est la merde (et avec la beta d'El Capitan je sens que ça va être pire).
C'est ça qui me freine aussi. J'ai pas l'habitude de travailler avec de tels outils (même Git) (je taff tjs dans mon coin, égoïstement) et ça me semble super compliqué. J'avais fait le script de toolbar et je l'avais donné tel quel…
J'ai pas trop de problème avec Git, mais j'ai jamais touché à Python avant alors de là à installer un projet conséquent comme ça…
La dernière fois que j'ai essayé je me suis tapé des erreurs en série, pour tomber sur une dont personne ne connaissait la solution. Du coup j'ai abandonné lâchement, en espérant que ça se résolve tout seul (on peut toujours rêver).
Si un développeur ZdS qui bosse sous Mac passe par là, je suis preneur d'un coup de main rapide pour la mise en place du bouzin sur ma machine
(D'ailleurs, faudrait que tu me dises dans quoi tu bosses. Depuis le temps que je te croise partout je sais toujours pas ce que tu fais…)
Bah faut toujours que j'arrive à installer le projet en local, comme d'habitude… sur Mac c'est la merde (et avec la beta d'El Capitan je sens que ça va être pire).
Je crois qu'Andr0 est sur Mac si tu as besoin d'aide.
Bah faut toujours que j'arrive à installer le projet en local, comme d'habitude… sur Mac c'est la merde (et avec la beta d'El Capitan je sens que ça va être pire).
C'est ça qui me freine aussi. J'ai pas l'habitude de travailler avec de tels outils (même Git) (je taff tjs dans mon coin, égoïstement) et ça me semble super compliqué. J'avais fait le script de toolbar et je l'avais donné tel quel…
C'est vrai que Git est pas forcément l'outil le plus simple à comprendre, mais il dans un tel projet on ne peut s'en passer. Après le reste c'est principalement des commandes shell toutes bêtes donc, si ça ne bug pas sur ta distro, ça devrait rouler comme sur des roulettes !
J'ai pas trop de problème avec Git, mais j'ai jamais touché à Python avant alors de là à installer un projet conséquent comme ça…
Python est un langage plutôt assez simple (surtout que tu sais déjà coder en Javascript). AMHA, ce qui est le plus dur c'est apprendre le fonctionnement du framework (ici, Django).
J'ai pas trop de problème avec Git, mais j'ai jamais touché à Python avant alors de là à installer un projet conséquent comme ça…
Je connaissais que Python de nom, y'a 6 mois. On s'y fait très vite, si tu as un peu d'expérience dans d'autre langages de programmation. Situphen et Sandhose seront la pour te taper sur les doigts, si tu fait des conneries sur le front, ne t'inquiète pas pour ça .
La dernière fois que j'ai essayé je me suis tapé des erreurs en série, pour tomber sur une dont personne ne connaissait la solution. Du coup j'ai abandonné lâchement, en espérant que ça se résolve tout seul (on peut toujours rêver).
On peut te donner un coup de main pour l'installation.
Si un développeur ZdS qui bosse sous Mac passe par là, je suis preneur d'un coup de main rapide pour la mise en place du bouzin sur ma machine
Je suis sous mac de temps en temps et j'ai installé le projet. Aprés, je suis pas un fin connaisseur de mac. Je peux essayer de t'aider comme je peux.
Je suis pas super dispo en ce moment, déménagement et tout. Si tu m'envois un MP avec une erreur, je te répondrais. Je vais passer de temps en temps sur le forum de dev, si tu poste là-bas. Je suis parfois sur l'IRC (même pseudo).
Ps: Andr0 est surement un plus compétent que moi, sur les domaines mac et Python.
Ps 2: Y'a aussi une installation docker en pré-alpha …
Bah faut toujours que j'arrive à installer le projet en local, comme d'habitude… sur Mac c'est la merde (et avec la beta d'El Capitan je sens que ça va être pire).
Après pour développer la bare d'outils, pas besoin de connaître et toucher à Python. L'installation du projet est le seul point compliqué pour pouvoir tester en local.
Bah faut toujours que j'arrive à installer le projet en local, comme d'habitude… sur Mac c'est la merde (et avec la beta d'El Capitan je sens que ça va être pire).
Je suis étonné que personne n'ai encore proposé d'agrandir la zone d'édition. Alors, c'est peut-être moi qui suis mal habitué avec vim qui fait toujours la hauteur de mon écran (presque 70 lignes), mais sincèrement, pour écrire un tutoriel, avoir 10 lignes de hauteur par défaut me semble vraiment peu.
Toujours lors de l'écriture d'un tutoriel, je ne trouve vraiment pas pratique le fait d'avoir la prévisualisation en dessous du texte. Vu qu'il n'y a pas de bandeau sur la gauche, ça serait super cool d'avoir l'éditeur et la prévisualisation côte à côte. Et puis tant qu'à faire, en rêvant un peu, on pourrait même faire en sorte que la prévisualisation et l'éditeur montrent toujours la même partie du tutoriel (en synchronisant le scroll de manière intelligente).
Je viens sur ce topic pour vous montrer sur quoi j'ai bossé récemment ; j'ai commencé une refonte complète de l'éditeur.
L'éditeur est pensé pour être totalement détaché de ZdS, dans un dépôt à part, et donc réutilisable. Y'a dessus encore aucun style, ni les extensions markdown ZdS pour le moment ; c'est encore un gros WIP.
C'est un éditeur basé sur CodeMirror, outil à la base de nombreux éditeurs, dont Brackets, et les dev tools de Firefox et Chrome. Ca permet, en plus d'avoir une API plus simple à manipuler que des textarea simples, de styliser le contenu de l'éditeur, et donc de voir par exemple en gras du texte entouré d'**.
J'insiste sur le fait que pour le moment, il n'y a aucun style derrière en dehors de celui par défaut de CodeMirror, donc je vous demanderais de ne pas faire attention à ça c:
Au niveau features on a:
bold/italic, qui fonctionnent dans les deux sens, et en fonction du contexte. C'est à dire que si on clique sur le bouton italic en ayant sélectionné un texte déjà en italique, ça va enlever un * (ou un _, si vous avez choisi d'utiliser ça).
les différents niveaux de titres, qui pareil, marchent dans les deux sens
les citations
les blocs de code
les liens ; si le texte sélectionné est une URL, ça utilise cette URL et met le curseur au niveau du nom du lien, sinon ça utilise la sélection comme nom et place le curseur au niveau du lien
les images au copy-paste + drag'n'drop ; il y a pas de backend derrière, donc vous aurez de toutes façons une URL type blob:{host}/{uuid}, qui fonctionne parfaitement pendant la durée de la session (Blob, URL.createObjectURL(), toussa toussa…) ; c'est juste un placeholder, qui deviendra évidemment un vrai upload vers une galerie une fois l'éditeur en place. L'import d'image via un sélecteur de fichier sera plus spécifique ZdS (car il sera sûrement dans une modale), et donc est pas implémenté ici (mais vu l'API que j'ai mis en place derrière, ça sera relativement trivial à implémenter )
le multi-curseur, grâce à CodeMirror, que j'ai laissé activé, et qui permet par exemple de sélectionner plusieurs mots, puis mettre en gras/italique/… ; aussi, on pourra mettre en place une recherche qui pourrait profiter de cette feature, pour pouvoir chercher toutes les occurrences d'un mot, et toutes les mettre en gras, par exemple.
les raccourcis claviers. J'en ai mis quelques un vite fait ; faut savoir que c'est super rapide à rajouter avec CodeMirror, et y'aurait même de quoi laisser à l'utilisateur la possibilité d'en rajouter/modifier assez facilement. (Ctrl se transforme en Cmd sur Mac)
Ctrl-B pour bold
Ctrl-I pour italique
Ctrl-K pour un lien
Ctrl-' pour augmenter le niveau de citation
Ctrl-Alt-' pour baisser le niveau de citation
Ca gère aussi les cas chelou genre, j'essaie de mettre de l'italic dans un titre, ou un titre dans une citation, ou de l'italic dans un titre dans une citation dans une citation.
Ce qui est encore prévu:
Les extensions ZdS
Les blocs info, secret & co
Les sources de citations / légendes d'images/vidéos/…
Les touches de clavier
Les smileys
Le texte barré
…
Styliser un peu le tout
Sauvegarde des brouillons + synchronisation en background des brouillons avec le serveur
Des bindings vim (en vrai, y'a un addon CodeMirror qui fait ça tout seul, et AMHA, on pourrait laisser l'option quelque part, pour le fun )
Quelque chose pour les listes (genre, quand on fait un retour à la ligne dans une liste, ca refait un - avec la bonne indentation)
L'autocomplétion (pour les @pseudo, voir les smileys, à la GitHub ; peut-être pas pour tout de suite)
La preview markdown
D'autres trucs que j'implémenterais au fur et à mesure ; des idées que j'aurais par-ci par-la.
D'un point de vue technique, c'est de l'ES6 transpilé via babel + browserify, avec de la doc auto via JSDoc, et des tests unitaires (pas encore beaucoup, je viens de mettre ça en place) via tape. Je vais pas détailler plus que ça ici, à moins que vous y teniez vraiment, mais sachez que cet éditeur me sert aussi de playground pour tester un peu ce que je risque de mettre en place pour le front dans un futur plus ou moins lointain (tests unitaires, browserify, toussa toussa…).
Je vous laisse essayer, torturer mon éditeur pour trouver des bugs, pour aussi signaler des comportement que vous trouvez pas logique/buggé, et me suggérer des fonctionnalités, en plus de celles que j'ai cité qui viendront au fil du temps
Je vais redire ce que j'ai dut dire tout au début. J'ai un problème fondamental avec les éditeurs WYSIWYM tel que celui-ci, surtout dans le cadre de zds. On va se retrouver avec deux parseurs : un coté client (pour rendre le texte en gras, italique, etc.) et celui coté serveur qui va générer le html.
Le truc est que le markdown est un langage ambiguë. C'est peu normé et il y a pleins de syntaxes qui peuvent être interprétées de plusieurs façon tout en restant valide. Si on compte les cas où l’utilisateur ne rentre pas un code 100% parfait c'est encore pire.
Ce qui me gène donc est qu'on risque d'avoir deux parseurs qui vont fatalement avoir un comportement différent sur certains éléments de syntaxes. Et là, bonjour les remontés de bugs. On risque d'avoir des utilisateurs qui ne vont pas comprendre pourquoi c'est rendu d'une façon dans l'éditeur et d'une autre une fois publié.
Perso ça me gène mais j'avoue ne pas avoir de solution miracle. Il est clair qu'un éditeur de ce type serait appréciable mais je pense qu'il est important de ce rendre compte que plus cet éditeur va supporter de la syntaxe, plus on va avoir des problèmes d'incompatibilité entre les deux.
Ce qui me gène donc est qu'on risque d'avoir deux parseurs qui vont fatalement avoir un comportement différent sur certains éléments de syntaxes. Et là, bonjour les remontés de bugs. On risque d'avoir des utilisateurs qui ne vont pas comprendre pourquoi c'est rendu d'une façon dans l'éditeur et d'une autre une fois publié.
Et bien, je pense que pour le confort de rédaction, c'est déjà mieux d'avoir un parseur pas parfait pour l'édition et un parseur de référence pour l'affichage final. Pour éviter les surprises, il suffit de dire que c'est un système d'aperçu, de preview, de prévisualisation, ou quelque autre mot similaire.
Au pire, c'est possible de conserver le bouton "Aperçu" actuel, qui lui va rendre la page correctement. Mais au moins, avec un parseur de prévisualisation, on évite des dizaines d'allers-retours.
Comme je le dis, je n'ai pas de solutions parfaite. Sinon il faudrait qu'on fasse le rendu côté serveur avec le même parser en js et c'est aussi du boulot.
Je faisai juste la remarque, pour bien que tout le monde au conscience du problème que ça peut poser.
Ce qu'on peut faire c'est le faire en plusieurs itérations : commencer pour le moment à s'occuper que des syntaxes inline (gras, italique, etc.) et laisser de côté les blocs pour le moment. Si ça ne pose pas de problèmes particuliers, on pourra les rajouter dans un second temps. Et ça permettra d'apporter un meilleurs éditeur plus rapidement.
Je spawn ici juste pour dire que le seul truc qui m'embête c'est le fait que ça pèse quand même plus de 110kb et que ça pique un peu quand on sait qu'actuellement on est déjà à 130kb pour les JS de ZdS + 130kb pour MathJax.
Peut-être faudrait-il ne pas le mettre sur mobile ? Peut-être qu'on moque grâce au cache.
Ce qui me fait peur c'est qu'au premier chargement, en 3G on est déjà à ~10secs pour le JS. En rajoutant ça, on passerait à 15secs, d'un coup.
N'y a-t-il pas moyen de faire plus léger en terme de poids final pour un rendu similaire ?
Une idée rapide : on met ça comme option sur les forums/commentaires, qui ont en général besoin de peu de mise en forme. Si on écrit un gros message, alors on clique sur "éditeur avancé" pour avoir un peu plus de fonctionnalités.
Je l'ai dit à Sandhose en MP, pour moi CodeMirror doit être désactivé sur mobile, et même la barre d'outils (inutile, c'est pas ergonomie pour un mobile).
Pour ce qui est du rendu côté client, faut bien se dire que c'est juste un highlight de la syntaxe du Markdown, pas un rendu complet. C'est pas du tout dans l'objectif de remplacer la preview, c'est juste complémentaire. Du coup, le seul risque, c'est que dans certains edge-case chelou, on aura éventuellement une coloration syntaxique pas de la bonne couleur. Je suis vraiment pas sûr que c'est très gênant. A ce niveau la, je pense que ça fait même un meilleur boulot que l'éditeur actuel. Vous avez déjà essayé de mettre en gras sur plusieurs lignes ? Sur l'éditeur actuel, ça va wrapper toute la sélection par des **, alors que c'est censé le faire séparément sur chaque ligne. Je pense que ce genre de comportements bizarre risque plus d'induire les utilisateurs en erreur que quelques edge-case sur de la coloration syntaxique.
Je spawn ici juste pour dire que le seul truc qui m'embête c'est le fait que ça pèse quand même plus de 110kb […]
C'est 64Kb actuellement minifié + gzippé.
Alors, faut savoir que mon code est relativement peu dépendant de CodeMirror, surtout au niveau de la logique de l'éditeur. Je songe actuellement à faire une sorte d'interface avec lequel l'éditeur va communiquer, qui permettrait de plugger l'éditeur soit sur CodeMirror s'il est chargé et qu'on est sur Desktop, soit sur un textarea standard, s'il est pas chargé et/ou on est sur mobile, et charger les 60Kb de CodeMirror en asynchrone.
Si maintenant, vous me dites clairement "osef de la coloration syntaxique du markdown", dans ce cas OK, je peux tout à fait complètement virer CodeMirror. Je trouve ça juste très dommage, et ça empêchera le développement de features avancé type rechercher/remplacer, voir même l'autocomplétion en plein milieu de l'éditeur (enfin encore que, GitHub le fait bien, mais d'une manière assez dégueulasse ). Aussi, je trouve que la coloration syntaxique permet presque de se passer de preview en temps réel ; et étant donné que le peu d'avancement sur l'amélioration du rendu markdown depuis pas mal de temps, je pense que c'est mieux comme ça
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
