OrgNote в 2026 году: итоги и текущее состояние

Прежде всего, я хочу поблагодарить всех, кто меня поддерживает - не только через подписку на Patreon, но в первую очередь за теплые слова и обратную связь.

Поздравляю всех с Новым годом. Вы потрясающие, и я желаю вам успехов в обучении, а также мирного неба над головой в наступающем году 🙏🏻

• Новый адрес сайта с версией для разработки: https://dev.org-note.com
• Локальная платформонезависимая файловая система
• Более продуманный способ хранения файлов через S3-подобный API на сервере
• OrgNote теперь поддерживает любые типы файлов, включая Markdown

Все типы файлов можно читать, но индексация и расширенный редактор сейчас работают только с Org файлами

• Новая концепция буферов (сильное вдохновение Emacs) для рендеринга контента
• Поддержка панелей и вкладок, включая мобильную версию
• Первый успешный запуск на реальном iOS устройстве через Xcode
• Асинхронная очередь и cron-задачи для API расширений
• Миграция конфигурации на формат TOML
• Улучшенная обработка ошибок с более подробными сообщениями
• Редактор Org файлов был значительно доработан
• Синхронизация в реальном времени через WebSockets
• Несколько новых встроенных расширений
• Более 1500 unit-тестов на клиентской стороне

На данный момент несколько сотен пользователей продолжают использовать основную прототипную версию приложения. Я решил оставить ее доступной еще на некоторое время, параллельно сосредоточившись на версии для разработки: https://dev.org-note.com

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

В раннем прототипе OrgNote я использовал простое in-memory хранилище для заметок. Оно работало нормально, но реальные файлы на диске отсутствовали. Это сбивало с толку многих пользователей и создавало проблемы с синхронизацией и резервным копированием. Кроме того, OrgNote нельзя было использовать без серверной части.

Новый подход к файловой системе полностью агностичен. Можно легко переключаться между разными файловыми системами или добавлять новые через расширения. Идея довольно простая - нужно лишь реализовать интерфейс файловой системы: interface.

export interface FileSystem {
  readFile: <
    T extends 'utf8' | 'binary' = 'utf8',
    R = T extends 'utf8' ? string : Uint8Array,
  >(
    path: string,
    encoding?: T
  ) => Promise<R>;
  writeFile: (
    path: string,
    content: string | Uint8Array,
    encoding?: BufferEncoding
  ) => Promise<void>;
  readDir: (path: string) => Promise<DiskFile[]>;
  fileInfo: (path: string) => Promise<DiskFile | undefined>;
  rename: (path: string, newPath: string) => Promise<void>;
  deleteFile: (path: string) => Promise<void>;
  rmdir: (path: string) => Promise<void>;
  mkdir: (path: string) => Promise<void>;
  isDirExist: (path: string) => Promise<boolean>;
  isFileExist: (path: string) => Promise<boolean>;
  utimeSync: (
    path: string,
    atime?: string | number | Date,
    mtime?: string | number | Date
  ) => Promise<void>;
  init?: (params?: FileSystemParams) => Promise<FileSystemParams | void>;
  mount?: (params?: FileSystemParams) => Promise<boolean>;
  pickFolder?: () => Promise<string>;
  prettifyPath?: (path: string) => string;
  wipe?: () => Promise<void>;
  watch?: (
    listener: (change: FileSystemChange) => void,
    params?: FileSystemParams
  ) => WatcherHandle | Promise<WatcherHandle>;
  copyFile?: (src: string, dest: string) => Promise<void>;
}

Благодаря этому подходу я могу реализовать файловую систему Android SAF. В результате будущие версии приложения смогут публиковаться в Google Play с нативной поддержкой файловой системы на современных Android устройствах. Например, становится возможным использовать такие инструменты, как Syncthing для синхронизации файлов.

В предыдущей версии MongoDB использовалась как основное хранилище заметок. Это позволяло реализовать серверный поиск и публикацию.

В новом подходе данные хранятся в любом S3-подобном хранилище без анализа их содержимого.

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

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

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

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

Я также добавил поддержку окон и вкладок. Этот подход вдохновлен тем, как это реализовано в приложении Obsidian для работы с заметками.

Вкладки на мобильных устройствах вдохновлены браузером Safari:

Одной из самых больших проблем прототипа была синхронизация большого количества файлов.

Для решения этой задачи я решил использовать два разных подхода.

Первый - это персистентная очередь, которая может обрабатывать задачи последовательно или пакетами с настраиваемым размером.

Второй подход основан на cron-задачах, которые могут запускать фоновые процессы аналогично классическому cron менеджеру. Оба этих механизма доступны через публичный API OrgNote и могут использоваться в расширениях.

Также я добавил простой менеджер очередей в UI для разработчиков:

В предыдущей версии приложения использовалась конфигурация на основе JSON. Этот вариант по-прежнему доступен (помечен как deprecated), но со временем я пришел к выводу, что TOML является одним из лучших форматов для конфигурации. Он более читаемый и гораздо проще в расширении.

Пакет orgnote.el также был переведен на конфигурационные файлы в формате TOML.

Я до сих пор не до конца уверен, как лучше всего мониторить ошибки на стороне пользователей. Мне хотелось бы избежать проприетарных решений вроде Sentry, так как они могут приводить к утечке данных. При этом мне все равно необходимы осмысленные stack trace для отладки.

Для этого я добавил новый глобальный обработчик ошибок, который должен значительно упростить отладку runtime ошибок. Посмотрим, насколько это окажется полезным.

Я не ставил эту цель во главу угла, но в процессе разработки в итоге реализовал несколько интересных улучшений, связанных с редактированием Org файлов:

• Свойство ID больше не является обязательным
• Поддержка плейсхолдеров для распространенных ключевых слов
• Улучшенная логика сворачивания
• Оптимизация производительности многострочных виджетов
• Улучшенный виджет изображений с поддержкой зума

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

Я получил много отзывов по поводу правой панели, поэтому решил добавить отдельный сайдбар для дополнительного контекста. Он также доступен через API OrgNote и может использоваться расширениями.

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

Другой пример - простой инструмент для отладки AST Org mode в реальном времени:

• Первый успешный запуск на физическом iOS устройстве 🎉
• Более 1500 клиентских unit-тестов для повышения общей стабильности

В этом году я планирую:

• Интегрировать agenda и трекер привычек
• Добавить календарь
• Опубликовать версию для разработки в продакшен
• Опубликовать iOS приложение в TestFlight
• Добавить поиск по текущему документу

Расширения:

• Граф
• Backlinks

Также я надеюсь найти время для интеграции AI провайдеров и MCP серверов для работы с заметками, но на данный момент это выглядит как довольно нетривиальная задача.