|
ATHENA is the Advanced Typesetting and Hypertext Environment for Notes and Archives. It is a hard fork of GNU TEXmacs oriented toward mathematical knowledge organization: writing, linking, searching, importing, maintaining, and publishing large mathematical note systems from inside one native application.
ATHENA keeps the central strength of TEXmacs: structured WYSIWYG mathematical writing. Documents are edited as semantic trees rather than plain source text, so formulas, enunciations, proofs, labels, links, images, tables, and metadata remain first-class document objects.
Native mathematical documents. Authors can write ordinary prose, display formulas, inline formulas, matrices, cases, aligned equations, tables, figures, proofs, definitions, theorems, propositions, lemmas, corollaries, remarks, notes, warnings, examples, exercises, solutions, answers, laws, conjectures, disambiguations, and proof variants in one editor.
Efficient Mathematical input. The editor includes Mathematica-style control shortcuts for fractions, scripts, overscripts, underscripts, roots, jump-out navigation, structural selection, and table row or column insertion. An ESC symbol picker inserts common symbols, operators, brackets, arrows, spaces, math fonts, and structured snippets.
Formula importer. The LATEX importer recognizes common mathematical idioms such as matrices, aligned displays, braced cases, double and contour integrals, long equality arrows, projective and injective limit arrows, semantic differential symbols, blackboard letters, textual operators, and formula-normalization preferences.
Readable mathematical blocks. Enunciations can use configurable background colors, proof and solution display options, display-first theorem titles, compact exercise rendering, and screen-only heading fold controls without changing export semantics.
Document rendering controls. Reflow layout, persistent fit-to-width, live word and character statistics, heading word counts, CJK line breaking in mixed text, oversized table wrapping, image drag resizing, and image scale preservation across zoom and PDF export are part of the editing experience.
A vault is an ATHENA knowledge base. It is not merely a directory of files: it carries identity maps, preferences, namespace data, startup pages, maintenance policy, image policy, and history.
Vault identity. Vaults are described by a Vaultfile and a UUID-backed map.tmdb database. The active vault is visible in window titles, recent vault lists, startup behavior, welcome pages, and vault-scoped commands.
Vault-scoped preferences. A vault can carry its own preference file, preferred document font, image insertion policy, startup pages, explorer settings, autosave policy, backup retention, label display mode, rendering colors, and maintenance settings.
Vault Explorer. A native Qt dock pane shows the vault file tree, tracks the active document, supports file operations, opens non-.ath files with the system, and can use the system trash for safer deletion.
Maintenance. Vault maintenance can run from the GUI or headlessly. It creates compressed backups, normalizes images, rewrites image references, anchors enunciations, purges old pre-save and full backups, collects orphan assets, and reports summaries and diagnostics.
Reliability tooling. ATHENA includes a vault bugcheck tool, backup viewer, error messages pane, crash-report integration, startup cache invalidation, cache cleaning, and explicit warnings for font substitution or export limitations.
ATHENA's linking model is built for mathematical notes where the target is often not a file, but a theorem, definition, proof, section, paragraph, or range inside a file.
Wikilinks. Wikilinks use stable UUID records, file hints, anchor hints, redirect handling, and repair tools. Native Qt insertion wizards support file-first and search-first workflows, previews, namespace filters, enunciation filters, and explicit display text.
Anchors and labels. Labels can be visible, small, or hidden with zero height. Heading and enunciation anchors can be generated or maintained automatically, duplicate source anchors are preserved as separate occurrences, and PDF destinations are preserved for export.
Transclusion. A transclusion stores UUID, file hint, begin anchor, and end anchor. It renders a live extracted range inside the host document, rebases relative image paths, avoids cycles, strips duplicate labels, provides jump-to-source behavior, and supports wizard-based insertion with previews.
Cardlinks. Local file drops can become inline cardlinks, PDF targets can be represented as cardlinks, and tmfs:// namespace pages can be linked as document objects instead of fragile text URLs.
Namespaces organize a mathematical vault by concepts and relations rather than by a single filesystem hierarchy. A document can belong to a subject, course, book, reading project, or constructed product namespace without being moved between directories.
Namespace registry. A vault-local SQLite database stores namespace definitions, templates, relations, sorters, homepages, initial content, and technical summary pages.
Namespace types. ATHENA supports abstract, semi-concrete, and concrete namespaces, derived parent inference, trivial sorters, custom libtcc sorters, namespace templates, and generated sub-product namespaces.
Native management. Namespace Manager and namespace creation wizards provide CRUD, member inspection, parent editing, homepage selection, style and sorter path selection, and compatibility checks for generated products.
Namespace browsing. Namespace Explorer is a dockable pane that shows subspaces and sorted member files. The quick switcher has a structured namespace tab, and tmfs://ns pages expose homepage and technical views.
Hierarchy visualization. Reverse hierarchy graphs can be shown in a native pane or inserted into documents, with Graphviz-backed layout, simplified transitive edges, zooming, panning, and double-click navigation.
Large mathematical archives need fast movement between files, concepts, definitions, and occurrences. ATHENA implements this as native panes and dialogs rather than as detached scripts.
Global search. A dockable vault-wide search pane scans documents, shows individual occurrences, supports rendered previews, highlights hit context, can filter by namespace or enunciation type, and navigates directly to the selected occurrence.
Quick switching. The vault quick switcher supports fuzzy matching, recent-file priority, current-file priority, file creation, namespace-structured browsing, namespace page opening, tab completion, and wraparound navigation.
Document outline. A live outline pane lists headings, supports navigation, and can show word counts for sections.
Command and window navigation. A command palette lists live menu and toolbar actions, the Window menu lists open windows, a Visual Studio-style buffer switcher supports MRU navigation, and shortcut listings can be generated from the active keymap.
Status feedback. The status bar has a centered live region for search match counts, statistics, progress, and document messages while preserving ordinary footer information.
ATHENA's interface is a Qt application with a modern docking workspace, native dialogs, and maintained Linux desktop behavior.
Advanced Docking System. Documents and tools live in Qt Advanced Docking System panes. Panes can be docked, floated, redocked, closed, reopened, restored across sessions, switched with tabs, and shown independently in task managers.
Wayland docking. On native Wayland, ATHENA uses Qt and the compositor-supported xdg-toplevel-drag path for pane dragging. Floating panes keep native system title bars while document tab dragging provides compositor transport and ADS redocking hints.
Native Qt tools. Preferences, page properties, metadata, font selection, information messages, image insertion, color picking, vault tools, namespace tools, search, outline, backup viewing, Google Tasks, and RAG controls are implemented as native Qt surfaces where appropriate.
Desktop integration. ATHENA uses native file dialogs, KDE file-dialog integration when available, system icons, system trash, file manager and text editor actions, native input methods, correct HiDPI scaling, and Wayland-safe popup, cursor, and repaint behavior.
Interface customization. Users can control cursor color, selection color, link colors, focus colors, enunciation colors, preferred fonts, font warnings, autosave, splash behavior, pane layout restoration, inertial scrolling, and startup cache behavior.
ATHENA contains a substantial importer for A-OFM, the Academic Obsidian-Flavored Markdown. This importer exists because mathematical Obsidian vaults typically encode proofs, theorem callouts, anchors, wikilinks, transclusions, images, tables, formulas, and metadata in ways that must become structured document objects.
A-OFM parser. The importer uses a two-phase architecture: PEG parsing for block structure and C++ conversion for inline content. It handles headings, paragraphs, lists, blockquotes, code blocks, tables, highlights, external links, images, PDF embeds, wikilinks, transclusions, anchors, metadata, and mathematical formulas.
Mathematical callouts. Obsidian callouts and proof markers are mapped to theorem-like, remark-like, exercise-like, and proof-like environments. The converter handles separated proofs, nested proofs, proof variants, solution blocks, QED cleanup, CJK proof markers, duplicate anchors, and title-derived labels.
Vault conversion. Whole-vault import creates a destination hierarchy, generates Vaultfile and map.tmdb, assigns UUIDs, resolves links and anchors, copies assets, converts image widths, inserts optional build warnings and document titles, and supports model vault preferences and namespace data.
Performance and diagnostics. Conversion uses command caches, preference caches, process-based parallelism, progress bars, timing telemetry, fallback blocks, detailed parse errors, and batch-friendly summaries so large archives can be migrated deliberately.
Other conversion support. HTML, MathJax, SVG via resvg, PDF export, image background removal, and LATEX formula insertion are maintained as part of the broader conversion surface.
ATHENA can publish structured mathematical content as documents, generated books, PDFs, and static websites.
PDF export. PDF generation preserves anchors, hidden labels, table of contents references, fallback glyphs, ornamented blocks, image scaling, DataArt covers, namespace hierarchy diagrams, and ATHENA creator metadata.
Namespace export. Namespace export can assemble selected hierarchy content, add generated covers, insert hierarchy diagrams, preserve export labels, and produce book-like outputs from vault structure.
Static websites. Website generation is driven by a Vaultfile-backed registry and a headless –generate-website path. The exported site shell includes a document iframe, vault explorer, namespace explorer, outline, global search, quick switcher, history, local layout persistence, and standalone document opening.
HTML fidelity. Export preserves document titles, ATHENA logo macros, homepage links, headings, enunciations, equations, generated labels, and MathJax-facing mathematical structures where the static format can carry them.
ATHENA includes optional tools for local and connected workflows. These features are kept separate from the core document model so ordinary authoring remains local and deterministic.
Formula cleaning. A local llama.cpp-based formula cleaner can normalize MathJax and imported formulas, with repository support for dataset generation, model conversion, and isolated model licensing.
RAG server. A continuous vault RAG MCP server exposes search, chunks, documents, backlinks, and related content over a streamable HTTP interface. It can use SQLite FTS and optional local embeddings.
Google Tasks. A native pane supports Google Tasks OAuth, background refresh, cloud todo list synchronization, task display, and task markers inside the workspace.
The project has been reshaped into an ATHENA-specific application rather than a lightly renamed TEXmacs build.
Project identity. Runtime paths, executable names, environment variables, application icons, splash screens, welcome pages, about pages, help text, startup messages, user configuration paths, and the primary save suffix .ath use ATHENA identity while preserving TEXmacs document compatibility where required.
Modern build system. ATHENA uses CMake, Qt6, KDE Frameworks where available, Guile 1.8, mimalloc, zstd, resvg, Ghostscript, Freetype, GnuTLS, GMP, PNG, JPEG, iconv, ThinLTO, lld, and Intel icpx workflows for optimized local builds.
Portable packaging. The tree contains launchers, runtime library handling, AppImage and container-build work, Windows and WSL-oriented packaging checks, relocatable release layouts, bundled ADS libraries, and runtime scripts for native Wayland and other supported Qt platforms.
Performance. Core string, tree, list, allocation, URL, font, and typesetting paths have been optimized with move semantics, const-reference APIs, mimalloc, cache fingerprints, font indexes, startup warmups, larger stack limits, and tail-recursive Scheme rewrites where Guile 1.8 would otherwise overflow.
Pruned legacy surface. Unsupported Android, stale autotools scaffolding, obsolete Docker server packaging, unused plugins, old remote-server paths, Cite TEXmacs integration, outdated build hooks, and non-English bundled documentation were removed to keep the maintained surface narrower.
ATHENA is designed around a simple premise: mathematical knowledge should not be split between a typesetter, a note graph, a search index, a publishing script, and a pile of conversion tools. A mathematical archive should remain a live collection of semantic documents, where writing, linking, reuse, structure, maintenance, and publication are parts of one system.
The feature set is therefore intentionally integrated. Vaults give the archive identity. Namespaces give it multiple mathematical organizations. Wikilinks and transclusions give it internal structure. Search, outlines, quick switchers, and panes make it navigable. Importers bring existing notes into the model. Exporters and website generation let the same model leave the editor without becoming a different project.