Melhoria no corte de e-mail (sem corte em blocos de código)

Funcionalidade
1

Também abri um problema no GitHub sobre isso, mas queria postar aqui também caso mais pessoas estejam acompanhando:

Acho que seria ótimo se a lógica de corte de e-mail pudesse ser aprimorada para evitar cortes dentro de blocos de código. Por exemplo, em um e-mail contendo:

```
# Isso não deve ser excluído
#
# Ou cortado
# É código
####
Código código código
```

Tudo abaixo do primeiro ‘#’ é cortado. Isso é um pouco inconveniente, pois muitas pessoas usam marcadores de comentário para dividir seções de seu código, às vezes até em strings de várias linhas para impressão. Também tem o recurso conveniente de que, se as pessoas quiserem copiar e colar a saída do programa em um e-mail e essa saída incluir tais linhas, o e-mail não será cortado nelas se a saída do programa estiver entre aspas. Existe alguma chance de que este seja um problema comum o suficiente para que alguém possa ter um momento para ver se ele pode ser aprimorado? Cheguei até a expressão regular onde a correspondência acontece, mas não tenho certeza de quão complexo seria adicionar uma exceção para blocos de código.

Obrigado!

2

Ok, tive que aprender um pouco de Ruby, mas:

Discussão é bem-vinda!

3 curtidas
5

Só para termos certeza de que estamos na mesma página, deixe-me reformular seu problema para que estejamos falando sobre a mesma coisa :wink:

Você quer a capacidade de lidar corretamente com blocos de código cercados em respostas de e-mail, especialmente se eles incluírem o símbolo #, que é frequentemente usado como um delimitador (de assinatura) e, portanto, cortado.

Portanto, se você fosse enviar a seguinte resposta de e-mail

Aqui está o meu patch

```
# Este é um comentário
####

resposta = 42
```

Parece bom?

Ele deveria ser “inteligente” o suficiente para reconhecer que as linhas entre o ``` são código real e, portanto, devem ser “ignoradas” do processamento regular.

Se for esse o caso, eu recomendaria uma solução/abordagem diferente. Pode ser melhor “elevar” todos os blocos de código na função preprocess! e injetá-los de volta depois.

Blocos de código cercados são um tanto difíceis de analisar corretamente usando uma regex, mas para uma solução boa o suficiente, isso deve funcionar

def hoist_code_blocks(text)
  blocks = {}
  pattern = /^```\\w*$\\n.*?^```$/m
  
  text.gsub(pattern) do |block|
    token = SecureRandom.hex
    blocks[token] = block
    token
  end

  [text, blocks]
end

Este método substituirá todos os blocos de código por um valor aleatório e manterá o controle do mapeamento entre o valor aleatório e o conteúdo do bloco no hash blocks.

Você pode chamá-lo assim

text = "algum texto\n```ruby\ndef foo\nend\n```\nmais texto"
new_text, blocks = hoist_code_blocks(text)

E então você pode “restaurar” os blocos de código com o seguinte código

blocks.each { |token, block| new_text.gsub!(token, block) }
6

Obrigado pela resposta! Você entendeu corretamente o problema que estou tendo, sim.

Eu também pensei em fazer algo assim, e ficaria feliz em ter isso implementado se estiver funcionando e corresponder ao comportamento do analisador no navegador o mais próximo possível. Por exemplo, na interface do navegador, é permitido espaço em branco antes da declaração da minha linguagem e espaço em branco após o fechamento:

int x=42;<br>
```         (muitos espaços aqui)

Ainda renderiza corretamente como:
```                    c++
int x=42;

No PR acima, tentei seguir as regras que pude identificar no analisador.

As outras duas perguntas que eu faria sobre sua implementação são se isso realmente deveria ser feito em preprocess!, para que os blocos também tenham que ser passados ou mantidos pela classe EmailReplyTrimmer (e qual seria preferível), e se pode haver um bug lá, porque o text que é retornado lá é o mesmo que o texto original, sem nenhuma substituição feita (aparentemente gsub retorna um enumerador das correspondências, mas você não está realmente fazendo a substituição aqui?).

Em qualquer caso, ficarei feliz se você usar o teste que foi adicionado no meu pull request acima, se você preferir adicionar este código ao analisador você mesmo, ou se você me informar sobre os dois problemas acima, posso criar um novo pull request. Você entendeu o problema perfeitamente, e parece que sua solução está próxima, só não tenho certeza de como você gostaria que fosse finalizada.

Obrigado!

7

Sim, está começando a ficar complicado… É factível, mas sempre haverá casos extremos em comparação com um analisador real.

Você também pode ter mais de 3 \ , sendo 3 o mínimo :wink:

Você também pode fazer isso na função trim, logo após a chamada de preprocess! e fazer a etapa de “pós-processamento” no final.

Certo, aquilo foi principalmente pseudo-código :sweat_smile:

Você provavelmente pode usar gsub! ou fazer text = text.gsub....

8

Ok, ótimo — Abri um novo PR aqui:

Obrigado novamente!

3 curtidas
9

Bumped a versão no Discourse também :up:

3 curtidas
10

Este tópico foi automaticamente fechado após 39 horas. Novas respostas não são mais permitidas.