# TODO List for byteb4rb1e_sphinxcontrib

This is a poor-man's issue tracker. I am not primarily a GitHub user so don't
want to commit to their issue tracking feature, but my primary SVC service
provider (Bitbucket) only offers paid integration into their issue tracker
(Jira). I don't have the time (and patience) at the moment to analyze the best
approach, so this file will have to suffice.

It's a very simple concept: Track any issues (features, bugfixes, hotfixes) in
here, assign a sequential number to it and use that number when branching.

I will try to develop a format so that I can parse the file later on, should I
decide to migrate to a real issue tracker. It's probably going to be Bugzilla,
but for that my html-theme-ref project needs to stabilize first.

## Format Specification

The file uses Markdown conventions for formatting headers and other text block
entitities, but SHOULD NOT be considered a Markdown file. That's why it has no
definitive file extension.

Each issue entry follows a structured format for easier parsing and future
migration.  Issues MUST be **appended** to this file and never moved, to
preserve Git diffing.

### Issue Format

```

ID: [ISSUE-NUMBER]
Type: [feature/bugfix/hotfix]
Title: [Short title]
Status: [open/in-progress/done/hold/cancelled]
Priority: [low/medium/high]
Created: [YYYY-MM-DD]
Description: [Detailed explanation]

---
```

- ISSUE-NUMBERs must be sequential
- truncation of description must be indentended so that every line starts at the
  same column
- issues must be started with two LF
- issues must be terminated with two LF, then `---`
- issues may have a free-text field (epilog), which must be started with two LF.

## Issues

ID: 1
Type: feature
Title: Experiment with repository layout and build environment
Status: in-progress
Priority: low
Created: 2025-06-06
Description: Find the best repository layout and build environment for my case

---

ID: 2
Type: feature
Title: Prototype dynamic slide-view directives ("reslide")
Status: open
Priority: high
Created: 2025-06-27
Description: Implement a Sphinx extension allowing reStructuredText documents to
             be rendered as both linear HTML pages and presentation-style
             slides.

             The system introduces a non-intrusive layer over standard reST
             content via three main directives:

             - `.. slide-master::` declares a reusable grid-based layout with
               named areas.
             - `.. slide::` marks a logical section as a slide and references a
               master layout.
             - `.. slide-slot::` maps specific content blocks into areas defined
               by the referenced slide master.

             Slides are composed in a single reST file without disrupting HTML
             output.  During HTML build, a toggle button is injected allowing
             users to switch between document view and presentation view using
             JavaScript and CSS.

             Additional features include:
             - Fallback or fluid "resize to fit" mode for content overflow
             - Optional pre-build warning system for oversized content
             - Placeholder wireframes for visualizing grid slots (dev mode)
             - Semantic rendering to preserve readability in both views

             Parsing relies on the sequential nature of reST processing to
             segment slide contents without modifying global tree behavior.

             This prototype sets up the basic parsing, node registration, and
             HTML translator customization. Styling and JavaScript interactivity
             will be minimal but functional.

---
