pkg/ui/markdown/styles.go (3)

13-17: Avoid swallowing errors.

If the user’s custom configuration fails to load (line 14), we silently fall back to built-in defaults. Consider adding a log message or an error return so the user knows their config is not being used.

---

33-36: Check unmarshal errors more thoroughly.

We simply return an error if JSON unmarshalling fails. It might be helpful to wrap the error to clarify that it occurred during style deserialization.

---

94-257: Consider using a single JSON file for built-in styles.

Currently, the built-in style is embedded in code. Storing it in a JSON file would make it more maintainable and consistent with the config-driven approach.

internal/tui/workflow/model.go (3)

25-25: Use consistent naming for simplicity.

The field name workflows is a map of workflow manifests, while the first column is called “Workflow Manifests.” Consider renaming fields or titles for consistency (e.g., workflowManifests).

---

152-157: Keep step item labeling consistent.

As above, defaulting the name to the command is a coherent fallback. Ensure no collisions happen if multiple steps share an empty name. Could optionally generate a unique label in such a scenario.

---

184-189: Watch for potential repeated logic.

The step item creation logic in lines 184-189 is nearly identical to lines 152-157. Centralizing this logic in a helper method helps keep it DRY.

pkg/schema/schema.go (2)

624-641: Double-check naming consistency.

Fields like BlockPrefix and Prefix can confuse usage if not well-documented. Clarify if both are required, or unify them for clarity.

---

643-645: Potential for extended syntax highlighting.

Your ChromaStyle currently stores color alone. If you plan to theme bold or italics for code tokens, consider adding extra fields or using the advanced Chroma config directly.

cmd/markdown/workflow.md (4)

1-2: Document valid commands more explicitly.

You reference “atmos workflow list is not valid.” Possibly provide a quick link to the valid commands for immediate clarity beyond your examples.

---

20-20: Consider consistent punctuation or an em dash.

To match style guidelines, consider an em dash instead of the lone hyphen when introducing your enumerations (e.g., “– Deploy a workflow” -> “— Deploy a workflow”). This minor detail can enhance readability.

🧰 Tools

🪛 Markdownlint (0.37.0)

20-20: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

38-39: Inconsistent messaging.

Line 39 references “Execute a specific workflow” after showing the command to list directory contents. Consider re-checking the heading or examples ordering to ensure clarity.

🧰 Tools

🪛 LanguageTool

[typographical] ~39-~39: Consider using an em dash in dialogues and enumerations.
Context: ... workflows shell $ ls workflows/ – Execute a specific workflow ```shell $ ...

(DASH_RULE)

🪛 Markdownlint (0.37.0)

38-38: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

7-11: Markdownlint reminder: removing $ from prompts.

Static analysis suggests removing $ to avoid style checks (MD014). Possibly keep the $ for clarity, or remove them consistently across all examples.

Also applies to: 20-21, 24-25, 28-29, 38-39, 42-42

🧰 Tools

🪛 Markdownlint (0.37.0)

7-7: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

8-8: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

9-9: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

---

10-10: null
Dollar signs used before commands without showing output

(MD014, commands-show-output)

internal/tui/components/code_view/main.go (1)

40-59: Consider error handling improvements in the SetContent method.

While the implementation looks good, the error handling could be enhanced to provide more context about why the rendering failed.

Consider this improvement:

 if language == "markdown" || language == "md" {
   m.IsMarkdown = true
   rendered, err = u.RenderMarkdown(content, "")
   if err != nil {
-    // Fallback to plain text if markdown rendering fails
+    // Log the error for debugging purposes
+    log.Printf("markdown rendering failed: %v", err)
+    // Fallback to plain text
     rendered = content
   }
 } else {
   m.IsMarkdown = false
   rendered, err = u.HighlightCode(content, language, m.SyntaxTheme)
   if err != nil {
-    // Fallback to plain text if syntax highlighting fails
+    // Log the error for debugging purposes
+    log.Printf("syntax highlighting failed for language %s: %v", language, err)
+    // Fallback to plain text
     rendered = content
   }
 }

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

Width(m.Viewport.Width).
Height(m.Viewport.Height).
Render(rendered)

#!/bin/bash
# Search for any existing viewport dimension handling
ast-grep --pattern 'func ($_, $_) SetSize(width int, height int) {
  $$$
  style := lipgloss.NewStyle().Width($_).Height($_)
  $$$
}'

#!/bin/bash
# Let's search for viewport-related code and dimension handling
rg -A 5 "viewport" --type go

# Also search for any width/height style settings
rg -A 3 "Width\(|Height\(" --type go

website/docs/cli/configuration/markdown-styling.mdx (1)

169-169: Fix minor typographical issues.

A few small improvements to enhance readability:

1. Line 169: Add "the" before "nearest"
2. Line 183: Use an em dash instead of a hyphen
3. Line 252: Add a period after "etc"

-  - Automatically maps hex colors to nearest ANSI 256 colors
+  - Automatically maps hex colors to the nearest ANSI 256 colors
-The color degradation is handled automatically by termenv's color profile detection. You don't need to configure anything - your styles will work everywhere
+The color degradation is handled automatically by termenv's color profile detection. You don't need to configure anything — your styles will work everywhere
-    - Use a terminal emulator known for true color support (e.g., Terminal.app, iTerm2, Windows Terminal, etc).
+    - Use a terminal emulator known for true color support (e.g., Terminal.app, iTerm2, Windows Terminal, etc.).

Also applies to: 183-183, 252-252

🧰 Tools

🪛 LanguageTool

[grammar] ~169-~169: A determiner may be missing.
Context: ...** - Automatically maps hex colors to nearest ANSI 256 colors - Detected via `$TERM...

(THE_SUPERLATIVE)

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

website/docs/cli/configuration/markdown-styling.mdx (3)

137-157: Update default styles to use theme variables.

The default styles use hardcoded colors instead of referencing theme variables, which is inconsistent with the configuration example above.

Update the default styles to use theme variables:

 settings:
   markdown:
     document:
-      color: "#FFFFFF"  # White text
+      color: "${colors.text}"
     heading:
-      color: "#00A3E0"  # Blue headings
+      color: "${colors.primary}"
       bold: true
     h1:
-      color: "#FFFFFF"  # White text
-      background_color: "#9B51E0"  # Purple background
+      color: "${colors.text}"
+      background_color: "${colors.secondary}"
       bold: true
       margin: 2
     code_block:
-      color: "#00A3E0"  # Blue code
+      color: "${colors.secondary}"
       margin: 1
     link:
-      color: "#00A3E0"  # Blue links
+      color: "${colors.primary}"
       underline: true

---

169-169: Fix minor grammatical and style issues.

A few minor issues in the text:

1. Line 169: Missing determiner before "nearest"
2. Line 183: Consider using an em dash for better readability
3. Line 252: Missing period after "etc" in American English

Apply these fixes:

-Automatically maps hex colors to nearest ANSI 256 colors
+Automatically maps hex colors to the nearest ANSI 256 colors

-You don't need to configure anything - your styles will work everywhere
+You don't need to configure anything — your styles will work everywhere

-Terminal.app, iTerm2, Windows Terminal, etc)
+Terminal.app, iTerm2, Windows Terminal, etc.)

Also applies to: 183-183, 252-252

🧰 Tools

🪛 LanguageTool

[grammar] ~169-~169: A determiner may be missing.
Context: ...** - Automatically maps hex colors to nearest ANSI 256 colors - Detected via `$TERM...

(THE_SUPERLATIVE)

---

229-233: Enhance accessibility best practices.

The best practices section could benefit from more specific guidance on color contrast ratios and tools for verification.

Add these specific recommendations:

 1. **Color Contrast**: Ensure sufficient contrast between text and background colors for readability.
+   - Use tools like [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/)
+   - Aim for a minimum contrast ratio of 4.5:1 for normal text
 2. **Consistent Styling**: Use a consistent color scheme across different elements.
 3. **Terminal Support**: Test your styling in different terminals to ensure compatibility.
 4. **Accessibility**: Consider color-blind users when choosing your color scheme.
+   - Avoid problematic color combinations (red/green, blue/purple)
+   - Test with color blindness simulators

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro