Ace: Não é possível fazer o ACE detectar ou usar novas linhas do unix

Criado em 12 jul. 2013  ·  10Comentários  ·  Fonte: ajaxorg/ace

Oi!

Eu uso o GitLab e ao usar o ACE para editar arquivos no git, ele continua salvando com novas linhas no estilo do Windows.

Isso torna o histórico do git quase inútil, além de quebrar coisas que não sabem o que fazer com o caractere \r (por exemplo, Augeas). Veja gitlabhq/gitlabhq#3982 para o histórico.

Eu sei que é ACE, mas não sei por que está acontecendo.

Eu tentei (através do console no chrome) coisas como:

  • editor.session.setNewlineMode('unix')
  • editor.session.getDocument().setNewlineMode('unix')

... mas ainda o envia de volta ao GitLab com \r\n como final da linha.

Eu li os documentos da API e pesquisei um monte, mas não consigo encontrar uma solução para esse problema.

Isso é um bug no ACE ou o gitlab está usando mal o ACE?

Tchau!

Comentários muito úteis

Ok, então eu sei o que está acontecendo e me sinto estúpido por não saber disso:

Quando você POST um formulário, ele usa o tipo MIME application/x-www-form-urlencoded . De acordo com os tipos de conteúdo do formulário W3, um navegador deve sempre codificar novas linhas como \r\n .

Então é aí que o \r\n está chegando. Acho que nunca notei antes.

A solução é fazer com que o aplicativo do servidor faça a "coisa certa" com os dados que voltam, o que pode
inclua a substituição \r\n por \n .

Obrigado rapazes. Fechando este assunto. Espero que alguém com um problema semelhante ache este problema útil.

Todos 10 comentários

Oi

Eu acho altamente improvável que isso seja um problema com ace.
Você pode testá-lo com o seguinte 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

também seria útil se você pudesse fornecer um URL para a página de exemplo onde eu pudesse tentar reproduzir o problema

Infelizmente, nosso gitlab é privado.

Não sei o que mais pode ser porque sai do servidor sem \r mas os tem quando volta.

Quando eu chegar em casa, verei como executar seu código de teste.

Resultados do seu código:

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

E quando eu salvo, ele é recebido pelo Rails como contendo \r\n para EOL.

Eu ainda estou cutucando isso, mas isso está me deixando louco.

procure o código que carrega o arquivo
ou ele substitui \n por \r\n ou o navegador faz isso automaticamente.

Aqui está o código que coloca o texto em um campo oculto para upload:

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

Não está fazendo nada para alterar os finais de linha. Por que um navegador faria essa mudança?

Ok, criei um exemplo de gist com um arquivo php que demonstra o erro.

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

Espero que isso nos ajude a descobrir o que está acontecendo de errado.

Tchau!

Seria melhor criar um teste com textarea regular, já que vimos que não é causado por ace.
Existem muitas maneiras pelas quais o texto nas janelas pode ser convertido para '\r\n', é por isso que o git tem a opção autocrlf.
A solução certa aqui é verificar no servidor se o arquivo já contém terminações de linha do Windows, se não convertê-lo para o formato linux.

Existem muitas maneiras pelas quais o texto nas janelas pode ser convertido para '\r\n', é por isso que o git tem a opção autocrlf.

Mas o Windows não está envolvido de forma alguma - o servidor é o CentOS6 e o ​​cliente é o Chrome no OS X.

Vou tentar mudar meu exemplo para usar uma área de texto oculta e ver se isso ajuda.

Não. Executando minha página de teste no OS X com o Chrome no OS XI ainda recebo os caracteres \r no envio.

Eu meio que concordo que não é problema do Ace, já que ele chega ao textarea sem \r ser adicionado. Mas algo estranho está acontecendo aqui e se conseguirmos descobrir, será um bom item de FAQ para Ace para que outros não tenham esse problema.

Ok, então eu sei o que está acontecendo e me sinto estúpido por não saber disso:

Quando você POST um formulário, ele usa o tipo MIME application/x-www-form-urlencoded . De acordo com os tipos de conteúdo do formulário W3, um navegador deve sempre codificar novas linhas como \r\n .

Então é aí que o \r\n está chegando. Acho que nunca notei antes.

A solução é fazer com que o aplicativo do servidor faça a "coisa certa" com os dados que voltam, o que pode
inclua a substituição \r\n por \n .

Obrigado rapazes. Fechando este assunto. Espero que alguém com um problema semelhante ache este problema útil.

Esta página foi útil?
0 / 5 - 0 avaliações