¿Qué lenguajes existen para tomar notas (no rebajas)?

Nota: Esta pregunta es muy específica para la investigación de lenguajes informáticos. La comunidad de Comp Sci SE pensó que era mejor publicar aquí en lugar de allí.

Me encanta tomar notas en mi entorno de programación nativo, pero estoy cansado del texto en blanco sin estructura. Estoy buscando un lenguaje o formato de intercambio de datos, no rebajas o trucos inteligentes de Emacs.

Tengo curiosidad acerca de una nueva solución para tomar notas que implica un aspecto ligero de la programación. Esto podría ser un DSL, pero realmente no estoy buscando nada como git markdown. Lo que estoy imaginando es algo como a continuación. El resaltado de sintaxis podría ayudar a separar visualmente los aspectos de las notas y puedo imaginarme vincular y estructurar de forma divertida en un paso de compilación.

Crear este lenguaje sería un tema de investigación divertido para mí, pero quiero ver si se ha hecho antes. Esto parece un poco python, pero me estoy imaginando algo como esto (o podría compilarse a esto):

topic
    an elementary intro to fruit

concept
    fruit exists in many different colors, shapes, and sizes

list:[colors, shape, size]
    orange
        colors: orange, green, yellow
        size: small
        shape: round
    banana
        colors: yellow, green
        shape: long

terms
    fructose: something to do with sugar
    hue: a form of color

related
    trees > tree-fruits.txt
    humans > ../human-notes/
    farms > ../../farms
¿Podría explicar lo que está mal con Markdown?
@svick Markdown está bien, simplemente no quiero rebajas. Markdown se usa como HTML: para diseño y énfasis. Quiero hacer más después de estructurar mi texto en una sintaxis (es decir, obtener significado).
¿Qué tipo de significado? Lo que veo en su muestra son encabezados, enlaces, listas desordenadas y listas de definición. De estos, Markdown admite todos excepto las listas de definiciones, pero incluso esos parecen ser compatibles con algunos dialectos .
Debería revisar Org si usa emacs. Incluso si no usa emacs, Org hace que valga la pena aprenderlo.
@svick No estoy seguro de si esto es un problema con Markdown per se , pero su implementación en Sublime Text 3 para Windows deja algo que desear.

Respuestas (2)

Si está buscando un formato de escritura humana para especificar datos estructurados (en lugar de solo formatos legibles por humanos como JSON y XML), eche un vistazo a YAML . No es específico para tomar notas, pero creo que podría funcionar aquí.

Al usarlo, su ejemplo podría escribirse como:

topic:
    an elementary intro to fruit

concept:
    fruit exists in many different colors, shapes, and sizes

list:
    orange:
        colors: [ orange, green, yellow ]
        size: small
        shape: round
    banana:
        colors: [ yellow, green ]
        shape: long

terms:
    fructose: something to do with sugar
    hue: a form of color

related:
    trees: tree-fruits.txt
    humans:  ../human-notes/
    farms: ../../farms
Genial, nunca consideré yaml, pero creo que podría luchar contra el contexto

Creo que valdría la pena echar un vistazo a la herramienta de generación de documentos Sphinx python. Originalmente se creó para la nueva documentación de Python y depende en gran medida del texto reestructurado .

Objetivos del texto reestructurado:

Desde el sitio web.

  1. Legible. El texto marcado debe ser fácil de leer sin ningún conocimiento previo del lenguaje de marcado. Debe ser tan fácil de leer en forma cruda como en forma procesada.
  2. Discreto. El marcado que se utiliza debe ser lo más simple y discreto posible. La simplicidad de las construcciones de marcado debe ser aproximadamente proporcional a su frecuencia de uso. Las construcciones más comunes, con marcado natural y obvio, deben ser las más simples y discretas. Las construcciones menos comunes, para las que no hay un marcado natural u obvio, deben ser distintivas.
  3. Inequívoco. Las reglas para el marcado no deben estar abiertas a interpretación. Para cualquier entrada dada, debe haber una y solo una salida posible (incluida la salida de error).
  4. No sorprende. Las construcciones de marcado no deberían generar resultados inesperados durante el procesamiento. Como alternativa, debe haber una manera de evitar el procesamiento de marcado no deseado cuando se usa una construcción de marcado en un contexto sin marcado (por ejemplo, cuando se documenta la sintaxis del marcado en sí).
  5. Intuitivo. El marcado debe ser lo más obvio y fácil de recordar posible, tanto para el autor como para el lector. Las construcciones deben inspirarse en fuentes naturales como mensajes de correo electrónico de texto sin formato, publicaciones en grupos de noticias y documentación de texto como archivos README.txt.
  6. Fácil. Debería ser fácil marcar texto usando cualquier editor de texto normal.
  7. Escalable. El marcado debe ser aplicable independientemente de la longitud del texto.
  8. Poderoso. El marcado debe proporcionar suficientes construcciones para producir un documento estructurado razonablemente rico.
  9. Idioma neutral. El marcado debe aplicarse a múltiples idiomas naturales (así como artificiales), no solo al inglés.
  10. Extensible. El marcado debe proporcionar una sintaxis y una interfaz simples para agregar un marcado general más complejo y un marcado personalizado.
  11. Formato de salida neutral. El marcado será apropiado para el procesamiento en múltiples formatos de salida y no estará sesgado hacia ningún formato en particular.
Por mucho que esta herramienta de generación de documentos parezca buena, el objetivo que busco no es generar documentación estructurada, sino proporcionar construcciones de lenguaje simples mientras se escriben notas sobre cualquier cosa (es decir, no relacionadas con la programación).
Esa es la parte del texto reestructurado: Sphinx se usa para juntarlo todo.