Please note that viewing media is not supported in history for now. Get Mycomarkup source of this revision

G™Minoteaur

Mostly copied from public Minoteaur documentation copied from internal documentation:

The new, inevitable Minoteaur is here and inescapably/inexorably so. I refer, of course, to Minoteaur 8, which is not actually here at all (this is Minoteaur 6; Minoteaur 7 and 7.1 [DATA EXPUNGED], although aggressive containment measures were able to save the vast majority (>99.3%) of the noosphere from contamination); I am using this because it's actually consistently up and doesn't lose data randomly to my changes which already exists. Not that Minoteaur 8 does this. You should be unconcerned by this and ignore any insinuations that it has or might. It has:

  • editing pages (incredibly advanced obscure feature, READ THIS)

  • viewing pages

  • search, slightly

  • contextual backlinks

  • page aliasing capability and case insensitivity

  • Markdown

  • a nicer editor (the Minoteaur 6 one, at least partly, so tab and whatever)

  • keyboard shortcuts (view/edit, focus search, save/done, enter in search box)

  • reworked content model (WIP) hahahano

  • basic tag system (search by tag; you can even remove tags from pages now, which I apparently didn't implement earlier because ???)

  • revision history

  • KaTeX - block maths and inline maths

  • captioned images

  • redaction for some reason

  • file upload

  • page icons

  • link to tag page (heav)

  • image formatting kind of works (heav)

  • BM25 search ranking

  • search results have moderately relevant snippets

  • search system also suggests relevant page names (Sublime Text algorithm)

  • dubiously reliable serverside JS scripting

  • dead links list

  • "recently viewed" bar (clientside, kind of oddly done)

  • DokuWiki importer for migration - parse wiki markup and serialize to extended Markdown, backdate old revisions, upload files, rearrange structures (please never use this again)

  • print view (enough)

  • mobile UI (enough)

  • hierarchical tag system (jankily)

  • search ranking control

  • exact/negation for search

  • structured data (sidebar, search queries) - mostly not that structured but you can do queries and primitive numerical operations

  • editing titles

  • per-page theming

It could maybe have:

  • more detailed logging/analysis than just "recently viewed" - track most common paths and pages, maybe store all logs ever for future analysis by better tooling (for purposes)

  • transclusion or something similar

  • useful file metadata

  • usable API for external programs - this already has a sort of API for use by the frontend, due to javascriptoidal forms, but it's highly specific to that frontend

    • never mind, good enough

  • synchronization between instances on different systems (distributed systems are hard, but something like the dokuwiki sync plugin would probably be doable - it just has to be able to agree on a list of revisions unapplied on each end and apply them, assuming no ordering-related horrors occur). This may be unnecessary/undesirable given that web, but there are circumstances where it would be desirable.

  • graph visualization (3D ? Cool hyperbolic geometry thing?) - how to do this nicely for arbitrary graphs appears to be an active area of research

  • export pages as HTML etc. (current solution is print-to-PDF)

  • share page for public (unathenticated) viewing (maybe just exporting of subsets would be better)

  • drawing capabilities - might slightly require overhauling entire data model, or just special attachments theoretically possible with new content model, just annoying now really annoying again - do not do whatsoever

  • diffs on revisions (which I dropped for mildly annoying reasons)

  • page filter-y thing, perhaps (unify with scripting, search)

  • login (okay, basic auth might work fine too)

  • less janky drafts

  • put page icons in more places

  • performance improvements - caching maths, perhaps, or working early exit in lists etc

    • not really needed

  • better discovery than the search thing (alphabetized index maybe); reorganize existing stuff

Heav wants:

  • automatic pluralization/singularization on name list

  • "Minoteaur subscribers"

Mild aesthetic-ish improvements:

  • Work out how to make an actually nice UI - Minoteaur 6 had a sort of proto-two-pane UI for "metadata" and buttons and whatever, Minoteaur 7 just has a search/navigation UI there - how much can I blatantly copy all other programs, and how much are they bad? Maybe I just need more modals or pullout menu bits or something. Three-pane UI design works well enough for now. Might need to work out how to render middle-bar stuff at the side but whatever.

  • Actually paginate things to avoid horrible performance problems (revisions, backlinks depending on use). Even the Python version was surprisingly fast. I might not have to for ages.

  • Investigate hashbow-type thing on page names for rainbows™. Maybe use nicer color space.

    • Previous development efforts, involving gradients, look rather bad.

Many useful Minoteaur pages (maths notes, primarily) were (are) just bullet-pointed lists. They are quick to write but have some readability and organization problems. Splitting pages as I do now looks nicer, but requires me to make decisions about when to split things up and how. Hypothetical Minoteaur 9 would represent all notes as a very large tree of bullet points (parts could of course be expanded or contracted as needed). There would be no pages. However, it would be possible to assign metadata or something to bullet points. There would be no explicit links, but highlighting phrases would allow you to jump to what the system thinks is the best thing to show you (based on context (LLM or something) and position in document), or possibly just scroll through all other instances.

Also note: concept - probably requires more detailed edits.

Minoteaur 9 concept (secret)

Many Minoteaur uses map quite well to nested bullet-pointed lists. It's somewhat desirable to be able to link straight to deeply nested lists, so links going to pages only is problematic. With bullet-point nesting to provide a hierarchy and links to bullet points, having separate pages at all feels inelegant. However, having to remember/copy a block ID or similar to create a link with the right target seems annoying. The "solution" to this is to make the entire notes database into a tree of bullet points and then have links take arbitrary keywords and connect to other blocks based on tree position and whether they contain the linked keyword in a subject role.