Ho anche aperto una issue su GitHub riguardo a questo, ma volevo postarla anche qui nel caso in cui più persone la stessero seguendo:
Penso sarebbe fantastico se la logica di “trimming” delle email potesse essere migliorata per evitare di tagliare all’interno dei blocchi di codice. Quindi, ad esempio, in un’email contenente:
```
# Questo non dovrebbe essere cancellato
#
# O tagliato
# È codice
####
Codice codice codice
```
Tutto ciò che si trova sotto il primo ‘#’ viene tagliato. Questo è un po’ scomodo, poiché molte persone usano i marcatori di commento per separare sezioni del loro codice, a volte anche in stringhe multi-linea per la stampa. Ha anche la comoda caratteristica che se le persone vogliono copiare e incollare l’output di un programma in un’email e quell’output include tali righe, l’email non verrà tagliata in corrispondenza di esse se l’output del programma è racchiuso tra apici. C’è qualche possibilità che questo sia un problema abbastanza comune da far sì che qualcuno abbia un momento per vedere se può essere migliorato? Sono arrivato fino all’espressione regolare dove avviene il matching, ma non sono sicuro di quanto sarebbe complesso aggiungere un’eccezione per i blocchi di codice.
Per essere sicuri di essere sulla stessa pagina, riformulo il tuo problema in modo che stiamo parlando della stessa cosa ;)\n\nVuoi la possibilità di gestire correttamente i blocchi di codice recintati nelle risposte email, specialmente se includono il simbolo #, che è spesso usato come delimitatore (di firma) e quindi viene tagliato.\n\nQuindi, se dovessi inviare la seguente risposta email\n\n\nEcco la mia patch\n\n```\n# Questo è un commento\n####\n\nanswer = 42\n```\n\nVa bene?\n\n\nDovrebbe essere abbastanza "intelligente" da riconoscere che le righe tra ``` sono codice effettivo e quindi dovrebbero essere "ignorate" dall’elaborazione normale.\n\nSe è così, consiglierei una soluzione / approccio diverso. Potrebbe essere meglio sollevare tutti i blocchi di codice nella funzione preprocess! e iniettarli nuovamente in seguito.\n\nI blocchi di codice recintati sono piuttosto difficili da analizzare correttamente usando un regex, ma per una soluzione sufficientemente buona, questo dovrebbe funzionare\n\nruby\ndef hoist_code_blocks(text)\n blocks = {}\n pattern = /^\w*\\n.*?^```/m\n \n text.gsub(pattern) do |block|\n token = SecureRandom.hex\n blocks[token] = block\n token\n end\n\n [text, blocks]\nend\n\n\nQuesto metodo sostituirà tutti i blocchi di codice con un valore casuale e terrà traccia della mappatura tra il valore casuale e il contenuto del blocco nell'hash `blocks`.\n\nPuoi chiamarlo così\n\nruby\ntext = "some text\nruby\\ndef foo\\nend\\n\nmore text"\nnew_text, blocks = hoist_code_blocks(text)\n\n\nE poi puoi \"ripristinare\" i blocchi di codice con il seguente codice\n\nruby\nblocks.each { |token, block| new_text.gsub!(token, block) }\n```
Grazie per la risposta! Hai compreso correttamente il problema che sto riscontrando, sì.
Ho pensato anch’io di fare qualcosa del genere e sono felice che venga implementato se funziona e corrisponde il più fedelmente possibile al comportamento del parser nel browser. Ad esempio, nell’interfaccia del browser mi è consentito uno spazio bianco prima della dichiarazione della lingua e uno spazio bianco dopo la chiusura:
int x=42;<br>
``` (molti spazi qui)
Viene ancora correttamente visualizzato come:
``` c++
int x=42;
Nel PR sopra ho cercato di seguire le regole che potevo identificare nel parser.
Le altre due domande che vorrei porre sulla tua implementazione sono se questo debba essere fatto in preprocess!, in modo che i blocchi debbano anche essere passati o mantenuti dalla classe EmailReplyTrimmer (e quale sarebbe preferibile), e se potrebbe esserci un bug lì, perché il text che viene restituito lì è lo stesso del testo originale, senza sostituzioni effettuate (apparentemente gsub restituisce un enumeratore delle corrispondenze, ma in realtà non stai facendo la sostituzione qui?).
In ogni caso, sono felice che tu possa usare il test che è stato aggiunto nel mio pull request sopra se preferisci aggiungere questo codice al parser tu stesso, o se mi comunichi i problemi sopra citati posso creare un nuovo pull request. Hai assolutamente capito il problema, e sembra che la tua soluzione sia vicina, solo non sono sicuro di come vorresti che venisse finalizzata.
