Ir al contenido

Linter

El plugin Linter mantiene el markdown de una raíz en una sola forma: reglas que la raíz acuerda, ejecutadas en cada archivo markdown que escribe la CLI, e informadas por eidos check para los archivos que se desviaron de todos modos. El bloque de frontmatter, cada región que posee una herramienta y cada bloque de código cercado se dejan byte a byte; las reglas cambian la forma, nunca el significado. Activado por defecto, escribe las reglas con sus valores por defecto la primera vez que se ejecuta; eidos plugin disable linter lo desactiva.

Cada una es un ajuste compartido, así que todas las máquinas y agentes aplican lo mismo:

Regla Por defecto Qué hace
trailing-whitespace activa Se quitan los espacios y tabuladores al final de una línea; hard-breaks (inactiva) conserva un salto duro de dos espacios
final-newline activa Exactamente un salto de línea termina el archivo
blank-lines activa Las líneas en blanco consecutivas se reducen a una, y ninguna abre el archivo
heading-blank-lines, code-blank-lines activas Una línea en blanco antes y después de cada encabezado y cada bloque cercado
single-h1 activa Un encabezado #; un segundo se rebaja a ##
heading-levels activa Ningún nivel saltado
heading-punctuation activa Se quita un ., ,, ; o : final de un encabezado
list-marker - Un marcador para cada lista sin orden: -, *, + u off
ordered-lists ascending 1. 2. 3., u one para 1. 1. 1., u off
emphasis-style _ _énfasis_, o *, u off; un guion bajo dentro de una palabra nunca se toca
strong-style ** **negrita**, o __, u off
bare-urls activa Una URL http suelta se envuelve en <>
tabs activa Un tabulador en prosa se convierte en cuatro espacios

Los valores por defecto son lo que escriben las semillas del estándar.

Con el plugin activo, cada archivo markdown que escribe la CLI pasa por las reglas activas, y el frontmatter de un Blueprint (plano) toma las reglas al guardar: un Blueprint (plano) o un documento de nivel superior guardado desde la página, eidos property set, la escritura de un plugin a través del anfitrión (la proyección de Comments). Una escritura que evita la CLI (tu editor, git) no pasa por el linter, que es para lo que está la comprobación. Un archivo de tarea es una escritura propia de Backlog y no pasa por el linter en esta versión. Nada pasa por el linter al leer.

Las reglas al guardar son del Linter. Cada una nombra una propiedad de tipo Date o Date & time y la pone en la fecha de hoy o en la hora cada vez que se guarda un Blueprint (plano): desde la página, con eidos property set o con la escritura de un plugin a través del anfitrión. Un guardado desde la vista Source se ordena y conserva los valores que escribiste. Una regla sobre una propiedad que ningún bloque de la tabla de Properties declara se omite, y la comprobación la señala como linter/on-save-property. Con el plugin apagado, no se pone nada. Una raíz cuyas reglas siguen en .eidos/plugins/eidosmd/settings.yaml, donde se guardaban antes, las sigue aplicando, y el primer cambio en la página del Linter las mueve.

La página del plugin bajo Settings tiene las reglas al guardar bajo On save, y luego lista los archivos desviados bajo Drift, con Lint every file, encima del formulario de las reglas. Cada hallazgo linter/<rule> en Health Check y en un Blueprint lleva Lint como su arreglo.

  • .eidos/plugins/linter/settings.yaml, compartido: una clave por regla, escrita con los valores por defecto la primera vez que el plugin está activado y editada en su página, y on_save, las reglas al guardar como { property, set: today | now }.
Ventana de terminal
eidos linter # each file the rules would change, with the rules; or clean
eidos linter Blueprints/specs # some paths; --json
eidos linter --fix # write the linted text and nothing else

--fix no ejecuta ninguna regla al guardar, así que un arreglo de espacios nunca cambia una fecha.

linter/<rule> como aviso por cada archivo y regla que las reglas todavía cambiarían, una vez por archivo y regla.