 |
Riepilogo | Fare clic nell’area di testo nell’editor selezionerà la riga corrispondente nel riquadro di anteprima e viceversa. |
 |
Link al Repository | \u003chttps://github.com/thijsbrilleman/discourse-click-to-edit\u003e |
 |
Guida all’Installazione | Come installare plugin in Discourse |
Fare clic nell’area di testo nell’editor selezionerà la riga corrispondente nel riquadro di anteprima e viceversa.
Ottima aggiunta all’editing di base di Discourse. Grazie per averla creata.
Sembra qualcosa che dovrebbe essere accolto con favore, anche se non ho voce in capitolo in merito.
Ciao 
Grazie, questo è davvero fantastico 
Stavo solo pensando che sarebbe fantastico renderlo un componente tematico. 
Non funziona molto bene su iPad, perché seleziona tutto il testo durante la scrittura. Sembra molto strano.
Grazie, e sono d’accordo. Ci darò un’occhiata non appena avrò tempo. Saresti sempre il benvenuto a presentare una pull request.
Questo è attualmente il comportamento previsto, ma sono ovviamente aperto a idee migliori. Che tipo di indicatore visivo consiglieresti?
Si mostrerebbe come testo incollato quando qualcosa è veramente selezionato. Poi ci sarebbe un’azione e una risposta.
Curioso, perché questo è un plugin e non un componente del tema? Tutti questi token possono essere generati lato client, no?
Bel lavoro comunque, adoro il fatto che ti basi sui numeri di riga iniettati dal motore di markdown.
Grazie Sam.
Come potresti aver notato, gli attributi data-ln sono presenti anche nell’html cotto generato e memorizzato sul server.
Ho implementato questo comportamento, in modo che in seguito potrei estendere il plugin per consentire l’inserimento/modifica affidabile di frammenti dalla pagina di visualizzazione dell’argomento, equivalente al pulsante di modifica mostrato di seguito (ma un po’ più robusto):
È passato un anno da quando l’ho scritto, ma se ricordo bene, a tal fine in plugin.rb la riga
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
è richiesta per assicurarsi che l’estensione MarkdownIt venga eseguita anche lato server durante la cottura dell’html.
Tuttavia, non ho trovato il tempo necessario per implementare la funzionalità di modifica estesa, quindi se quel requisito viene eliminato, si potrebbe convertirlo in un componente, immagino.
@sam Sto investigando la conversione in un componente tematico, ma non riesco a capire come eseguire questo codice nel contesto di un plugin markdownit:
// javascripts/lib/discourse-markdown/initialize_markdownit_plugin.js:
export function setup(helper) {
helper.registerPlugin(markdownitLineNumbers); // markdownitLineNumbers già disponibile
}
Ho il sospetto che la riga nel plugin che ho scritto in precedenza spruzzi anche un po’ di magia lato client:
# plugin.rb
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
Hai qualche idea?
Non sono sicuro, contatterò il team.
Credo che ciò sia dovuto al fatto che attualmente è limitato solo all’ambito dei plugin. Funzionerebbe senza quel controllo. (Questo codice è stato introdotto in questo commit)
Volevo integrare i numeri di riga per un altro componente, ma non volevo creare un plugin, quindi ci ho rinunciato. Sarebbe fantastico se le funzionalità markdown potessero essere supportate nei componenti del tema!
A parte questo, un’ottima funzionalità che hai proposto qui: molto bella. 
Ah sì, questo chiarisce le cose.
Guardando questo codice, potrebbe essere possibile iniettare manualmente il plugin markdown dal componente del tema al runtime, ma sarebbe piuttosto macchinoso. Attenderò il verdetto dal team principale prima di provare a implementarlo.
La nostra pipeline markdown viene eseguita sia sul client (per l’anteprima) che sul server (per il pre-rendering dell’HTML dei post). Ecco perché è progettata solo per i plugin: sono gli unici che possono iniettare codice lato server.
Ora… questo caso è piuttosto insolito, poiché l’estensione è necessaria solo nel composer e non sul server. Quindi, farlo da un componente del tema dovrebbe essere fattibile.
Avevi in mente una strategia particolare per questo?
Sembra qualcosa che avrebbe un ampio appeal. Può essere difficile trovare il proprio posto in un post lungo. Potrebbe essere pr-welcome?
Sovrascrivi questa funzione nel codebase originale:
// discourse/app/assets/javascripts/discourse/app/components/d-editor.js
async cachedCookAsync(text, options) {
this._cachedCookFunction ||= await generateCookFunction(options || {});
return await this._cachedCookFunction(text);
}
con un inizializzatore di componente tema:
export default {
name: "d-editor-cached-cook-async-override",
initialize() {
const dEditor = require("discourse/components/d-editor").default;
dEditor.reopen({
cachedCookAsync(text, options) {
// codice duplicato qui per restituire una funzione di cottura alterata
},
});
},
};
Significherebbe un bel po’ di duplicazione di codice, se funzionasse almeno. Sporco, sporco.
Hmm sì, sono d’accordo - decisamente non ideale. Duplicare il codice potrebbe anche non essere possibile, perché i moduli markdown-it vengono caricati in modo asincrono e non fanno parte del sistema di moduli amd a cui temi/plugin hanno accesso diretto. 
Costruire un sistema per consentire ai temi di contribuire con trasformazioni md solo lato client potrebbe essere interessante, anche se i casi d’uso sono piuttosto limitati. Nel 99% dei casi, le persone vogliono che le trasformazioni md si applichino anche lato server.
Quindi penso che, per ora, attenersi a un plugin sia probabilmente l’approccio migliore.
Mi chiedo se questo tipo di decorazione dovrebbe essere applicato comunque?
Ad esempio:
<p data-source-line="0">.....</p>
L’attributo data aggiuntivo aiuterà molte implementazioni interne che abbiamo, come, ad esempio, non mostrare l’autocompletamento quando ci si trova all’interno di un blocco di codice. Anche la citazione e la modifica rapida diventano molto più facili.
L’implementazione banale comporta quasi nessun peso aggiuntivo, ma ci permette di eliminare un mucchio di codice sorgente.
L’abbiamo avuto in passato (dietro una flag), ma è stato rimosso in questo commit. Ho trovato questo screenshot da alcune discussioni interne su quella funzionalità:
cioè il problema di prestazioni riguardava il codice di sincronizzazione dello scorrimento, non l’iniezione dei numeri di riga 
Quindi sì, non ho obiezioni ad aggiungere l’iniezione del data-source-line nel core, purché venga aggiunta solo in anteprima. Ti interesserebbe creare una PR per questo @pipkin?
Volentieri! Sono felice di poter ricambiare qualcosa a voi ragazzi.
