I miei utenti hanno iniziato subito a lamentarsi di una cosa fastidiosa. Smettono di scrivere subito quando hanno bisogno, diciamo, di mettere in grassetto qualcosa, toccano due volte una parola, cliccano su B e continuano a scrivere. Certo, un nuovo tocco su B interrompe l’uso del grassetto — e dare uno spazio, una virgola, una nuova parola, qualunque cosa non scegliere prima di mettere in grassetto, fa il trucco.
Lontano da quello principale, però.
Per iniziare, questo sembra davvero carino!
Tuttavia, vorrei aggiungere un mattone al piccolo muro di commenti dicendo che si dovrebbe sempre avere la possibilità di tornare alla modalità di input “raw”. Forse sono vecchio stile 
E un piccolo bug report (una specie di atteso, ma vale la pena segnalarlo): Nella nuova modalità, hai opzioni limitate per modificare il tuo testo con un prompt che si concentra sulla formattazione:
Ohh la quantità di dibattito filosofico che quel commento copre 
Ottimo! Molti utenti trovano Discourse “troppo tecnico” e penso che l’editor WYSIWYG possa aiutare molto!
Quindi ora “basta” implementare il compositore WYSIWYG per diagrammi Mermaid!
Oppure, se è troppo difficile, penso che questo sia l’unico che non si limita a rendere colorato il blocco di codice, ma visualizza effettivamente qualcosa di completamente diverso. La vista a due lati funziona bene lì. Penso che dovrebbe funzionare all’interno dell’editor, senza la necessità di passare al vecchio modo. Non sono sicuro di come, però.
Questo va un po’ più in là nel futuro di quanto abbiamo pianificato. Penso che sia probabile che offriremo una preferenza utente per abilitare l’opzione Markdown, ma al momento non è scolpito nella pietra. Apprezzo comunque la tua opinione, è un input utile.
È una funzionalità sperimentale, quindi procedi a tuo rischio e pericolo. Ti chiediamo gentilmente di condividere qui qualsiasi feedback per tenere tutto in un unico posto per noi, questo ci renderà la vita molto più facile
Non riesco a riprodurre questo problema. La mia bozza viene salvata quando faccio clic su un collegamento. Tuttavia, lavoreremo su un’interfaccia utente per i collegamenti (vedi la sezione 
Funzionalità mancanti) in modo che dovrebbe aiutare a capire come modificare il collegamento.
Capisco il problema che descrivi, ma non sono sicuro di cosa fare al riguardo. Ho testato questo scenario su Google Docs e Notion, ed entrambi hanno la stessa esperienza (cioè, dopo aver evidenziato una parola e attivato il grassetto, tutte le parole che digiti dopo aver spostato il cursore da quella parola sono anch’esse in grassetto). Penso che questa sia solo una conseguenza dell’uso di un editor di testo rich e dell’impossibilità di vedere chiaramente dove finisce la formattazione.
Le scorciatoie da tastiera (CMD+B) sono disponibili e la scrittura in Markdown funziona ancora, se questo può essere d’aiuto. Continuerò comunque a pensarci per vedere se c’è una soluzione migliore. Come Obsidian gestisce la modifica mi viene in mente, ma non sarebbe semplice per noi realizzarlo in questo momento.
I diagrammi Mermaid potrebbero essere un po’ più avanti nel percorso, ma prendo nota del tuo interesse e lo aggiungo come Funzionalità mancante.
Ho registrato il feedback sulla rimozione dei titoli 
Posso riprodurlo con i onebox inline, ci darò un’occhiata oggi, giusto per evitare di navigare via finché non lavoriamo sull’interfaccia utente per passare dai collegamenti ai onebox.
Ho provato a copiare i messaggi della chat in un argomento.
Passare a markdown ha risolto il problema, quindi al momento non è un problema grave.
Le citazioni/trascrizioni della chat non sono ancora supportate, ma ci stiamo lavorando.
Una cosa che ho notato è che il doppio tocco della barra spaziatrice su iOS e macOS a volte non crea un punto fermo (periodo) come dovrebbe, in modalità WYSIWYG.
In origine avevo scritto che non lo fa mai, ma me l’ha appena fatto. Quindi sembra un bug? Qualcun altro può confermare?
Sembra un grande miglioramento per noi non tecnici, team di Discourse. Grazie
Ho notato che se inizio una riga con quattro spazi, questa viene automaticamente trasformata in codice (e poi il grassetto e il corsivo non funzionano più).
Leggerà gli spazi come caratteri effettivi se ne uso fino a tre all’inizio? Comunque, non abbastanza per il mio caso d’uso. modifica: non considera gli spazi come caratteri.
C’è un modo per far funzionare il tasto Tab come fa in Google Docs e Word? O per usare tutti gli spazi che voglio senza perdere le opzioni di formattazione? Questo sarebbe particolarmente speciale quando si incolla del testo da un file Docs, ad esempio, in modo che assomigli di più a come appariva nella versione originale.
Inoltre, questa sembra una buona idea:
Inoltre, di solito non uso i colori, ma potrei vederne l’importanza per alcune persone. Pensi che ci arriverai?
Questo è tutto da parte mia. Grazie ancora!
Stiamo solo cercando di essere coerenti con l’aspetto che avrà quando pubblicherai il post: una riga iniziata con 4 spazi verrà convertita in un blocco di codice quando il post verrà pubblicato.
Non proprio, no. Alla fine stiamo ancora costruendo un Markdown “abbellito” per poi trasformarlo in HTML, quindi solo le cose che possono già essere fatte con la nostra attuale elaborazione Markdown→HTML saranno supportate in questo nuovo editor.
Abbiamo l’opportunità di creare nuovi tipi di contenuto, ovviamente, ma dovranno essere supportati anche tramite Markdown grezzo, poiché questa è la nostra fonte di verità.
Mi sto divertendo molto con il nuovo composer!
Un’abitudine che devo cambiare è che non posso più usare semplicemente shift-su o shift-giù per selezionare il paragrafo corrente su cui mi trovo. Non mi ero reso conto di quanto spesso lo facessi, ma lo faccio continuamente, per cancellare del testo o selezionarlo e spostarlo.
Ora devo usare shift-sinistra o shift-destra (o shift-cmd-sinistra o shift-cmd-destra) per selezionare l’ultima parte del testo sulla riga superiore o inferiore. Se ha senso. Altrimenti inizia a selezionare il paragrafo successivo.
Penso che questo sia un passo avanti per gli utenti non tecnici! Anche se, come @Canapin, mi ci vorrà un po’ di tempo per abituarmi al cambiamento 
. Sarebbe sicuramente apprezzato un interruttore per passare rapidamente dalla modalità Markdown alla modalità WYSIWYG.
Come altri hanno notato, l’area di modifica sul desktop potrebbe essere un po’ più larga. E ho anche riscontrato il problema di non poter tornare al testo normale una volta inserito un titolo - forse renderizzarlo solo una volta completata la riga e premuto Invio è un’opzione? (Apprezzerei non dover usare il mouse per annullare questo, e sembra anche coerente con il modo in cui altri tag vengono renderizzati solo una volta completati)
In aggiunta:
Non riesco a creare elenchi multilivello
Non sono sicuro di come potrei indentare il codice in un blocco di codice
Il contrasto del menu a discesa della lingua per i blocchi di codice è un po’ basso (screenshot qui sotto) - l’ho perso all’inizio
L’inserimento di tabelle come markdown non sembra funzionare (quando una tabella è stata creata nel vecchio editor, viene renderizzata correttamente)
Quando una tabella è seguita da un altro elemento di blocco (come una citazione), non è possibile inserire una nuova riga dopo la tabella
Sembra che non ci sia supporto per le note a piè di pagina (penso che ci sia anche un bug con le note a piè di pagina nel vecchio editor - se provo a creare le note a piè di pagina 1 e 2, solo la prima viene renderizzata correttamente)
Se incollo un’immagine dagli appunti, non sono sicuro di come creare il testo alternativo, né saprei come cambiare le dimensioni dell’immagine.
Mi piace molto il modo in cui funzionano gli elenchi multilivello. Inizia semplicemente inserendo il markdown come al solito e inizierà automaticamente il tuo primo punto elenco. Quindi premi Invio per crearne un altro. Premi Tab per indentare. Elimina per cambiare da punto elenco a numero, ecc. Premi Maiusc+Tab per creare un altro punto elenco.
Ok, grazie! Suppongo di non averci provato a causa della cosa del blocco di codice e perché non funziona nel vecchio editor. Ma ha senso il modo in cui funziona nel nuovo editor.
Mi ricorda: in realtà sarebbe bello se gli elenchi numerati ciclassero attraverso simboli diversi (ad esempio, primo livello = numeri, secondo livello = caratteri minuscoli, terzo livello = numeri romani, quarto livello = caratteri maiuscoli). Ma presumo che questo non sia in discussione perché non fa parte delle specifiche CommonMark o GFM?
Ho usato il nuovo composer alcune volte di recente e non mi sono nemmeno ricordato e accorto che ora fosse WISYWIG; intendo dire che mi è stato così naturale usarlo che non ci ho pensato mentre scrivevo 
come se il composer fosse sempre stato così, anche se non era così.
Non mi è nemmeno dispiaciuto affatto lo spazio ristretto della finestra. 
Un’esperienza davvero fluida, e non ho riscontrato bug, ma il mio utilizzo è stato solo di contenuti di base (testo, citazioni, formattazione standard).
Non so se sia ancora così anche con il composer normale, ma prima l’anteprima era quasi identica al post definitivo. Ricordo di essermi lamentato un po’ un po’ di tempo fa perché la larghezza dell’anteprima era leggermente diversa dalla larghezza di un post, il che rendeva l’anteprima non esattamente identica al contenuto pubblicato.
Ora, non sono sicuro che mi lamenterei se il composer fosse più largo di un post, se fosse più comodo da usare di prima. 
Ok, questo è un buon punto! Avere il contenuto pubblicato corrispondente al contenuto modificato minimizzerebbe certamente l’attrito.
In questo caso, penso che preferirei che il contenuto modificato fosse sullo stesso asse visivo del contenuto pubblicato.
Beh, questo non è un mezzo di stampa, quindi il contenuto pubblicato non è (quasi) identico per tutti.
Ho iniziato a lavorarci ieri, spero non sia troppo complicato e che possiamo avere qualcosa presto…
Quella citazione nella chat non è un grosso problema perché riguarda principalmente i moderatori e gli amministratori, che sanno come tornare al vecchio sistema.
La funzione nota a piè di pagina è più importante.
A dire il vero, quella era solo la mia opinione, e davvero non so come vanno le cose là fuori.
È divertente. I miei utenti si lamentavano del markdown e della mancanza di WYSIWYG prima. Ora, nessuno di loro si è ancora passato al nuovo sistema. Quasi capisco perché. Quasi tutti usano mobile e in realtà si lamentavano delle immagini e non vedevano nient’altro che markdown.
Non usano altro, e torniamo alla mia vecchia affermazione: abbiamo bisogno di uno strumento per nascondere e mostrare la toolbar. Gli utenti comuni sono abituati allo stile dei social media dove scrivono solo testo, lo inviano, e basta. E dato che Discourse offre, più o meno, questa possibilità, non hanno incentivi a cambiare o a provare il nuovo sistema. Tranne vedere le immagini nel compositore, ma il mio forum non è così ricco di immagini.
Le persone comuni potrebbero avere un’altra storia, ma non sanno di quella magia di passaggio.
