Verbesserung beim E-Mail-Trimming (kein Trimmen in Codeblöcken)

Merkmal
1

Ich habe auch ein GitHub-Problem dazu eröffnet, wollte es aber auch hier posten, falls mehr Leute zuschauen:

Ich denke, es wäre großartig, wenn die Logik zum Kürzen von E-Mails verbessert werden könnte, um das Kürzen innerhalb von Codeblöcken zu vermeiden. Zum Beispiel in einer E-Mail, die Folgendes enthält:

```
# Dies sollte nicht gelöscht werden
#
# Oder gekürzt werden
# Es ist Code
####
Code Code Code
```

Alles unter dem ersten ‘#’ wird gekürzt. Das ist etwas unpraktisch, da viele Leute Kommentarzeichen verwenden, um Abschnitte ihres Codes zu unterteilen, manchmal sogar in mehrzeiligen Zeichenketten zum Drucken. Es hat auch die praktische Funktion, dass, wenn Leute Programm-Ausgaben per Copy-Paste in eine E-Mail einfügen und diese Ausgaben solche Zeilen enthalten, die E-Mail an diesen Stellen nicht gekürzt wird, wenn die Programm-Ausgabe in Anführungszeichen eingeschlossen ist. Besteht die Chance, dass dies ein häufig genug auftretendes Problem ist, dass jemand einen Moment Zeit hat, um zu sehen, ob es verbessert werden könnte? Ich bin bis zum Regex gekommen, wo das Matching stattfindet, aber ich bin mir nicht sicher, wie komplex das Hinzufügen einer Ausnahme für Codeblöcke wäre.

Danke!

2

Ok, ich musste ein wenig Ruby lernen, aber:

Diskussion ist willkommen!

3 „Gefällt mir“
5

Damit wir uns richtig verstehen, lasse ich Sie das Problem noch einmal mit meinen Worten formulieren :wink:

Sie möchten die Möglichkeit haben, eingefasste Codeblöcke in E-Mail-Antworten korrekt zu behandeln, insbesondere wenn sie das #-Symbol enthalten, das oft als (Signatur-)Trennzeichen verwendet und daher abgeschnitten wird.

Wenn Sie also die folgende E-Mail-Antwort senden würden

Hier ist mein Patch

```
# Das ist ein Kommentar
####

Antwort = 42
```

Sieht es gut aus?

sollte es “clever” genug sein, zu erkennen, dass die Zeilen zwischen den ``` tatsächlicher Code sind und daher von der regulären Verarbeitung “ignoriert” werden sollten.

Wenn das der Fall ist, würde ich eine andere Lösung / einen anderen Ansatz empfehlen. Es wäre vielleicht besser, alle Codeblöcke in der Funktion preprocess! zu heben und sie danach wieder einzufügen.

Eingefasste Codeblöcke sind mit einem Regex etwas schwer korrekt zu parsen, aber für eine ausreichend gute Lösung sollte dies funktionieren

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

Diese Methode ersetzt alle Codeblöcke durch einen zufälligen Wert und speichert die Zuordnung zwischen dem zufälligen Wert und dem Inhalt des Blocks im blocks-Hash.

Sie können sie wie folgt aufrufen

text = "etwas Text\n```ruby\ndef foo\nend\n```\nmehr Text"
new_text, blocks = hoist_code_blocks(text)

Und dann können Sie die Codeblöcke mit dem folgenden Code “wiederherstellen”

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

Danke für die Antwort! Sie haben das Problem, das ich habe, richtig verstanden, ja.

Ich habe auch darüber nachgedacht, so etwas zu tun, und ich bin froh, wenn das implementiert wird, wenn es funktioniert und dem Verhalten des In-Browser-Parsers so genau wie möglich entspricht. Zum Beispiel erlaube ich im Browser-Interface Leerzeichen vor meiner Sprachdeklaration und Leerzeichen nach meinem Abschluss:

int x=42;<br>
```         (viele Leerzeichen hier)

Im obigen PR habe ich versucht, die Regeln zu befolgen, die ich im Parser identifizieren konnte.

Die anderen beiden Fragen, die ich zu Ihrer Implementierung stellen würde, sind, ob dies wirklich in `preprocess!` geschehen sollte, sodass die Blöcke auch weitergegeben oder von der Klasse `EmailReplyTrimmer` gehalten werden müssen (und was bevorzugt würde), und ob es dort möglicherweise einen Fehler gibt, da der zurückgegebene `text` derselbe ist wie der ursprüngliche Text, ohne dass Ersetzungen vorgenommen wurden (scheinbar gibt `gsub` einen Enumerator der Übereinstimmungen zurück, aber Sie führen die Ersetzung hier nicht tatsächlich durch?).

Auf jeden Fall freue ich mich, wenn Sie den Test verwenden, der in meinem obigen Pull-Request hinzugefügt wurde, wenn Sie es vorziehen, diesen Code selbst zum Parser hinzuzufügen, oder wenn Sie mir die oben genannten Probleme mitteilen, kann ich einen neuen Pull-Request erstellen. Sie haben das Problem absolut richtig erfasst, und es sieht so aus, als ob Ihre Lösung nahe dran ist. Ich bin nur nicht ganz sicher, wie Sie es beenden möchten.

Danke!
7

Ja, es wird langsam kompliziert… Es ist machbar, aber es wird immer Ausnahmefälle geben, im Gegensatz zu einem echten Parser.

Sie können auch mehr als 3 ` haben, 3 ist das Minimum :wink:

Sie können es auch in der trim-Funktion machen, direkt nach dem Aufruf von preprocess! und den “postprocess”-Schritt gegen Ende.

Stimmt, das war hauptsächlich Pseudocode :sweat_smile:

Sie können wahrscheinlich gsub! verwenden oder text = text.gsub... tun.

8

Ok, super – ich habe hier einen neuen PR geöffnet:

Nochmal vielen Dank!

3 „Gefällt mir“
9

Die Version in Discourse wurde ebenfalls hochgestuft :up:

3 „Gefällt mir“
10

Dieses Thema wurde nach 39 Stunden automatisch geschlossen. Neue Antworten sind nicht mehr möglich.