Ace: Не удается заставить ACE обнаруживать или использовать новые строки unix

Привет

Я думаю, что маловероятно, что это проблема с ace.
Можете ли вы проверить это с помощью следующего кода?

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

также было бы полезно, если бы вы могли указать URL-адрес страницы примера, где я мог бы попытаться воспроизвести проблему.

Увы, наш гитлаб частный.

Я не знаю, что еще это может быть, потому что он уходит с сервера без \r , но имеет их, когда возвращается.

Когда я вернусь домой, я позабочусь о запуске вашего тестового кода.

Результаты вашего кода:

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

И когда я его сохраняю, Rails принимает его как содержащий \r\n для EOL.

Я все еще тыкаю в это, но это сводит меня с ума.

ищите код, который загружает файл
либо он заменяет \n на \r\n, либо браузер делает это автоматически.

Вот код, который помещает текст в скрытое поле для загрузки:

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

Он ничего не делает, чтобы изменить окончания строк. Зачем браузеру делать это изменение?

Хорошо, я создал пример с файлом php, который демонстрирует ошибку.

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

Надеюсь, это поможет нам понять, что происходит не так.

Чао!

Было бы лучше создать тест с обычным текстовым полем, поскольку мы видели, что это не вызвано ace.
Существует множество способов преобразования текста в окнах в '\r\n', поэтому в git есть опция autocrlf.
Правильное решение здесь - проверить на сервере, содержит ли файл уже окончания строк Windows, если не преобразовать его в формат linux.

Существует множество способов преобразования текста в окнах в '\r\n', поэтому в git есть опция autocrlf.

Но Windows никоим образом не участвует — сервер — CentOS6, а клиент — Chrome на OS X.

Вместо этого я попытаюсь изменить свой пример на использование скрытого текстового поля и посмотреть, поможет ли это.

Неа. Запустив мою тестовую страницу в OS X с Chrome в OS XI, вы все равно получите символы \r при отправке.

Я вроде как согласен, что это не проблема Эйса, поскольку он доходит до textarea без добавления \r . Но здесь происходит что-то странное, и если мы сможем это выяснить, это станет хорошим пунктом часто задаваемых вопросов для Ace, чтобы у других не было этой проблемы.

Итак, я знаю, что происходит, и я чувствую себя глупо, не зная этого:

Когда вы POST форму, она использует тип MIME application/x-www-form-urlencoded . В соответствии с типами содержимого форм W3 браузер всегда должен кодировать новые строки как \r\n .

Так вот где в дело \r\n . Наверное, я никогда раньше не замечал.

Решение состоит в том, чтобы серверное приложение делало «Правильно» с возвращаемыми данными, что может
включите замену \r\n на \n .

Спасибо, парни. Закрытие этого вопроса. Надеюсь, кто-нибудь с подобной проблемой найдет этот вопрос полезным.