Para mantener legible el código fuente de una tabla Markdown, añade espacios de relleno a las celdas y vuelve a alinear cada columna después de hacer cambios extensos. En un Mac con Obsidian, edita la tabla con el editor nativo y luego revisa el modo Source. Hay que comprobar por separado el relleno del código fuente y la alineación del texto renderizado.

Este flujo de trabajo está pensado para quien mantiene una pequeña tabla Markdown en una nota de escritorio: una lista de lecturas, un inventario de artículos de papelería o una lista de verificación de proyectos. El objetivo es que el texto sea fácil de revisar a medida que cambian las entradas, sin dejar de conservar una tabla funcional en el renderizador previsto.

¿Qué hace legible el código fuente de una tabla Markdown?

Una tabla legible en el código fuente tiene límites de columna reconocibles, espaciado uniforme y una fila completa por línea. Sus barras verticales se alinean cuando se muestra con una fuente monoespaciada. La documentación de GitHub indica explícitamente que las celdas no necesitan tener el mismo ancho ni las columnas del código fuente tienen que estar perfectamente alineadas, por lo que esta alineación es una comodidad al editar, no un requisito para que la tabla sea válida. Organizar información con tablas.

Por ejemplo, esta tabla sintética es compacta, pero resulta más difícil de revisar cuando se introduce un nombre de artículo más largo:

| Item | Finish | Count |
| --- | --- | ---: |
| Pencil | Matte | 4 |
| Large sketchbook | Linen | 12 |

Añadir espacios facilita revisar el mismo contenido como texto sin formato:

| Item             | Finish | Count |
| ---------------- | ------ | ----: |
| Pencil           | Matte  |     4 |
| Large sketchbook | Linen  |    12 |

En GFM, se eliminan los espacios entre los límites de las barras verticales y el contenido de las celdas. Por lo tanto, el relleno no establece el ancho de las columnas renderizadas. Los dos puntos de ----: controlan la alineación a la derecha de la columna renderizada; los espacios antes de 4 simplemente hacen que este ejemplo del código fuente sea más fácil de revisar. Especificación de GitHub Flavored Markdown, tablas.

Trata estas opciones como dos decisiones distintas: elige el relleno para facilitar la lectura del código fuente y los dos puntos de la fila delimitadora para alinear el texto renderizado. Si tu único problema son las barras verticales desiguales en el editor, cambiar los dos puntos no lo resolverá.

¿Qué renderizador leerá la tabla?

Las tablas con barras verticales son una extensión, no una función de CommonMark básico. La especificación actual de CommonMark corresponde a la versión 0.31.2, mientras que la especificación GFM publicada por GitHub define explícitamente las tablas como una extensión de CommonMark. Que un renderizador se describa solo como compatible con CommonMark no garantiza que admita tablas con barras verticales. Comprueba si también admite una extensión para tablas. Especificación de CommonMark, Especificación de GitHub Flavored Markdown.

Estas diferencias importan al pasar una nota de una aplicación a otra:

Destino Comportamiento documentado Opción práctica
CommonMark básico La especificación básica no incluye la sintaxis de tablas con barras verticales Confirma que haya una extensión para tablas disponible
GitHub Su guía de tablas exige al menos tres guiones en cada celda delimitadora Usa --- o más
Obsidian Su guía de tablas acepta un mínimo de dos guiones y no exige que las celdas del código fuente estén alineadas Usa tres o más si también el destino es GitHub

Los requisitos de guiones anteriores proceden de las respectivas guías de cada producto. Usar al menos tres es una convención compartida y práctica para estos dos destinos; no hace que todos los renderizadores Markdown sean equivalentes. Documentación de tablas de GitHub, Sintaxis de formato avanzado de Obsidian.

Para una tabla destinada tanto a Obsidian como a GitHub, usa barras verticales iniciales y finales, espacios normales como relleno y una línea en blanco antes y después de la tabla. La guía de GitHub pide una línea en blanco antes; la especificación GFM documenta que una línea vacía termina una tabla. Mantener explícitos ambos límites también facilita identificar la tabla en el código fuente. Documentación de tablas de GitHub, Límites de tablas en GFM.

Cómo mantener la tabla en Obsidian en un Mac

Obsidian ofrece una opción práctica para quienes quieren editar celdas cómodamente y tener después un código Markdown legible. Las notas de la versión de escritorio 1.5.8 introdujeron el formato automático de tablas mientras se escribe y describen específicamente cómo las columnas quedan más limpias al verlas en el modo Source. Se trata de un comportamiento documentado del editor, no de una función de la sintaxis Markdown. Notas de la versión de escritorio 1.5.8 de Obsidian.

Sigue esta secuencia para una nota normal:

  1. Abre la nota en Live Preview. Si es necesario, selecciona ese modo mediante el icono de estado del editor.
  2. Inserta una tabla con el comando Insert Table o haz clic con el botón derecho y elige Insert → Table.
  3. Introduce o modifica el contenido de las celdas en el editor de tablas. Haz clic con el botón derecho en la tabla cuando necesites añadir, eliminar, mover u ordenar filas y columnas.
  4. Selecciona Source mode mediante el icono de estado y revisa el Markdown resultante.
  5. Cambia a Reading view para comprobar la tabla tal como se muestra.

Los controles de modo están documentados en Vistas y modo de edición; la inserción de tablas y las operaciones del menú contextual se documentan en Sintaxis de formato avanzado.

Si cambias de modo con frecuencia, asigna una tecla de acceso rápido a Toggle Live Preview/Source mode. En macOS, Cmd+E alterna entre las vistas de lectura y edición; usa el comando de modo específico cuando quieras pasar concretamente de un modo de edición al otro. Vistas y modo de edición de Obsidian.

Si al escribir directamente en Source mode el relleno queda desigual, vuelve al editor nativo de tablas para seguir editando y luego revisa el código fuente. La documentación citada respalda el formato automático de tablas y la inspección precisa del código fuente, pero no garantiza de forma universal que cada modificación arbitraria del código fuente reciba el relleno correcto de inmediato. Para una tabla pequeña que siga desigual, el método manual que aparece a continuación te da control directo.

Cómo volver a alinear las columnas del código fuente después de un cambio extenso

Sigue una regla sencilla: haz que cada columna del código fuente tenga el ancho suficiente para la entrada actual más larga, incluido el encabezado. Añade relleno a las demás celdas de esa columna. Vuelve a calcular cuando una entrada supere el espacio disponible.

Aquí tienes un ejemplo paso a paso que usa solo texto ASCII sin formato. Empieza con esta tabla:

| Item   | Finish | Count |
| ------ | ------ | ----: |
| Pencil | Matte  |     4 |
| Folder | Linen  |    12 |

Ahora reemplaza Folder por Large sketchbook. El nuevo elemento tiene 16 caracteres, así que la primera columna necesita un espacio de contenido de 16 caracteres. Deja un espacio inmediatamente dentro de cada barra delimitadora y luego añade suficientes espacios finales para completar ese ancho:

  • Item tiene 4 caracteres, así que añade 12 espacios de relleno después y, a continuación, el espacio delimitador.
  • Pencil tiene 6 caracteres, así que añade 10 espacios de relleno después y, a continuación, el espacio delimitador.
  • Large sketchbook ocupa los 16 caracteres, así que solo necesita el espacio delimitador a continuación.
  • Amplía la primera celda delimitadora a 16 guiones para tener una guía visual a juego.

El resultado es la tabla con relleno que se mostró antes. Solo había que ensanchar la primera columna. Las demás columnas conservan su espaciado y sus marcadores de alineación.

Esta es una receta manual de formato para el ejemplo ASCII indicado, no un algoritmo general para calcular el ancho de caracteres. Para la edición habitual, revisa el resultado en una vista del código fuente con fuente monoespaciada. Si las celdas contienen bastante formato en línea, calcula el ancho según los caracteres escritos, incluidos signos de puntuación como las comillas invertidas y los asteriscos.

Después de una serie de cambios, alinea la tabla una sola vez en lugar de ajustar cada fila con cada pulsación de tecla. Si las entradas suelen convertirse en párrafos, considera dejar solo una etiqueta breve en la tabla y trasladar la explicación a prosa normal debajo. Así reduces el mantenimiento de los espacios en blanco sin acortar la información subyacente.

¿Qué debes comprobar cuando se rompe una tabla?

Empieza por la estructura antes de ajustar los espacios. En GFM, las filas de encabezado y delimitadores deben tener el mismo número de celdas. A las filas del cuerpo con menos celdas se les añaden celdas vacías; se ignoran las que tienen celdas de más. Por eso una tabla puede parecer correcta y, aun así, omitir contenido en el resultado renderizado. Reglas de análisis de tablas de GFM.

Después de un cambio importante, sigue esta secuencia de diagnóstico:

  1. Compara las filas de encabezado y delimitadores. Asigna una celda delimitadora a cada encabezado.
  2. Revisa todas las filas del cuerpo. Mantén el número previsto de celdas incluso cuando un valor esté vacío.
  3. Busca barras verticales literales en el contenido. Una barra sin escape puede interpretarse como otro límite.
  4. Revisa los límites de las filas. Mantén cada fila de la tabla en una sola línea del código fuente y evita las líneas en blanco dentro de la tabla.
  5. Previsualiza el destino. Comprueba tanto los valores mostrados como el aspecto de la tabla.

Para las barras verticales literales, GitHub documenta que se coloque una barra invertida antes del carácter. Este ejemplo completo mantiene Blue | Green dentro de una sola celda:

| Item   | Options       |
| ------ | ------------- |
| Folder | Blue \| Green |

El escape es estructural; añadir más espacios alrededor de una barra sin escape no resolverá el problema. Ejemplo de barra vertical literal de GitHub.

Obsidian también documenta cómo escapar la barra vertical de un alias de enlace interno dentro de una tabla. Se trata de una consideración sintáctica específica de Obsidian, así que un alias con escape no demuestra por sí solo que el enlace funcione de forma equivalente en GitHub. Guía de formato de tablas de Obsidian.

No pulses Enter en medio de una celda larga para que su código fuente parezca más estrecho. Las tablas GFM aceptan contenido en línea y excluyen elementos de bloque; no ofrecen un formato general de celdas con varias líneas en el código fuente. Si las filas de una sola línea se vuelven poco prácticas, traslada las explicaciones largas fuera de la tabla. Reglas de contenido de tablas de GFM.

Mantén pequeña la rutina de mantenimiento: termina los cambios de contenido, revisa los límites de las celdas, vuelve a rellenar las columnas afectadas y revisa la tabla renderizada. En Obsidian, el editor nativo de tablas seguido del modo Source mode es un punto de partida práctico. El relleno manual sigue siendo útil cuando quieres una disposición concreta en texto sin formato.

Fuentes