ZEP-14 : Refonte de l'assistant d'édition Markdown

Tentons de l'améliorer au besoin des membres !

a marqué ce sujet comme résolu.

Reprise du dernier message de la page précédente

Ouais, mais cette discussion avait déjà eu lieu sur le topic de Clem, du coup c'est pas vraiment la peine de relancer sauf en cas d'éléments nouveaux. ;)

Édité par viki53

Mes tutos — Développeur JS (front principalement) — Consultant qualité, ergonomie et UX

+0 -0

4 espaces, parce que certains langages plantent si tu mets des tabulations, mais tous les langages fonctionnent avec des espaces comme indentation.

Ctrl + Tab pour indenter : non. Ca permet de changer d'onglet dans le navigateur, c'est encore pire que de péter l'accessibilité d'un simple formulaire (c'est peut-être même impossible…).

Pour l'utilisation de la syntaxe avec une tabulation + code, on pourra éventuellement mettre un raccourcis clavier, mais ça ne me semble pas être le truc le plus important, donc probablement un raccourcis pas super pratique.

En effet, j'utilise jamais la syntaxe ```<lang> mais plutôt les 4 espaces (habitude de StackOverflow qui gère la coloration automatique selon le sujet de la question)

Tu peux colorer en specifiant le langage aussi :

1
2
3
4
def test():
    print "hello zds"

test()

et le code correspondant :

1
2
3
4
5
    ::python
    def test():
        print "hello zds"

    test()
+1 -0

La syntaxe des Makefile ne supporte que des tabs. Copier-coller des Makefile depuis le Web est d'ailleurs systématiquement casse-gueule à cause des colorations syntaxiques qui convertissent les tabs en espace, c'est une cause courante d'erreur.

Gwenn

Difficile de trouver un consensus sur ce point : le problème est le même en Python pour ceux qui copient du code avec Tab alors qu'ils codent à l'espace et vice-versa. Imaginez avec le whitespace désormais :D Le problème est qu'à moins de faire de la détection de l'indentation (et donc transformer l'éditeur en mini-IDE…), c'est impossible de savoir s'il faut 4 espaces ou une tabulation quand on utilisera le raccourci.

Par contre je suis d'accord sur le fait qu'il ne faut pas convertir les tabs en espaces ou inversement (ce n'était pas envisagé de toute manière je pense)

+0 -0

Pour moi la solution est simple : on respecte les standards du web, et on ne peut pas utiliser la touche tab dans un textearea, parce qu'elle passe au champ suivant du formulaire. On a pas non plus de raccourci clavier équivalent, que personne ne va connaître et qui risque de rentrer en conflit avec la conf de l'utilisateur.

Je pense à un truc, sous Vim, on peut indenter du texte en mode normal avec les chevrons < et >. Il est peut être possible d'indenter (dans un sens ou l'autre) avec ces touches lorsque du texte est sélectionné ? Ça a une chance ridiculement faible d'entrer en conflit avec un raccourci clavier de l'utilisateur (comparé aux raccourcis Mod+Key) tout en étant assez simplement mémorisable.

C'est juste une idée comme ça, je n'ai aucune idée de la faisabilité de la chose.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+0 -0

On pourrait coupler avec une touche supplémentaire (Shift, Ctrl, whatever) pour le coup et permettre d'indenter n'importe où dans le textarea tout en laissant la possibilité d'utiliser les chevrons pour mettre en place une citation (chose qui pourrait aussi se faire en sélectionnant un bloc, d'ailleurs).

Mes tutos — Développeur JS (front principalement) — Consultant qualité, ergonomie et UX

+0 -0

Je pense à un truc, sous Vim, on peut indenter du texte en mode normal avec les chevrons < et >. Il est peut être possible d'indenter (dans un sens ou l'autre) avec ces touches lorsque du texte est sélectionné ? Ça a une chance ridiculement faible d'entrer en conflit avec un raccourci clavier de l'utilisateur (comparé aux raccourcis Mod+Key) tout en étant assez simplement mémorisable.

C'est juste une idée comme ça, je n'ai aucune idée de la faisabilité de la chose.

@dri1

Poussons le vice encore plus loin ; adoptons un style vim pour écrire (i pour écrire, … etc). :D

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+2 -0

Pour moi la solution est simple : on respecte les standards du web, et on ne peut pas utiliser la touche tab dans un textearea, parce qu'elle passe au champ suivant du formulaire.

SpaceFox

+1, et si je peux me permettre, ce n'est pas uniquement un standard du web, car c'est aussi (et peut-être depuis plus longtemps) un standard dans les interfaces graphiques des OS, pour passer d'un élément à l'autre d'une fenêtre.

Édité par Ymox

Evitez qu’on vous dise de les lire : FAQ PHP et SymfonyTutoriel WAMP • Cliquez 👍 pour dire merci • Marquez vos sujets résolus

+0 -0

Flori@n.B a eu raison de m'indiquer ce sujet que j'avais loupé.

J'ai créé un petit serveur websockets pour pouvoir générer un aperçu en temps-réel (au fil de la frappe) faisant appel à zMarkdown.

Les sources sont ici et voici une image si vous souhaitez voir ce que ça peut donner.

Un aperçu de l'éditeur en temps-réel

Si ça inspire quelqu'un, faîtes-vous plaisir, le code est fait pour être utilisé.

Happiness is a warm puppy

+3 -0

Cette réponse a aidé l’auteur du sujet

S'il faut prioriser, pour moi le plus gros point noir de notre formulaire d'édition, c'est l'insertion d'image. Écrire un tuto ou un article avec le système actuel, c'est tout bonnement horrible.

Il faut un truc simple et fonctionnel. Ex :

  1. clic sur le bouton image
  2. apparition d'un champ html file
  3. récupération de l'image
  4. enregistrement auto dans une galerie par défaut de l'utilisateur
  5. collage du lien dans la textarea

Améliorons la validation ! - ZdS, faut bien secouer, sinon la pulpe, elle reste en bas !

+8 -0

Pour l'upload d'image un système de drag'n'drop (sur la zone d'édition), et attraper le coller (CTRL + V) serait le bien venu. :)

(via imgur)

A-312

Pourquoi passer par un service externe ?

Pourquoi on pourrait pas donner une galerie "upload" par défaut a chaque utilisateur et les uploads iront dedans ?

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+0 -0

Je verrai bien l'upload d'image comme sur Github, c'est-à-dire la possibilité de drag'n'drop ou de sélectionner son fichier et l'insertion automatique d'un lien markdown dans l'éditeur (à l'emplacement du curseur).


Autre proposition, voir si des zesteurs peuvent nous faire des icônes (gras, italique…) personnalisés pour remplacer les actuels !

+1 -0

je supporte un peu toute les idées qui facilitent l’hébergement d'images à partir de l’éditeur de message. C'est vrai que le drag'n'drop avec un hébergement dans une galerie par défaut ça semble vraiment cool ! (par contre pour quelqu'un qui a une connexion un peu lente, une image un peu lourde ça donne quoi ? Ça freeze pendant 5s ?)

Pour le moment c'est vraiment pas ergonomique. Et en plus ça fait un peu tache parce que sinon le site est quand même super bien foutu !

+0 -0

je supporte un peu toute les idées qui facilitent l’hébergement d'images à partir de l’éditeur de message. C'est vrai que le drag'n'drop avec un hébergement dans une galerie par défaut ça semble vraiment cool ! (par contre pour quelqu'un qui a une connexion un peu lente, une image un peu lourde ça donne quoi ? Ça freeze pendant 5s ?)

Vael

Chez GitHub ça insère un MD de base le temps que l'image soit uploadée, puis ça le remplace une fois que le fichier a sa propre URL.

A priori ça pourrait se faire, une fois qu'un début d'API sera en place pour ça (avec une galerie par défaut, etc.).

Mes tutos — Développeur JS (front principalement) — Consultant qualité, ergonomie et UX

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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