1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
//! # CLI Templates Module
//!
//! Out output pipleine, oustanding crate based, relies on templates for rendering term output.
//!
//! We have preference for stand-alone templates files, as seprateing them from code makes is easier
//! and safer to edit, diff and so on.
//!
//! We then include the template files as string constants here, so that they can be used as a regular
//! string literals elsewhere in the code.
//!
//! Templates are minijinja based. A few important best practices:
//!
//! 1. Blank Lines / Whitespace:
//!
//! While natural to keep templates organized as the output they produce, there are often times
//! where that forces the template to become unreadble (i.e. many nested conditionals, very long
//! lines). It can become quite tricky to iterate on blank lines and whitespaces, specilly when
//! dealing with loops and conditionals.
//! For this reason, we have templates requiring explicit line breaks, which make it clear where
//! they are coming from.
//! 2. Reusability and Composition:
//! Templates can and should be nested when appropriate. This allows for reuse (i.e. a pad
//! listing title) that can be used in multiple places, and keeps templates smaller and more
//! readable. Else we descend into a "god output" where everything is defined.
//!
//! 3. Judicial Conditionals:
//! While conditionals are necessary, they can quickly make templates unreadable.
//! They are best used when branching what gets output, but not when they contronling styles.
//!
//! For example, {% if pad.is_pinned %} <pinned-style> {% else %} <regular-style> {% endif %}
//! throughout various parts in the template. In this case its best to set the style variable
//! that does the logic, and then use the style variable directly.
//!
//! 4. Harder Logic
//! While best avoided, for when more complex logic is needed, it is best to move that logic
//! into the rust code, and pass the results as functions for the template to use.
//!
//! ## Debugging Template Output
//!
//! When developing or testing templates, use the `--output=term-debug` flag to see
//! style names as markup tags instead of ANSI escape codes:
//!
//! ```bash
//! padz list --output=term-debug
//! ```
//!
//! This renders output like:
//! ```text
//! [pinned]⚲[/pinned] [time]⚪︎[/time] [list-index]p1.[/list-index][list-title]My Pad[/list-title]
//! ```
//!
//! This is invaluable for:
//! - Verifying that the correct style is applied to each template element
//! - Debugging layout issues by seeing exactly what styles are where
//! - Writing test assertions that check for specific style applications
//! - Comparing output between template changes without ANSI code noise
//!
// Main templates
pub const LIST_TEMPLATE: &str = include_str!;
pub const FULL_PAD_TEMPLATE: &str = include_str!;
pub const TEXT_LIST_TEMPLATE: &str = include_str!;
pub const MESSAGES_TEMPLATE: &str = include_str!;
// Partial templates (used via {% include %} in main templates)
pub const DELETED_HELP_PARTIAL: &str = include_str!;
pub const PEEK_CONTENT_PARTIAL: &str = include_str!;
pub const MATCH_LINES_PARTIAL: &str = include_str!;
pub const PAD_LINE_PARTIAL: &str = include_str!;