En C++, tu as aussi intérêt à te limiter à un sous-ensemble assez restreint du langage.
J'aime bien ton article, il est bien documenté et soulève des points valides de manière respectueuse et agréable à lire.
Il se trouve que je ne suis quasiment pas affecté par les points négatifs que tu soulèves : je n'utilise pas (beaucoup) npm ni de bibliothèques externes, ni les webworkers. Je n'ai pour l'instant pas trop adopté la syntaxe des déconstructions pour des raisons de compatibilité des navigateurs mais je vais certainement bientôt m'y mettre, et pour null et undefined je me suis fait un modèle qui fonctionne pour moi (undefined = la fonction ne retourne rien de particulier, null est explicitement renvoyé quand l'élément n'existe pas mais effectivement ce n'est pas forcément idéal).
Pour ton { a, b } = o, ça s'explique certainement par le fait que { a, b } est interprété comme un bloc de code qui contient une instruction pas terminée par un point virgule (ce qui est autorisé en JS, et je ne suis pas fan de ça), et cette instruction a, b est composée de deux sous-instructions (qui sont des expressions…) séparées avec l'opérateur virgule. L'analyse syntaxique échoue au niveau du = parce = après un bloc de code n'a pas de sens. Les parenthèses interdisent l'analyseur de considérer les accolades comme un bloc de code. Je sais, c'est dommage. Ce n'est pas incompréhensible, mais je reconnais que c'est pénible.
Pour le ===, C'est pénible et c'est la même chose en PHP : j'ai décidé de considérer que == ne devait pas être utilisé.
Je n'ai pas affirmé qu'on peut écrire du beau code dans n'importe quel langage.
Le ruban de Turing est un modèle pour raisonner sur la calculabilité, raisonnements qui seraient lourds à faire avec un langage de programmation quelconque. Il n'est pas question d'écrire des programmes avec dans la vie de tous les jours. Le brainfuck n'est pas pensé pour écrire du code maintenable.
Un tas d'application à succès de taille respectable qui continuent à évoluer et à fonctionner ont été écrites avec du JS, c'est qu'elles doivent être un minimum maintenables (Firefox, Thunderbird, PDF.js, Signal, Wire, Wordpress, un tas de gros sites web, …).
On peut dire la même chose de PHP (malgré ses nombreuses incohérences - Nextcloud, WordPress…), de Java (malgré ses lourdeurs), de C (malgré le nombre de pièges dans lesquels on peut tomber), de C++ (malgré sa complexité)… et bien sûr, il est possible d'écrire du code médiocre dans ces langages.
Si un code n'est pas maintenable dans n'importe lequel de ces langages, c'est que les personnes qui l'ont écrit ont mal fait leur boulot, étaient inexpérimentées dans les langages utilisés, que le processus de développement a eu des loupés ou que le langage choisi n'est pas adapté au cas d'utilisation. Après, il y a des pièges dans tous les langages. Il est nécessaire de connaître profondément la sémantique des outils qu'on utilise et d'apprendre à éviter ces pièges (vous avez déjà utilisé une liste vide comme valeur par défaut d'un paramètre de fonction en Python ?). Si vous utilisez une scie sans avoir appris à l'utiliser, vous allez peut-être couper ce que vous vouliez couper, mais vous risquez aussi de vous couper un doigt. Et si vous savez vous en servir, vous risquez quand même de vous blesser, donc la vigilance reste de la partie.
En C aussi, on peut avoir du code qui compile et qui tourne, mais qui se vautre à l'exécution à cause d'un dépassement (quand on a la chance que ça crash !).
Et puis si quelqu'un ne se sent pas capable d'écrire du code propre en $LANGAGE parce cette personne n'accroche pas avec son fonctionnement, ce n'est pas grave, il y a d'autres langages qui pourront mieux lui convenir.
On peut écrire des immondices dans n'importe quel langage. Si les choses sont faites avec un peu de discipline, on peut arriver à un résultat correct.
Il suffit de ne pas faire n'importe quoi, d'utiliser un sous-ensemble correct du langage et de suivre les bonnes pratiques qu'on a choisies et de s'y tenir. Il y a des très bons linters si on veut avoir un peu de rigueur "garantie". Je ne les utilise plus actuellement mais j'en étais fan il y a quelques années et j'ai beaucoup appris grâce à eux.
Ne pas écrire du code trop intelligent, éviter les constructions bizarres, nommer ses variables correctement, et en fait appliquer les conseils qui s'appliquent à tous les langages font déjà beaucoup de bien.
Je préfère aussi avoir du typage statique mais ce n'est pas le seul aspect du langage et en l'occurrence, TypeScript offre un système de type meilleur que beaucoup de langages typés (mais il y a mieux aussi).
hey les gens, la "transpilation" C'EST DE LA COMPILATION, compiler ce n'est que transformer un langage dans un autre…
Pas la peine d'être désagréable comme ça.
Est-ce que le terme "transpiler" a été inventé par les gens du milieu Javascript ? Non.
Est-il est mal utilisé ? Pas à ma connaissance.
Est-il ambigu ou vague ? Non.
Quel est le problème d'utiliser "transpiler" à la place de "compiler" ?
On peut ne pas aimer le terme transpiler, et considérer que c'est une forme spécifique de compilation, et préférer juste dire compilation. On peut ne pas aimer les néologismes. Mais ça n'a rien à voir avec "ils ne connaissent tout simplement ce qui se fait en dehors de leur propre écosystème". C'est hors sujet.
Il y a une différence entre ignorance et choix.
Je ne changerai pas mon avis plus ou moins neutre sur le mot "transpiler" avec des remarques en majuscules et continuerai à l'utiliser tant que personne ne me donnera un argument solide.
Commenter c'est aussi écrire. Devrait-on dire "écrire" plutôt que "commenter" ? Non, "commenter" a un sens plus précis.
Je dis ça en ayant écrit un compilateur jouet (vers assembleur) et un transpileur (vers Javascript). Il y a plein de problèmes que je n'ai pas touchés dans le second cas, notamment l'allocation de registre (mais effectivement, il y a des problèmes de renommage dans les deux cas). Il y a aussi un problème que j'ai traité dans le second cas et pas dans le premier cas : la lisibilité du code produit, et calquer le formatage du code source. Pour moi ce n'est pas complètement aberrant de vouloir appeler ces deux trucs différemment et chaque camps devrait respecter les avis de l'autre camp.
Sur le fond du problème : Javascript a clairement ses travers et son écosystème est étouffant mais ce n'est clairement pas un mauvais langage. Après, il y a des questions de goût et des expressions comme "ad nauseam" n'ont rien à faire dans un argumentaire solide.
On peut ne pas aimer et ça ne se discute peut-être pas trop, mais on peut faire du Javascript correct sans utiliser la lourdeur de l'écosystème (perso j'écris systématiquement du Javascript standard ou du TypeScript occasionnellement).
Je ne comprends pas toute cette haine pour ce langage. Il faut juste passer un peu de temps à accepter ses défauts (il y en a beaucoup - mais j'en connais dans les autres langages que j'utilise), à comprendre son fonctionnement et à apprécier ses richesses. Et des langages comme TypeScript retirent une partie des problèmes si on veut plus de garanties sur les types.
Importe ton interpréteur Lua, je ne désactiverai pas mon bloqueur de scripts pour ton projet (ça me gonfle de voir mon navigateur devoir interpréter du code pour afficher un article), ma bande passante et mon processeur ont d'autres trucs à faire et les ressources énergétiques de la planète aussi. Après on parle de bibliothèques légères, faudrait voir à être cohérent. Grrr. Désolé pour le petit coup de gueule.
J'ai eu l'idée il y a quelques années de faire exactement ça.
Me rendant compte que ça voulait dire d'implémenter un moteur de rendu HTML/CSS, avec les difficultés du style traitement des textes bi-directionnels, j'ai abandonné.
J'ai essayé sur un document que j'ai écrit dans une syntaxe maison, le résultat est très bon.
J'ai toujours été frustré par la gestion des passages à la page suivante avec les impressions des moteurs de rendu classiques (au mauvais endroit, lignes coupées en deux) et autre problème (marges, taille de la police, WebKit qui ne prenait pas en charge les césure correctement).
Un « petit » manque : si MathJax est utilisé, les formules ne s'afficheront pas (j'imagine que prendre en charge Javascript n'est pas trivial). Pour ce cas particulier, KaTeX est une piste à explorer.
Peut-être qu'un jour on pourra écrire des articles pour des conférences comme ça ?
système de gestion de raccourcis clavier super sous Plasma mais bogué, ce qui veut dire que c'est soit impossible, soit incroyablement compliqué d'avoir à la fois ALT+< pour passer au morceau précédent et ALT+> au morceau suivant sur mon clavier AZERTY (https://bugs.kde.org/show_bug.cgi?id=397984)
Par un hasard assez fou, ce bogue vient d'être corrigé apparemment.
Posté par raphj .
En réponse au journal Ubuntu, Fais moi rêver !.
Évalué à 5.
Dernière modification le 04 novembre 2018 à 09:42.
Je ne vois pas pourquoi ça serait là pour faire chier. Je peux comprendre que monter la partition du téléphone sur l'ordinateur alors qu'elle est en cours d'utilisation sur le téléphone est un peu délicat. MTP est une solution à ce problème et je ne vois pas de raison particulière sur pourquoi ça ne devrait pas fonctionner correctement sous GNU/Linux.
Pour ma part j'utilise adb pull/push, scp ou rsync.
copier-coller avec la molette sous Wayland. Tant qu'on n'aura pas ça, pas de Wayland pour moi.
Sous GNOME avec Wayland ça marche.
Je crois qu'il s'agit d'une extension à Wayland, pas encore standard. Du coup, ça ne marche pas sous tous les environnements, ou selon les bibliothèques graphiques. J'ai bon espoir que ça se standardise.
Posté par raphj .
En réponse au journal Ubuntu, Fais moi rêver !.
Évalué à 3.
Dernière modification le 01 novembre 2018 à 19:25.
Ça fait plusieurs années que le HiDPI existe, pourquoi on a encore ces problèmes ?
Car c'est un exercice plutôt compliqué.
Oui, j'ai cru comprendre. Ça oblige à ne pas simplement faire un ×1,5, mais plutôt un × 3 / 2 ou des choses comme ça. Et on se retrouve avec des fractions de pixels. Dans tous les cas, le compositeur ne peut pas donner une image complètement net. Un jour, je me suis retrouvé devant un Mac Retina, et l'affichage ne m'avait pas paru complètement net. C'était peut-être pour ça. Ou alors un mauvais réglage. À vrai dire je ne sais plus bien.
Mais si j'ai pris un écran HiDPI, c'est justement pour que tout soit net.
Ce qui serait sympa, ce serait d'avoir un truc qui ressemble au zoom des navigateur. Aussi, Android semble bien s'en sortir sur ces questions là. Il doit y avoir une solution élégante à ce problème, au moins pour les applications libres maintenues aujourd'hui.
Posté par raphj .
En réponse au journal Ubuntu, Fais moi rêver !.
Évalué à 10.
Dernière modification le 01 novembre 2018 à 17:16.
Je vais répondre un truc générique, je ne connais pas les changements de la version 18.10 d'Ubuntu.
Oui, finalement un système stable et qui fait ce qu'on lui demande est une chose positive, et je dis ça en tant que quelqu'un qui était quasiment toujours sur les versions de développement d'Ubuntu quand je l'utilisais et qui aime les nouveautés.
Je vois l'absence de grandes nouveautés visible sur une distribution grand public d'un bon œil, ça veut dire que tout ne va pas changer et ne sera pas à réapprendre à chaque migration pour des gens qui ne sont pas particulièrement intéressés par les nouveautés. Si l'environnement fonctionne tel quel, pas besoin de tout chambouler.
Ça veut aussi dire que je suis plus familier avec un environnement un peu plus "vieux" (une LTS) quand je dois aider quelqu'un.
En ce qui me concerne, j'aime plutôt bien les grandes nouveautés visibles en général mais j'ai plutôt tendance à bien apprécier les petits changements discrets mais pratiques ou agréables, comme :
Les petites barres de chargement dans les boutons des fenêtres de la barre des tâches
l'interface de pilotage des lecteurs multimédias intégré à l'environnement qui devient plus pratique (et qui est là en premier lieu, d'ailleurs ! c'est fantastique, MPRIS. Je peux même avoir un certain contrôle depuis le téléphone grâce à ça, quelque soit le lecteur multimédia utilisé)
La proposition d'installer un logiciel pas encore installé lorsque son nom est tapé dans l'interface d'exécution de commandes (Alt+F2) - ce genre de chose me fait occasionnellement abandonner la ligne de commande alors que c'est souvent le plus efficace.
La musique qui se coupe sur l'ordinateur lors de la réception d'un appel sur le téléphone
la barre de titre de la fenêtre de Firefox qui peut maintenant être cachée.
Thunderbird qui ne rame / se bloque plus régulièrement, certainement grâce au passage à Quantum avec du parallélisme pour régler le problème.
Sous plasma 5 des améliorations discrètes comme ça arrivent à chaque version. L'interface reste globalement inchangée mais c'est de plus en plus peaufiné / léché et stable et ça me donne envie d'être toujours sur la dernière version.
Par contre il reste des choses qui me semblent plus ou moins indispensables et qui ne sont pas là, par exemple :
une mise à l'échelle fractionnée correct pour les écrans HiDPI (expérimental et flou sous Gnome/Wayland, plus ou moins inexistant sous Plasma), et prise en charge correcte d'un affichage composé écrans avec DPI différents. Ça fait plusieurs années que le HiDPI existe, pourquoi on a encore ces problèmes ?
absence de plantages de l'affichage lors du retour de veille (X11).
copier-coller avec la molette sous Wayland. Tant qu'on n'aura pas ça, pas de Wayland pour moi.
Firefox natif sous Wayland
correction orthographique fonctionnelle dans Kate (je n'arrive plus à faire fonctionner ça depuis le passage à KDE 5, en tout cas sous Debian et Ubuntu)
système de gestion de raccourcis clavier super sous Plasma mais bogué, ce qui veut dire que c'est soit impossible, soit incroyablement compliqué d'avoir à la fois ALT+< pour passer au morceau précédent et ALT+> au morceau suivant sur mon clavier AZERTY (https://bugs.kde.org/show_bug.cgi?id=397984)
pas très important, mais les ombres sous les fenêtres qui gèrent leur propres décorations avec KWin ? je sais qu'un des développeurs principaux est contre les décorations par le client mais c'est frustrant. (exemples : Chromium, Firefox, Evince, Gedit)
utilisation d'un téléphone en MTP un peu aléatoire selon les configurations
petits bogues ou comportements pas très intuitifs avec le wifi / bluetooth, occasionnellement.
défilement parfait sous firefox avec le touchpad toujours pas activé par défaut
défilement cinétique un peu partout. J'ai ça dans Evince mais pas dans Okular sur cet ordinateur (mais je crois l'avoir observé sur un autre ordinateur…)
zoom à deux doigts avec le touchpad
annotations de PDF facile à utiliser.
Donc oui pour les nouveautés discrètes et incrémentales. J'adore les grosses nouveautés, mais le plus important pour moi, ce sont les choses qu'on ne voit pas forcément mais qui font que tout fonctionne correctement (avec les évolutions actuelles).
Suite à une question au webmestre relative à cette mention, celle-ci a été corrigée. La page ne parle plus de logiciels libres de droits, mais de logiciels libres.
Félicitations, votre commentaire marque l'apparition d'un même sur Linuxfr.
Tu feras attention, j'ai remarqué la présence de l'expression : "libre de droits" dans ton commentaire. D'après la page https://fr.wikipedia.org/wiki/Libre_de_droits, cette notion n'existe pas en droit français.
« En gros : peut-on s'adresser à la Cour de Cassation, pour négocier ce qu'elle affirme, en citant wikipedia ?
(et ce, même si on a un très bon raisonnement basé sur le droit moral) »
Généralement, on peut demander des précisions à un être humain :-)
Et je viens de le faire pour toi ! J'ai envoyé un message au webmestre du site de la cours de cassation pour avoir plus de précisions. N'hésite pas, à l'avenir, à le faire aussi si tu retombes sur une situation similaire si la question t'importe. Cela te permettra de formuler tes interrogations le plus précisément possible.
Sur la page https://fr.wikipedia.org/wiki/Libre_de_droits, il est affirmé que le « libre de droit » n'existe pas en France. Aussi, le logiciel étant, sauf erreur, considéré comme une œuvre, est donc concerné par le droit de paternité qui est semble-t-il perpétuel, inaliénable et imprescriptible.
S'agit-il d'une imprécision sur cette page de mentions légales, et l'expression « logiciel libre » serait plus appropriée (https://fr.wikipedia.org/wiki/Logiciel_libre), ou alors l'affirmation sur page Wikipédia « Libre de droits » est-elle erronée (ou je l'ai mal comprise) ?
Bien cordialement,
XXX
Bien sûr, je n'aurai pas le droit de citer sa réponse éventuelle sans son consentement.
À priori, cette affirmation découle de l'analyse de la loi. L'identité de la personne ayant fait cette affirmation n'est que peu importante à mon avis, bien que ça permettrait de lui demander le raisonnement qu'elle a eu. N'hésite pas à te référer à mon commentaire plus haut pour une tentative d'explication possible.
Sur la page Wikipédia en lien dans le commentaire auquel tu réponds : « En droit français, en 2015, et en termes strictement juridiques, la notion « libre de droits » n'existe pas. Cette appellation reste manifestement contraire au code de la propriété intellectuelle (articles L.111-1, L. 121-1, L. 131-3), notamment le droit moral concernant l'œuvre reste incessible. ».
Je ne les ai pas lu, mais une analyse des articles cités répondront sûrement à ton interrogation ;-)
Si des interrogations subsistaient, n'hésite pas à laisser un commentaire en indiquant ton cheminement.
Apparemment, le "libre de droits" n'existe pas en France dans la loi [1]. Donc déjà, "logiciel libre de droits" n'a pas de sens légal.
Et ça paraît logique si on comprends "libre de droits" comme "sans droits attachés" : le droit moral, qui fait partie du droit d'auteur et qui reconnaît notamment à l'auteur la paternité de l’œuvre, est perpétuel, inaliénable et imprescriptible en France. [2]
Ce qui veut dire qu'on ne peut pas supprimer le droit moral d'une œuvre en France. Donc il y a toujours le droit moral attaché à une œuvre. Et un logiciel est une œuvre. Donc un logiciel libre de droits c'est à priori impossible en France.
Aussi, les licences des logiciels libres sont des contrats entre les auteurs et les utilisateurs. Contrats applicables par les auteurs par le droit d'auteur. Donc à ma connaissance, un logiciel libre sans droit d'auteur, ça n'existe pas. Donc un logiciel libre de droits ça n'a pas de sens pour cette troisième raison.
Je ne suis pas un avocat, juste un lecteur de Wikipedia.
Je crois que ça ne coûte rien de leur poser la question ! Il n'y a pas besoin de leur dire qu'il y a une erreur si on n'en est pas sûr. Il est même autorisé de dire à quelqu'un qu'on pense qu'il a fait une erreur. Si c'est dit avec tact et respect, ça ne devrait poser aucun problème.
Vu comment j'ai repris des bouts de phrases de ces deux liens comme un sale, on peut considérer ce commentaire comme une œuvre dérivée sous licence CC BY-SA 3.0.
Merci pour les liens ! Je ne suis pas sûr d'être tombé sur le premier, d'autant que je cherche de l'aide en anglais. J'essaierai ça.
Pour le deuxième je suis déjà tombé dessus. Le problème était : « Note: Since version 1.5 of the protocol, a Firefox Account is required in order to use the synchronization service. » (que j'avais compris comme : il faut un compte sur les serveurs de Mozilla).
Pour référence, voilà comment j'avais fait (sans les espaces en début de lignes, mais je ne sais pas comment citer correctement un code markdown pour produire un bloc de code) :
> Voici un code dans une citation :
>
```
echo "salut"
```
Un texte dans la citation après le code.
Et là, ce qui suit pète tout. Je passe deux lignes vides, puis j'indente une ligne avec 8 espaces, puis je passe une ligne vide et je commence à écrire "J'essaie de […]" :
texte indentée ?
```J'essaie de sortir du bloc de code. Je n'ai pas écrit les trois guillemets qui débutent cette ligne, ils apparaissent tout seuls. Par contre, j'avais passé une ligne qui a disparu. Si je ne passe pas la ligne, ce comportement n'apparaît pas. Idem si je ne passe qu'une ligne et pas deux avant le "texte indenté ?".
Je n'arrive pas à sortir de ce bloc de code.
J'espère que j'ai réussi à être compréhensible mais ce n'est pas évident. Je suis tombé sur ce comportement en essayant de citer un code.
À plus :-]
P.S.: Voici la source de ce commentaire : https://framabin.org/p/?e8c3707081753b1b#evPLh7aVALnU5XG6riKUUV966jDFT8EQhCwptTv3vLU=
P.P.S : on a des comportements amusants en insérant des ``` dans ce bloc de code.
Effectivement, l'évolution de la traduction Markdown -> HTML que tu mentionnes me paraît être une bonne idée. Je peux écrire une entrée dans le suivi pour ça si ça paraît utile à quelqu'un.
Ah, effectivement c'est élégant comme ça. Il me semble que j'avais trouvé une autre manière de faire (que je n'ai pas trouvé élégante) ou alors ma mémoire me fait défaut.
Bref, je ne suis pas fan du Markdown, peut-être en partie parce que je ne le pratique pas assez, mais trouver une syntaxe qui plairait à tout le monde est probablement une idée assez utopique de toute façon.
Sinon, est-ce que ça vaudrait le coup que je crée une entrée dans le suivi pour proposer une option qui permet à l'utilisateur de saisir un commentaire / un journal en HTML (à voir pour les dépêches et l'interaction que cette option pourrait avoir avec l'aspect édition collective des dépêches), quitte à ce que cet HTML soit épuré et transformé ? (pas d'utilisation de styles, de scripts, d'iframes, d'objets, toutes les balises fermantes correspondent à des balises ouvrantes et vice-versa). Quitte à ce que ce soit une option proposée à partir d'un certain karma pour limiter les éventuels problèmes de sécurité non anticipés que cela pourrait poser. Je n'ai aucune idée si ça a déjà été discuté par le passé.
Ça permettrait aux grincheux comme moi d'utiliser la syntaxe qu'ils / elles veulent pour rédiger, y compris l'HTML directement.
Merci pour l'aide-edition, mais dans ton message, les blocs de codes sont hors des puces, et d'ailleurs chaque puce est dans une liste différente. Voici ce que donne "Code source de la sélection" dans Firefox :
<ul><li>la version avec <em>echo</em> :</li></ul><pre><codeclass="bash"><spanclass="nb">echo</span><spanclass="s2">"toto"</span></code></pre><ul><li>la version avec printf :</li></ul>
Y a-t-il moyen d'éviter ça ?
Peut-être que beaucoup pensent que je chipote mais j'attache de l'importance à ce genre de choses.
À la personne qui m'a moinsé : je suis intéressé par savoir ce j'ai écrit de gênant pour éviter de recommencer à l'avenir.
(edit: et effectivement j'avais réussi pour le code dans une citation, mais je n'avais pas trouvé la syntaxe que j'ai utilisée élégante / intuitive - je suppose que c'est une question de goût personnel, là on n'y peut pas grand chose)
Je ne sais jamais comment on fait pour mettre un code dans une puce ou dans une citation en Markdown et j'ai bien galéré sur mon dernier journal avec ça.
Dans une vie antérieure, j'ai conçu une syntaxe dans laquelle ça se passe comme ça :
- La version avec `echo` :
[code=bash <<<
echo "toto"
>>>]
- La version avec `printf` :
[code=bash <<<
printf "toto\n"
>>>]
Ou, si on veut être plus explicite :
- La version avec `echo` : [
[code=bash <<<
echo "toto"
>>>]
]
- La version avec `printf` : [
[code=bash <<<
printf "toto\n"
>>>]
]
Pour une citation :
Voici ce que cette page disait :
[quote
Ce code ne fonctionne pas toujours comme attendu :
[code=bash <<<
echo "$message"
>>>]
]
Pour les titres, pas de caractères bizarres : un = au début de la ligne donne un titre de premier niveau, deux = donnent un titre de deuxième niveau et il est également possible d'utiliser une notation sous forme de sections du genre :
[ = Titre 1
Cette section présente tartempion, un dessert peu connu.
[ = Titre 1.1
Lorem ipsum...
]
]
Et c'est d'ailleurs transformé en sections HTML. Les espaces de début de lignes dans les blocs de code sont détectés et supprimés, en conservant malgré tout l'indentation du code. Le code du document lui-même peut en conséquence être indenté.
On sort de l'esprit Markdown qui est censé être lisible tel quel, mais finalement ici on ne voit jamais que le résultat HTML et je préfère que ce soit facile à écrire et à comprendre plutôt que « plus ou moins naturel » à lire.
Je n'aime pas du tout Markdown non plus, et faire des contorsions pour écrire ce que je dois écrire. Je préfèrerais pouvoir rédiger dans un langage style (X)HTML (il n'est pas vraiment question d'utiliser autre chose y compris la syntaxe que j'ai mentionnée plus haut, elle aurait probablement les mêmes problèmes que je trouve à Markdown pour d'autres gens de toute façon). Les règles sont extrêmement claires et simples et il n'y a pas d'histoire de « Oh, la liste n'est pas reconnue comme une liste parce qu'elle n'est pas entourée de lignes vides », ou « Ah, j'ai trop indenté les tirets de cette liste, du coup elle est reconnue comme un bloc de code ». Ou « J'ai mis une nouvelle ligne entre deux items de la liste, donc c'est reconnu comme deux listes ». Tu veux écrire une citation ? Alors tu la mets entre <citation> et </citation>. Aucun mystère ou comportement étrange pour quelqu'un qui n'a pas l'habitude.
[^] # Re: TypeScript
Posté par raphj . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 3. Dernière modification le 13 novembre 2018 à 11:16.
Ah ah, oui, cette image m'amuse beaucoup.
En C++, tu as aussi intérêt à te limiter à un sous-ensemble assez restreint du langage.
J'aime bien ton article, il est bien documenté et soulève des points valides de manière respectueuse et agréable à lire.
Il se trouve que je ne suis quasiment pas affecté par les points négatifs que tu soulèves : je n'utilise pas (beaucoup) npm ni de bibliothèques externes, ni les webworkers. Je n'ai pour l'instant pas trop adopté la syntaxe des déconstructions pour des raisons de compatibilité des navigateurs mais je vais certainement bientôt m'y mettre, et pour
nulletundefinedje me suis fait un modèle qui fonctionne pour moi (undefined= la fonction ne retourne rien de particulier,nullest explicitement renvoyé quand l'élément n'existe pas mais effectivement ce n'est pas forcément idéal).Pour ton
{ a, b } = o, ça s'explique certainement par le fait que{ a, b }est interprété comme un bloc de code qui contient une instruction pas terminée par un point virgule (ce qui est autorisé en JS, et je ne suis pas fan de ça), et cette instructiona, best composée de deux sous-instructions (qui sont des expressions…) séparées avec l'opérateur virgule. L'analyse syntaxique échoue au niveau du=parce=après un bloc de code n'a pas de sens. Les parenthèses interdisent l'analyseur de considérer les accolades comme un bloc de code. Je sais, c'est dommage. Ce n'est pas incompréhensible, mais je reconnais que c'est pénible.Pour le
===, C'est pénible et c'est la même chose en PHP : j'ai décidé de considérer que==ne devait pas être utilisé.[^] # Re: TypeScript
Posté par raphj . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 2. Dernière modification le 13 novembre 2018 à 10:35.
Ben voyons.
Je n'ai pas affirmé qu'on peut écrire du beau code dans n'importe quel langage.
Le ruban de Turing est un modèle pour raisonner sur la calculabilité, raisonnements qui seraient lourds à faire avec un langage de programmation quelconque. Il n'est pas question d'écrire des programmes avec dans la vie de tous les jours. Le brainfuck n'est pas pensé pour écrire du code maintenable.
Un tas d'application à succès de taille respectable qui continuent à évoluer et à fonctionner ont été écrites avec du JS, c'est qu'elles doivent être un minimum maintenables (Firefox, Thunderbird, PDF.js, Signal, Wire, Wordpress, un tas de gros sites web, …).
On peut dire la même chose de PHP (malgré ses nombreuses incohérences - Nextcloud, WordPress…), de Java (malgré ses lourdeurs), de C (malgré le nombre de pièges dans lesquels on peut tomber), de C++ (malgré sa complexité)… et bien sûr, il est possible d'écrire du code médiocre dans ces langages.
Si un code n'est pas maintenable dans n'importe lequel de ces langages, c'est que les personnes qui l'ont écrit ont mal fait leur boulot, étaient inexpérimentées dans les langages utilisés, que le processus de développement a eu des loupés ou que le langage choisi n'est pas adapté au cas d'utilisation. Après, il y a des pièges dans tous les langages. Il est nécessaire de connaître profondément la sémantique des outils qu'on utilise et d'apprendre à éviter ces pièges (vous avez déjà utilisé une liste vide comme valeur par défaut d'un paramètre de fonction en Python ?). Si vous utilisez une scie sans avoir appris à l'utiliser, vous allez peut-être couper ce que vous vouliez couper, mais vous risquez aussi de vous couper un doigt. Et si vous savez vous en servir, vous risquez quand même de vous blesser, donc la vigilance reste de la partie.
En C aussi, on peut avoir du code qui compile et qui tourne, mais qui se vautre à l'exécution à cause d'un dépassement (quand on a la chance que ça crash !).
Et puis si quelqu'un ne se sent pas capable d'écrire du code propre en $LANGAGE parce cette personne n'accroche pas avec son fonctionnement, ce n'est pas grave, il y a d'autres langages qui pourront mieux lui convenir.
[^] # Re: TypeScript
Posté par raphj . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à -4.
On peut écrire des immondices dans n'importe quel langage. Si les choses sont faites avec un peu de discipline, on peut arriver à un résultat correct.
Il suffit de ne pas faire n'importe quoi, d'utiliser un sous-ensemble correct du langage et de suivre les bonnes pratiques qu'on a choisies et de s'y tenir. Il y a des très bons linters si on veut avoir un peu de rigueur "garantie". Je ne les utilise plus actuellement mais j'en étais fan il y a quelques années et j'ai beaucoup appris grâce à eux.
Ne pas écrire du code trop intelligent, éviter les constructions bizarres, nommer ses variables correctement, et en fait appliquer les conseils qui s'appliquent à tous les langages font déjà beaucoup de bien.
Je préfère aussi avoir du typage statique mais ce n'est pas le seul aspect du langage et en l'occurrence, TypeScript offre un système de type meilleur que beaucoup de langages typés (mais il y a mieux aussi).
[^] # Re: TypeScript
Posté par raphj . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 2. Dernière modification le 12 novembre 2018 à 11:50.
Pas la peine d'être désagréable comme ça.
Est-ce que le terme "transpiler" a été inventé par les gens du milieu Javascript ? Non.
Est-il est mal utilisé ? Pas à ma connaissance.
Est-il ambigu ou vague ? Non.
Quel est le problème d'utiliser "transpiler" à la place de "compiler" ?
On peut ne pas aimer le terme transpiler, et considérer que c'est une forme spécifique de compilation, et préférer juste dire compilation. On peut ne pas aimer les néologismes. Mais ça n'a rien à voir avec "ils ne connaissent tout simplement ce qui se fait en dehors de leur propre écosystème". C'est hors sujet.
Il y a une différence entre ignorance et choix.
Je ne changerai pas mon avis plus ou moins neutre sur le mot "transpiler" avec des remarques en majuscules et continuerai à l'utiliser tant que personne ne me donnera un argument solide.
Commenter c'est aussi écrire. Devrait-on dire "écrire" plutôt que "commenter" ? Non, "commenter" a un sens plus précis.
Je dis ça en ayant écrit un compilateur jouet (vers assembleur) et un transpileur (vers Javascript). Il y a plein de problèmes que je n'ai pas touchés dans le second cas, notamment l'allocation de registre (mais effectivement, il y a des problèmes de renommage dans les deux cas). Il y a aussi un problème que j'ai traité dans le second cas et pas dans le premier cas : la lisibilité du code produit, et calquer le formatage du code source. Pour moi ce n'est pas complètement aberrant de vouloir appeler ces deux trucs différemment et chaque camps devrait respecter les avis de l'autre camp.
Sur le fond du problème : Javascript a clairement ses travers et son écosystème est étouffant mais ce n'est clairement pas un mauvais langage. Après, il y a des questions de goût et des expressions comme "ad nauseam" n'ont rien à faire dans un argumentaire solide.
On peut ne pas aimer et ça ne se discute peut-être pas trop, mais on peut faire du Javascript correct sans utiliser la lourdeur de l'écosystème (perso j'écris systématiquement du Javascript standard ou du TypeScript occasionnellement).
Je ne comprends pas toute cette haine pour ce langage. Il faut juste passer un peu de temps à accepter ses défauts (il y en a beaucoup - mais j'en connais dans les autres langages que j'utilise), à comprendre son fonctionnement et à apprécier ses richesses. Et des langages comme TypeScript retirent une partie des problèmes si on veut plus de garanties sur les types.
Importe ton interpréteur Lua, je ne désactiverai pas mon bloqueur de scripts pour ton projet (ça me gonfle de voir mon navigateur devoir interpréter du code pour afficher un article), ma bande passante et mon processeur ont d'autres trucs à faire et les ressources énergétiques de la planète aussi. Après on parle de bibliothèques légères, faudrait voir à être cohérent. Grrr. Désolé pour le petit coup de gueule.
# Trop bien !
Posté par raphj . En réponse au journal Première version stable pour WeasyPrint. Évalué à 2. Dernière modification le 09 novembre 2018 à 15:22.
J'ai eu l'idée il y a quelques années de faire exactement ça.
Me rendant compte que ça voulait dire d'implémenter un moteur de rendu HTML/CSS, avec les difficultés du style traitement des textes bi-directionnels, j'ai abandonné.
J'ai essayé sur un document que j'ai écrit dans une syntaxe maison, le résultat est très bon.
J'ai toujours été frustré par la gestion des passages à la page suivante avec les impressions des moteurs de rendu classiques (au mauvais endroit, lignes coupées en deux) et autre problème (marges, taille de la police, WebKit qui ne prenait pas en charge les césure correctement).
Un « petit » manque : si MathJax est utilisé, les formules ne s'afficheront pas (j'imagine que prendre en charge Javascript n'est pas trivial). Pour ce cas particulier, KaTeX est une piste à explorer.
Peut-être qu'un jour on pourra écrire des articles pour des conférences comme ça ?
[^] # Re: L'important : les finitions.
Posté par raphj . En réponse au journal Ubuntu, Fais moi rêver !. Évalué à 2.
Par un hasard assez fou, ce bogue vient d'être corrigé apparemment.
https://bugs.kde.org/show_bug.cgi?id=350816
[^] # Re: L'important : les finitions.
Posté par raphj . En réponse au journal Ubuntu, Fais moi rêver !. Évalué à 5. Dernière modification le 04 novembre 2018 à 09:42.
Je ne vois pas pourquoi ça serait là pour faire chier. Je peux comprendre que monter la partition du téléphone sur l'ordinateur alors qu'elle est en cours d'utilisation sur le téléphone est un peu délicat. MTP est une solution à ce problème et je ne vois pas de raison particulière sur pourquoi ça ne devrait pas fonctionner correctement sous GNU/Linux.
Pour ma part j'utilise adb pull/push, scp ou rsync.
[^] # Re: L'important : les finitions.
Posté par raphj . En réponse au journal Ubuntu, Fais moi rêver !. Évalué à 2.
Je crois qu'il s'agit d'une extension à Wayland, pas encore standard. Du coup, ça ne marche pas sous tous les environnements, ou selon les bibliothèques graphiques. J'ai bon espoir que ça se standardise.
Encore une fois, le développeur principal de Kwin était réticent sur ce sujet à un moment, je crois. On peut lire des trucs là dessus ici : https://blog.martin-graesslin.com/blog/2016/07/synchronizing-the-x11-and-wayland-clipboard/
[^] # Re: L'important : les finitions.
Posté par raphj . En réponse au journal Ubuntu, Fais moi rêver !. Évalué à 3. Dernière modification le 01 novembre 2018 à 19:25.
Oui, j'ai cru comprendre. Ça oblige à ne pas simplement faire un ×1,5, mais plutôt un × 3 / 2 ou des choses comme ça. Et on se retrouve avec des fractions de pixels. Dans tous les cas, le compositeur ne peut pas donner une image complètement net. Un jour, je me suis retrouvé devant un Mac Retina, et l'affichage ne m'avait pas paru complètement net. C'était peut-être pour ça. Ou alors un mauvais réglage. À vrai dire je ne sais plus bien.
Mais si j'ai pris un écran HiDPI, c'est justement pour que tout soit net.
Ce qui serait sympa, ce serait d'avoir un truc qui ressemble au zoom des navigateur. Aussi, Android semble bien s'en sortir sur ces questions là. Il doit y avoir une solution élégante à ce problème, au moins pour les applications libres maintenues aujourd'hui.
# L'important : les finitions.
Posté par raphj . En réponse au journal Ubuntu, Fais moi rêver !. Évalué à 10. Dernière modification le 01 novembre 2018 à 17:16.
Je vais répondre un truc générique, je ne connais pas les changements de la version 18.10 d'Ubuntu.
Oui, finalement un système stable et qui fait ce qu'on lui demande est une chose positive, et je dis ça en tant que quelqu'un qui était quasiment toujours sur les versions de développement d'Ubuntu quand je l'utilisais et qui aime les nouveautés.
Je vois l'absence de grandes nouveautés visible sur une distribution grand public d'un bon œil, ça veut dire que tout ne va pas changer et ne sera pas à réapprendre à chaque migration pour des gens qui ne sont pas particulièrement intéressés par les nouveautés. Si l'environnement fonctionne tel quel, pas besoin de tout chambouler.
Ça veut aussi dire que je suis plus familier avec un environnement un peu plus "vieux" (une LTS) quand je dois aider quelqu'un.
En ce qui me concerne, j'aime plutôt bien les grandes nouveautés visibles en général mais j'ai plutôt tendance à bien apprécier les petits changements discrets mais pratiques ou agréables, comme :
Sous plasma 5 des améliorations discrètes comme ça arrivent à chaque version. L'interface reste globalement inchangée mais c'est de plus en plus peaufiné / léché et stable et ça me donne envie d'être toujours sur la dernière version.
Par contre il reste des choses qui me semblent plus ou moins indispensables et qui ne sont pas là, par exemple :
Donc oui pour les nouveautés discrètes et incrémentales. J'adore les grosses nouveautés, mais le plus important pour moi, ce sont les choses qu'on ne voit pas forcément mais qui font que tout fonctionne correctement (avec les évolutions actuelles).
[^] # Re: un sondage , un sondage !
Posté par raphj . En réponse au journal La compote de pommes en gourde n'est PAS un truc de fainéant.. Évalué à 1.
C'est proposé.
# Site corrigé
Posté par raphj . En réponse au journal les logiciels libres sont libres de droits. Évalué à 3.
Suite à une question au webmestre relative à cette mention, celle-ci a été corrigée. La page ne parle plus de logiciels libres de droits, mais de logiciels libres.
[^] # Re: Timeout
Posté par raphj . En réponse au journal Horodater un cambriolage avec des logs. Évalué à -2. Dernière modification le 02 octobre 2018 à 08:29.
[commentaire supprimé]
[^] # Re: "Libre de droits" notion sujette à caution
Posté par raphj . En réponse au journal les logiciels libres sont libres de droits. Évalué à 4. Dernière modification le 25 septembre 2018 à 23:30.
Félicitations, votre commentaire marque l'apparition d'un même sur Linuxfr.
Tu feras attention, j'ai remarqué la présence de l'expression : "libre de droits" dans ton commentaire. D'après la page https://fr.wikipedia.org/wiki/Libre_de_droits, cette notion n'existe pas en droit français.
[^] # Re: Qui affirme que "libre de droit*" n'existe pas en France ? *[s]
Posté par raphj . En réponse au journal les logiciels libres sont libres de droits. Évalué à 1. Dernière modification le 24 septembre 2018 à 21:11.
Je croyais que le Secret de la correspondance s'appliquait ici et il semblerait que non.
Je me coucherai moins con !
[^] # Re: Qui affirme que "libre de droit*" n'existe pas en France ? *[s]
Posté par raphj . En réponse au journal les logiciels libres sont libres de droits. Évalué à 6. Dernière modification le 24 septembre 2018 à 00:45.
« En gros : peut-on s'adresser à la Cour de Cassation, pour négocier ce qu'elle affirme, en citant wikipedia ?
(et ce, même si on a un très bon raisonnement basé sur le droit moral) »
Généralement, on peut demander des précisions à un être humain :-)
Et je viens de le faire pour toi ! J'ai envoyé un message au webmestre du site de la cours de cassation pour avoir plus de précisions. N'hésite pas, à l'avenir, à le faire aussi si tu retombes sur une situation similaire si la question t'importe. Cela te permettra de formuler tes interrogations le plus précisément possible.
Bien sûr, je n'aurai pas le droit de citer sa réponse éventuelle sans son consentement.
[^] # Re: Qui affirme que "libre de droit*" n'existe pas en France ? *[s]
Posté par raphj . En réponse au journal les logiciels libres sont libres de droits. Évalué à 3. Dernière modification le 23 septembre 2018 à 18:47.
À priori, cette affirmation découle de l'analyse de la loi. L'identité de la personne ayant fait cette affirmation n'est que peu importante à mon avis, bien que ça permettrait de lui demander le raisonnement qu'elle a eu. N'hésite pas à te référer à mon commentaire plus haut pour une tentative d'explication possible.
Sur la page Wikipédia en lien dans le commentaire auquel tu réponds : « En droit français, en 2015, et en termes strictement juridiques, la notion « libre de droits » n'existe pas. Cette appellation reste manifestement contraire au code de la propriété intellectuelle (articles L.111-1, L. 121-1, L. 131-3), notamment le droit moral concernant l'œuvre reste incessible. ».
Je ne les ai pas lu, mais une analyse des articles cités répondront sûrement à ton interrogation ;-)
Si des interrogations subsistaient, n'hésite pas à laisser un commentaire en indiquant ton cheminement.
[^] # Re: Quelle facilité de la conclusion!
Posté par raphj . En réponse au journal les logiciels libres sont libres de droits. Évalué à 8.
Apparemment, le "libre de droits" n'existe pas en France dans la loi [1]. Donc déjà, "logiciel libre de droits" n'a pas de sens légal.
Et ça paraît logique si on comprends "libre de droits" comme "sans droits attachés" : le droit moral, qui fait partie du droit d'auteur et qui reconnaît notamment à l'auteur la paternité de l’œuvre, est perpétuel, inaliénable et imprescriptible en France. [2]
Ce qui veut dire qu'on ne peut pas supprimer le droit moral d'une œuvre en France. Donc il y a toujours le droit moral attaché à une œuvre. Et un logiciel est une œuvre. Donc un logiciel libre de droits c'est à priori impossible en France.
Aussi, les licences des logiciels libres sont des contrats entre les auteurs et les utilisateurs. Contrats applicables par les auteurs par le droit d'auteur. Donc à ma connaissance, un logiciel libre sans droit d'auteur, ça n'existe pas. Donc un logiciel libre de droits ça n'a pas de sens pour cette troisième raison.
Je ne suis pas un avocat, juste un lecteur de Wikipedia.
Je crois que ça ne coûte rien de leur poser la question ! Il n'y a pas besoin de leur dire qu'il y a une erreur si on n'en est pas sûr. Il est même autorisé de dire à quelqu'un qu'on pense qu'il a fait une erreur. Si c'est dit avec tact et respect, ça ne devrait poser aucun problème.
[1] https://fr.wikipedia.org/wiki/Libre_de_droits
[2] https://fr.wikipedia.org/wiki/Droit_d'auteur
Vu comment j'ai repris des bouts de phrases de ces deux liens comme un sale, on peut considérer ce commentaire comme une œuvre dérivée sous licence CC BY-SA 3.0.
[^] # Re: Correction
Posté par raphj . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 2.
Merci BAud de prendre tout ce temps à me lire et me répondre !
Je suis moi aussi un gros utilisateur du bouton prévisualiser et son utilisation obligatoire est une bonne chose.
[^] # Re: Mes descriptions...
Posté par raphj . En réponse à la dépêche Firefox 61 & 62. Évalué à 3.
Merci pour les liens ! Je ne suis pas sûr d'être tombé sur le premier, d'autant que je cherche de l'aide en anglais. J'essaierai ça.
Pour le deuxième je suis déjà tombé dessus. Le problème était : « Note: Since version 1.5 of the protocol, a Firefox Account is required in order to use the synchronization service. » (que j'avais compris comme : il faut un compte sur les serveurs de Mozilla).
[^] # Re: Correction
Posté par raphj . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 1. Dernière modification le 20 septembre 2018 à 01:50.
Pour référence, voilà comment j'avais fait (sans les espaces en début de lignes, mais je ne sais pas comment citer correctement un code markdown pour produire un bloc de code) :
Et là, ce qui suit pète tout. Je passe deux lignes vides, puis j'indente une ligne avec 8 espaces, puis je passe une ligne vide et je commence à écrire "J'essaie de […]" :
[^] # Re: Correction
Posté par raphj . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à -2. Dernière modification le 20 septembre 2018 à 01:05.
Effectivement, l'évolution de la traduction Markdown -> HTML que tu mentionnes me paraît être une bonne idée. Je peux écrire une entrée dans le suivi pour ça si ça paraît utile à quelqu'un.
Ah, effectivement c'est élégant comme ça. Il me semble que j'avais trouvé une autre manière de faire (que je n'ai pas trouvé élégante) ou alors ma mémoire me fait défaut.
Bref, je ne suis pas fan du Markdown, peut-être en partie parce que je ne le pratique pas assez, mais trouver une syntaxe qui plairait à tout le monde est probablement une idée assez utopique de toute façon.
Sinon, est-ce que ça vaudrait le coup que je crée une entrée dans le suivi pour proposer une option qui permet à l'utilisateur de saisir un commentaire / un journal en HTML (à voir pour les dépêches et l'interaction que cette option pourrait avoir avec l'aspect édition collective des dépêches), quitte à ce que cet HTML soit épuré et transformé ? (pas d'utilisation de styles, de scripts, d'iframes, d'objets, toutes les balises fermantes correspondent à des balises ouvrantes et vice-versa). Quitte à ce que ce soit une option proposée à partir d'un certain karma pour limiter les éventuels problèmes de sécurité non anticipés que cela pourrait poser. Je n'ai aucune idée si ça a déjà été discuté par le passé.
Ça permettrait aux grincheux comme moi d'utiliser la syntaxe qu'ils / elles veulent pour rédiger, y compris l'HTML directement.
[^] # Re: Correction
Posté par raphj . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 4. Dernière modification le 19 septembre 2018 à 17:04.
Merci pour l'aide-edition, mais dans ton message, les blocs de codes sont hors des puces, et d'ailleurs chaque puce est dans une liste différente. Voici ce que donne "Code source de la sélection" dans Firefox :
Y a-t-il moyen d'éviter ça ?
Peut-être que beaucoup pensent que je chipote mais j'attache de l'importance à ce genre de choses.
À la personne qui m'a moinsé : je suis intéressé par savoir ce j'ai écrit de gênant pour éviter de recommencer à l'avenir.
(edit: et effectivement j'avais réussi pour le code dans une citation, mais je n'avais pas trouvé la syntaxe que j'ai utilisée élégante / intuitive - je suppose que c'est une question de goût personnel, là on n'y peut pas grand chose)
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par raphj . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 10.
Souvent, avec un oreiller et un bon matelas :-)
[^] # Re: Correction
Posté par raphj . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 1.
Je ne sais jamais comment on fait pour mettre un code dans une puce ou dans une citation en Markdown et j'ai bien galéré sur mon dernier journal avec ça.
Dans une vie antérieure, j'ai conçu une syntaxe dans laquelle ça se passe comme ça :
Ou, si on veut être plus explicite :
Pour une citation :
Pour les titres, pas de caractères bizarres : un
=au début de la ligne donne un titre de premier niveau, deux=donnent un titre de deuxième niveau et il est également possible d'utiliser une notation sous forme de sections du genre :Et c'est d'ailleurs transformé en sections HTML. Les espaces de début de lignes dans les blocs de code sont détectés et supprimés, en conservant malgré tout l'indentation du code. Le code du document lui-même peut en conséquence être indenté.
On sort de l'esprit Markdown qui est censé être lisible tel quel, mais finalement ici on ne voit jamais que le résultat HTML et je préfère que ce soit facile à écrire et à comprendre plutôt que « plus ou moins naturel » à lire.
Je n'aime pas du tout Markdown non plus, et faire des contorsions pour écrire ce que je dois écrire. Je préfèrerais pouvoir rédiger dans un langage style (X)HTML (il n'est pas vraiment question d'utiliser autre chose y compris la syntaxe que j'ai mentionnée plus haut, elle aurait probablement les mêmes problèmes que je trouve à Markdown pour d'autres gens de toute façon). Les règles sont extrêmement claires et simples et il n'y a pas d'histoire de « Oh, la liste n'est pas reconnue comme une liste parce qu'elle n'est pas entourée de lignes vides », ou « Ah, j'ai trop indenté les tirets de cette liste, du coup elle est reconnue comme un bloc de code ». Ou « J'ai mis une nouvelle ligne entre deux items de la liste, donc c'est reconnu comme deux listes ». Tu veux écrire une citation ? Alors tu la mets entre
<citation>et</citation>. Aucun mystère ou comportement étrange pour quelqu'un qui n'a pas l'habitude.