 |
Resumen | Hacer clic en el área de texto en el compositor seleccionará la línea correspondiente en el panel de vista previa, y viceversa. |
 |
Enlace del Repositorio | https://github.com/thijsbrilleman/discourse-click-to-edit |
 |
Guía de Instalación | Cómo instalar plugins en Discourse |
Hacer clic en el área de texto en el compositor seleccionará la línea correspondiente en el panel de vista previa, y viceversa.
Muy buena adición a la edición principal de Discourse. Gracias por crearlo.
Parece algo que debería ser bienvenido, aunque no tengo voz en eso.
Hola 
Gracias, esto es genial 
Solo estoy pensando que sería increíble convertirlo en un componente temático. 
Gracias, y estoy de acuerdo. Lo investigaré tan pronto como tenga tiempo. Siempre serías bienvenido a presentar una pull request.
Este es actualmente el comportamiento previsto, pero por supuesto estoy abierto a mejores ideas. ¿Qué tipo de indicación visual recomendarías?
Se mostraría como texto pegado cuando algo está realmente seleccionado. Luego habría una acción y una respuesta.
Curioso, ¿por qué esto es un plugin en lugar de un componente de tema? ¿No se pueden generar todos estos tokens del lado del cliente?
Buen trabajo, por cierto, me encanta que te apoyes en los números de línea inyectados por el motor de markdown.
Gracias, Sam.
Como habrás notado, los atributos data-ln también están presentes en el HTML cocido generado y almacenado en el servidor.
Implementé este comportamiento para poder extender el plugin más adelante y permitir la inserción/edición confiable de fragmentos desde la página de vista del tema, equivalente al botón de edición que se muestra a continuación (pero un poco más robusto):
Ha pasado un año desde que lo escribí, pero si mal no recuerdo, para ese fin en plugin.rb la línea
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
es necesaria para asegurar que la extensión MarkdownIt también se ejecute en el servidor al cocinar el HTML.
Sin embargo, no he encontrado el tiempo necesario para implementar la función de edición extendida, así que si ese requisito se elimina, podría convertirse en un componente, supongo.
@sam Estoy investigando cómo convertirlo en un componente temático, pero no puedo averiguar cómo ejecutar este código en el contexto de un plugin de markdownit:
// javascripts/lib/discourse-markdown/initialize_markdownit_plugin.js:
export function setup(helper) {
helper.registerPlugin(markdownitLineNumbers); // markdownitLineNumbers ya está disponible
}
Sospecho que la línea en el plugin que escribí anteriormente también incluye algo de magia del lado del cliente:
# plugin.rb
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
¿Tienes alguna idea?
No estoy seguro, contactaré al equipo.
Creo que esto se debe a que actualmente está restringido solo al ámbito de los plugins. Funcionaría sin esa comprobación. (Este código se introdujo en este commit)
Quería integrar números de línea para otro componente, pero no quería hacer un plugin, así que renuncié a ello. ¡Sería genial si las características de markdown pudieran ser compatibles con los componentes de temas!
Por cierto, una gran característica que propusiste aquí – muy bien. 
Ah sí, esto lo aclara.
Mirando este código, podría ser posible inyectar manualmente el plugin de markdown del componente temático en tiempo de ejecución, pero sería bastante improvisado. Esperaré el veredicto del equipo principal antes de intentar implementarlo.
Nuestro pipeline de markdown se ejecuta tanto en el cliente (para vista previa) como en el servidor (para pre-renderizar el HTML de las publicaciones). Por eso está diseñado solo para plugins; son los únicos que pueden inyectar código en el lado del servidor.
Ahora… este caso es bastante inusual, ya que la extensión solo se necesita en el compositor y no en el servidor. Por lo tanto, hacerlo desde un componente temático debería ser factible.
¿Tenías alguna estrategia en particular en mente para esto?
Esto parece algo que tendría un gran atractivo. Puede ser difícil encontrar tu lugar en una publicación larga. ¿Podría ser pr-welcome?
Anula esta función en el código base original:
// 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 inicializador de componente de tema:
export default {
name: "d-editor-cached-cook-async-override",
initialize() {
const dEditor = require("discourse/components/d-editor").default;
dEditor.reopen({
cachedCookAsync(text, options) {
// duplica el código aquí para devolver una función de cocción alterada
},
});
},
};
Significaría una gran cantidad de duplicación de código, si es que funcionara. Sucio, sucio.
Hmm sí, de acuerdo, definitivamente no es ideal. Duplicar el código podría ni siquiera ser posible, porque los módulos de markdown-it se cargan de forma asíncrona y no forman parte del sistema de módulos amd al que los temas/plugins tienen acceso directo. 
Construir un sistema para permitir que los temas contribuyan con transformaciones de md solo del lado del cliente podría ser genial, aunque los casos de uso son bastante limitados. En el 99% de los casos, la gente quiere que las transformaciones de md se apliquen también del lado del servidor.
Así que creo que, por ahora, seguir con un plugin es probablemente el mejor enfoque.
Me pregunto si este tipo de decoración debería aplicarse de todos modos.
Por ejemplo:
<p data-source-line="0">.....</p>
El atributo de datos adicional ayudará a muchas implementaciones internas que tenemos, como, por ejemplo, no mostrar el autocompletado cuando estás dentro de un bloque de código. También las citas y la edición rápida se vuelven mucho más fáciles.
La implementación trivial casi no conlleva peso adicional, pero nos permite eliminar un montón de código fuente.
Ya tuvimos esto en el pasado (detrás de una bandera), pero se eliminó en este commit. Encontré esta captura de pantalla de algunas discusiones internas sobre esa característica:
es decir, el problema de rendimiento estaba en el código de sincronización del desplazamiento, no en la inyección de los números de línea 
Así que sí, no tengo objeciones a agregar la inyección de data-source-line en el núcleo, siempre y cuando solo se agregue en la vista previa. ¿Estarías interesado en crear un PR para esto, @pipkin?
¡Con mucho gusto! Me alegra poder devolver algo a ustedes.
