Какие языки существуют для ведения заметок (не уценки)?

Примечание. Этот вопрос очень специфичен для исследования языков компьютерных наук. Сообщество Comp Sci SE сочло за лучшее публиковать здесь, а не там.

Мне нравится делать заметки в родной среде программирования, но я устал от простого белого текста с нечеткой структурой. Я ищу язык или формат обмена данными, а не уценку или хитрые трюки с emacs.

Меня интересует новое решение для ведения заметок, которое включает в себя легкий аспект программирования. Это может быть DSL, но я действительно не ищу ничего похожего на git markdown. То, что я себе представляю, выглядит примерно так, как показано ниже. Подсветка синтаксиса может помочь визуально разделить аспекты заметок, и я могу представить себе забавное связывание и структурирование на этапе компиляции.

Создание этого языка было бы для меня забавной темой исследования, но я хочу посмотреть, было ли это сделано раньше. Это выглядит немного python'ish, но я представляю что-то вроде этого (или может быть скомпилировано к этому):

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
Не могли бы вы объяснить, что не так с Markdown?
@svick Уценка в порядке, я просто не хочу уценки. Markdown используется как HTML: для разметки и выделения. Я хочу сделать больше после того, как структурирую свой текст с помощью синтаксиса (т.е. выявлю смысл).
Какой смысл? В вашем образце я вижу заголовки, ссылки, неупорядоченные списки и списки определений. Из них Markdown поддерживает все, кроме списков определений, но даже они, кажется, поддерживаются некоторыми диалектами .
Вам следует проверить Org, если вы используете emacs. Даже если вы не используете emacs, Org стоит того, чтобы его изучить.
@svick Не уверен, что это проблема с Markdown как таковым , но его реализация в Sublime Text 3 для Windows оставляет желать лучшего.

Ответы (2)

Если вы ищете удобный для записи формат для указания структурированных данных (в отличие от просто удобочитаемых форматов, таких как JSON и XML), взгляните на YAML . Это не относится к ведению заметок, но я думаю, что здесь это может сработать.

Используя его, ваш пример можно было бы написать так:

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
Отлично - я никогда не рассматривал yaml, но я думаю, что это может противоречить контексту.

Я думаю, что вам стоит потратить время на то, чтобы взглянуть на инструмент генерации документов Sphinx python. Первоначально он был создан для новой документации Python и сильно зависит от реструктурированного текста .

Цели реструктурированного текста:

С сайта.

  1. Удобочитаемый. Размеченный текст должен легко читаться без предварительного знания языка разметки. Он должен быть так же легко читаем в необработанном виде, как и в обработанном виде.
  2. Ненавязчивый. Используемая разметка должна быть максимально простой и ненавязчивой. Простота конструкций разметки должна быть примерно пропорциональна частоте их использования. Наиболее распространенные конструкции, с естественной и очевидной разметкой, должны быть максимально простыми и ненавязчивыми. Менее распространенные конструкции, для которых нет естественной или очевидной разметки, должны быть отличительными.
  3. Однозначный. Правила разметки не должны быть открытыми для интерпретации. Для любого заданного ввода должен быть один и только один возможный вывод (включая вывод ошибок).
  4. Неудивительно. Конструкции разметки не должны вызывать неожиданный вывод при обработке. В качестве запасного варианта должен быть способ предотвратить нежелательную обработку разметки, когда конструкция разметки используется в контексте, отличном от разметки (например, при документировании самого синтаксиса разметки).
  5. Интуитивно понятный. Разметка должна быть максимально очевидной и легко запоминающейся как для автора, так и для читателя. Конструкции должны получать сигналы из таких естественных источников, как текстовые сообщения электронной почты, сообщения групп новостей и текстовая документация, такая как файлы README.txt.
  6. Легкий. Размечать текст с помощью любого обычного текстового редактора должно быть легко.
  7. Масштабируемость. Разметка должна быть применима независимо от длины текста.
  8. Мощный. Разметка должна обеспечивать достаточное количество конструкций для создания достаточно богато структурированного документа.
  9. Язык-нейтральный. Разметка должна применяться к нескольким естественным (а также искусственным) языкам, а не только к английскому.
  10. Расширяемый. Разметка должна обеспечивать простой синтаксис и интерфейс для добавления более сложной общей разметки и пользовательской разметки.
  11. Выходной формат нейтрален. Разметка будет подходящей для обработки в нескольких выходных форматах и ​​не будет смещена в сторону какого-либо конкретного формата.
Несмотря на то, что этот инструмент генерации документов кажется хорошим, цель, которую я преследую, состоит не в том, чтобы создавать структурированную документацию, а в том, чтобы предоставлять простые языковые конструкции при вводе заметок о чем угодно (т.е. не связанных с программированием).
Это реструктурированная текстовая часть — Sphinx используется, чтобы свести все воедино.