Ace: Impossible de faire en sorte qu'ACE détecte ou utilise les nouvelles lignes Unix

salut

Je pense qu'il est très peu probable que ce soit un problème avec ace.
Pouvez-vous le tester avec le code suivant?

var session = editor.session
session.setNewLineMode("unix"); // same as session.setOption("newLineMode", "unix");
JSON.stringify(ace.session.doc.getNewLineCharacter()); // == '"\n"'
session.doc.getValue().indexOf("\r") == -1

il serait également utile que vous donniez une URL à une page d'exemple où je pourrais essayer de reproduire le problème

Hélas, notre gitlab est privé.

Je ne sais pas ce que cela pourrait être d'autre car il sort du serveur sans \r mais les a quand il revient.

Quand je rentrerai à la maison, je verrai comment exécuter votre code de test.

Résultats de votre code :

session = editor.session
// => undefined
session.setNewLineMode("unix")
// => undefined
JSON.stringify(session.doc.getNewLineCharacter())
// => ""\n""
session.doc.getValue().indexOf("\r") == -1
// => true

Et quand je l'enregistre, il est reçu par Rails comme contenant \r\n pour EOL.

J'essaie encore de faire ça, mais ça me rend dingue.

recherchez le code qui télécharge le fichier
soit il remplace \n par \r\n, soit le navigateur le fait automatiquement.

Voici le code qui place le texte dans un champ masqué pour le téléchargement :

https://github.com/gitlabhq/gitlabhq/blob/5-4-stable/app/views/edit_tree/show.html.haml#L42 -L45

Il ne fait rien pour changer les fins de ligne. Pourquoi un navigateur ferait-il ce changement ?

D'accord, j'ai créé un exemple d'essentiel avec un fichier php qui illustre l'erreur.

https://gist.github.com/docwhat/5992954#file-ace-windows-newlines-php

Espérons que cela nous aidera à comprendre ce qui ne va pas.

Ciao !

Il serait préférable de créer un test avec une zone de texte régulière, car nous avons vu qu'il n'est pas causé par ace.
Il existe de nombreuses façons de convertir le texte sur Windows en '\r\n', c'est pourquoi git a l'option autocrlf.
La bonne solution ici est de vérifier sur le serveur si le fichier contient déjà des fins de ligne Windows, sinon de le convertir au format Linux.

Il existe de nombreuses façons de convertir le texte sur Windows en '\r\n', c'est pourquoi git a l'option autocrlf.

Mais Windows n'est en aucun cas impliqué - Le serveur est CentOS6 et le client est Chrome sur OS X.

Je vais essayer de changer mon exemple en utilisant une zone de texte masquée à la place et voir si cela aide.

Nan. L'exécution de ma page de test sur OS X avec Chrome sur OS XI obtient toujours les caractères \r lors de la soumission.

Je suis en quelque sorte d'accord que ce n'est pas le problème d'Ace, puisqu'il atteint le textarea sans ajouter \r . Mais quelque chose de bizarre se passe ici et si nous pouvons le comprendre, cela fera un bon article de FAQ pour Ace afin que les autres n'aient pas ce problème.

Ok, donc je sais ce qui se passe et je me sens stupide de ne pas savoir ceci:

Lorsque vous POST un formulaire, il utilise le type MIME application/x-www-form-urlencoded . Selon les types de contenu de formulaire W3, un navigateur doit toujours coder les retours à la ligne en \r\n .

C'est donc là que les \r\n entrent en jeu. Je suppose que je n'avais jamais remarqué auparavant.

La solution consiste à faire en sorte que l'application serveur fasse la « bonne chose » avec les données qui reviennent, ce qui pourrait
inclure le remplacement \r\n par \n .

Merci les gars. Fermeture de ce sujet. Espérons que toute personne ayant un problème similaire trouvera ce problème utile.