Ace: No se puede hacer que ACE detecte o use nuevas líneas de Unix

Hola

Creo que es muy poco probable que este sea un problema con el as.
¿Puedes probarlo con el siguiente código?

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

también sería útil si pudiera proporcionar una URL a la página de ejemplo donde podría intentar reproducir el problema

Por desgracia, nuestro gitlab es privado.

No sé qué más podría ser porque sale del servidor sin \r pero los tiene cuando vuelve.

Cuando llegue a casa veré si puedo ejecutar tu código de prueba.

Resultados de tu código:

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

Y cuando lo guardo, Rails lo recibe como que contiene \r\n para EOL.

Todavía estoy hurgando en esto, pero me está volviendo loco.

busque el código que sube el archivo
o reemplaza \n con \r\n o el navegador lo hace automáticamente.

Aquí está el código que coloca el texto en un campo oculto para cargarlo:

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

No está haciendo nada para cambiar los finales de línea. ¿Por qué un navegador haría este cambio?

Bien, creé una esencia de ejemplo con un archivo php que demuestra el error.

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

Esperemos que esto nos ayude a descubrir qué está fallando.

¡Ciao!

Sería mejor crear una prueba con textarea regular, ya que hemos visto que no es causado por ace.
Hay muchas formas en que el texto de las ventanas se puede convertir a '\r\n', es por eso que git tiene la opción autocrlf.
La solución correcta aquí es verificar en el servidor si el archivo ya contiene finales de línea de Windows, si no, convertirlo a formato Linux.

Hay muchas formas en que el texto de las ventanas se puede convertir a '\r\n', es por eso que git tiene la opción autocrlf.

Pero Windows no está involucrado de ninguna manera: el servidor es CentOS6 y el cliente es Chrome en OS X.

Intentaré cambiar mi ejemplo para usar un área de texto oculta y ver si eso ayuda.

No. Al ejecutar mi página de prueba en OS X con Chrome en OS X, sigo recibiendo los caracteres \r al enviar.

Estoy más o menos de acuerdo en que no es problema de Ace, ya que llega al textarea sin agregar \r . Pero algo extraño está pasando aquí y si podemos resolverlo, será un buen artículo de preguntas frecuentes para Ace para que otros no tengan este problema.

Bien, sé lo que está pasando y me siento estúpido por no saber esto:

Cuando POST un formulario, usa el tipo MIME application/x-www-form-urlencoded . De acuerdo con los tipos de contenido de formulario W3 , un navegador siempre debe codificar nuevas líneas como \r\n .

Así que ahí es donde entran los \r\n . Supongo que nunca me di cuenta antes.

La solución es hacer que la aplicación del servidor haga "lo correcto" con los datos que regresan, lo que podría
incluye reemplazar \r\n con \n .

Gracias chicos. Cerrando este tema. Con suerte, cualquier persona con un problema similar encontrará útil este problema.