amprev is a lightweight Markdown preview application focused on:
- predictable behavior
- clean UI
- fast feedback loop while writing
- engineering discipline over feature bloat
It follows the ASTEAM philosophy: clear boundaries, minimal abstractions and intentional design decisions.
Different views of amprev rendering GitHub Flavored Markdown in real time.
- Live Markdown preview
- Clean and neutral UI (Libadwaita)
- Dark / Light / System theme support
- Export to PDF
- Scroll synchronization (proportional)
- Syntax highlight support
- Keyboard-driven workflow
- Minimal and distraction-free interface
amprev is not trying to be everything.
It intentionally avoids:
- complex WYSIWYG behavior
- heavy plugin systems
- unnecessary abstractions
Core principles:
- Editor is the source of truth
- Preview is always derived and disposable
- UI should not own business logic
- Rendering must be predictable and cheap
- Simplicity over cleverness
The project is organized around clear boundaries:
models/→ document state and persistence rulescore/→ markdown engine (UI-agnostic)services/→ theme, sync, export, highlightui/→ window and visual compositionapp/→ bootstrap and actions
Each module has a single responsibility and avoids cross-layer leakage.
amprev supports:
system→ follows OS theme via Libadwaitadark→ forced dark modelight→ forced light mode
The stored preference represents user intent, not final toolkit state.
Scroll synchronization is proportional, not semantic.
This is a deliberate trade-off:
- ✔ fast and stable
- ✔ low complexity
- ✖ not pixel-perfect for all structures
PDF export is supported.
Notes:
- output fidelity depends on the rendering backend
- export does not mutate editor state
- failures are handled without crashing the app
- Vala
- Meson
- Ninja
- GTK4
- Libadwaita
meson setup build
meson compile -C build./build/amprevActive development.
Focus areas:
- stability
- rendering performance
- UI consistency
- clean architecture
amprev follows ASTEAM-style comments:
- document intent, not syntax
- document contracts and limits
- avoid noise and redundancy
If the code is clear, it stays uncommented.
Contributions are welcome, but discipline matters.
Before contributing:
- respect project structure
- avoid unnecessary abstractions
- keep changes small and focused
- follow ASTEAM commenting style
MIT
This project is built with a simple rule:
If it needs a comment to explain obvious code, the code is wrong. If it needs a comment to explain a decision, the comment is mandatory.