Mises à jour de yAronet - Page 35

(mon pauvre, pour la première partie, tu sais pas dans quoi tu t'embarques )

Je sais pas (je regarde en meme temps) la balise [s] est sensé etre toujour supporté non ?
Avec la skin sombre ça ne fait rien (je test une autre skin dans la foulée) :

Test test test

edit: bon ben la ça a marché, la barre ne devais pas etre visible enfait. Ok j'ai rien dit

./1020 : qu'est ce que tu veux dire par "que la balise media mette le lien sélectionné au bon endroit" ?

On me suggère que ça signifie "que la syntaxe soit [media]url[/media] au lieu de [media=url]", et si c'est bien ça la réponse est définitivement non (déjà discuté dans ce topic). Si ça veut dire autre chose, je n'ai pas compris la question, tu peux préciser ?

[edit] J'ai peut-être compris, tu parles du lien "media" à droite des posts qui fait n'importe quoi ? Si c'est ça, je ne corrigerai pas la version actuelle, ça sera remplacé en même temps que l'intégralité du formulaire de post, mais c'est prévu.

Pour les liens YouTube en HTTPs, c'est fait.

Note pour la suite du topic : svp, soyez précis (vraiment) dans vos questions et demandes.

Merci pour le https.

C'est le lien dont je parle, je précise...

Je me fiche pas mal de la syntaxe : ce que je veux dire c'est que lorsqu'on poste par exemple une image, on peut sélectionner l'url de l'image dans le post puis cliquer sur le lien de la balise image dans la liste à droite et l'url va gentiment d'elle même entre [img] et [/img].

Lorsqu'on fait la même chose avec le lien vers la balise media on pourrait s'attendre à ce que l'url se place aussi où il faut (juste après le = avec cette syntaxe, à la place du http:// ) et pas bêtement à la suite de la balise fermée comme maintenant.

http://http://) tiens tiens - oui oui, osef

• Zerosquare note : un paquet de fraises plates pour Zeph...


(cherchez pas, c'est une private joke)

./1024 : ok donc c'est bien ma deuxième suggestion, c'est prévu mais il faudra pas être pressé
./1025

Avec la balise [code=c], le backslash en fin de ligne disparait (normalement il y en a un aux 4 premières lignes) :
#define bcall(romcall); #asm rst rbr_call defw romcall #endasm

t'es sûr du point virgule?

Pour le compilo (z88dk), il n'en faut pas à la suite de #endasm, donc si j'en met pas là quand je ferais appel à la macro il n'en faudra pas non plus, ce qui risque de faire un peu tâche dans du code C, non ?

Enfin je débute en C (mais apparemment ça va pas chercher loin sur du z80).

C'est une combinaison d'effets non voulue entre la balise [code] qui traite les retours à la ligne de façon particulière et le backslash qui permet d'annuler une balise. Un retour à la ligne est une balise comme une autre, du coup le fait de la précéder d'un backslash l'annule. En dehors d'une balise [code] par exemple ça permet d'aller à la ligne pendant l'édition sans qu'un retour à la ligne n'apparaisse à l'affichage (édite mon post pour un exemple). Du coup c'est assez chiant à régler, et vu l'importance ça attendra.

L'importance? C'est très important, ça casse #define dans tous les langages qui utilisent le préprocesseur C!

comme tu ne postes jamais la moindre ligne de code, c'est vrai que c'est très important.

Oui prend ton temps, je sais à quel point ça peut être chiant de fixer ce genre de truc

squalyl (./1032) :
comme tu ne postes jamais la moindre ligne de code, c'est vrai que c'est très important.

Euh si, ça m'arrive d'en poster.

Je ne sais pas s'il s'agit d'un bug ou de mon PC, mais parfois la validation d'un edit inline prend 1/2 seconde (normal), parfois il faut 30 secondes au post pour être validé. J'utilise Fx 17.0.5 ESR, ça fait ça à ceux qui utilisent une version plus récente ?

C'est pareil ici — avec Chromium.

Pareil ici, mais rarement. Ce qui arrive plus souvent, c'est que l'aperçu d'un post via la page Suivi des sujets mette une dizaine de secondes à charger, alors que d'habitude c'est quasi-instantané.

Ah oui, j'ai pas parlé de la fréquence, c'est dans les 1 fois sur 2, et la taille du post n'est pas en rapport.

Les fois où ça arrive vous avez pu voir avec un outil de debug (Firebug, l'inspecteur de Chrome, etc) l'étape ou les étapes qui prend/prennent du temps ?

Je n'ai pas regardé.
Je le ferai à l'occasion.
C'est quel outil sur chromium ? Network ?

J'ai pas pensé à regarder. Par contre ça n'a pas l'air de toucher qu'une seule requête, on dirait plus que c'est un ralentissement transitoire (si j'essaie de prévisualiser d'autres posts pendant que ça rame, ils ne s'affichent pas non plus, et au bout de quelques secondes ils se chargent tous).

Je laisse le soin à ceux qui s'y connaisssent en web d'approfondir ça

./1040 : yep, par contre l'ennui c'est que ça ne capture que quand il est ouvert. Dans le cas de Folco si ça se produit vraiment une fois sur deux ça devrait être facile de reproduire le problème mais sinon...

il n'y a que sur yAronet que ça vous fait ça ? (question annexe : vous n'êtes pas chez Free par hasard ?)

OK.
Je crois qu'il n'y a que sur yN, oui.
Non, je me connecte avec un hotspot (, du coup ça ne m'avait pas inquiété )
J'essaierai de voir si c'est pareil depuis le boulot.

Pas chez Free, et le problème est spécifique à yAronet, pour autant que je le remarque. Mais chez moi ça le fait assez rarement (très loin du 50% de Folco).

Zerosquare (./1045) :
Pas chez Free, et le problème est spécifique à yAronet, pour autant que je le remarque.

Dans le même genre avec le JS, le popup de citer/sauver apparait pas à chaque fois, parfois à la sélection, parfois à la désélection.

Bon alors puisque ça m'arrive souvent, comment faire pour trouver ce qui prend du temps avec Fx ? J'ai installé FireBug

testdffdsfqsdfsdfsdfsdfsdfsdfsdf

(comme de bien entendu, une solution au problème semble être d'installer FireBug ><)

Je ne connais pas trop firebug mais il doit y avoir un onglet "réseau" dans lequel tu vois chaque élément chargé sur une page (dans le cas d'un edit inline il ne devrait y avoir qu'une seule requête) et une décomposition du temps de chargement en plusieurs étapes (qqchose du genre requête/attente/téléchargement). C'est pas dit que ces informations servent à grand chose, mais comme je ne vois pas trop d'où peut venir le problème et qu'il ne se produit pas chez moi ça va être un peu compliqué ^^

Yep, j'ai trouvé où sont affichés les timings des requêtes. Je tente, je tente, c'est dingue ce truc xD

Je viens de regarder pour le bug ./1027 et ça serait vraiment pénible à corriger : les échappements de balise sont gérés bien avant d'avoir connaissance du contexte (puisque le contexte est justement défini en fonction des balises trouvées) donc il faudrait changer pas mal de logique pour pouvoir détecter qu'un échappement de retour à la ligne ne doit pas être pris en compte à l'intérieur d'une balise [code]. Accessoirement ça aurait toutes les chances de faire apparaître d'autres bugs au passage, donc je ne pense pas toucher à ça.

Il reste deux solutions :

- Échapper les backslashs pour qu'ils soient traités comme des caractères normaux (pas besoin de mise à jour de yN, ça fonctionne déjà ), ou
- Remplacer la séquence d'échappement "\" par quelque chose de moins fréquent (par exemple "\\").

À vous de voir, perso je préfère la première solution puisque la seconde rend l'échappement moins pratique quand on veut réellement s'en servir, et qu'il m'arrive plus souvent de vouloir échapper une balise ou un smiley que de vouloir placer un "\" en fin de ligne.

Puis pour les codeurs, c'est assez naturel d'échapper les \, donc ça nous changera pas trop