Как поддерживать базу знаний на основе emacs?

Я лично веду список каталогов проектов со схожей структурой. В каждом есть tasklist.org, подкаталог отслеживания (где я делаю оценку проекта и отслеживаю время и всегда веду дневник, который является main вещью для проекта - в нём будут ссылки на другие файлы для проекта), подкаталог docs, который обычно состоит из вещей, которые я собираюсь опубликовать (docs для проекта, предложения и т.д.). Я получаю свои файлы повестки дня на tasklist.org в каждом из подкаталогов, так что моя повестка дня работает нормально.

Я думаю, что организация данных немного изменится в вашем случае (возможно, такие темы, как "функциональное программирование" и т.д.). Я скептически отношусь к тому, насколько иерархическая структура помогла бы, поскольку это ограничило бы вас в одном взгляде на вещи (опять теги против папок). Вот некоторые вещи, которые приходят на ум.

1. Храните "главный" орг-файл, который содержит ссылки на все "интересные" части другого содержимого верхнего уровня (похожие на дневник, о котором я упоминал выше).
2. Правильно отметьте все свои материалы (через некоторое время вы остановитесь на наборе полезных тегов), а затем воспользуйтесь функцией поиска тегов для быстрого поиска по файлам. При этом предполагается, что все файлы находятся в ваших agenda-files.
3. Наконец, если ваши данные слишком экзотичны, чтобы вставить их в структуру, вы можете подумать об использовании полнотекстового индексатора (например, xapian) и интегрировать его в ваш Emacs. Об этом шла дискуссия по поводу здесь .

Обновление : 26/Nov/2019

Недавно я наткнулся на пакет hyperbole, который утверждает, что он является информационным организатором. Я не использовал его, но у меня есть соблазн обновить его, когда я это сделаю.

[org-режим] отлично подходит для управления "действенными" элементами, но я продолжаю добавлять вещи более общего характера, которые мне не понадобятся в повседневной работе (how-tos, чтение заметок и т.д.), так что управление становится медленным и трудным.

Я последователь Дэвида Аллена и его методологии Getting Things Done . Я использую Emacs для трёх списков, которые он рекомендует:

• Next Actions

• Project Resources

• The Someday/Maybe list

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

Мне было интересно, какую структуру можно было бы использовать для обработки такого рода информации (классификация и поиск), и есть ли другие способы, которые могли бы помочь в работе?

Для такого рода информации я мигрировал от Emacs. Вместо этого я храню каталог ~/etc/howto, и в этот каталог я помещаю файлы, которые содержат "маленькие самородки на выбранных темах", где ключевым критерием является то, что информация имеет долгосрочное значение .

Я мог бы искать в этом каталоге с помощью Emacs, но мой Emacs Lisp не такой уж и горячий, поэтому вместо него я написал скрипт оболочки howto (для наглядности некоторые проверки ошибок опущены):

case $# in
  1) ;;
  *) echo "Usage: $0 <topic>" 1>&2; exit 2 ;;
esac

topic="$1"

# Note the ordering: first exact matches, then beginning matches, then any matches

set xxx `find $HOME/etc/howto/. -name "$topic"     -not -type d -print` \
        `find $HOME/etc/howto/. -name "${topic}?*" -not -type d -not -name '*~' -print` \
        `find $HOME/etc/howto/. -name "?*$topic*"  -not -type d -not -name '*~' -print`
shift

case $# in
  0) echo "No file found matching *$topic*" 1>&2 ; exit 1 ;;
  *) for i
     do
       less "$i"
     done
     ;;
esac

Примеры включают в себя:

• howto football вызывает три самородка, в таком порядке:

  • Инструкции, чтобы дать моей жене о том, как записать футбольный матч на компьютере

  • Инструкции для меня, как именно, что взять и как одеться, когда у меня есть билеты на футбольный матч

  • Инструкции для транскодирования футбольного матча, чтобы он мог быть передан по сети и просмотрен вдали от дома

• howto filesystem вызывает инструкции по копированию файловой системы

• howto batteries вызывает список рекомендуемых перезаряжаемых батарей

Одна из причин, по которой я не использую Emacs, заключается в том, что мой реальный сценарий немного сложнее, чем то, что вы видите выше: он также обрабатывает PDF и djvu файлы, так что, например, как бритва вызывает документ djvu руководство, которое пришло с моей электрической бритвы.

У меня более 500 элементов в главном каталоге или подкаталогах, и даже в таком масштабе система работает для меня достаточно хорошо. Надеюсь, вы тоже сочтете это полезным.

Я пробовал несколько способов управлять базой знаний в прошлом. У меня есть куча «наггетков знаний» (кстати, спасибо, мне нравится этот термин) на всевозможные разнообразные темы, начиная от того, как настроить Apache Tomcat SSL Cert, чтобы контролировать ежемесячный семейный бюджет, чтобы сохранить Список весов и повторений завершен на тренировках.

Я пытался держать их в блоге WordPress, на личном вики, используя ручку и бумагу и т. Д.

В конце концов, Emacs и Org-Mode - это четкий победитель для меня. Я люблю иметь возможность начать простую и строить более сложные функциональные возможности, сколько мне нужно. Я использовал много советов, описанных Sacha Chua .

В моем случае я всегда в конечном итоге с кучей нот (более формальных и организованных), смешанных с элементами действия (менее формальным). В целом я поддерживаю один список главных «элемента действий», а затем создать отдельный файл для заметок на каждой теме. До сих пор GreeP хорошо работал для меня, чтобы быстро найти файл, содержащий ноты. Я часто создаю закладку EMACS C-X R M , чтобы быстро перейти к файлам Notes.

Простые блоги, CMS и Wikis (например, Drupal и WordPress) хороши в классификации и поисках. Может быть, вы можете экспортировать файлы ORG в HTML и публиковать их в блоге, CMS или Wiki? Возможно, не слишком сложно подключить к возможностях метки блога / Wiki / CMS.

Вы можете ускорить ORG-режим, сохраняя свои заметки в отдельном файле (или по одному для каждой широкой темы), который не включен в обычный список файлов повестки дня. Настроить org-pastenda-файлы , чтобы увидеть список.

Используйте Орг-запомнить , чтобы быстро ввести заметки, не прерывая расход. Любая течь их в то время, либо сохранить их где-то, чтобы быть позже. Вы можете использовать тег в запоминающем шаблоне (настройка CORG-Memblates ), чтобы пометить заметки для повторного возмещения, и использовать пользовательский поиск повестки дня ( org-agenda-custom-commands ) чтобы перечислить их.

Тейте каждой заметки с соответствующими темами и используйте поисковые системы повестки дня, чтобы найти их. Вы можете определить пользовательский поиск, который знает, чтобы посмотреть в правильных файлах, или вы можете посетить файл и ограничить поиск повестки дня, чтобы просто этот файл.

Я держу файл заметок, и ваш вопрос только что вдохновил меня вернуться и начать мечать их всеми. Работает угощение!

На работе мы используем Wiki (на самом деле, несколько - глобальный вики плюс вики на проект) для этого. Он идеально подходит для не иерархических данных, но также может использоваться для иерархических данных. Он форматируемый, гипертекстуальный, связываемый-к, поисковой, разделяемой, но также собственности, он поддерживает историю и другие хорошие вещи.

Лично я также использовал для этого вики. Но в эти дни я обычно просто забуду вещи вместо этого. Гораздо проще.