Created
February 22, 2026 05:54
-
-
Save paulrobello/e471ef82cc0c8db869358d5924786805 to your computer and use it in GitHub Desktop.
Repository Wiki — generated by GitNexus
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <meta charset="UTF-8"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"> | |
| <title>par-term — Wiki</title> | |
| <script src="https://cdn.jsdelivr.net/npm/marked@11.0.0/marked.min.js"></script> | |
| <script src="https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.min.js"></script> | |
| <style> | |
| *{margin:0;padding:0;box-sizing:border-box} | |
| :root{ | |
| --bg:#ffffff;--sidebar-bg:#f8f9fb;--border:#e5e7eb; | |
| --text:#1e293b;--text-muted:#64748b;--primary:#2563eb; | |
| --primary-soft:#eff6ff;--hover:#f1f5f9;--code-bg:#f1f5f9; | |
| --radius:8px;--shadow:0 1px 3px rgba(0,0,0,.08); | |
| } | |
| body{font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,sans-serif; | |
| line-height:1.65;color:var(--text);background:var(--bg)} | |
| .layout{display:flex;min-height:100vh} | |
| .sidebar{width:280px;background:var(--sidebar-bg);border-right:1px solid var(--border); | |
| position:fixed;top:0;left:0;bottom:0;overflow-y:auto;padding:24px 16px; | |
| display:flex;flex-direction:column;z-index:10} | |
| .content{margin-left:280px;flex:1;padding:48px 64px;max-width:960px} | |
| .sidebar-header{margin-bottom:20px;padding-bottom:16px;border-bottom:1px solid var(--border)} | |
| .sidebar-title{font-size:16px;font-weight:700;color:var(--text);display:flex;align-items:center;gap:8px} | |
| .sidebar-title svg{flex-shrink:0} | |
| .sidebar-meta{font-size:11px;color:var(--text-muted);margin-top:6px} | |
| .nav-section{margin-bottom:2px} | |
| .nav-item{display:block;padding:7px 12px;border-radius:var(--radius);cursor:pointer; | |
| font-size:13px;color:var(--text);text-decoration:none;transition:all .15s; | |
| white-space:nowrap;overflow:hidden;text-overflow:ellipsis} | |
| .nav-item:hover{background:var(--hover)} | |
| .nav-item.active{background:var(--primary-soft);color:var(--primary);font-weight:600} | |
| .nav-item.overview{font-weight:600;margin-bottom:4px} | |
| .nav-children{padding-left:14px;border-left:1px solid var(--border);margin-left:12px} | |
| .nav-group-label{font-size:11px;font-weight:600;color:var(--text-muted); | |
| text-transform:uppercase;letter-spacing:.5px;padding:12px 12px 4px;user-select:none} | |
| .sidebar-footer{margin-top:auto;padding-top:16px;border-top:1px solid var(--border); | |
| font-size:11px;color:var(--text-muted);text-align:center} | |
| .content h1{font-size:28px;font-weight:700;margin-bottom:8px;line-height:1.3} | |
| .content h2{font-size:22px;font-weight:600;margin:32px 0 12px;padding-bottom:6px;border-bottom:1px solid var(--border)} | |
| .content h3{font-size:17px;font-weight:600;margin:24px 0 8px} | |
| .content h4{font-size:15px;font-weight:600;margin:20px 0 6px} | |
| .content p{margin:12px 0} | |
| .content ul,.content ol{margin:12px 0 12px 24px} | |
| .content li{margin:4px 0} | |
| .content a{color:var(--primary);text-decoration:none} | |
| .content a:hover{text-decoration:underline} | |
| .content blockquote{border-left:3px solid var(--primary);padding:8px 16px;margin:16px 0; | |
| background:var(--primary-soft);border-radius:0 var(--radius) var(--radius) 0; | |
| color:var(--text-muted);font-size:14px} | |
| .content code{font-family:'SF Mono',Consolas,'Courier New',monospace;font-size:13px; | |
| background:var(--code-bg);padding:2px 6px;border-radius:4px} | |
| .content pre{background:#1e293b;color:#e2e8f0;border-radius:var(--radius);padding:16px; | |
| overflow-x:auto;margin:16px 0} | |
| .content pre code{background:none;padding:0;font-size:13px;line-height:1.6;color:inherit} | |
| .content table{border-collapse:collapse;width:100%;margin:16px 0} | |
| .content th,.content td{border:1px solid var(--border);padding:8px 12px;text-align:left;font-size:14px} | |
| .content th{background:var(--sidebar-bg);font-weight:600} | |
| .content img{max-width:100%;border-radius:var(--radius)} | |
| .content hr{border:none;border-top:1px solid var(--border);margin:32px 0} | |
| .content .mermaid{margin:20px 0;text-align:center} | |
| .menu-toggle{display:none;position:fixed;top:12px;left:12px;z-index:20; | |
| background:var(--bg);border:1px solid var(--border);border-radius:var(--radius); | |
| padding:8px 12px;cursor:pointer;font-size:18px;box-shadow:var(--shadow)} | |
| @media(max-width:768px){ | |
| .sidebar{transform:translateX(-100%);transition:transform .2s} | |
| .sidebar.open{transform:translateX(0);box-shadow:2px 0 12px rgba(0,0,0,.1)} | |
| .content{margin-left:0;padding:24px 20px;padding-top:56px} | |
| .menu-toggle{display:block} | |
| } | |
| .empty-state{text-align:center;padding:80px 20px;color:var(--text-muted)} | |
| .empty-state h2{font-size:20px;margin-bottom:8px;border:none} | |
| </style> | |
| </head> | |
| <body> | |
| <button class="menu-toggle" id="menu-toggle" aria-label="Toggle menu">☰</button> | |
| <div class="layout"> | |
| <nav class="sidebar" id="sidebar"> | |
| <div class="sidebar-header"> | |
| <div class="sidebar-title"> | |
| <svg width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2"><path d="M2 3h6a4 4 0 014 4v14a3 3 0 00-3-3H2z"/><path d="M22 3h-6a4 4 0 00-4 4v14a3 3 0 013-3h7z"/></svg> | |
| par-term | |
| </div> | |
| <div class="sidebar-meta" id="meta-info"></div> | |
| </div> | |
| <div id="nav-tree"></div> | |
| <div class="sidebar-footer">Generated by GitNexus</div> | |
| </nav> | |
| <main class="content" id="content"> | |
| <div class="empty-state"><h2>Loading…</h2></div> | |
| </main> | |
| </div> | |
| <script> | |
| var PAGES = {"agents":"# Agents\n\n# Agents Module Documentation\n\n## Overview\n\nThe **Agents** module is designed to facilitate the integration and execution of various coding agents that adhere to the ACP (Agent Communication Protocol). Each agent is defined in a TOML configuration file, which specifies its identity, name, short name, protocol, type, and the command to run it. This module serves as a centralized repository for managing these agents, allowing developers to easily add, modify, or execute them as needed.\n\n## Purpose\n\nThe primary purpose of the Agents module is to provide a standardized way to configure and run different coding agents. Each agent can be invoked through a command defined in its respective TOML file, enabling seamless interaction with various coding tools and services.\n\n## Key Components\n\n### TOML Configuration Files\n\nEach agent is represented by a TOML file located in the `agents` directory. The structure of these files is consistent, allowing for easy parsing and execution. Below is a breakdown of the key fields in each TOML file:\n\n- **identity**: A unique identifier for the agent, typically the domain of the service.\n- **name**: The full name of the agent.\n- **short_name**: A shorthand reference for the agent, used for command-line invocation.\n- **protocol**: The communication protocol used by the agent (in this case, always \"acp\").\n- **type**: The type of the agent, which is \"coding\" for all agents in this module.\n- **run_command**: A mapping of command patterns to the actual command that should be executed to run the agent.\n\n### Example Configuration\n\nHere’s an example of a TOML configuration for the **Amp (AmpCode)** agent:\n\n```toml\nidentity = \"ampcode.com\"\nname = \"Amp (AmpCode)\"\nshort_name = \"amp\"\nprotocol = \"acp\"\ntype = \"coding\"\n\n[run_command]\n\"*\" = \"npx -y amp-acp\"\n```\n\n### Agents List\n\nThe following agents are currently defined in the module:\n\n1. **Amp (AmpCode)**: \n - Command: `npx -y amp-acp`\n \n2. **Auggie (Augment Code)**: \n - Command: `auggie --acp`\n \n3. **Claude Code**: \n - Command: `claude-code-acp`\n \n4. **Copilot**: \n - Command: `copilot --acp`\n \n5. **Docker cagent**: \n - Command: `cagent acp`\n \n6. **Gemini CLI**: \n - Command: `gemini --experimental-acp`\n \n7. **Codex CLI**: \n - Command: `npx @zed-industries/codex-acp`\n \n8. **OpenHands**: \n - Command: `openhands acp`\n\n## Execution Flow\n\nCurrently, there are no internal or outgoing calls detected within the Agents module, nor are there any execution flows. The module primarily serves as a configuration repository, and the execution of agents is handled externally through the defined commands.\n\n## Integration with the Codebase\n\nThe Agents module is designed to be easily integrated with other parts of the codebase that require interaction with coding agents. Developers can reference the agents by their short names and execute the corresponding commands as needed. \n\n### Example Usage\n\nTo execute an agent, a developer can use the following command pattern:\n\n```bash\n# Example command to run the Amp agent\nnpx -y amp-acp\n```\n\nThis command can be executed in a terminal or invoked programmatically, depending on the context of use.\n\n## Conclusion\n\nThe Agents module provides a flexible and extensible framework for managing coding agents that utilize the ACP protocol. By defining agents in TOML configuration files, developers can easily add new agents or modify existing ones without altering the core logic of the module. This modular approach enhances maintainability and scalability, making it easier to adapt to new coding tools and services as they emerge.","ai-inspector-ai-inspector":"# AI Inspector — ai_inspector\n\n# AI Inspector Module Documentation\n\n## Overview\n\nThe **AI Inspector** module (`ai_inspector`) is designed to facilitate interactions between users and an AI agent within a terminal environment. It manages chat conversations, processes agent responses, and provides a user interface for monitoring and controlling the agent's actions. The module is composed of several components, including chat management, shader context handling, and a user interface panel.\n\n## Key Components\n\n### 1. Chat Management (`chat.rs`)\n\nThe chat management component is responsible for maintaining the state of the conversation between the user and the AI agent. It tracks messages, manages user input, and processes updates from the agent.\n\n#### Key Structures\n\n- **ChatMessage**: An enum representing different types of messages in the chat, including user messages, agent responses, tool calls, command suggestions, and system messages.\n\n- **ChatState**: A struct that holds the current state of the chat, including:\n - `messages`: A vector of `ChatMessage` instances representing the conversation history.\n - `input`: The current user input that has not yet been sent.\n - `streaming`: A boolean indicating whether the agent is currently streaming a response.\n - `agent_text_buffer`: A buffer for assembling agent message chunks before they are flushed to the message history.\n\n#### Key Functions\n\n- **new()**: Creates a new instance of `ChatState`.\n- **handle_update(update: SessionUpdate)**: Processes incoming updates from the agent, updating the chat state accordingly.\n- **flush_agent_message()**: Finalizes the agent's message, extracting any command suggestions and resetting the streaming state.\n- **add_user_message(text: String)**: Adds a user message to the conversation, marking it as pending.\n- **cancel_last_pending()**: Cancels and removes the most recent pending user message.\n\n### 2. Shader Context Handling (`shader_context.rs`)\n\nThis component manages the context related to shaders when the user interacts with the AI agent regarding shader programming. It detects shader-related keywords and builds a context block that describes the current shader state, available shaders, and instructions for shader management.\n\n#### Key Functions\n\n- **should_inject_shader_context(message: &str, config: &Config)**: Determines if shader context should be injected based on the presence of shader-related keywords in the message or the current configuration.\n- **classify_shaders(shaders: &[String]) -> (Vec<&str>, Vec<&str>)**: Classifies shaders into background and cursor categories based on their filenames.\n- **scan_shaders(shaders_dir: &Path) -> Vec<String>**: Scans a directory for shader files and returns a sorted list of filenames.\n- **build_shader_context(config: &Config) -> String**: Constructs a shader context block to be injected into agent prompts, detailing the current shader state, available shaders, and instructions for applying changes.\n\n### 3. User Interface Panel (`panel.rs`)\n\nThe user interface panel provides a graphical interface for interacting with the AI Inspector. It displays chat messages, allows user input, and shows the current state of the agent and terminal.\n\n#### Key Structures\n\n- **AIInspectorPanel**: A struct that represents the state of the inspector panel, including:\n - `open`: A boolean indicating if the panel is open.\n - `width`: The current width of the panel.\n - `scope`: The current snapshot scope for displaying terminal state.\n - `view_mode`: The current view mode for displaying commands.\n - `chat`: An instance of `ChatState` for managing the chat conversation.\n\n#### Key Functions\n\n- **new(config: &Config)**: Initializes a new inspector panel from the provided configuration.\n- **toggle()**: Toggles the panel's open/closed state.\n- **show(ctx: &Context, available_agents: &[AgentConfig]) -> InspectorAction**: Renders the inspector panel and returns any actions to perform based on user interactions.\n\n## Execution Flow\n\nThe execution flow of the AI Inspector module can be summarized as follows:\n\n1. **User Interaction**: The user interacts with the UI panel, sending messages to the AI agent.\n2. **Chat Management**: The `ChatState` processes user messages and agent responses, updating the conversation history.\n3. **Shader Context Handling**: If the user discusses shaders, the shader context is injected based on the keywords detected in the messages.\n4. **UI Rendering**: The panel is rendered, displaying the chat history, agent status, and any relevant shader information.\n\n### Mermaid Diagram\n\n```mermaid\ngraph TD;\n A[User Interaction] -->|Sends Message| B[ChatState]\n B -->|Processes Update| C[Agent Response]\n C -->|Updates Messages| B\n B -->|Injects Shader Context| D[Shader Context]\n D -->|Builds Context Block| E[Agent Prompt]\n E -->|Displays in UI| F[AIInspectorPanel]\n F -->|Renders Chat| B\n```\n\n## Integration with the Codebase\n\nThe `ai_inspector` module integrates with other parts of the codebase, including:\n\n- **par_term_acp**: The module interacts with the Agent Communication Protocol (ACP) for sending and receiving messages from the agent.\n- **Config**: The module uses configuration settings to manage shader states and UI preferences.\n- **egui**: The user interface is built using the `egui` library, allowing for responsive and interactive components.\n\n## Conclusion\n\nThe AI Inspector module is a comprehensive solution for managing interactions between users and an AI agent in a terminal environment. It effectively handles chat management, shader context, and user interface rendering, providing a seamless experience for users engaging with the AI. Developers can extend and contribute to this module by adding new features, improving existing functionality, or enhancing the user interface.","ai-inspector":"# AI Inspector\n\n# AI Inspector Module Overview\n\nThe **AI Inspector** module (`ai_inspector`) serves as a comprehensive framework for managing interactions between users and an AI agent in a terminal environment. It integrates several sub-modules that work collaboratively to facilitate chat management, shader context handling, and user interface operations.\n\n## Sub-modules and Their Interactions\n\n### 1. [Chat Management](chat.md)\nThe **Chat Management** sub-module is the backbone of the AI Inspector, responsible for tracking the conversation state, processing user inputs, and managing agent responses. It utilizes structures like `ChatMessage` to handle various message types and ensures smooth communication flow. Key workflows include:\n\n- **Message Handling**: The chat management system interacts with the user interface to display messages and updates. For instance, it calls functions like `render_chat_messages` and `flush_agent_message` to ensure that the latest messages are presented to the user in real-time.\n\n### 2. [Shader Context](shader_context.md)\nThe **Shader Context** sub-module provides the necessary context for rendering visual elements associated with the AI's responses. It processes keywords and configurations that influence how messages are displayed. This sub-module works closely with the chat management component, as it relies on data from chat messages to build the appropriate shader context.\n\n### 3. [User Interface Panel](panel.md)\nThe **User Interface Panel** sub-module is responsible for rendering the visual components of the AI Inspector. It integrates outputs from both the chat management and shader context sub-modules to present a cohesive user experience. Functions like `render_controls` and `show` are pivotal in displaying the chat interface and action bar, allowing users to interact seamlessly with the AI agent.\n\n## Key Workflows\n\nThe AI Inspector module orchestrates several key workflows that span across its sub-modules:\n\n- **User Interaction Flow**: When a user sends a message, the chat management sub-module captures this input, processes it, and updates the conversation state. The UI panel then renders this message while the shader context applies any necessary visual formatting.\n\n- **Agent Response Handling**: Upon receiving a response from the AI agent, the chat management sub-module updates the conversation and triggers the UI panel to refresh the displayed messages. The shader context may also modify how these responses are visually represented based on predefined configurations.\n\n- **Real-time Updates**: The system is designed to handle real-time updates efficiently, ensuring that user inputs and agent responses are reflected immediately in the UI, enhancing the overall interaction experience.\n\n## Conclusion\n\nThe **AI Inspector** module is a robust framework that integrates chat management, shader context handling, and user interface rendering to create an interactive environment for users and AI agents. For detailed information on each sub-module, please refer to the following links:\n\n- [Chat Management](chat.md)\n- [Shader Context](shader_context.md)\n- [User Interface Panel](panel.md)","application-app":"# Application — app\n\n# Application Module Documentation\n\nThe **Application** module serves as the core of the application, managing the state, configuration, and interactions of the terminal emulator. It integrates various functionalities such as file transfers, copy mode handling, configuration updates, and event handling, providing a cohesive user experience.\n\n## Overview\n\nThe Application module is composed of several sub-modules, each responsible for specific functionalities. The key components include:\n\n- **Anti-idle Logic**: Manages keep-alive signals to prevent idle timeouts.\n- **Bell State Management**: Handles audio and visual notifications.\n- **Configuration Updates**: Detects changes in application settings.\n- **Copy Mode Handling**: Facilitates text selection and clipboard operations.\n- **File Transfer Management**: Manages uploads and downloads, including progress tracking.\n- **Event Handling**: Processes user input and window events.\n\n## Key Components\n\n### 1. Anti-idle Logic (`anti_idle.rs`)\n\nThe `anti_idle` module provides a utility function to determine if a keep-alive signal should be sent based on the last activity timestamp.\n\n#### Function: `should_send_keep_alive`\n\n```rust\npub(crate) fn should_send_keep_alive(\n last_activity: Instant,\n now: Instant,\n idle_threshold: Duration,\n) -> bool\n```\n\n- **Parameters**:\n - `last_activity`: The timestamp of the last user activity.\n - `now`: The current timestamp.\n - `idle_threshold`: The duration after which a keep-alive should be sent.\n \n- **Returns**: `true` if the idle threshold has been exceeded, indicating a keep-alive should be sent.\n\n#### Example Usage\n\n```rust\nif should_send_keep_alive(last_activity, Instant::now(), Duration::from_secs(60)) {\n // Send keep-alive signal\n}\n```\n\n### 2. Bell State Management (`bell.rs`)\n\nThe `bell` module manages the state of audio and visual bells, providing feedback to the user.\n\n#### Struct: `BellState`\n\n```rust\npub struct BellState {\n pub audio: Option<AudioBell>,\n pub last_count: u64,\n pub visual_flash: Option<Instant>,\n}\n```\n\n- **Fields**:\n - `audio`: An optional `AudioBell` instance for sound notifications.\n - `last_count`: Tracks the last bell event count.\n - `visual_flash`: Timestamp for the visual bell flash.\n\n#### Example Initialization\n\n```rust\nlet bell_state = BellState::new();\n```\n\n### 3. Configuration Updates (`config_updates.rs`)\n\nThis module tracks changes in application configuration, replacing numerous boolean flags with a structured approach.\n\n#### Struct: `ConfigChanges`\n\n```rust\n#[derive(Default)]\npub(crate) struct ConfigChanges {\n pub theme: bool,\n // Other fields...\n}\n```\n\n- **Method: `detect`**\n\n```rust\npub fn detect(old: &Config, new: &Config) -> Self\n```\n\n- **Purpose**: Compares two configurations and returns a `ConfigChanges` instance indicating which fields have changed.\n\n### 4. Copy Mode Handling (`copy_mode_handler.rs`)\n\nThe `copy_mode_handler` module manages entering and exiting copy mode, handling key events for text selection.\n\n#### Key Functions\n\n- **`enter_copy_mode`**: Activates copy mode and anchors the cursor.\n- **`exit_copy_mode`**: Deactivates copy mode and clears selections.\n- **`handle_copy_mode_key`**: Processes key events while in copy mode.\n\n### 5. File Transfer Management (`file_transfers.rs`)\n\nThis module handles file transfers, including uploads and downloads, and provides a progress overlay.\n\n#### Struct: `FileTransferState`\n\n```rust\npub(crate) struct FileTransferState {\n pub active_transfers: Vec<TransferInfo>,\n pub pending_saves: VecDeque<PendingSave>,\n // Other fields...\n}\n```\n\n- **Method: `check_file_transfers`**\n\n```rust\npub(crate) fn check_file_transfers(&mut self)\n```\n\n- **Purpose**: Polls for file transfer events, updates active transfers, and processes completed downloads.\n\n### 6. Event Handling (`handler.rs`)\n\nThe `handler` module implements the `ApplicationHandler` trait, routing window events to the appropriate `WindowState`.\n\n#### Key Functions\n\n- **`handle_window_event`**: Processes window events, including keyboard and mouse input.\n- **`update_window_title_with_shell_integration`**: Updates the window title based on shell integration data.\n\n## Execution Flow\n\nThe execution flow of the application is primarily driven by user interactions and system events. Below is a simplified flow of how key events are processed:\n\n```mermaid\ngraph TD;\n A[User Input] -->|Key Event| B[handle_key_event]\n B --> C[handle_copy_mode_key]\n C --> D[execute_copy_mode_search]\n D --> E[search_lines_forward]\n E --> F[line_text_at_absolute]\n F --> G[scrollback_len]\n```\n\n## Integration with the Codebase\n\nThe Application module interacts with various parts of the codebase, including:\n\n- **Window Management**: The `WindowState` struct manages the state of the application window and integrates with the `WindowManager`.\n- **Terminal Management**: The terminal's state is accessed through the `tab_manager`, allowing for operations like resizing and updating the display.\n- **Configuration Management**: The `Config` struct is used to load and save application settings, with changes detected by the `ConfigChanges` struct.\n\n## Conclusion\n\nThe Application module is a critical component of the terminal emulator, providing essential functionalities for user interaction, configuration management, and file handling. Understanding its structure and flow is vital for developers looking to contribute to or extend the application.","application":"# Application\n\n# Application Module Overview\n\nThe **Application** module is the central hub of the terminal emulator, orchestrating various functionalities to ensure a seamless user experience. It integrates multiple sub-modules, each specializing in distinct aspects of application management, including state handling, configuration, and user interactions.\n\n## Sub-modules and Their Interactions\n\nThe Application module comprises the following key sub-modules:\n\n- **[Anti-idle Logic](anti-idle-logic.md)**: Prevents idle timeouts by managing keep-alive signals.\n- **[Bell State Management](bell-state-management.md)**: Provides audio and visual notifications for user alerts.\n- **[Configuration Updates](configuration-updates.md)**: Monitors and applies changes to application settings dynamically.\n- **[Copy Mode Handling](copy-mode-handling.md)**: Enables text selection and clipboard operations for enhanced user interaction.\n- **[Mouse Events](mouse-events.md)**: Handles mouse interactions, translating them into terminal commands.\n\n### Key Workflows\n\nThe sub-modules work together through a series of interconnected workflows:\n\n1. **Event Handling**: User inputs are processed through the **[Input Events](input-events.md)** sub-module, which routes commands to appropriate handlers, such as **[Copy Mode Handling](copy-mode-handling.md)** for text selection or **[Mouse Events](mouse-events.md)** for mouse interactions.\n\n2. **Configuration Management**: Changes in settings are detected by **[Configuration Updates](configuration-updates.md)**, which then apply these changes across all relevant windows via the **[Window Manager](window-manager.md)**, ensuring a consistent user experience.\n\n3. **Clipboard Synchronization**: The **[Tmux Handler](tmux-handler.md)** sub-module synchronizes clipboard actions with Tmux sessions, allowing for seamless text management across different environments.\n\n4. **Notification System**: The **[Bell State Management](bell-state-management.md)** sub-module works in tandem with the **[Anti-idle Logic](anti-idle-logic.md)** to provide timely notifications while managing user activity states.\n\n### Cross-Module Interactions\n\nSeveral cross-module calls enhance the functionality of the Application module:\n\n- **State Initialization**: The `initialize_async` function in **[Window State](window-state.md)** initializes the application state, which is crucial for rendering and user interactions.\n- **Redraw Requests**: The `force_surface_reconfigure` function triggers redraws in response to configuration changes, ensuring that the UI reflects the latest settings.\n- **Clipboard Management**: The `sync_clipboard_to_tmux` function in **[Tmux Handler](tmux-handler.md)** ensures that clipboard actions are synchronized with Tmux, enhancing usability.\n\n## Conclusion\n\nThe Application module serves as a cohesive framework that integrates various functionalities through its sub-modules. By leveraging their specialized capabilities, it provides a robust environment for terminal operations, ensuring that user interactions are smooth and efficient. For detailed information on each sub-module, please refer to the linked documentation.","arrangements":"# Arrangements\n\n# Arrangements Module Documentation\n\nThe **Arrangements** module is designed to manage the layout of windows in a multi-monitor environment. It captures the current state of window arrangements, including their positions, sizes, and tab information, allowing users to save and restore these layouts seamlessly. This module is particularly useful for applications that require a consistent window layout across different sessions or monitor configurations.\n\n## Overview\n\nThe Arrangements module consists of several components that work together to capture, restore, and manage window layouts. The key functionalities include:\n\n- **Capture**: Captures the current arrangement of windows and monitors.\n- **Restore**: Restores a previously saved arrangement, ensuring that windows are positioned correctly on the available monitors.\n- **Storage**: Handles the persistence of arrangements to a YAML file for later retrieval.\n\n### Key Components\n\n1. **Capture** (`src/arrangements/capture.rs`)\n - The `capture_arrangement` function captures the current state of all windows and monitors. It creates a `WindowArrangement` object that includes details about each window, such as its position, size, and the tabs it contains.\n - The function uses `monitor_info_from_handle` to gather information about each monitor.\n\n2. **Restore** (`src/arrangements/restore.rs`)\n - The `build_monitor_mapping` function creates a mapping between saved monitor indices and currently available monitors, allowing for accurate restoration of window positions.\n - The `compute_restore_position` function calculates the absolute position of a window based on its relative position and the monitor it is assigned to. It ensures that windows are clamped within the visible area of the monitor.\n\n3. **Storage** (`src/arrangements/storage.rs`)\n - The `load_arrangements` and `save_arrangements` functions manage the reading and writing of window arrangements to a YAML file located at `~/.config/par-term/arrangements.yaml`.\n - The module uses the `ArrangementManager` to handle collections of `WindowArrangement` objects, providing methods for adding, removing, and retrieving arrangements.\n\n### Data Structures\n\nThe module defines several key data structures that represent the state of window arrangements:\n\n- **WindowArrangement**: Represents a complete layout of windows, including monitor layout and individual window snapshots.\n- **WindowSnapshot**: Contains information about a single window, including its position, size, and the tabs it holds.\n- **MonitorInfo**: Holds details about a monitor, such as its name, position, and size.\n- **TabSnapshot**: Represents a single tab within a window, including its current working directory (CWD), title, and any custom properties.\n\n### Execution Flow\n\nThe following diagram illustrates the flow of operations within the Arrangements module:\n\n```mermaid\ngraph TD;\n A[capture_arrangement] -->|captures| B[WindowArrangement]\n B --> C[WindowSnapshot]\n C --> D[TabSnapshot]\n A --> E[monitor_info_from_handle]\n E --> F[MonitorInfo]\n B --> G[save_arrangements]\n G --> H[arrangements_path]\n H --> I[load_arrangements]\n I --> J[ArrangementManager]\n J --> K[WindowArrangement]\n```\n\n### Usage\n\nTo use the Arrangements module, follow these steps:\n\n1. **Capture Current Arrangement**:\n Call the `capture_arrangement` function, passing the current window states and the event loop. This will return a `WindowArrangement` object that can be saved.\n\n ```rust\n let arrangement = capture_arrangement(\"My Layout\".to_string(), &windows, &event_loop);\n ```\n\n2. **Save Arrangement**:\n Use the `save_arrangements` function to persist the captured arrangement to a file.\n\n ```rust\n save_arrangements(&manager)?;\n ```\n\n3. **Load Arrangement**:\n To restore a previously saved arrangement, call `load_arrangements`, which will return an `ArrangementManager` containing the saved layouts.\n\n ```rust\n let manager = load_arrangements()?;\n ```\n\n4. **Restore Arrangement**:\n Use the `restore` functionality to apply a saved arrangement to the current window state.\n\n### Integration with the Codebase\n\nThe Arrangements module is integrated with the broader application through the `WindowManager`, which calls the capture and restore functions as needed. The `WindowManager` handles user interactions, such as saving and restoring layouts, and communicates with the Arrangements module to manage window states effectively.\n\n### Conclusion\n\nThe Arrangements module provides a robust solution for managing window layouts in applications that require multi-monitor support. By capturing and restoring window states, it enhances user experience and productivity, allowing users to maintain their preferred working environments across sessions. Developers can extend this module by adding new features or improving existing functionalities, ensuring that it meets the evolving needs of users.","documentation-agents-md":"# Documentation — AGENTS.md\n\n# AGENTS.md Module Documentation\n\n## Overview\n\nThe **AGENTS.md** module serves as a foundational document for understanding the GitNexus MCP (Multi-Component Platform). It provides essential guidelines for navigating the codebase, utilizing tools for code analysis, and understanding the architecture and impact of changes within the project. This module is crucial for developers who need to engage with the codebase effectively, whether for debugging, refactoring, or impact analysis.\n\n## Purpose\n\nThe primary purpose of the **AGENTS.md** module is to facilitate developers in:\n\n- Understanding the overall architecture of the codebase.\n- Performing impact analysis to determine the consequences of code changes.\n- Debugging issues by tracing bugs effectively.\n- Refactoring code with confidence through structured workflows.\n\n## Key Components\n\n### 1. Starting Point\n\nEvery engagement with the codebase should begin with the following steps:\n\n1. **Read the Context**: Access the codebase overview and check the freshness of the index by visiting `gitnexus://repo/{name}/context`.\n2. **Match Your Task**: Identify the task you need to perform and refer to the corresponding skill file.\n3. **Follow the Workflow**: Adhere to the outlined workflow and checklist in the skill file to ensure thoroughness.\n\n### 2. Skills\n\nThe module outlines specific skills that guide developers in various tasks:\n\n| Task | Skill File |\n|------|------------|\n| Understand architecture / \"How does X work?\" | `.claude/skills/gitnexus/exploring/SKILL.md` |\n| Blast radius / \"What breaks if I change X?\" | `.claude/skills/gitnexus/impact-analysis/SKILL.md` |\n| Trace bugs / \"Why is X failing?\" | `.claude/skills/gitnexus/debugging/SKILL.md` |\n| Rename / extract / split / refactor | `.claude/skills/gitnexus/refactoring/SKILL.md` |\n\n### 3. Tools Reference\n\nThe module provides a set of tools that enhance code analysis capabilities:\n\n| Tool | Description |\n|------|-------------|\n| `query` | Provides execution flows related to a concept. |\n| `context` | Offers a comprehensive view of symbols and their relationships. |\n| `impact` | Analyzes the blast radius of symbols at various depths. |\n| `detect_changes` | Identifies the impact of current changes in the code. |\n| `rename` | Facilitates coordinated renaming across multiple files. |\n| `cypher` | Allows for raw graph queries to explore relationships. |\n| `list_repos` | Helps discover indexed repositories. |\n\n### 4. Resources Reference\n\nFor quick navigation, the module lists lightweight resources that provide essential information:\n\n| Resource | Content |\n|----------|---------|\n| `gitnexus://repo/{name}/context` | Overview and staleness check. |\n| `gitnexus://repo/{name}/clusters` | Functional areas with cohesion scores. |\n| `gitnexus://repo/{name}/processes` | All execution flows within the codebase. |\n| `gitnexus://repo/{name}/schema` | Graph schema for Cypher queries. |\n\n### 5. Graph Schema\n\nThe graph schema defines the relationships within the codebase, which can be queried using Cypher. The nodes represent various code elements, while the edges define their relationships.\n\n**Nodes**: File, Function, Class, Interface, Method, Community, Process \n**Edges**: CALLS, IMPORTS, EXTENDS, IMPLEMENTS, DEFINES, MEMBER_OF, STEP_IN_PROCESS\n\nExample Cypher Query:\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"myFunc\"})\nRETURN caller.name, caller.filePath\n```\n\n## Execution Flows\n\nCurrently, there are no detected execution flows for this module. This indicates that the module does not have any internal or external calls, which may suggest it serves primarily as a documentation and guidance tool rather than a functional code component.\n\n## Conclusion\n\nThe **AGENTS.md** module is an essential resource for developers working within the GitNexus MCP. By following the structured approach outlined in this documentation, developers can effectively navigate the codebase, perform necessary analyses, and contribute to the project with confidence. For any further inquiries or clarifications, refer to the skill files or utilize the tools provided for deeper insights into the codebase.","documentation-claude-md":"# Documentation — CLAUDE.md\n\n# CLAUDE.md Documentation\n\n## Overview\n\nThe **CLAUDE.md** module serves as a comprehensive guide for developers working on the **par-term** project, a cross-platform GPU-accelerated terminal emulator frontend built in Rust. This document outlines the project's architecture, development commands, testing strategies, and critical considerations for contributing to the codebase.\n\n## Project Overview\n\n**par-term** leverages the [par-term-emu-core-rust](https://github.com/paulrobello/par-term-emu-core-rust) library for handling VT sequence processing, PTY management, and inline graphics protocols. The frontend utilizes **wgpu** for GPU-accelerated rendering, employing custom WGSL shaders for rendering and post-processing.\n\n### Key Features\n- **Language**: Rust (Edition 2024)\n- **Platform**: Cross-platform (macOS, Linux, Windows)\n- **Graphics API**: wgpu (supports Vulkan, Metal, DirectX 12)\n- **Current Version**: 0.20.0\n\n## Development Commands\n\n### Build & Run\n\nFor day-to-day development, use the following commands to build and run the application:\n\n```bash\nmake build # Dev-release build (optimized)\nmake run # Run in dev-release mode\n```\n\nFor debugging or distribution builds, use:\n\n```bash\nmake build-debug # Debug build (unoptimized)\nmake build-full # Full release build (optimized for distribution)\n```\n\n### Testing & Code Quality\n\nTo ensure code quality and functionality, utilize the following commands:\n\n```bash\nmake test # Run all tests\nmake all # Format, lint, test, and build\nmake pre-commit # Run pre-commit checks\n```\n\n### Debugging\n\nWhen debugging, avoid using `killall par-term` to prevent terminating all instances. Instead, use:\n\n```bash\npkill -f \"target/debug/par-term\" # Safely kill the debug instance\n```\n\nTo run the application with debug logging:\n\n```bash\nmake run-debug # Run with DEBUG_LEVEL=3\n```\n\n### Other Commands\n\nAdditional commands for specific tasks include:\n\n```bash\nmake test-graphics # Test graphics with debug logging\nmake profile # CPU profiling with flamegraph\nmake clean # Clean build artifacts\n```\n\n## Architecture Overview\n\nThe architecture of **par-term** is structured into several key layers, facilitating a clear separation of concerns:\n\n- **App Layer**: Located in `src/app/`, handles application logic and user interactions.\n- **Terminal Layer**: Found in `src/terminal/`, manages terminal emulation and input/output.\n- **Renderer Layer**: Comprises `src/renderer/` and `src/cell_renderer/`, responsible for rendering text and graphics.\n- **GPU Shaders Layer**: Contains custom shaders in `src/shaders/` for rendering effects.\n\n### Data Flow\n\nThe data flow within the application can be summarized as follows:\n\n```mermaid\ngraph TD;\n A[Window Events] --> B[Input Handler];\n B --> C[PTY];\n C --> D[VT Parser];\n D --> E[Styled Segments];\n E --> F[GPU Renderer];\n```\n\n### Key Patterns\n\n- Utilizes the **Tokio** runtime for asynchronous PTY I/O.\n- Implements a glyph atlas for efficient text rendering.\n- Caches RGBA textures for inline graphics protocols (Sixel, iTerm2, Kitty).\n- Maintains a scrollback buffer with viewport offset rendering.\n\n## Code Organization Guidelines\n\nTo maintain code quality and readability, adhere to the following guidelines:\n\n- Keep files under 500 lines; refactor files exceeding 800 lines.\n- Extract modules when logical groupings emerge.\n- Centralize constants and prefer composition over duplication.\n\n## Platform-Specific Notes\n\n- **macOS**: Uses Metal backend; platform-specific code is in `src/macos_metal.rs`.\n- **Linux**: Requires Vulkan backend and X11/Wayland libraries.\n- **Windows**: Utilizes DirectX 12 backend.\n\n## Configuration\n\nConfiguration files are stored in an XDG-compliant manner:\n\n- **Linux/macOS**: `~/.config/par-term/config.yaml`\n- **Windows**: `%APPDATA%\\par-term\\config.yaml`\n\nRefer to `src/config.rs` for available settings and defaults.\n\n## Common Development Workflows\n\n### Adding a New Configuration Option\n\n1. Update the `Config` struct in `src/config.rs`.\n2. Modify the `Default` implementation.\n3. Integrate the new config value in the relevant component.\n4. Add UI controls in the appropriate `src/settings_ui/*_tab.rs`.\n5. Update search keywords in `src/settings_ui/sidebar.rs`.\n\n### Custom Shaders\n\n**par-term** supports two shader systems: **background shaders** and **cursor shaders**. Ensure to develop and debug shaders in the appropriate directories and follow the guidelines in `docs/CUSTOM_SHADERS.md`.\n\n### Debugging PTY Issues\n\nTo debug PTY-related issues, enable logging and check the `TerminalManager::read()` and `write()` methods for I/O errors.\n\n## Testing Considerations\n\n- Some tests may require active PTY sessions and are marked as `#[ignore]`.\n- Integration tests are located in the `tests/` directory and cover various modules.\n\n## Critical Gotchas\n\n- Use `try_lock()` for accessing `tab.terminal` in sync contexts.\n- Avoid using `log::info!()`; instead, utilize custom debug macros for logging.\n\n## Conclusion\n\nThis documentation provides a foundational understanding of the **CLAUDE.md** module and its role within the **par-term** project. By following the guidelines and workflows outlined here, developers can effectively contribute to the codebase and maintain high standards of quality and performance. For further details, refer to the linked documents and resources throughout this guide.","documentation-docs":"# Documentation — docs\n\n# Documentation for the **Documentation — docs** Module\n\nThe **Documentation — docs** module serves as a comprehensive guide for developers working with the `par-term` terminal emulator. It encompasses various aspects of the application, including accessibility features, system architecture, window arrangements, automation capabilities, and more. This documentation is structured to provide clarity on how each component functions and how they interconnect within the overall architecture of the application.\n\n## Table of Contents\n- [Overview](#overview)\n- [Key Components](#key-components)\n - [Accessibility Features](#accessibility-features)\n - [System Architecture](#system-architecture)\n - [Window Arrangements](#window-arrangements)\n - [Automation](#automation)\n - [Badges](#badges)\n - [Command History](#command-history)\n - [Command Separators](#command-separators)\n- [How It Works](#how-it-works)\n- [Configuration](#configuration)\n- [Related Documentation](#related-documentation)\n\n## Overview\n\nThe **docs** module provides essential documentation for the `par-term` terminal emulator, detailing its features, architecture, and configuration options. It is designed to assist developers in understanding the codebase, contributing to its development, and utilizing its features effectively.\n\n## Key Components\n\n### Accessibility Features\n\nThe accessibility features ensure that terminal content is readable and usable for all users. Key functionalities include:\n\n- **Minimum Contrast Enforcement**: Automatically adjusts text colors to meet WCAG standards for contrast.\n- **Configuration Options**: Allows users to set minimum contrast ratios and adjust settings through a user-friendly interface.\n\n### System Architecture\n\nThe architecture of `par-term` is modular, consisting of three primary layers:\n\n1. **Application Layer**: Manages OS events, state, and multi-tab management.\n2. **Emulation Layer**: Handles PTY sessions and VT state.\n3. **Presentation Layer**: Responsible for rendering the terminal output.\n\n```mermaid\ngraph TB\n subgraph \"Application Layer (par-term)\"\n App[App Entry Point]\n WM[Window Manager]\n WS[Window State]\n TabMgr[Tab Manager]\n PaneMgr[Pane Manager]\n TabUI[Tab Bar UI]\n Menu[Native Menu]\n Input[Input Handler]\n Keybind[Keybinding Registry]\n Config[Configuration<br>par-term-config]\n SettingsWin[Settings Window<br>par-term-settings-ui]\n Profile[Profile Manager]\n SSH[SSH Discovery]\n StatusBar[Status Bar]\n ACP[ACP Agent<br>par-term-acp]\n end\n\n subgraph \"Emulation Layer (par-term-terminal)\"\n Tab[Tab / Terminal Session]\n Pane[Pane / Split]\n TM[Terminal Manager]\n Core[Core Emulation Library]\n PTY[PTY Process]\n Tmux[tmux Integration]\n end\n\n subgraph \"Presentation Layer (par-term-render, par-term-fonts)\"\n Renderer[Master Renderer]\n CellRender[Cell Renderer]\n GraphicRender[Graphics Renderer]\n Shader[Custom Shaders]\n Search[Search UI]\n GPU[WGPU / GPU]\n end\n\n App --> WM\n WM --> WS\n WM --> Menu\n WM --> SettingsWin\n Input --> WS\n Keybind --> WS\n WS --> TabMgr\n WS --> TabUI\n TabMgr --> Tab\n Tab --> PaneMgr\n PaneMgr --> Pane\n Pane --> TM\n Tab --> Tmux\n Profile --> Tab\n SSH --> Tab\n StatusBar --> WS\n WS --> Renderer\n TM --> Core\n Core <--> PTY\n Tmux <--> PTY\n Core --> Renderer\n Renderer --> CellRender\n Renderer --> GraphicRender\n Renderer --> Search\n CellRender --> Shader\n Shader --> GPU\n GraphicRender --> GPU\n```\n\n### Window Arrangements\n\nThe window arrangements feature allows users to save and restore complete window layouts, including positions, sizes, and active tabs. This functionality is crucial for users who frequently switch between different working environments.\n\n### Automation\n\nThe automation system enables developers to react to terminal output with regex-based triggers, execute actions, run coprocesses, and observer scripts. This feature enhances the terminal's interactivity and responsiveness to user commands.\n\n### Badges\n\nBadges provide a visual representation of session information, such as the current user and host, displayed in the terminal corner. This feature enhances the user experience by providing contextual information without cluttering the terminal output.\n\n### Command History\n\nThe command history feature allows users to search and re-execute previous commands using fuzzy matching. This functionality improves productivity by enabling quick access to frequently used commands.\n\n### Command Separators\n\nCommand separators visually delineate the output of different commands in the terminal, enhancing readability. This feature requires shell integration to function correctly.\n\n## How It Works\n\nThe **docs** module integrates with the core components of `par-term` to provide a seamless user experience. Each feature is designed to interact with the terminal's rendering engine, input handling, and event management systems. For example, the accessibility features utilize the rendering engine to adjust text colors dynamically based on user settings.\n\n## Configuration\n\nConfiguration options for the **docs** module can be set in the `config.yaml` file. Each feature has its own set of configurable parameters, allowing users to customize their terminal experience according to their preferences.\n\n### Example Configuration\n\n```yaml\n# Accessibility settings\nminimum_contrast: 4.5\n\n# Window arrangements\nauto_restore_arrangement: \"Work Setup\"\n\n# Badges\nbadge_enabled: true\nbadge_format: \"\\\\(session.username)@\\\\(session.hostname)\"\n```\n\n## Related Documentation\n\n- [Accessibility](ACCESSIBILITY.md) - Detailed information on accessibility features.\n- [System Architecture](ARCHITECTURE.md) - Overview of the `par-term` architecture.\n- [Window Management](WINDOW_MANAGEMENT.md) - Managing window layouts and arrangements.\n- [Automation](AUTOMATION.md) - Triggers, actions, and scripting capabilities.\n- [Badges](BADGES.md) - Configuration and usage of badges in the terminal.\n- [Command History](COMMAND_HISTORY.md) - Searching and managing command history.\n- [Command Separators](COMMAND_SEPARATORS.md) - Visual separators for command output.\n\nThis documentation serves as a comprehensive guide for developers to understand and contribute to the `par-term` terminal emulator effectively. Each section provides insights into the functionality and configuration of the various components, ensuring a smooth development experience.","documentation-gemini-md":"# Documentation — GEMINI.md\n\n# GEMINI Module Documentation\n\n## Overview\n\nThe **GEMINI** module serves as a documentation file that references another documentation file, **CLAUDE.md**. This module does not contain any executable code or logic; instead, it acts as a pointer to the **CLAUDE** documentation, which presumably contains the actual content and details relevant to the GEMINI context.\n\n## Purpose\n\nThe primary purpose of the GEMINI module is to provide a structured way to access the documentation contained in **CLAUDE.md**. This can be useful for developers who are navigating the codebase and need to understand the context or functionality that **CLAUDE.md** covers.\n\n## Key Components\n\n### 1. Reference to CLAUDE.md\n\nThe only significant component of the GEMINI module is the line:\n\n```markdown\nread @CLAUDE.md\n```\n\nThis line indicates that the content of **CLAUDE.md** should be read or included when accessing the GEMINI documentation. \n\n### 2. No Internal Logic\n\nGEMINI does not contain any internal functions, classes, or logic. It is purely a documentation reference, which means it does not interact with other parts of the codebase in a traditional sense. There are no incoming or outgoing calls, and no execution flows are detected.\n\n## How It Connects to the Codebase\n\nSince GEMINI is a documentation file, its connection to the rest of the codebase is indirect. Developers will typically access GEMINI to find information that is elaborated in **CLAUDE.md**. \n\n### Usage Scenario\n\nWhen a developer needs to understand a specific feature or functionality that is documented in **CLAUDE.md**, they can refer to GEMINI to locate that documentation quickly. This modular approach to documentation helps maintain clarity and organization within the codebase.\n\n## Conclusion\n\nThe GEMINI module is a straightforward documentation reference that enhances the navigability of the codebase by linking to **CLAUDE.md**. While it does not contain any executable code or logic, it plays a crucial role in guiding developers to the relevant documentation they need to understand the system better.\n\nFor further details, developers should refer to **CLAUDE.md** directly, as it contains the substantive content that GEMINI points to.","documentation-matrix-md":"# Documentation — MATRIX.md\n\n# Documentation for MATRIX.md Module\n\n## Overview\n\nThe **MATRIX.md** module serves as a comprehensive feature comparison matrix between two terminal emulators: **iTerm2** and **par-term**. This document provides a detailed assessment of the features available in both applications, categorizing them by functionality, implementation status, usefulness, and estimated effort required for implementation. The goal is to facilitate developers in understanding the current capabilities of **par-term** relative to **iTerm2**, identify gaps, and prioritize future development efforts.\n\n## Purpose\n\nThe primary purpose of this module is to:\n- Provide a clear and structured comparison of features between **iTerm2** and **par-term**.\n- Highlight implemented, partially implemented, and unimplemented features in **par-term**.\n- Assess the usefulness of each feature and the effort required for its implementation.\n- Serve as a reference for developers to identify areas for improvement and feature parity with **iTerm2**.\n\n## Structure\n\nThe document is organized into several sections, each focusing on a specific category of terminal features. Each section contains a table that outlines the features, their status, usefulness, effort, and additional notes. The categories include:\n\n1. **Terminal Dimensions & Window**\n2. **Typography & Fonts**\n3. **Cursor**\n4. **Background & Visual Effects**\n5. **Colors & Themes**\n6. **Tab Bar**\n7. **Scrollback & Scrollbar**\n8. **Selection & Clipboard**\n9. **Mouse & Pointer**\n10. **Keyboard & Input**\n11. **Shell & Session**\n12. **Notifications & Bell**\n13. **Logging & Recording**\n14. **Profiles**\n15. **Split Panes**\n16. **Inline Graphics**\n17. **Hyperlinks & URLs**\n18. **Triggers & Automation**\n19. **tmux Integration**\n20. **Performance & Power**\n21. **Accessibility**\n22. **AI Integration**\n23. **Status Bar**\n24. **Toolbelt**\n25. **Composer & Auto-Complete**\n26. **Copy Mode**\n27. **Snippets & Actions**\n28. **Window Arrangements & Placement**\n29. **Session Management & Quit Behavior**\n30. **Tab Styles & Appearance**\n31. **Pane & Split Customization**\n32. **Profile Switching & Dynamic Profiles**\n33. **Image Protocol Enhancements**\n34. **Audio & Haptic Feedback**\n35. **Advanced GPU & Rendering Settings**\n36. **Advanced Configuration**\n37. **Unicode & Text Processing**\n38. **Browser Integration**\n39. **Progress Bars**\n40. **Advanced Paste & Input**\n41. **Advanced Shell Integration**\n42. **Network & Discovery**\n43. **Miscellaneous**\n44. **Badges**\n\n## Key Components\n\n### Feature Tables\n\nEach section contains a feature table with the following columns:\n\n- **Feature**: The name of the feature being compared.\n- **iTerm2**: The implementation status and details of the feature in iTerm2.\n- **par-term**: The implementation status and details of the feature in par-term.\n- **Status**: Indicates whether the feature is implemented (✅), partially implemented (🔶), or not implemented (❌).\n- **Useful**: A rating of the feature's importance (⭐⭐⭐ = Essential, ⭐⭐ = Nice to have, ⭐ = Low priority, ➖ = Not applicable).\n- **Effort**: An estimate of the effort required to implement the feature (🟢 = Low, 🟡 = Medium, 🔴 = High, 🔵 = Very High).\n- **Notes**: Additional information or context regarding the feature.\n\n### Implementation Status\n\nThe status of each feature is crucial for developers to understand what is currently available in **par-term** and what needs to be prioritized for future development. The status is categorized as follows:\n\n- **Implemented (✅)**: The feature is fully functional in **par-term**.\n- **Partial (🔶)**: The feature is partially implemented, with some functionality available but not complete.\n- **Not Implemented (❌)**: The feature is not available in **par-term**.\n\n### Usefulness and Effort Ratings\n\nThe usefulness and effort ratings help prioritize development tasks. Features rated as essential (⭐⭐⭐) should be prioritized for implementation, while those with low priority (⭐) can be considered for future releases. Similarly, features with low effort (🟢) can be implemented quickly, while those with high effort (🔴) may require more planning and resources.\n\n## Connection to the Codebase\n\nThe **MATRIX.md** module does not directly interact with the codebase but serves as a reference document for developers working on the **par-term** project. It provides insights into feature parity with **iTerm2**, guiding development efforts and ensuring that the terminal emulator remains competitive and feature-rich.\n\n### Future Development\n\nThe matrix highlights areas where **par-term** can improve its feature set to match or exceed that of **iTerm2**. Developers can use this document to identify high-priority features that need to be implemented or improved, ensuring that the terminal emulator evolves to meet user needs.\n\n## Conclusion\n\nThe **MATRIX.md** module is an essential resource for developers working on the **par-term** project. It provides a structured comparison of features between **iTerm2** and **par-term**, helping to identify gaps and prioritize future development efforts. By understanding the current capabilities and areas for improvement, developers can work towards creating a more robust and feature-rich terminal emulator.\n\n```mermaid\ngraph TD;\n A[Feature Comparison Matrix] --> B[Terminal Dimensions & Window]\n A --> C[Typography & Fonts]\n A --> D[Cursor]\n A --> E[Background & Visual Effects]\n A --> F[Colors & Themes]\n A --> G[Tab Bar]\n A --> H[Scrollback & Scrollbar]\n A --> I[Selection & Clipboard]\n A --> J[Mouse & Pointer]\n A --> K[Keyboard & Input]\n A --> L[Shell & Session]\n A --> M[Notifications & Bell]\n A --> N[Logging & Recording]\n A --> O[Profiles]\n A --> P[Split Panes]\n A --> Q[Inline Graphics]\n A --> R[Hyperlinks & URLs]\n A --> S[Triggers & Automation]\n A --> T[tmux Integration]\n A --> U[Performance & Power]\n A --> V[Accessibility]\n A --> W[AI Integration]\n A --> X[Status Bar]\n A --> Y[Toolbelt]\n A --> Z[Composer & Auto-Complete]\n A --> AA[Copy Mode]\n A --> AB[Snippets & Actions]\n A --> AC[Window Arrangements & Placement]\n A --> AD[Session Management & Quit Behavior]\n A --> AE[Tab Styles & Appearance]\n A --> AF[Pane & Split Customization]\n A --> AG[Profile Switching & Dynamic Profiles]\n A --> AH[Image Protocol Enhancements]\n A --> AI[Audio & Haptic Feedback]\n A --> AJ[Advanced GPU & Rendering Settings]\n A --> AK[Advanced Configuration]\n A --> AL[Unicode & Text Processing]\n A --> AM[Browser Integration]\n A --> AN[Progress Bars]\n A --> AO[Advanced Paste & Input]\n A --> AP[Advanced Shell Integration]\n A --> AQ[Network & Discovery]\n A --> AR[Miscellaneous]\n A --> AS[Badges]\n```\n\nThis diagram illustrates the hierarchical structure of the feature comparison matrix, showing how each category connects to the overall purpose of the module.","documentation-panes-md":"# Documentation — PANES.md\n\n# Documentation for PANES.md Module\n\n## Overview\n\nThe **PANES.md** module outlines the implementation of split panes and native tmux integration for the par-term terminal emulator. This document serves as a guide for developers looking to understand the architecture, features, and implementation phases of these functionalities.\n\n### Purpose\n\nThe primary goal of this module is to enhance the terminal experience by allowing users to split their terminal view into multiple panes, both horizontally and vertically, and to integrate seamlessly with tmux, a terminal multiplexer. This integration allows users to manage their terminal sessions more effectively, leveraging the capabilities of both split panes and tmux.\n\n## Key Features\n\n### Split Panes\n\nThe split panes feature includes:\n\n- **Horizontal and Vertical Splits**: Users can split the terminal into multiple panes, either stacked vertically or side by side.\n- **Pane Navigation**: Users can easily switch focus between panes using keyboard shortcuts.\n- **Pane Resizing**: Users can resize panes using keyboard shortcuts or mouse interactions.\n- **Visual Indicators**: Inactive panes can be dimmed to provide a clear focus indicator.\n- **Per-pane Titles and Backgrounds**: Each pane can have its own title and background image.\n- **Broadcast Input**: Users can send input to multiple panes simultaneously.\n\n### tmux Integration\n\nThe tmux integration feature includes:\n\n- **Control Mode**: Utilizes tmux's control mode (`-CC`) for structured command output.\n- **Native Tabs**: Maps tmux windows to native tabs in the par-term UI.\n- **Pane Synchronization**: Maps tmux panes to native split panes, maintaining the layout.\n- **Session Management**: Provides a UI for listing and attaching to tmux sessions.\n- **Clipboard Synchronization**: Syncs clipboard contents between tmux and par-term.\n\n## Architecture\n\n### Pane Tree Data Structure\n\nThe core of the split panes feature is the **Pane Tree Data Structure**, which is a binary tree that allows for arbitrary nesting of splits. The structure is defined as follows:\n\n```rust\nWindow\n└── Tab\n └── PaneNode (enum)\n ├── Leaf { terminal_id, bounds }\n └── Split { direction, ratio, children: [PaneNode, PaneNode] }\n```\n\n- **Leaf Nodes**: Represent individual terminal instances.\n- **Split Nodes**: Represent a split in the terminal, defined by direction (horizontal or vertical) and a ratio that determines the split position.\n\n### Pane Manager Component\n\nThe `PaneManager` struct, located in `src/app/pane_manager.rs`, is responsible for managing the pane tree. Key methods include:\n\n- `split_horizontal()`: Splits the current pane horizontally.\n- `split_vertical()`: Splits the current pane vertically.\n- `close_pane()`: Closes the currently focused pane.\n- `resize_pane()`: Resizes the focused pane.\n\nThe `PaneManager` also tracks the currently focused pane using `focused_pane_id` and recalculates layouts on window resize events.\n\n### Rendering Changes\n\nThe rendering system must support multiple viewports for each pane. Key changes include:\n\n- **CellRenderer**: Needs to render each pane in its designated region.\n- **Dividers**: Customizable dividers between panes for visual separation.\n- **Inactive Pane Dimming**: Implemented via shader uniforms or post-processing techniques.\n\n### Input Routing\n\nInput routing is crucial for user interaction:\n\n- **Mouse Events**: Routed to the pane under the cursor.\n- **Keyboard Input**: Routed to the focused pane.\n- **Keyboard Shortcuts**: Defined for navigation and resizing, compatible with iTerm2.\n\n## Implementation Phases\n\nThe implementation is divided into five phases, each building upon the previous one:\n\n1. **Phase 1: Split Pane Foundation** (Weeks 1-3)\n - Implement basic split functionality and navigation.\n \n2. **Phase 2: Split Pane Polish** (Weeks 4-5)\n - Enhance features like resizing, dimming, and titles.\n\n3. **Phase 3: tmux Control Mode** (Weeks 6-8)\n - Establish basic tmux integration and session management.\n\n4. **Phase 4: tmux Pane Integration** (Weeks 9-11)\n - Full synchronization of tmux panes with native splits.\n\n5. **Phase 5: Advanced Features** (Weeks 12-14)\n - Complete feature parity with iTerm2, including advanced input broadcasting and clipboard sync.\n\n## Integration with the Codebase\n\nThe PANES.md module connects with the broader par-term codebase through the following components:\n\n- **Core Library**: Utilizes the `par-term-emu-core-rust` library for tmux control mode support and notification parsing.\n- **Session Management**: The new `src/tmux/` module handles tmux session state and lifecycle, including commands and synchronization.\n- **User Interface**: Integrates with the par-term UI to provide a seamless user experience for managing tabs and panes.\n\n### Mermaid Diagram\n\nThe following diagram illustrates the relationship between the key components of the PANES.md module:\n\n```mermaid\ngraph TD;\n A[User Input] -->|Keyboard/Mouse| B[Input Routing]\n B --> C[Pane Manager]\n C --> D[Pane Tree]\n D --> E[Leaf Nodes]\n D --> F[Split Nodes]\n C --> G[Rendering Changes]\n G --> H[CellRenderer]\n G --> I[Dividers]\n C --> J[Focus Tracking]\n C --> K[Resize Handling]\n L[tmux Integration] --> M[Session Manager]\n M --> N[Notification Parser]\n M --> O[Command Builders]\n```\n\n## Conclusion\n\nThe PANES.md module is a critical component of the par-term terminal emulator, providing essential features for split pane management and tmux integration. By understanding its architecture, features, and implementation phases, developers can effectively contribute to its development and enhancement. \n\nFor further details, refer to the references section for links to related documentation and resources.","documentation-quick-start-fonts-md":"# Documentation — QUICK_START_FONTS.md\n\n# Quick Start: Font Features in par-term\n\n## Overview\n\nThe **Quick Start: Font Features** module provides a streamlined guide for developers to configure and utilize advanced font rendering capabilities in the `par-term` terminal emulator. This module focuses on ensuring that text is displayed using high-quality, properly styled fonts, including support for CJK (Chinese, Japanese, Korean) characters, emojis, and mathematical symbols.\n\n## Purpose\n\nThe primary goal of this module is to enhance the visual quality of text in the terminal by allowing users to specify custom fonts for different styles and character sets. This is particularly important for developers who require precise rendering of text in various languages and formats.\n\n## Key Components\n\n### 1. Font Configuration\n\nThe core of the module revolves around the configuration file located at `~/.config/par-term/config.yaml`. This file allows users to specify:\n\n- **Primary Font Family**: The default font used for regular text.\n- **Styled Fonts**: Specific fonts for bold, italic, and bold-italic text.\n- **Font Ranges**: Custom fonts for specific Unicode ranges, such as CJK characters, emojis, and mathematical symbols.\n\n### 2. Font Availability Check\n\nBefore configuring fonts, users are encouraged to verify the availability of the desired fonts using the `fc-list` command. This ensures that the specified fonts are installed on the system.\n\n### 3. Testing Font Rendering\n\nThe module provides a series of commands to test the rendering of different font styles and character sets. This includes commands for bold, italic, CJK characters, emojis, and mathematical symbols.\n\n### 4. Troubleshooting\n\nCommon issues related to font rendering are addressed in the troubleshooting section, providing solutions for problems such as missing fonts or incorrect configurations.\n\n## Configuration Steps\n\n### Basic Font Setup\n\n1. **Check Font Availability**: Use the command line to verify that the desired fonts are installed.\n ```bash\n fc-list | grep -i \"JetBrains Mono\"\n ```\n\n2. **Update Configuration**: Edit the `config.yaml` file to specify the font families.\n ```yaml\n font_family: \"JetBrains Mono\"\n font_family_bold: \"JetBrains Mono Bold\"\n font_family_italic: \"JetBrains Mono Italic\"\n font_family_bold_italic: \"JetBrains Mono Bold Italic\"\n ```\n\n3. **Test the Configuration**: Start `par-term` and run commands to verify that the fonts render correctly.\n ```bash\n par-term\n echo -e \"\\e[1mBold Text\\e[0m\"\n echo -e \"\\e[3mItalic Text\\e[0m\"\n ```\n\n### CJK Support\n\nTo enable proper rendering of CJK characters:\n\n1. **Install CJK Fonts**: Ensure that the necessary fonts are installed.\n ```bash\n sudo apt install fonts-noto-cjk # For Debian/Ubuntu\n ```\n\n2. **Update Configuration**: Add font ranges for CJK characters in `config.yaml`.\n ```yaml\n font_ranges:\n - start: 0x4E00\n end: 0x9FFF\n font_family: \"Noto Sans CJK SC\"\n ```\n\n3. **Test CJK Rendering**: Start `par-term` and run commands to display CJK characters.\n ```bash\n echo \"Chinese: 你好世界\"\n ```\n\n### Emoji and Math Symbols\n\nSimilar steps can be followed to configure emoji and mathematical symbols, ensuring that the appropriate fonts are specified in the configuration file.\n\n## Complete Setup Example\n\nFor a comprehensive setup that includes all features, the following configuration can be used:\n\n```yaml\nfont_family: \"JetBrains Mono\"\nfont_size: 14.0\n\nfont_family_bold: \"JetBrains Mono Bold\"\nfont_family_italic: \"JetBrains Mono Italic\"\nfont_family_bold_italic: \"JetBrains Mono Bold Italic\"\n\nfont_ranges:\n - start: 0x4E00\n end: 0x9FFF\n font_family: \"Noto Sans CJK SC\"\n - start: 0x1F600\n end: 0x1F64F\n font_family: \"Apple Color Emoji\"\n - start: 0x2200\n end: 0x22FF\n font_family: \"STIX Two Math\"\n - start: 0x2500\n end: 0x257F\n font_family: \"DejaVu Sans Mono\"\n```\n\n## Testing Script\n\nA test script (`test_fonts.sh`) is provided to automate the verification of font features. This script covers various text types, including ASCII, bold, italic, CJK characters, emojis, and mathematical symbols.\n\n```bash\n#!/bin/bash\n# Test script for par-term font features\n# (Content omitted for brevity)\n```\n\nMake the script executable and run it to ensure all features are functioning as expected.\n\n## Troubleshooting Common Issues\n\n### Styled Fonts Not Working\n\n- Verify that the fonts are installed using `fc-list`.\n- Check for spelling errors in the configuration file.\n\n### CJK Characters Showing Boxes\n\n- Ensure that CJK fonts are installed.\n- Verify the font names in the configuration.\n\n### Emoji Not Rendering\n\n- Check for the presence of emoji fonts.\n- Update the configuration to match the installed font names.\n\n## Conclusion\n\nThe **Quick Start: Font Features** module is designed to help developers quickly set up and test advanced font rendering in the `par-term` terminal. By following the outlined steps, users can achieve high-quality text display tailored to their needs.\n\n## Next Steps\n\n- Explore the `examples/` directory for complete configurations.\n- Review `examples/README.md` for a comprehensive guide.\n- Check `IMPLEMENTATION_SUMMARY.md` for technical details.\n- Experiment with different font combinations to find the best fit for your terminal experience.\n\n## Pro Tips\n\n1. Start with basic configurations and gradually add features.\n2. Test each font range individually to isolate issues.\n3. Use logging to debug font loading issues.\n\n---\n\n```mermaid\ngraph TD;\n A[User] -->|Configures| B[config.yaml]\n B -->|Specifies| C[Font Families]\n B -->|Specifies| D[Font Ranges]\n C -->|Renders| E[Terminal Output]\n D -->|Renders| E\n E -->|Displays| F[Styled Text]\n E -->|Displays| G[CJK Characters]\n E -->|Displays| H[Emojis]\n E -->|Displays| I[Math Symbols]\n```\n\nEnjoy your beautifully rendered terminal! 🎉","documentation-readme-md":"# Documentation — README.md\n\n# par-term Documentation\n\n## Overview\n\nThe **par-term** module is a cross-platform, GPU-accelerated terminal emulator frontend built with Rust. It leverages the **par-term-emu-core-rust** library to provide high-performance terminal emulation, modern typography, and rich graphics support. This module is designed to enhance the terminal experience with features such as multi-window support, customizable profiles, and advanced rendering capabilities.\n\n## Key Features\n\n- **Cross-Platform Support**: Runs on macOS, Linux, and Windows with native performance.\n- **GPU-Accelerated Rendering**: Utilizes `wgpu` for efficient text rasterization and rendering.\n- **Multi-Window & Multi-Tab Management**: Supports multiple independent terminal sessions in separate windows and tabs.\n- **Custom GLSL Shaders**: Offers a variety of shaders for background effects and cursor animations.\n- **Advanced Input Handling**: Full support for pseudo-terminal (PTY) integration and advanced input features.\n- **Dynamic Themes and Customization**: Allows users to customize themes, fonts, and terminal behavior.\n\n## Architecture\n\nThe architecture of **par-term** is modular, allowing for easy maintenance and extensibility. The core components include:\n\n- **Terminal Engine**: The underlying terminal emulation logic is handled by the **par-term-emu-core-rust** library.\n- **Rendering Engine**: The rendering is powered by `wgpu`, which provides GPU-accelerated graphics.\n- **User Interface**: The settings and overlays are managed using the `egui` library, providing a responsive and modern UI.\n- **Configuration Management**: Configuration is handled through YAML files, allowing for easy customization and persistence.\n\n### Component Interaction\n\n```mermaid\ngraph TD;\n A[User Interface] -->|Interacts with| B[Rendering Engine]\n B -->|Renders| C[Terminal Output]\n C -->|Uses| D[Terminal Engine]\n D -->|Processes| E[User Input]\n E -->|Sends to| A\n```\n\n## Core Components\n\n### 1. Terminal Engine\n\nThe terminal engine is responsible for emulating terminal behavior, including handling escape sequences, managing input/output, and maintaining the terminal state. It is built on the **par-term-emu-core-rust** library, which provides compatibility with various terminal standards (VT100, VT220, etc.).\n\n### 2. Rendering Engine\n\nThe rendering engine utilizes `wgpu` to perform GPU-accelerated rendering of text and graphics. It manages the rendering pipeline, including text rasterization, shader application, and frame buffering. This component is crucial for achieving high performance and responsiveness in the terminal.\n\n### 3. User Interface\n\nThe user interface is built using the `egui` library, which allows for a responsive and interactive settings panel. Users can configure terminal settings, manage profiles, and customize their experience through this interface.\n\n### 4. Configuration Management\n\nConfiguration is stored in YAML format, allowing users to define terminal behavior, appearance, and other settings. The configuration file is loaded at startup, and changes can be made through the settings UI or directly in the YAML file.\n\n## Getting Started\n\n### Installation\n\nTo install **par-term**, you can use Homebrew on macOS or build from source. Here are the steps for both methods:\n\n#### Homebrew (macOS)\n\n```bash\nbrew install --cask paulrobello/tap/par-term\n```\n\n#### From Source\n\n1. Clone the repository:\n ```bash\n git clone https://github.com/paulrobello/par-term\n cd par-term\n ```\n\n2. Build and run:\n ```bash\n cargo run\n ```\n\n3. For an optimized release version:\n ```bash\n cargo build --release\n ./target/release/par-term\n ```\n\n### Configuration\n\nConfiguration is managed through a YAML file located at:\n\n- **Unix**: `~/.config/par-term/config.yaml`\n- **Windows**: `%APPDATA%\\par-term\\config.yaml`\n\nHere’s an example configuration snippet:\n\n```yaml\ncols: 80\nrows: 24\nfont_size: 13.0\nfont_family: \"JetBrains Mono\"\ntheme: \"dark-background\"\n```\n\n## Contributing\n\nContributions to **par-term** are welcome! To contribute, please ensure you follow the coding standards and run the checks before submitting a pull request:\n\n```bash\nmake checkall\n```\n\n## Conclusion\n\nThe **par-term** module is a powerful terminal emulator that combines modern graphics capabilities with a rich feature set. Its modular architecture allows for easy enhancements and maintenance, making it an excellent choice for developers looking to contribute to an open-source terminal project. For more detailed information on specific features, refer to the documentation sections provided in the README.","documentation":"# Documentation\n\n# Documentation Module Overview\n\nThe **Documentation** module serves as a centralized resource for developers working on the **par-term** terminal emulator project. It encompasses several sub-modules, each focusing on different aspects of the project, from architecture and feature comparisons to specific functionalities and quick-start guides. Together, these sub-modules provide a comprehensive understanding of the project, facilitating effective development and contribution.\n\n## Purpose\n\nThe primary purpose of the Documentation module is to equip developers with the necessary information to navigate, understand, and contribute to the **par-term** codebase. It covers essential topics such as architecture, feature comparisons, and implementation details, ensuring that developers can efficiently engage with the project.\n\n## Sub-module Integration\n\nThe sub-modules within the Documentation module are interconnected, each contributing to a holistic understanding of the **par-term** project:\n\n- **[AGENTS.md](AGENTS.md)**: Provides foundational guidelines for understanding the overall architecture and performing impact analysis, which is crucial for developers working across all aspects of the project.\n \n- **[CLAUDE.md](CLAUDE.md)**: Offers a detailed guide on the **par-term** project, including its architecture and development practices. This module is essential for developers looking to contribute to the core functionalities of the terminal emulator.\n\n- **[GEMINI.md](GEMINI.md)**: Acts as a reference to **CLAUDE.md**, streamlining access to its content and ensuring that developers can easily find relevant information.\n\n- **[MATRIX.md](MATRIX.md)**: Provides a feature comparison between **iTerm2** and **par-term**, helping developers identify gaps and prioritize future enhancements based on the current capabilities of the terminal emulator.\n\n- **[PANES.md](PANES.md)**: Details the implementation of split panes and tmux integration, enhancing the terminal experience. This module is particularly relevant for developers focused on user interface improvements.\n\n- **[QUICK_START_FONTS.md](QUICK_START_FONTS.md)**: Offers a quick-start guide for configuring advanced font features, ensuring that developers can enhance text rendering quality in the terminal.\n\n- **[README.md](README.md)**: Serves as the main entry point for the **par-term** project, summarizing its key features and functionalities.\n\n- **[docs](docs)**: Provides a comprehensive guide covering various aspects of the application, including accessibility features and system architecture, further enriching the developer's understanding of the project.\n\n## Key Workflows\n\nThe workflows that span these sub-modules include:\n\n1. **Understanding Architecture**: Developers can start with **AGENTS.md** to grasp the overall architecture, then dive into **CLAUDE.md** for specific project details.\n\n2. **Feature Development**: Using **MATRIX.md**, developers can assess existing features and identify areas for improvement, while **PANES.md** and **QUICK_START_FONTS.md** provide guidance on implementing specific functionalities.\n\n3. **Documentation Navigation**: The **GEMINI.md** module simplifies access to **CLAUDE.md**, ensuring that developers can quickly find the information they need.\n\nBy leveraging the interconnected nature of these sub-modules, developers can efficiently navigate the **par-term** project and contribute effectively. For detailed information on each aspect, please refer to the respective sub-module documentation.","examples":"# Examples\n\n# Examples Module Documentation\n\n## Overview\n\nThe **Examples** module provides a collection of configuration files that demonstrate various features of the `par-term` terminal emulator. These configurations showcase how to effectively utilize font styling, text shaping, and Unicode range mapping to enhance the terminal's visual output. This documentation will guide developers through the purpose, structure, and usage of the example configurations.\n\n## Purpose\n\nThe primary goal of the Examples module is to serve as a reference for users who want to customize their terminal experience. By providing clear examples, developers can quickly understand how to implement specific features and configurations in their own setups.\n\n## Key Components\n\nThe Examples module consists of several YAML configuration files, each demonstrating different aspects of terminal configuration:\n\n1. **`config-styled-fonts.yaml`**: \n - **Purpose**: Showcases the use of separate font families for bold and italic text.\n - **Key Features**:\n ```yaml\n font_family: \"JetBrains Mono\"\n font_family_bold: \"JetBrains Mono Bold\"\n font_family_italic: \"JetBrains Mono Italic\"\n font_family_bold_italic: \"JetBrains Mono Bold Italic\"\n ```\n\n2. **`config-text-shaping.yaml`**:\n - **Purpose**: Demonstrates HarfBuzz text shaping for ligatures and complex scripts.\n - **Key Features**:\n ```yaml\n enable_text_shaping: true\n enable_ligatures: true\n enable_kerning: true\n font_family: \"Fira Code\"\n ```\n\n3. **`config-font-ranges.yaml`**:\n - **Purpose**: Illustrates Unicode range-based font mapping.\n - **Key Features**:\n ```yaml\n font_ranges:\n - start: 0x4E00\n end: 0x9FFF\n font_family: \"Noto Sans CJK SC\"\n ```\n\n4. **`config-complete.yaml`**:\n - **Purpose**: A comprehensive configuration that combines all features.\n - **Key Features**: Includes styled fonts, Unicode ranges, and detailed comments.\n\n## Configuration Structure\n\nEach configuration file follows a structured format that includes:\n\n- **Terminal Dimensions**: Specifies the number of columns and rows.\n- **Font Configuration**: Defines the primary font and any styled variants.\n- **Unicode Range-Specific Fonts**: Maps specific Unicode ranges to designated fonts.\n- **Text Shaping Options**: Enables HarfBuzz for ligatures and kerning.\n- **Scrollback and Theme Settings**: Configures scrollback lines and visual themes.\n\n### Example Configuration Flow\n\nThe following Mermaid diagram illustrates the flow of font selection based on the configuration settings:\n\n```mermaid\ngraph TD;\n A[Text Input] --> B{Is Text Styled?}\n B -- Yes --> C[Use Styled Font]\n B -- No --> D{Is Character in Unicode Range?}\n D -- Yes --> E[Use Unicode Range Font]\n D -- No --> F[Use General Fallback Font]\n C --> G[Render Text]\n E --> G\n F --> G\n```\n\n## Font Selection Priority\n\nUnderstanding the font selection priority is crucial for achieving the desired rendering:\n\n1. **Styled Fonts**: Used for bold, italic, or bold-italic text.\n2. **Unicode Range Fonts**: Checked in order; the first match wins.\n3. **General Fallback Fonts**: System fonts with good Unicode coverage.\n4. **Primary Font**: The default font used for all other text.\n\n### Example Scenarios\n\n- **Bold CJK Text**: If the character is bold and falls within the CJK range, the configured CJK font will be used instead of the bold font.\n- **Emoji Rendering**: Emoji characters will always use the designated emoji font, regardless of other styling.\n\n## Best Practices\n\n1. **Font Availability**: Ensure that the specified fonts are installed on the system before configuring.\n2. **Testing Configurations**: Create test files with various Unicode characters to verify font rendering.\n3. **Performance Considerations**: Be mindful of the number of font ranges, as more ranges may slightly increase lookup time.\n\n## Troubleshooting\n\nCommon issues and their resolutions include:\n\n- **Font Not Being Used**: Check if the font is installed and correctly referenced in the configuration.\n- **Bold/Italic Not Working**: Ensure that the styled font families are installed and correctly named.\n- **Missing Characters**: Verify that the character is included in the defined Unicode ranges and that the font supports the glyph.\n\n## Configuration Location\n\nTo apply a configuration, copy the desired YAML file to the appropriate location:\n\n- **macOS/Linux**: `~/.config/par-term/config.yaml`\n- **Windows**: `%APPDATA%\\par-term\\config.yaml`\n\nAlternatively, use the `--config` flag to specify a custom path:\n```bash\npar-term --config path/to/config.yaml\n```\n\n## Conclusion\n\nThe Examples module is a valuable resource for developers looking to customize their terminal experience with `par-term`. By understanding the provided configurations and their components, users can effectively enhance their terminal's visual output and functionality. For further reading, refer to the [Unicode Character Ranges](https://en.wikipedia.org/wiki/Unicode_block) and the [Font Configuration Guide](../docs/FONTS.md). \n\n## Contributing\n\nDevelopers are encouraged to contribute their own configuration examples by submitting a pull request to this module.","fonts":"# Fonts\n\n# Fonts Module Documentation\n\n## Overview\n\nThe **Fonts** module is a critical component of the par-term terminal emulator, responsible for managing font loading, fallback mechanisms, and text shaping. It ensures comprehensive Unicode coverage by providing a structured way to load fonts from the system, handle various font styles, and shape text for rendering. This module is designed to support a wide range of characters, including ASCII, CJK (Chinese, Japanese, Korean), emojis, and other Unicode symbols.\n\n## Key Components\n\n### 1. FontManager\n\nThe `FontManager` is the central class in this module, orchestrating the loading and management of fonts. It handles the following tasks:\n\n- **Primary Font Loading**: Loads the primary font specified by the user or falls back to an embedded font if none is provided.\n- **Styled Font Variants**: Supports bold, italic, and bold-italic variants of the primary font.\n- **Fallback Chain**: Constructs a fallback chain of fonts to ensure that missing glyphs can be rendered using alternative fonts.\n- **Unicode Range Fonts**: Allows for the specification of fonts that cover specific Unicode ranges, such as CJK characters or emojis.\n- **Glyph Lookup**: Provides methods to find glyphs for characters, taking into account the specified styles (bold, italic).\n\n#### Mermaid Diagram: FontManager Architecture\n\n```mermaid\ngraph TD;\n A[FontManager] -->|loads| B[Primary Font]\n A -->|loads| C[Styled Fonts]\n A -->|builds| D[Fallback Chain]\n A -->|loads| E[Unicode Range Fonts]\n A -->|finds| F[Glyphs]\n```\n\n### 2. FontData\n\nThe `FontData` struct encapsulates the raw font data and provides a `FontRef` for glyph operations. It ensures that the font data is managed correctly, allowing for safe access during rendering.\n\n### 3. Fallbacks\n\nThe `FALLBACK_FAMILIES` constant defines a prioritized list of fallback font families. This list is used when the primary font does not contain a required glyph. The order of fonts is designed to cover various use cases, including:\n\n- Nerd Font icons\n- Standard monospace fonts\n- CJK support\n- Emoji and symbol fonts\n- General Unicode coverage\n\n### 4. Loader Functions\n\nThe `loader` module provides utility functions for loading fonts from the system and embedded resources. Key functions include:\n\n- `load_embedded_font()`: Loads a default embedded font (DejaVu Sans Mono) when no system fonts are available.\n- `load_font_from_db()`: Loads a font from the system font database based on the family name.\n- `load_font_from_db_with_style()`: Loads a font with specific style attributes (weight and style).\n\n### 5. Text Shaping\n\nThe module integrates with the `TextShaper` class, which utilizes HarfBuzz (via rustybuzz) for advanced text shaping capabilities. This includes:\n\n- Ligature support (e.g., fi, fl)\n- Complex emoji sequences\n- Bidirectional text handling\n- Kerning and contextual alternates\n\n### 6. Unicode Range Fonts\n\nThe `UnicodeRangeFont` struct allows for the mapping of specific fonts to Unicode ranges. This is particularly useful for languages that require specialized fonts, such as CJK characters.\n\n## How It Works\n\n1. **Initialization**: When a `FontManager` instance is created, it loads system fonts and initializes the primary font. If no primary font is specified, it defaults to the embedded DejaVu Sans Mono font.\n\n2. **Building the Fallback Chain**: The `build_fallback_chain` method constructs a list of fallback fonts based on the `FALLBACK_FAMILIES` constant. This ensures that if the primary font lacks a glyph, the system will attempt to find it in the fallback fonts.\n\n3. **Glyph Lookup**: The `find_glyph` method is used to locate the appropriate glyph for a given character, considering the specified styles (bold, italic). It first checks the styled font, then the Unicode range-specific fonts, and finally the fallback fonts.\n\n4. **Text Shaping**: The `shape_text` method in the `TextShaper` class is called to shape text using the appropriate font. This method handles complex text rendering, including ligatures and bidirectional text.\n\n5. **Caching**: The `TextShaper` employs an LRU cache to optimize performance by storing previously shaped text runs, reducing the need for repeated shaping of the same text.\n\n## Integration with the Codebase\n\nThe Fonts module is integrated with the broader par-term codebase, providing essential functionality for rendering text in the terminal emulator. It connects with other components such as:\n\n- **Renderer**: The rendering engine calls the `FontManager` to retrieve font references and glyphs for drawing text on the screen.\n- **Text Shaping**: The `TextShaper` is utilized for shaping text before rendering, ensuring that complex scripts and emojis are displayed correctly.\n- **Configuration**: The module can be configured to load specific fonts based on user preferences, allowing for customization of the terminal's appearance.\n\n## Conclusion\n\nThe Fonts module is a robust and flexible system for managing fonts and text rendering in the par-term terminal emulator. By providing a comprehensive fallback mechanism and advanced text shaping capabilities, it ensures that users can view a wide range of characters and symbols accurately and beautifully. Developers contributing to this module should focus on maintaining the integrity of font loading, enhancing text shaping features, and ensuring compatibility with various Unicode characters.","input":"# Input\n\n# Input Module Documentation\n\n## Overview\n\nThe **Input** module is responsible for handling keyboard input events and converting them into terminal input bytes. It integrates with the `winit` library to capture keyboard events and manages modifier keys (like Ctrl, Alt, and Shift) to ensure that the correct input is sent to the terminal. Additionally, it provides clipboard functionality for copying and pasting text, supporting both standard clipboard operations and primary selection on Linux systems.\n\n## Key Components\n\n### InputHandler Struct\n\nThe core of the Input module is the `InputHandler` struct, which encapsulates the state and behavior related to input handling. Here are its key fields:\n\n- **modifiers**: Tracks the current state of modifier keys (Ctrl, Alt, Shift).\n- **clipboard**: An optional clipboard instance for managing clipboard operations.\n- **left_option_key_mode** and **right_option_key_mode**: Configurable modes for handling the Option/Alt keys.\n- **left_alt_pressed** and **right_alt_pressed**: Boolean flags to track which Alt key is currently pressed.\n\n### Main Functions\n\n#### 1. `new()`\n\n```rust\npub fn new() -> Self\n```\n\nCreates a new instance of `InputHandler`, initializing the clipboard and setting default values for modifiers and option key modes. If clipboard initialization fails, a warning is logged.\n\n#### 2. `update_modifiers(&mut self, modifiers: Modifiers)`\n\n```rust\npub fn update_modifiers(&mut self, modifiers: Modifiers)\n```\n\nUpdates the current state of modifier keys based on the provided `Modifiers` instance.\n\n#### 3. `handle_key_event(&mut self, event: KeyEvent) -> Option<Vec<u8>>`\n\n```rust\npub fn handle_key_event(&mut self, event: KeyEvent) -> Option<Vec<u8>>\n```\n\nProcesses a keyboard event and converts it into terminal input bytes. It handles character keys, special keys, and applies the appropriate transformations based on the current modifier states.\n\n#### 4. `paste_from_clipboard(&mut self) -> Option<String>`\n\n```rust\npub fn paste_from_clipboard(&mut self) -> Option<String>\n```\n\nRetrieves text from the clipboard and returns it as a `String`. If the clipboard is unavailable or an error occurs, it logs a warning or error.\n\n#### 5. `copy_to_clipboard(&mut self, text: &str) -> Result<(), String>`\n\n```rust\npub fn copy_to_clipboard(&mut self, text: &str) -> Result<(), String>\n```\n\nCopies the provided text to the clipboard. Returns an error if the clipboard is unavailable.\n\n### Option Key Modes\n\nThe `InputHandler` supports three modes for handling the Option/Alt keys:\n\n- **Normal**: The character is sent as-is.\n- **Meta**: The high bit (8th bit) is set for ASCII characters.\n- **Esc**: An ESC prefix is sent before the character.\n\nThe mode can be updated using the `update_option_key_modes` method.\n\n### Clipboard Operations\n\nThe module provides clipboard functionality, including:\n\n- **Copying text**: Using `copy_to_clipboard` and `copy_to_primary_selection` (Linux only).\n- **Pasting text**: Using `paste_from_clipboard` and `paste_from_primary_selection` (Linux only).\n- **Checking for images**: The `clipboard_has_image` method checks if the clipboard contains an image.\n\n## Execution Flow\n\nThe `InputHandler` interacts with various parts of the application, primarily through keyboard event handling. Below is a simplified execution flow for handling a key event:\n\n```mermaid\ngraph TD;\n A[handle_key_event] --> B[handle_key_event_with_mode]\n B --> C[apply_option_key_mode]\n B --> D[get_base_character]\n B --> E[try_modify_other_keys_encoding]\n C --> F[get_active_option_mode]\n```\n\n1. **handle_key_event**: This function is called when a key event occurs.\n2. **handle_key_event_with_mode**: It processes the event and determines how to handle it based on the current state of modifiers.\n3. **apply_option_key_mode**: This function applies the appropriate transformation based on the active option key mode.\n4. **get_base_character**: Retrieves the unmodified character for the key event.\n5. **try_modify_other_keys_encoding**: Checks if the event should be encoded using the modifyOtherKeys format.\n\n## Integration with the Codebase\n\nThe `InputHandler` is designed to be integrated into a larger application, where it can be called from various event handlers. For example:\n\n- **Keyboard Events**: The `handle_key_event` function is invoked from input event handlers to process user input.\n- **Clipboard Actions**: Clipboard operations are triggered from menu actions or mouse events, allowing users to copy and paste text seamlessly.\n\n### Example Usage\n\nHere’s a brief example of how to use the `InputHandler` in an application:\n\n```rust\nlet mut input_handler = InputHandler::new();\n\n// Update modifiers based on current state\ninput_handler.update_modifiers(current_modifiers);\n\n// Handle a key event\nif let Some(bytes) = input_handler.handle_key_event(key_event) {\n // Send bytes to terminal\n}\n\n// Copy text to clipboard\ninput_handler.copy_to_clipboard(\"Hello, World!\").unwrap();\n```\n\n## Conclusion\n\nThe **Input** module provides a robust framework for handling keyboard input and clipboard operations in a terminal application. By encapsulating the logic for modifier keys and input transformations, it allows developers to focus on building features without worrying about the intricacies of input handling. The module is designed for extensibility and can be easily integrated into various applications.","keybindings":"# Keybindings\n\n# Keybindings Module Documentation\n\n## Overview\n\nThe **Keybindings** module provides a flexible and runtime-configurable keybinding system for the `par-term` terminal application. It allows users to define custom keyboard shortcuts in a `config.yaml` file, enabling a personalized and efficient user experience. This module supports various key combinations, modifier remapping, and physical key bindings, making it adaptable to different keyboard layouts and user preferences.\n\n## Features\n\n- **Configurable Key Combinations**: Users can define shortcuts like `Ctrl+Shift+B`, `CmdOrCtrl+V`, etc.\n- **Modifier Remapping**: Users can swap modifier keys (e.g., Ctrl and Super) to suit their preferences.\n- **Physical Key Support**: Allows for language-agnostic bindings by matching physical key positions.\n\n## Key Components\n\n### 1. KeybindingRegistry\n\nThe `KeybindingRegistry` is the core structure that manages keybindings. It maps parsed key combinations to action names.\n\n#### Key Methods\n\n- **`new()`**: Creates a new empty registry.\n \n ```rust\n pub fn new() -> Self\n ```\n\n- **`from_config(keybindings: &[KeyBinding])`**: Initializes the registry from a list of keybindings defined in the configuration. Invalid keybindings are logged and skipped.\n \n ```rust\n pub fn from_config(keybindings: &[KeyBinding]) -> Self\n ```\n\n- **`lookup(event: &winit::event::KeyEvent, modifiers: &winit::event::Modifiers)`**: Looks up the action associated with a key event, returning the action name if a match is found.\n \n ```rust\n pub fn lookup(&self, event: &winit::event::KeyEvent, modifiers: &winit::event::Modifiers) -> Option<&str>\n ```\n\n- **`lookup_with_options(...)`**: An advanced lookup method that allows for modifier remapping and physical key matching.\n \n ```rust\n pub fn lookup_with_options(\n &self,\n event: &winit::event::KeyEvent,\n modifiers: &winit::event::Modifiers,\n remapping: &ModifierRemapping,\n use_physical_keys: bool,\n ) -> Option<&str>\n ```\n\n### 2. KeybindingMatcher\n\nThe `KeybindingMatcher` is responsible for matching key events against defined key combinations. It supports both logical and physical key matching.\n\n#### Key Methods\n\n- **`from_event(event: &KeyEvent, modifiers: &WinitModifiers)`**: Creates a matcher from a `winit` key event.\n \n ```rust\n pub fn from_event(event: &KeyEvent, modifiers: &WinitModifiers) -> Self\n ```\n\n- **`matches_with_physical_preference(combo: &KeyCombo, use_physical_keys: bool)`**: Checks if the current event matches a given key combo, with an option to prefer physical key matches.\n \n ```rust\n pub fn matches_with_physical_preference(&self, combo: &KeyCombo, use_physical_keys: bool) -> bool\n ```\n\n### 3. KeyCombo and Modifiers\n\nThe `KeyCombo` struct represents a parsed key combination, including its modifiers and the key itself. The `Modifiers` struct encapsulates the state of modifier keys (Ctrl, Alt, Shift, Super, CmdOrCtrl).\n\n### 4. Parser\n\nThe `parser` module provides functions to parse human-readable key strings into `KeyCombo` structs. It supports various formats and handles errors gracefully.\n\n#### Key Functions\n\n- **`parse_key_combo(s: &str) -> Result<KeyCombo, ParseError>`**: Parses a key combination string into a `KeyCombo`.\n \n ```rust\n pub fn parse_key_combo(s: &str) -> Result<KeyCombo, ParseError>\n ```\n\n- **`key_combo_to_bytes(combo: &KeyCombo) -> Result<Vec<u8>, String>`**: Converts a `KeyCombo` into terminal byte sequences.\n \n ```rust\n pub fn key_combo_to_bytes(combo: &KeyCombo) -> Result<Vec<u8>, String>\n ```\n\n## Execution Flow\n\nThe execution flow of the keybinding system can be summarized as follows:\n\n1. **Configuration Loading**: The `KeybindingRegistry::from_config` method is called to load keybindings from the configuration file.\n2. **Key Event Handling**: When a key event occurs, the `lookup` or `lookup_with_options` method is invoked to find the corresponding action.\n3. **Key Matching**: The `KeybindingMatcher` checks if the event matches any registered key combinations, considering modifiers and remappings.\n4. **Action Execution**: If a match is found, the associated action is executed.\n\n### Mermaid Diagram\n\n```mermaid\ngraph TD;\n A[Key Event] -->|lookup| B[KeybindingRegistry]\n B -->|matches| C[KeybindingMatcher]\n C -->|returns action| D[Action Execution]\n B -->|from_config| E[Configuration]\n E -->|loads keybindings| B\n```\n\n## Integration with the Codebase\n\nThe Keybindings module integrates with the broader `par-term` application, particularly in handling user input events. The `handle_key_event` function in the input event handling module calls the `lookup_with_options` method to determine the action associated with a key event. This allows for a seamless user experience where custom keybindings can trigger specific actions defined in the application.\n\n## Conclusion\n\nThe Keybindings module is a powerful and flexible system that enhances the usability of the `par-term` terminal application. By allowing users to define their own keybindings and supporting various keyboard layouts, it caters to a wide range of user preferences and workflows. Developers can extend and modify this module to accommodate additional features or custom behaviors as needed.","miscellaneous-config":"# Miscellaneous — config\n\n# Miscellaneous — Config Module Documentation\n\n## Overview\n\nThe **Miscellaneous — config** module is responsible for managing terminal configuration settings within the application. It serves as a wrapper around the `par-term-config` crate, which provides a comprehensive set of configuration types, defaults, and utilities specifically designed for terminal applications.\n\nThis module does not contain any internal logic or execution flows; instead, it acts as a conduit to expose the functionality provided by the `par-term-config` crate. By re-exporting all configuration types, it simplifies the process of accessing terminal configuration settings throughout the codebase.\n\n## Purpose\n\nThe primary purpose of the config module is to centralize terminal configuration management, allowing developers to easily access and modify terminal settings without needing to directly interact with the underlying `par-term-config` crate. This abstraction promotes code reusability and maintainability.\n\n## Key Components\n\n### Re-exports from `par-term-config`\n\nThe module re-exports all types and utilities from the `par-term-config` crate. This includes:\n\n- **Configuration Types**: These are the data structures that represent various terminal settings, such as colors, fonts, and layout options.\n- **Defaults**: Predefined default values for terminal configurations that can be used as a baseline for customization.\n- **Utilities**: Helper functions and methods that facilitate the manipulation and retrieval of configuration settings.\n\n### Example Usage\n\nTo utilize the configuration types and utilities provided by this module, developers can import the config module directly. Here’s a simple example:\n\n```rust\nuse config::*; // Import everything from the config module\n\nfn main() {\n // Create a new terminal configuration instance\n let mut terminal_config = TerminalConfig::default();\n\n // Modify some settings\n terminal_config.set_color_scheme(ColorScheme::Dark);\n terminal_config.set_font_size(12);\n\n // Apply the configuration\n terminal_config.apply();\n}\n```\n\nIn this example, the `TerminalConfig` type is used to create a new configuration instance, modify its properties, and apply the changes.\n\n## Integration with the Codebase\n\nThe config module is designed to be used throughout the application wherever terminal configuration is required. By re-exporting the types from `par-term-config`, it ensures that all parts of the codebase can access terminal settings consistently.\n\n### Call Graph\n\nSince this module does not contain any internal calls or execution flows, there is no call graph to represent. However, it is important to note that any module that requires terminal configuration can directly import from the config module, thereby gaining access to all the necessary types and utilities.\n\n## Conclusion\n\nThe **Miscellaneous — config** module serves as a crucial component for managing terminal configurations in a streamlined manner. By leveraging the capabilities of the `par-term-config` crate, it provides a simple interface for developers to work with terminal settings, enhancing the overall maintainability and usability of the codebase. \n\nFor further details on the specific types and utilities available, refer to the documentation of the `par-term-config` crate.","miscellaneous-keybindings":"# Miscellaneous — keybindings\n\n# Miscellaneous — Keybindings Module Documentation\n\n## Overview\n\nThe **Keybindings** module serves as a bridge to the `par-term-keybindings` crate, providing a streamlined interface for managing keybindings within the application. This module is designed to facilitate the integration of keybinding functionalities, allowing developers to easily implement and customize keyboard shortcuts in terminal applications.\n\n## Purpose\n\nThe primary purpose of this module is to re-export keybinding functionalities from the `par-term-keybindings` crate, ensuring that developers can access and utilize these features without needing to directly interact with the underlying crate. This abstraction simplifies the process of implementing keybindings and enhances code maintainability.\n\n## Key Components\n\n### Re-exports\n\nThe module re-exports all public items from the `par-term-keybindings` crate, which includes:\n\n- **Keybinding Definitions**: Structures and enums that define keybindings.\n- **Keybinding Parsing**: Functions and utilities for parsing keybinding configurations.\n- **Keybinding Management**: Methods for adding, removing, and triggering keybindings.\n\nAdditionally, the module re-exports the `parser` submodule from `par-term-keybindings` for backward compatibility. This allows existing code that relies on the parser to continue functioning without modification.\n\n### Code Structure\n\nThe module is structured as follows:\n\n```rust\npub use par_term_keybindings::*;\npub use par_term_keybindings::parser;\n```\n\nThis simple structure indicates that all public items from `par-term-keybindings` are available for use, along with the `parser` submodule.\n\n## How It Works\n\nThe **Keybindings** module does not contain any internal logic or execution flows; it solely acts as a conduit for the functionalities provided by the `par-term-keybindings` crate. When a developer imports this module, they gain access to all the keybinding features defined in the crate, allowing for seamless integration into their applications.\n\n### Example Usage\n\nHere’s a brief example of how a developer might use the keybindings module in their application:\n\n```rust\nuse your_crate::keybindings;\n\n// Define a keybinding\nlet my_keybinding = keybindings::Keybinding::new(\"Ctrl+C\", \"Copy\");\n\n// Add the keybinding to the application\nkeybindings::add_keybinding(my_keybinding);\n```\n\nIn this example, the developer creates a new keybinding for the \"Copy\" action and adds it to the application using the `add_keybinding` function.\n\n## Integration with the Codebase\n\nThe **Keybindings** module is designed to be easily integrated into the larger codebase. By re-exporting the functionalities of `par-term-keybindings`, it allows developers to implement keybindings without needing to understand the intricacies of the underlying crate. This promotes a clean separation of concerns and enhances the modularity of the code.\n\n### Call Graph\n\nSince this module does not have any internal calls or execution flows, the call graph is straightforward. It primarily serves as a re-export layer, with no additional complexity introduced.\n\n```mermaid\ngraph TD;\n A[Keybindings Module] --> B[par-term-keybindings Crate];\n A --> C[parser Submodule];\n```\n\n## Conclusion\n\nThe **Keybindings** module is a crucial component for managing keyboard shortcuts in terminal applications. By re-exporting the functionalities of the `par-term-keybindings` crate, it simplifies the implementation of keybindings and ensures backward compatibility. Developers can leverage this module to enhance user experience through customizable keyboard interactions, all while maintaining clean and maintainable code.","miscellaneous-menu":"# Miscellaneous — menu\n\n# Miscellaneous - Menu Module Documentation\n\n## Overview\n\nThe **menu** module provides a cross-platform native menu system for the `par-term` terminal application. It leverages the `muda` crate to create and manage menus on macOS, Windows, and Linux. This module defines the structure and behavior of the application's menu, including actions that can be triggered by user interactions.\n\n## Key Components\n\n### 1. MenuAction Enum\n\nThe `MenuAction` enum defines all possible actions that can be triggered from the menu system. Each variant corresponds to a specific menu action, such as opening a new window, managing profiles, or toggling fullscreen mode.\n\n```rust\n#[derive(Debug, Clone, Copy, PartialEq, Eq)]\npub enum MenuAction {\n NewWindow,\n CloseWindow,\n Quit,\n ManageProfiles,\n ToggleProfileDrawer,\n OpenProfile(ProfileId),\n NewTab,\n CloseTab,\n NextTab,\n PreviousTab,\n SwitchToTab(usize),\n Copy,\n Paste,\n ToggleFullscreen,\n ShowHelp,\n // ... other actions\n}\n```\n\n### 2. MenuManager Struct\n\nThe `MenuManager` struct is responsible for managing the native menu system. It contains the root menu, a mapping of menu item IDs to actions, and a submenu for dynamic profile items.\n\n```rust\npub struct MenuManager {\n menu: Menu,\n action_map: HashMap<MenuId, MenuAction>,\n profiles_submenu: Submenu,\n profile_menu_items: Vec<MenuItem>,\n}\n```\n\n#### Key Methods\n\n- **new()**: Initializes a new `MenuManager` instance with the default menu structure. It sets up the menu items and their corresponding actions.\n\n- **init_for_window(&self, window: &Arc<Window>)**: Initializes the menu for a specific window. This method is platform-specific, handling macOS, Windows, and Linux differently.\n\n- **poll_events(&self)**: Polls for menu events and returns any triggered actions. This method allows the application to respond to user interactions with the menu.\n\n- **update_profiles(&mut self, profiles: &[&Profile])**: Updates the profiles submenu with the current list of profiles. This method should be called whenever profiles are loaded or modified.\n\n- **update_profiles_from_manager(&mut self, manager: &crate::profile::ProfileManager)**: A convenience method to update profiles from a `ProfileManager`.\n\n### 3. Menu Structure\n\nThe menu structure is built in the `new()` method of `MenuManager`. It includes various submenus such as File, Edit, View, and Help, each containing relevant menu items. The structure is designed to be intuitive and follows platform conventions.\n\n#### Example Menu Structure\n\n```mermaid\ngraph TD;\n A[Menu] --> B[File]\n A --> C[Edit]\n A --> D[View]\n A --> E[Help]\n B --> F[New Window]\n B --> G[Close Window]\n C --> H[Copy]\n C --> I[Paste]\n D --> J[Toggle Fullscreen]\n E --> K[Show Help]\n```\n\n## Execution Flow\n\nThe `MenuManager` is typically initialized when a new window is created in the application. The `init_for_window` method is called to set up the menu for that window. The application then enters a loop where it polls for menu events using the `poll_events` method. When a user interacts with the menu, the corresponding `MenuAction` is returned, allowing the application to respond appropriately.\n\n### Example Flow\n\n1. **Window Creation**: The application creates a new window, triggering `init_for_window`.\n2. **Menu Initialization**: The menu is initialized for the window, setting up the menu structure.\n3. **Event Loop**: The application enters an event loop, calling `poll_events` to check for user interactions.\n4. **Action Handling**: When a menu item is selected, the corresponding `MenuAction` is returned, and the application executes the associated functionality.\n\n## Integration with Other Modules\n\nThe `menu` module interacts with other parts of the `par-term` codebase, particularly the `profile` module. The `update_profiles` method relies on the `Profile` struct to dynamically update the profiles submenu. Additionally, the `poll_events` method is called from the main application loop to handle user interactions.\n\n### Related Modules\n\n- **Profile Module**: Provides the `Profile` struct and related functionality for managing terminal profiles.\n- **Window Manager**: Responsible for creating and managing application windows, including initializing the menu for each window.\n\n## Conclusion\n\nThe **menu** module is a crucial component of the `par-term` application, providing a user-friendly interface for accessing various functionalities. By leveraging the `muda` crate, it ensures a consistent experience across different platforms. Developers contributing to this module should focus on maintaining the menu structure, adding new actions, and ensuring compatibility with the profile management system.","miscellaneous-pane":"# Miscellaneous — pane\n\n# Pane Management Module Documentation\n\n## Overview\n\nThe **Pane Management Module** is responsible for managing terminal panes within a tab in a terminal emulator. It provides functionality for creating, splitting, closing, and navigating between panes, as well as handling their layout and resizing. This module is crucial for enabling a multi-pane terminal experience, allowing users to work with multiple terminal sessions simultaneously.\n\n## Key Components\n\n### 1. PaneManager\n\nThe `PaneManager` is the core structure that manages the pane tree. It provides methods for:\n\n- **Creating and initializing panes**: Methods like `new`, `with_initial_pane`, and `create_initial_pane` handle the creation of new panes.\n- **Splitting panes**: The `split` method allows users to split the currently focused pane either horizontally or vertically.\n- **Closing panes**: The `close_pane` method removes a pane from the tree and handles focus changes if the closed pane was the currently focused one.\n- **Navigating between panes**: The `navigate` method allows users to switch focus between panes based on a specified direction.\n- **Resizing panes**: The `resize_split` method adjusts the size of a split pane based on user input.\n\n### 2. PaneNode\n\nThe `PaneNode` enum represents the structure of the pane tree. It can be either:\n\n- **Leaf**: Contains a single `Pane` instance.\n- **Split**: Contains two child `PaneNode` instances, along with the direction of the split and the ratio of space allocated to each child.\n\nThis binary tree structure allows for arbitrary nesting of panes, enabling complex layouts.\n\n### 3. Pane\n\nThe `Pane` struct represents an individual terminal pane. It encapsulates the terminal session, scroll state, mouse state, and other properties necessary for managing the terminal's behavior. Key features include:\n\n- **Terminal Management**: Each pane has its own `TerminalManager` instance, which handles the terminal's input and output.\n- **Background Settings**: Each pane can have its own background configuration, allowing for customization.\n\n### 4. PaneBounds\n\nThe `PaneBounds` struct defines the dimensions and position of a pane within the terminal. It provides methods for checking if a point is within the bounds and calculating grid sizes based on cell dimensions.\n\n### 5. SplitDirection\n\nThe `SplitDirection` enum defines the possible directions for splitting panes: `Horizontal` (top/bottom) and `Vertical` (left/right).\n\n## How It Works\n\nThe `PaneManager` maintains a tree of `PaneNode` instances, starting with a root node that can be either a leaf or a split. When a new pane is created, it is added to this tree structure. The manager handles all operations related to pane manipulation, including:\n\n- **Creating Initial Panes**: When a new tab is created, the `create_initial_pane` method is called to set up the first pane.\n- **Splitting Panes**: The `split` method calculates the new dimensions for the split panes and updates the tree structure accordingly.\n- **Closing Panes**: The `close_pane` method traverses the tree to find and remove the specified pane, updating the focus as necessary.\n- **Navigating Panes**: The `navigate` method uses the `find_pane_in_direction` function to determine which pane to focus next based on the current position.\n\n### Execution Flow\n\nThe following diagram illustrates the execution flow for splitting a pane:\n\n```mermaid\ngraph TD;\n A[split] --> B[focused_pane];\n B --> C[find_pane];\n A --> D[create_initial_pane];\n D --> E[new];\n E --> F[set_theme];\n E --> G[set_max_clipboard_sync_events];\n```\n\n## Integration with Other Modules\n\nThe Pane Management Module interacts with several other components in the codebase:\n\n- **Terminal Module**: Each `Pane` contains a `TerminalManager` that handles the terminal's input/output.\n- **Configuration Module**: The `Config` struct is used to initialize panes with user-defined settings, such as dimensions and background images.\n- **Session Management**: The module integrates with session management to restore pane layouts from saved sessions.\n\n## Usage\n\nTo use the `PaneManager`, you typically instantiate it and call its methods to manage panes. For example:\n\n```rust\nlet mut pane_manager = PaneManager::new();\nlet initial_pane_id = pane_manager.create_initial_pane(&config, runtime, None)?;\npane_manager.split(SplitDirection::Vertical, &config, runtime)?;\n```\n\nThis code initializes a new `PaneManager`, creates an initial pane, and then splits it vertically.\n\n## Conclusion\n\nThe Pane Management Module is a vital part of the terminal emulator, providing the necessary infrastructure for managing multiple terminal panes. Its design allows for flexibility and extensibility, making it easy to integrate with other components of the application. By understanding its key components and how they interact, developers can effectively contribute to and enhance the pane management functionality.","miscellaneous-session":"# Miscellaneous — session\n\n# Miscellaneous — Session Module Documentation\n\n## Overview\n\nThe **session** module is responsible for capturing, saving, and restoring the state of the application across sessions. This includes the layout of windows, tabs, and pane configurations. The module ensures that users can seamlessly continue their work from where they left off, enhancing the user experience by providing automatic session persistence.\n\n## Key Components\n\nThe session module consists of several key components:\n\n1. **Session State Types**: These are data structures that represent the state of the session, including windows, tabs, and pane layouts.\n2. **Capture Functionality**: Functions that capture the current state of the application and serialize it into a format suitable for storage.\n3. **Restore Functionality**: Functions that load the saved session state and validate paths to ensure they are still valid.\n4. **Storage Management**: Functions that handle the file I/O operations for saving and loading session data.\n\n### 1. Session State Types\n\nThe session state is represented by several structs and enums:\n\n- **SessionState**: The top-level structure that contains a timestamp and a list of windows.\n- **SessionWindow**: Represents a single window's position, size, tabs, and the active tab index.\n- **SessionTab**: Represents a single tab's properties, including the working directory, title, custom color, user title, custom icon, and pane layout.\n- **SessionPaneNode**: An enum that represents the structure of pane layouts, supporting both leaf nodes and split nodes.\n\n```rust\n#[derive(Debug, Clone, Serialize, Deserialize)]\npub struct SessionState {\n pub saved_at: String,\n pub windows: Vec<SessionWindow>,\n}\n\n#[derive(Debug, Clone, Serialize, Deserialize)]\npub struct SessionWindow {\n pub position: (i32, i32),\n pub size: (u32, u32),\n pub tabs: Vec<SessionTab>,\n pub active_tab_index: usize,\n}\n\n#[derive(Debug, Clone, Serialize, Deserialize)]\npub struct SessionTab {\n pub cwd: Option<String>,\n pub title: String,\n pub custom_color: Option<[u8; 3]>,\n pub user_title: Option<String>,\n pub custom_icon: Option<String>,\n pub pane_layout: Option<SessionPaneNode>,\n}\n\n#[derive(Debug, Clone, Serialize, Deserialize)]\npub enum SessionPaneNode {\n Leaf { cwd: Option<String> },\n Split {\n direction: SplitDirection,\n ratio: f32,\n first: Box<SessionPaneNode>,\n second: Box<SessionPaneNode>,\n },\n}\n```\n\n### 2. Capture Functionality\n\nThe `capture_session` function is the primary entry point for capturing the current state of all open windows. It iterates through the `windows` HashMap, retrieves the state of each window, and constructs a `SessionState` object.\n\n```rust\npub fn capture_session(windows: &HashMap<WindowId, WindowState>) -> SessionState {\n // Implementation details...\n}\n```\n\nThe `capture_pane_node` function is called recursively to capture the layout of panes within each tab.\n\n```rust\npub fn capture_pane_node(node: &PaneNode) -> SessionPaneNode {\n // Implementation details...\n}\n```\n\n### 3. Restore Functionality\n\nThe restore functionality is primarily handled by the `load_session` and `validate_cwd` functions. The `load_session` function reads the session state from a file and returns it as an `Option<SessionState>`. If the file does not exist or is corrupt, it handles these cases gracefully.\n\n```rust\npub fn load_session() -> Result<Option<SessionState>> {\n // Implementation details...\n}\n```\n\nThe `validate_cwd` function ensures that the working directory paths stored in the session are valid, falling back to the user's home directory if necessary.\n\n```rust\npub fn validate_cwd(cwd: &Option<String>) -> Option<String> {\n // Implementation details...\n}\n```\n\n### 4. Storage Management\n\nThe storage management functions handle the file I/O for saving and loading session data. The `save_session` function serializes the `SessionState` to YAML format and writes it to a predefined location.\n\n```rust\npub fn save_session(state: &SessionState) -> Result<()> {\n // Implementation details...\n}\n```\n\nThe `session_path` function determines the file path for the session state, typically located at `~/.config/par-term/last_session.yaml`.\n\n```rust\npub fn session_path() -> PathBuf {\n // Implementation details...\n}\n```\n\n## Execution Flow\n\nThe execution flow of the session module can be summarized as follows:\n\n1. **Capture Session**: When the application needs to save the current state, it calls `capture_session`, which gathers the state of all open windows and their tabs.\n2. **Save Session**: The captured state is then passed to `save_session`, which serializes it and writes it to the session file.\n3. **Load Session**: Upon application startup, `load_session` is called to read the session file and restore the state.\n4. **Validate Paths**: During restoration, `validate_cwd` checks the validity of working directories.\n\n```mermaid\ngraph TD;\n A[capture_session] --> B[save_session];\n A --> C[capture_pane_node];\n D[load_session] --> E[validate_cwd];\n D --> F[load_session_from];\n F --> E;\n```\n\n## Conclusion\n\nThe **session** module is a crucial part of the application, providing functionality for session persistence. By capturing the state of windows, tabs, and pane layouts, it allows users to resume their work seamlessly. Understanding this module is essential for developers looking to contribute to the application's session management features.","miscellaneous-snippets":"# Miscellaneous — snippets\n\n# Miscellaneous — Snippets Module Documentation\n\n## Overview\n\nThe **snippets** module provides a robust engine for variable substitution and insertion within text snippets. It allows developers to define both built-in and custom variables, facilitating dynamic text generation based on session context or user-defined values. This module is particularly useful in applications where snippets of text need to be customized based on user input or environmental variables.\n\n## Key Features\n\n- **Variable Substitution**: Supports substitution of variables in the format `\\(variable_name)`.\n- **Session Variable Access**: Access to session-specific variables such as hostname, username, and job.\n- **Custom Variables**: Allows users to define custom variables for specific snippets.\n- **Text Processing**: Processes text to replace variable placeholders with their corresponding values.\n- **Integration with Terminal**: Facilitates text insertion directly into terminal applications.\n\n## Architecture\n\nThe core of the snippets module is the `VariableSubstitutor` struct, which handles the logic for variable substitution. Below is a simplified call graph illustrating the main components and their interactions:\n\n```mermaid\ngraph TD;\n A[VariableSubstitutor] -->|substitute| B[substitute_with_session]\n B -->|resolve_variable_with_session| C[resolve_variable]\n C -->|parse| D[BuiltInVariable]\n B -->|get| E[SessionVariables]\n A -->|extract_variables| F[extract_variables]\n```\n\n## Components\n\n### 1. `VariableSubstitutor`\n\nThe `VariableSubstitutor` struct is the main entry point for variable substitution. It contains a regex pattern to identify variable placeholders and methods to perform substitutions.\n\n#### Methods\n\n- **`new()`**: Constructs a new instance of `VariableSubstitutor` with a regex pattern to match variable syntax.\n \n- **`substitute(&self, text: &str, custom_vars: &HashMap<String, String>)`**: \n - Substitutes variables in the provided text using custom variables.\n - Returns a `SubstitutionResult<String>` containing the processed text or an error.\n\n- **`substitute_with_session(&self, text: &str, custom_vars: &HashMap<String, String>, session_vars: Option<&SessionVariables>)`**: \n - Similar to `substitute`, but also considers session variables.\n - This method is crucial for resolving variables that depend on the current session context.\n\n- **`has_variables(&self, text: &str) -> bool`**: \n - Checks if the provided text contains any variable placeholders.\n\n- **`extract_variables(&self, text: &str) -> Vec<String>`**: \n - Extracts and returns a list of variable names found in the text.\n\n### 2. `SubstitutionError`\n\nThis enum defines the possible errors that can occur during variable substitution:\n\n- **`InvalidVariable(String)`**: Indicates that a variable name is empty or invalid.\n- **`UndefinedVariable(String)`**: Indicates that a variable is not defined in either custom or built-in variables.\n\n### 3. `SubstitutionResult<T>`\n\nA type alias for `Result<T, SubstitutionError>`, simplifying the return type for substitution operations.\n\n### 4. `BuiltInVariable`\n\nThis struct (not fully detailed in the provided code) is responsible for handling built-in variables. It provides methods to parse variable names and resolve their values based on predefined logic.\n\n### 5. `SessionVariables`\n\nThis struct (also not fully detailed) represents session-specific variables. It provides access to various session attributes like hostname, username, and job.\n\n## Usage Example\n\nHere’s a simple example of how to use the `VariableSubstitutor`:\n\n```rust\nuse std::collections::HashMap;\nuse crate::snippets::VariableSubstitutor;\n\nfn main() {\n let substitutor = VariableSubstitutor::new();\n let mut custom_vars = HashMap::new();\n custom_vars.insert(\"name\".to_string(), \"Alice\".to_string());\n\n let text = \"Hello \\\\(name), welcome!\";\n match substitutor.substitute(text, &custom_vars) {\n Ok(result) => println!(\"{}\", result), // Output: Hello Alice, welcome!\n Err(e) => eprintln!(\"Error: {}\", e),\n }\n}\n```\n\n## Testing\n\nThe module includes a comprehensive suite of tests to ensure the correctness of variable substitution. Key tests include:\n\n- **`test_substitute_builtin_variables`**: Validates substitution of built-in variables.\n- **`test_substitute_custom_variables`**: Validates substitution of user-defined custom variables.\n- **`test_undefined_variable`**: Ensures that undefined variables return the appropriate error.\n- **`test_extract_variables`**: Tests the extraction of variable names from text.\n\n## Integration with the Codebase\n\nThe snippets module is integrated into the broader application through various entry points, such as:\n\n- **`generate_snippet_action_keybindings`**: Calls the `new` method to create a `VariableSubstitutor` instance.\n- **`execute_snippet`**: Uses `substitute_with_session` to process snippets based on the current session context.\n\nThis module is designed to be flexible and extensible, allowing developers to easily add new variables or modify existing ones as needed.\n\n## Conclusion\n\nThe **snippets** module is a powerful tool for managing dynamic text generation through variable substitution. Its design emphasizes flexibility and ease of use, making it a valuable component for applications that require customizable text snippets. Developers can leverage this module to enhance user experience by providing context-aware text generation capabilities.","miscellaneous-src":"# Miscellaneous — src\n\n# Miscellaneous Module Documentation\n\nThe **Miscellaneous** module in the `src` directory encompasses various components that enhance the functionality of the terminal emulator. This documentation provides an overview of the key components, their purposes, and how they interconnect within the codebase.\n\n## Overview\n\nThe Miscellaneous module includes several functionalities such as audio management, badge rendering, command history management, clipboard history, and shell integration. Each component serves a specific purpose, contributing to the overall user experience and functionality of the terminal emulator.\n\n### Key Components\n\n1. **Audio Management (`audio_bell.rs`)**\n - **Purpose**: Manages audio notifications for terminal events, such as bell sounds.\n - **Key Structures**:\n - `AudioBell`: Responsible for playing audio notifications. It manages an audio output stream and a sink for playback.\n - **Key Functions**:\n - `new()`: Initializes a new `AudioBell` instance.\n - `play()`: Plays a standard bell sound.\n - `play_file()`: Plays a sound file at a specified volume.\n - `play_alert()`: Plays an alert sound based on configuration.\n\n2. **Badge System (`badge.rs`)**\n - **Purpose**: Displays dynamic session information in the terminal, such as hostname, username, and current path.\n - **Key Structures**:\n - `SessionVariables`: Holds session-related data for badge interpolation.\n - `BadgeState`: Manages the state and configuration of the badge.\n - **Key Functions**:\n - `interpolate_badge_format()`: Replaces placeholders in the badge format string with actual session variable values.\n - `render_badge()`: Renders the badge overlay in the terminal.\n\n3. **Command History Management (`command_history.rs`)**\n - **Purpose**: Tracks and persists command history across sessions.\n - **Key Structures**:\n - `CommandHistoryEntry`: Represents a single command entry with metadata.\n - `CommandHistory`: Manages a collection of command history entries.\n - **Key Functions**:\n - `add()`: Adds a command to history, ensuring deduplication.\n - `load()`: Loads command history from disk.\n - `save()`: Saves command history to disk.\n\n4. **Clipboard History UI (`clipboard_history_ui.rs`)**\n - **Purpose**: Manages the user interface for clipboard history, allowing users to select and paste previous clipboard entries.\n - **Key Structures**:\n - `ClipboardHistoryUI`: Manages the state and visibility of the clipboard history window.\n - **Key Functions**:\n - `show()`: Displays the clipboard history window and handles user interactions.\n\n5. **Shell Integration (`cli.rs`)**\n - **Purpose**: Handles command-line interface interactions and shell integration installation.\n - **Key Structures**:\n - `Cli`: Represents the command-line interface structure.\n - `RuntimeOptions`: Holds runtime options passed from the CLI.\n - **Key Functions**:\n - `process_cli()`: Processes CLI arguments and executes corresponding commands.\n\n### Execution Flow\n\nThe components in the Miscellaneous module interact with each other and other parts of the codebase to provide a cohesive user experience. Below is a simplified execution flow diagram illustrating how these components connect:\n\n```mermaid\ngraph TD;\n A[CLI] -->|Processes commands| B[AudioBell]\n A -->|Displays session info| C[BadgeState]\n A -->|Manages command history| D[CommandHistory]\n A -->|Handles clipboard actions| E[ClipboardHistoryUI]\n A -->|Installs shell integration| F[Shell Integration]\n B -->|Plays sounds| G[Audio Output]\n C -->|Interpolates variables| H[SessionVariables]\n D -->|Loads and saves history| I[File System]\n E -->|Displays UI| J[User Interface]\n```\n\n### How It Works\n\n- **Initialization**: The terminal initializes the `AudioBell`, `BadgeState`, and `CommandHistory` components during startup. The `Cli` processes any command-line arguments to configure these components.\n- **User Interaction**: Users can trigger audio notifications through terminal events, view session information via badges, and access command history or clipboard entries through their respective UIs.\n- **Persistence**: Command history is saved to disk, allowing users to retrieve their command history across sessions. The clipboard history is managed in memory and displayed in a UI when requested.\n- **Shell Integration**: The CLI allows users to install shell integration, enhancing the terminal's capabilities by enabling features like command completion and history management.\n\n### Conclusion\n\nThe Miscellaneous module plays a crucial role in enhancing the terminal emulator's functionality. By managing audio notifications, displaying session information, and handling command and clipboard histories, it significantly improves the user experience. Understanding these components and their interactions is essential for developers looking to contribute to or extend the terminal's capabilities.","miscellaneous":"# Miscellaneous\n\n# Miscellaneous Module Overview\n\nThe **Miscellaneous** module serves as a collection of diverse functionalities that enhance the terminal emulator's capabilities. It is composed of several sub-modules, each addressing specific aspects of terminal management, configuration, and user interaction. Together, these components create a cohesive environment that improves user experience and operational efficiency.\n\n## Purpose\n\nThe primary goal of the Miscellaneous module is to provide essential features that support terminal operations, including audio notifications, configuration management, keybindings, menu systems, pane management, session persistence, and snippet handling. By integrating these functionalities, the module ensures a seamless and intuitive user experience.\n\n## Sub-module Interconnections\n\n### 1. **Audio Management** \n - Manages audio notifications for terminal events, enhancing user feedback.\n\n### 2. **Configuration Management** \n - Centralizes terminal configuration settings through the `par-term-config` crate, allowing easy access to configuration types across the application.\n\n### 3. **Keybindings** \n - Facilitates the implementation of customizable keyboard shortcuts by re-exporting functionalities from the `par-term-keybindings` crate.\n\n### 4. **Menu System** \n - Provides a native cross-platform menu interface using the `muda` crate, allowing users to interact with the application through a structured menu.\n\n### 5. **Pane Management** \n - Manages multiple terminal panes, enabling users to create, split, and navigate between panes for a multi-session experience.\n\n### 6. **Session Management** \n - Captures and restores application state, ensuring users can continue their work seamlessly across sessions.\n\n### 7. **Snippets** \n - Offers a dynamic text generation engine for variable substitution, allowing for customizable text snippets based on user input or session context.\n\n## Key Workflows\n\nThe Miscellaneous module supports several key workflows that span across its sub-modules:\n\n- **User Interaction**: The menu system interacts with keybindings to provide a responsive user interface, allowing users to execute commands and navigate the application efficiently.\n- **Session Persistence**: The session management component works in tandem with pane management to save and restore the layout and state of terminal sessions, ensuring continuity in user workflows.\n- **Dynamic Text Handling**: The snippets module can utilize session variables and user-defined inputs to generate context-sensitive text, enhancing productivity during terminal sessions.\n\nFor detailed information on each sub-module, please refer to the following links:\n\n- [Audio Management](src/audio_bell.md)\n- [Configuration Management](src/config.md)\n- [Keybindings](src/keybindings.md)\n- [Menu System](src/menu.md)\n- [Pane Management](src/pane.md)\n- [Session Management](src/session.md)\n- [Snippets](src/snippets.md)\n\nBy integrating these functionalities, the Miscellaneous module significantly enriches the terminal emulator's user experience, making it a versatile tool for developers and users alike.","other-build-rs":"# Other — build.rs\n\n# Documentation for the **Other — build.rs** Module\n\n## Overview\n\nThe `build.rs` module is a build script for a Rust project that conditionally compiles Windows-specific resources when the project is built on a Windows operating system. This module is essential for ensuring that the application has the appropriate metadata and icons when packaged for Windows users.\n\n## Purpose\n\nThe primary purpose of `build.rs` is to handle the compilation of Windows resources, such as icons and metadata, which are necessary for the application to present itself correctly in the Windows environment. This includes setting the application icon and defining properties like the product name and file description.\n\n## How It Works\n\nThe `build.rs` script is executed by Cargo, Rust's package manager and build system, before the actual compilation of the Rust code begins. The script checks the target operating system and, if it is Windows, it uses the `winres` crate to compile the specified resources.\n\n### Key Components\n\n1. **Conditional Compilation**:\n - The script uses the `#[cfg(target_os = \"windows\")]` attribute to ensure that the resource compilation code is only executed when the target OS is Windows. This prevents unnecessary compilation steps on other platforms.\n\n2. **WindowsResource**:\n - The `winres::WindowsResource` struct is instantiated to manage the Windows resources. This struct provides methods to set various properties and compile the resources.\n\n3. **Setting Properties**:\n - The following properties are set using the `set` method:\n - **Icon**: The application icon is specified with `res.set_icon(\"assets/par-term.ico\")`.\n - **Product Name**: The name of the product is set to \"par-term\".\n - **File Description**: A brief description of the application is provided.\n - **Legal Copyright**: The copyright information is included.\n\n4. **Compilation**:\n - The `res.compile()` method is called to compile the resources. If the compilation fails, an error message is displayed using `expect`.\n\n### Code Example\n\nHere is the complete code for the `build.rs` module:\n\n```rust\nfn main() {\n // Only compile Windows resources on Windows\n #[cfg(target_os = \"windows\")]\n {\n let mut res = winres::WindowsResource::new();\n res.set_icon(\"assets/par-term.ico\");\n res.set(\"ProductName\", \"par-term\");\n res.set(\"FileDescription\", \"GPU-accelerated terminal emulator\");\n res.set(\"LegalCopyright\", \"Copyright (c) Paul Robello\");\n res.compile().expect(\"Failed to compile Windows resources\");\n }\n}\n```\n\n## Connection to the Codebase\n\nThe `build.rs` module does not have any direct internal calls or dependencies within the codebase, as it primarily serves as a pre-build script. However, it indirectly affects the rest of the application by ensuring that the compiled resources are available when the application is run on Windows.\n\n### Execution Flow\n\nSince there are no internal or outgoing calls from this module, it operates independently during the build process. The successful execution of `build.rs` ensures that the application has the necessary resources when it is executed on a Windows platform.\n\n## Conclusion\n\nThe `build.rs` module is a crucial part of the build process for the application, specifically for Windows users. By conditionally compiling resources, it ensures that the application is properly configured for its target environment. Developers contributing to this module should focus on maintaining the resource definitions and ensuring compatibility with the `winres` crate.","other-cargo-toml":"# Other — Cargo.toml\n\n# Documentation for the **Other — Cargo.toml** Module\n\n## Overview\n\nThe `Cargo.toml` file is a crucial component of Rust projects, serving as the manifest for the `par-term` terminal emulator. This file defines the project's metadata, dependencies, build configurations, and workspace settings. The `par-term` project is a cross-platform GPU-accelerated terminal emulator that supports inline graphics, making it suitable for various command-line utilities and graphical user interfaces.\n\n## Purpose\n\nThe primary purpose of the `Cargo.toml` file is to manage the configuration and dependencies of the `par-term` project. It allows developers to specify the libraries and modules that the project relies on, as well as to configure build profiles and features. This modular approach facilitates easier development, testing, and deployment of the terminal emulator.\n\n## Key Components\n\n### Workspace Configuration\n\nThe `[workspace]` section defines the members of the workspace, which are individual packages that can be built together. The `par-term` project consists of multiple components, each responsible for different functionalities:\n\n- **par-term-acp**: Implements the Agent Communication Protocol.\n- **par-term-config**: Manages configuration settings.\n- **par-term-fonts**: Handles font management and text shaping.\n- **par-term-terminal**: Manages terminal operations, including PTY and shell integration.\n- **par-term-render**: Provides GPU-accelerated rendering capabilities.\n- **par-term-settings-ui**: Implements the settings user interface.\n- **par-term-input**: Generates input sequences for keyboard and mouse interactions.\n- **par-term-keybindings**: Manages keybindings and their parsing.\n- **par-term-scripting**: Supports scripting and observer patterns.\n- **par-term-ssh**: Manages SSH host discovery and connections.\n- **par-term-update**: Handles self-updating mechanisms.\n- **par-term-mcp**: Implements the Model Context Protocol.\n- **par-term-tmux**: Integrates with tmux for terminal multiplexing.\n\n### Package Metadata\n\nThe `[package]` section contains metadata about the `par-term` package, including:\n\n- **name**: The name of the package (`par-term`).\n- **version**: The current version of the package (`0.21.0`).\n- **edition**: The Rust edition used (`2024`).\n- **authors**: The author of the project.\n- **description**: A brief description of the project.\n- **repository**: The URL of the project's repository.\n- **homepage**: The homepage URL for the project.\n- **documentation**: The URL for the project's documentation.\n- **keywords**: Relevant keywords for the project.\n- **categories**: Categories that describe the project.\n\n### Dependencies\n\nThe `[dependencies]` section lists all the external libraries that the `par-term` project depends on. Each dependency is specified with its path and version. Some notable dependencies include:\n\n- **tokio**: An asynchronous runtime for handling PTY operations.\n- **serde**: A framework for serializing and deserializing data.\n- **winit**: A window management library.\n- **wgpu**: A GPU abstraction layer for rendering.\n- **log**: A logging library for tracking application behavior.\n\n### Build Profiles\n\nThe `[profile]` sections define different build configurations for the project:\n\n- **release**: Optimized for performance with settings for code optimization and linking.\n- **dev-release**: A fast build profile for development, providing a balance between speed and optimization.\n- **dev**: A debug profile with no optimization, suitable for development and testing.\n\n### Features\n\nThe `[features]` section allows for optional features to be enabled or disabled during the build process. For example, the `dev-tools` feature enables additional utilities for testing.\n\n## Architecture Overview\n\nThe `Cargo.toml` file serves as the backbone of the `par-term` project, connecting various components and managing dependencies. Below is a simplified representation of the architecture:\n\n```mermaid\ngraph TD;\n A[par-term] --> B[par-term-acp]\n A --> C[par-term-config]\n A --> D[par-term-fonts]\n A --> E[par-term-terminal]\n A --> F[par-term-render]\n A --> G[par-term-settings-ui]\n A --> H[par-term-input]\n A --> I[par-term-keybindings]\n A --> J[par-term-scripting]\n A --> K[par-term-ssh]\n A --> L[par-term-update]\n A --> M[par-term-mcp]\n A --> N[par-term-tmux]\n```\n\n## Conclusion\n\nThe `Cargo.toml` file is essential for the `par-term` project, providing a structured way to manage dependencies, build configurations, and project metadata. Understanding this file is crucial for developers looking to contribute to the `par-term` terminal emulator, as it lays the groundwork for the entire codebase. By leveraging the modular architecture defined in this file, developers can efficiently work on individual components while maintaining coherence across the project.","other-casks":"# Other — Casks\n\n# Documentation for the **Other — Casks** Module: `par-term`\n\n## Overview\n\nThe `par-term` module is a Homebrew Cask definition for installing the `par-term` application, a cross-platform GPU-accelerated terminal emulator that supports inline graphics. This module is part of the Homebrew package manager ecosystem, which allows users to easily install and manage software on macOS.\n\n## Purpose\n\nThe primary purpose of this module is to define the installation process for the `par-term` application, including its versioning, dependencies, and cleanup procedures. It provides a standardized way to install the application using Homebrew, ensuring that users can easily access and manage it.\n\n## Key Components\n\n### Cask Definition\n\nThe cask definition is encapsulated within a `cask` block, which includes several key attributes:\n\n- **Architecture Handling**: \n ```ruby\n arch arm: \"aarch64\", intel: \"x86_64\"\n ```\n This line specifies the architecture for the application, allowing Homebrew to select the appropriate binary based on the user's system architecture (ARM or Intel).\n\n- **Version and SHA256 Checksum**:\n ```ruby\n version \"0.21.0\"\n sha256 arm: \"4981398d607648330b56757411f351532cfe6d9531be3c0e592ddebcab1ec525\",\n intel: \"b20589e1673f8844994bd625f46ddeab8f001a8a94919133fda550c464ffef19\"\n ```\n The version of the application is specified along with its SHA256 checksum for both architectures. This ensures the integrity of the downloaded files.\n\n- **Download URL**:\n ```ruby\n url \"https://github.com/paulrobello/par-term/releases/download/v#{version}/par-term-macos-#{arch}.zip\"\n ```\n The URL for downloading the application is dynamically constructed using the specified version and architecture.\n\n- **Application Metadata**:\n ```ruby\n name \"par-term\"\n desc \"Cross-platform GPU-accelerated terminal emulator with inline graphics support\"\n homepage \"https://github.com/paulrobello/par-term\"\n ```\n This section provides metadata about the application, including its name, description, and homepage URL.\n\n- **Dependencies**:\n ```ruby\n depends_on macos: \">= :catalina\"\n ```\n This line specifies that the application requires macOS Catalina or later to run.\n\n- **Livecheck**:\n ```ruby\n livecheck do\n url :homepage\n strategy :github_latest\n end\n ```\n The `livecheck` block defines how Homebrew checks for updates to the application. It uses the GitHub releases page to determine the latest version.\n\n- **Application Installation**:\n ```ruby\n app \"par-term.app\"\n ```\n This line specifies the application bundle to be installed.\n\n- **Cleanup Procedures**:\n ```ruby\n zap trash: [\n \"~/Library/Application Support/par-term\",\n \"~/Library/Preferences/com.paulrobello.par-term.plist\",\n \"~/Library/Saved Application State/com.paulrobello.par-term.savedState\",\n \"~/.config/par-term\",\n ]\n ```\n The `zap` block defines files and directories to be removed when the application is uninstalled, ensuring a clean removal.\n\n## Execution Flow\n\nThis module does not have any internal or outgoing calls, nor does it exhibit any execution flows. It is a straightforward Cask definition that Homebrew processes when a user installs or uninstalls the `par-term` application.\n\n## Integration with Homebrew\n\nThe `par-term` Cask integrates seamlessly with the Homebrew ecosystem. When a user runs the command:\n\n```bash\nbrew install --cask par-term\n```\n\nHomebrew reads the Cask definition, downloads the appropriate version of the application, verifies the checksum, and installs it in the `/Applications` directory. The user can later uninstall the application using:\n\n```bash\nbrew uninstall --cask par-term\n```\n\nThis command triggers the cleanup procedures defined in the `zap` block, ensuring that all associated files are removed.\n\n## Conclusion\n\nThe `par-term` module is a well-structured Cask definition that facilitates the installation and management of the `par-term` application on macOS. By adhering to Homebrew's conventions, it ensures a smooth user experience while providing essential metadata and cleanup procedures. Developers looking to contribute to this module should focus on maintaining the accuracy of versioning, checksums, and dependencies as the application evolves.","other-cross-toml":"# Other — Cross.toml\n\n# Cross.toml Module Documentation\n\n## Overview\n\nThe **Cross.toml** module is a configuration file used in Rust projects to define cross-compilation settings for the `aarch64-unknown-linux-gnu` target. This module specifies pre-build commands that are executed to prepare the build environment for cross-compiling applications targeting the ARM64 architecture on a Linux system.\n\n## Purpose\n\nThe primary purpose of the **Cross.toml** module is to automate the setup of the necessary dependencies and environment configurations required for building applications for the ARM64 architecture. This is particularly useful for developers who need to compile their Rust applications for different architectures without manually installing dependencies each time.\n\n## Key Components\n\n### Target Specification\n\nThe module defines a target section for `aarch64-unknown-linux-gnu`, which is the target architecture for ARM64 Linux systems. This section contains a list of pre-build commands that are executed before the actual build process begins.\n\n```toml\n[target.aarch64-unknown-linux-gnu]\n```\n\n### Pre-Build Commands\n\nThe `pre-build` array contains a series of shell commands that are executed in sequence. These commands are responsible for:\n\n1. **Adding the ARM64 architecture**: This command allows the package manager to recognize and install ARM64 packages.\n ```bash\n dpkg --add-architecture arm64\n ```\n\n2. **Updating the package list**: This ensures that the package manager has the latest information about available packages.\n ```bash\n apt-get update\n ```\n\n3. **Installing necessary development libraries**: The following command installs a set of libraries required for building applications that depend on various graphical and audio functionalities:\n ```bash\n apt-get install -y libasound2-dev:arm64 libxkbcommon-dev:arm64 libwayland-dev:arm64 libxcb-render0-dev:arm64 libxcb-shape0-dev:arm64 libxcb-xfixes0-dev:arm64 libgtk-3-dev:arm64 libxdo-dev:arm64 libssl-dev:arm64\n ```\n\n### Dependencies\n\nThe libraries specified in the `apt-get install` command are essential for applications that utilize:\n\n- **Audio**: `libasound2-dev` provides development files for the ALSA sound library.\n- **Windowing and Graphics**: Libraries like `libxkbcommon-dev`, `libwayland-dev`, `libxcb-*`, and `libgtk-3-dev` are crucial for applications that require graphical user interfaces.\n- **Networking and Security**: `libssl-dev` is necessary for applications that implement secure communications.\n\n## Execution Flow\n\nThe **Cross.toml** module does not have any internal calls, outgoing calls, or incoming calls. It serves as a configuration file that is read by the Rust toolchain during the build process. The execution flow is straightforward:\n\n1. The Rust build system detects the target architecture specified in the `Cross.toml`.\n2. The pre-build commands are executed in the order they are defined.\n3. Once the environment is set up with the required libraries, the actual build process for the target architecture can commence.\n\n## Integration with the Codebase\n\nThe **Cross.toml** module is typically used in conjunction with the Rust toolchain and Cargo, Rust's package manager and build system. When a developer specifies the target architecture during the build process (e.g., using `cargo build --target aarch64-unknown-linux-gnu`), Cargo will reference the **Cross.toml** file to execute the pre-build commands.\n\nThis integration allows developers to maintain a consistent build environment across different architectures, simplifying the cross-compilation process.\n\n## Conclusion\n\nThe **Cross.toml** module is a vital component for developers looking to cross-compile Rust applications for the ARM64 architecture. By automating the setup of necessary dependencies, it streamlines the build process and ensures that applications can be built efficiently and reliably for different target environments.","other-examples":"# Other — examples\n\n# Hello Observer Module Documentation\n\n## Overview\n\nThe **Hello Observer** module is a Python script designed to interact with the par-term terminal environment. It listens for specific terminal events, processes them, and responds with commands formatted as JSON. This module serves as an example of how to implement a par-term observer, showcasing the scripting protocol and providing a foundation for further development.\n\n## Purpose\n\nThe primary purpose of the Hello Observer script is to demonstrate how to:\n- Read terminal events from standard input (stdin).\n- Log messages and send notifications based on those events.\n- Update the terminal UI with relevant information.\n\n## Key Components\n\n### 1. Event Handling\n\nThe script listens for three types of events:\n- **bell_rang**: Triggered when the terminal bell is activated.\n- **cwd_changed**: Triggered when the current working directory changes.\n- **command_complete**: Triggered when a command execution completes.\n\n### 2. Functions\n\nThe script contains several key functions that facilitate its operation:\n\n- **`send_command(cmd: dict) -> None`**: Sends a JSON command to the par-term environment. This function is the core method for communicating with the terminal.\n\n- **`log(level: str, message: str) -> None`**: Logs messages through the par-term logging system. It uses `send_command` to format the log message as a JSON object.\n\n- **`set_panel(title: str, content: str) -> None`**: Updates a markdown panel in the terminal UI. This function allows the script to display real-time information about its status and the events it processes.\n\n- **`notify(title: str, body: str) -> None`**: Displays a desktop notification. This is useful for alerting the user about significant events, such as command failures.\n\n- **`main() -> None`**: The entry point of the script. It initializes the observer, processes incoming events, and manages the overall flow of the application.\n\n### 3. Execution Flow\n\nThe execution flow of the Hello Observer script is straightforward. Upon starting, it logs its initialization, sets up the UI panel, and enters a loop to read events from stdin. Each event is processed based on its type, and appropriate actions are taken (logging, updating the panel, or sending notifications).\n\n### 4. Example Usage\n\nTo use the Hello Observer script, include it in your `config.yaml` as follows:\n\n```yaml\nscripts:\n - name: \"Hello Observer\"\n script_path: \"scripts/examples/hello_observer.py\"\n auto_start: true\n subscriptions: [\"bell_rang\", \"cwd_changed\", \"command_complete\"]\n```\n\nThis configuration ensures that the script starts automatically and subscribes to the specified events.\n\n## Call Graph\n\nThe following Mermaid diagram illustrates the internal function calls within the Hello Observer module:\n\n```mermaid\ngraph TD;\n A[main] -->|calls| B[log]\n A -->|calls| C[set_panel]\n A -->|reads| D[stdin]\n D -->|parses| E[event]\n E -->|triggers| F[notify]\n E -->|triggers| B\n E -->|triggers| C\n```\n\n## Conclusion\n\nThe Hello Observer module is a practical example of how to implement an observer in the par-term environment. By understanding its structure and functionality, developers can extend or modify the script to suit their needs, whether for logging, notifications, or UI updates. This module serves as a foundation for building more complex interactions within the terminal.","other-gallery":"# Other — gallery\n\n# Other — Gallery Module Documentation\n\n## Overview\n\nThe **Gallery Module** is a static HTML page designed to showcase a collection of shader effects. It serves as a visual reference for developers and artists working with shaders, providing a user-friendly interface to view and interact with various shader examples. The gallery is styled using CSS to create an appealing layout and hover effects, enhancing the user experience.\n\n## Purpose\n\nThe primary purpose of the Gallery Module is to present a visually organized collection of shader effects, allowing users to easily browse through different shaders. Each shader is represented as a card that includes an image and a name, making it straightforward for users to identify and select shaders for further exploration or implementation.\n\n## Key Components\n\n### HTML Structure\n\nThe HTML structure of the gallery is straightforward, consisting of a main container and individual shader cards. Below are the key components:\n\n- **`<h1>`**: Displays the title of the gallery.\n- **`.gallery`**: A grid container that holds all shader cards.\n- **`.shader-card`**: Each shader card contains:\n - An `<img>` element for the shader preview.\n - A `<div>` with the class `.shader-name` for the shader's name.\n\n### CSS Styling\n\nThe CSS styles are embedded within the `<head>` section of the HTML document. Key styling features include:\n\n- **Grid Layout**: The gallery uses CSS Grid to create a responsive layout that adjusts based on the screen size.\n- **Card Design**: Each shader card has a dark background, rounded corners, and a shadow effect that enhances its appearance. A hover effect is applied to elevate the card slightly and change its shadow, providing visual feedback to users.\n- **Typography**: The font styles are chosen for readability and aesthetic appeal, with a focus on contrasting colors to ensure text visibility against the background.\n\n### Shader Cards\n\nEach shader card is constructed as follows:\n\n```html\n<div class=\"shader-card\">\n <img src=\"shader-image.png\" alt=\"shader-name\" loading=\"lazy\">\n <div class=\"shader-name\">shader-name</div>\n</div>\n```\n\n- **Image Source**: The `src` attribute of the `<img>` tag points to the shader's image file.\n- **Alt Text**: The `alt` attribute provides a description of the shader for accessibility.\n- **Lazy Loading**: The `loading=\"lazy\"` attribute is used to improve performance by deferring the loading of images until they are needed.\n\n## How It Works\n\nThe Gallery Module does not include any JavaScript or dynamic content; it is purely a static HTML page. When the page is loaded in a browser, the CSS styles are applied, and the gallery is rendered as a grid of shader cards. Users can scroll through the gallery to view different shaders.\n\n### Example of a Shader Card\n\nHere’s an example of how a shader card is structured in the HTML:\n\n```html\n<div class=\"shader-card\">\n <img src=\"animated-gradient-shader.png\" alt=\"animated-gradient-shader\" loading=\"lazy\">\n <div class=\"shader-name\">animated-gradient-shader</div>\n</div>\n```\n\nThis card displays the \"animated-gradient-shader\" with its corresponding image.\n\n## Integration with the Codebase\n\nThe Gallery Module is designed to be a standalone component within the broader application. It does not have any direct dependencies or interactions with other modules, as indicated by the absence of internal or outgoing calls. However, it can be linked to from other parts of the application, allowing users to navigate to the gallery easily.\n\n### Navigation\n\nTo integrate the gallery into the application, you can create a link in other HTML files:\n\n```html\n<a href=\"gallery/index.html\">View Shader Gallery</a>\n```\n\nThis link will direct users to the gallery page, where they can explore the shaders.\n\n## Conclusion\n\nThe Gallery Module is a simple yet effective way to showcase shader effects in a visually appealing manner. Its clean design and responsive layout make it easy for users to browse through various shaders. Developers can contribute to this module by adding new shader cards or modifying the existing styles to enhance the user experience. \n\nFor any further enhancements or features, consider integrating JavaScript for dynamic content loading or user interactions, such as filtering or searching through shaders.","other-gh-pages":"# Other — gh-pages\n\n# gh-pages Module Documentation\n\n## Overview\n\nThe **gh-pages** module serves as the front-end for the **par-term** project, a GPU-accelerated terminal emulator. This module provides a user-friendly interface for installation instructions, feature highlights, and links to resources related to the **par-term** project. It consists of an HTML file and two shell scripts that facilitate the installation of shaders and shell integration.\n\n## Key Components\n\n### 1. `index.html`\n\nThe `index.html` file is the main entry point for the **gh-pages** module. It contains the structure and styling for the web page that users will interact with. The key sections of this file include:\n\n- **Header**: Displays the project title, tagline, and badges for version, stars, and license.\n- **Quick Install Section**: Provides commands for installing shaders and shell integration.\n- **Resources Section**: Contains links to the shader gallery, GitHub repository, downloads, and documentation.\n- **Features Section**: Lists the key features of the **par-term** terminal emulator.\n- **Footer**: Credits the creator and provides licensing information.\n\n#### HTML Structure\n\n```html\n<body>\n <div class=\"container\">\n <header>...</header>\n <section class=\"section\">...</section>\n <section class=\"section\">...</section>\n <section class=\"section\">...</section>\n <footer>...</footer>\n </div>\n</body>\n```\n\n### 2. `install-shaders.sh`\n\nThis shell script automates the installation of shaders for the **par-term** terminal emulator. It downloads the latest shaders from the GitHub repository and extracts them to the appropriate configuration directory based on the user's operating system.\n\n#### Key Functions\n\n- **detect_config_dir**: Determines the correct configuration directory based on the operating system.\n- **cleanup**: Cleans up temporary files after the script execution.\n- **download_url**: Fetches the latest release download URL for the shaders.\n- **unzip**: Extracts the downloaded shaders to the specified directory.\n\n#### Usage\n\nTo install shaders, users can run the following command:\n\n```bash\ncurl -sSL https://paulrobello.github.io/par-term/install-shaders.sh | sh\n```\n\n### 3. `install-shell-integration.sh`\n\nThis shell script installs shell integration for **par-term**, enabling features like directory tracking and command notifications. It modifies the user's shell configuration file to include the necessary integration scripts.\n\n#### Key Functions\n\n- **detect_shell**: Identifies the user's shell (bash, zsh, or fish).\n- **get_rc_file**: Determines the appropriate configuration file for the detected shell.\n- **download_file**: Downloads required files using either `curl` or `wget`.\n- **add_integration_block**: Inserts the integration block into the user's RC file.\n\n#### Usage\n\nTo install shell integration, users can run the following command:\n\n```bash\ncurl -sSL https://paulrobello.github.io/par-term/install-shell-integration.sh | sh\n```\n\n## How It Works\n\nThe **gh-pages** module operates as a static website that provides essential information and installation scripts for the **par-term** project. When users access the page, they are presented with a visually appealing layout that guides them through the installation process.\n\n### Execution Flow\n\n1. Users visit the **gh-pages** URL, which serves the `index.html` file.\n2. The page displays installation commands for shaders and shell integration.\n3. Users can execute the provided commands in their terminal to install the necessary components.\n4. The installation scripts handle downloading and configuring the required files automatically.\n\n## Integration with the Codebase\n\nThe **gh-pages** module is designed to be a standalone front-end interface for the **par-term** project. It does not directly interact with other modules in the codebase but serves as a bridge for users to access installation scripts and project resources.\n\n### Mermaid Diagram\n\nThe following diagram illustrates the relationship between the components of the **gh-pages** module:\n\n```mermaid\ngraph TD;\n A[index.html] -->|Displays| B[install-shaders.sh]\n A -->|Displays| C[install-shell-integration.sh]\n B -->|Downloads| D[shaders.zip]\n C -->|Modifies| E[RC file]\n```\n\n## Conclusion\n\nThe **gh-pages** module is a crucial part of the **par-term** project, providing users with an easy way to install and configure the terminal emulator. By understanding its components and how they work together, developers can contribute to enhancing the user experience and functionality of the **par-term** project.","other-ideas-md":"# Other — ideas.md\n\n# Documentation for the **Other — ideas.md** Module\n\n## Overview\n\nThe **ideas.md** module serves as a repository for brainstorming and documenting ideas related to the project. It is not a functional code module but rather a markdown file that provides a space for developers to jot down thoughts, suggestions, and potential features that could enhance the project. This module is essential for fostering collaboration and innovation within the development team.\n\n## Purpose\n\nThe primary purpose of the **ideas.md** module is to:\n\n- Provide a centralized location for team members to share and discuss ideas.\n- Encourage creativity and exploration of new features or improvements.\n- Serve as a historical record of ideas that can be revisited or implemented in the future.\n\n## Structure\n\nThe **ideas.md** file is structured in a way that allows for easy navigation and understanding. Here are the key components typically found in this module:\n\n1. **Idea Title**: A clear and concise title for the idea.\n2. **Description**: A detailed explanation of the idea, including its purpose and potential impact on the project.\n3. **Benefits**: A list of advantages that implementing the idea could bring.\n4. **Challenges**: Any potential obstacles or considerations that need to be addressed.\n5. **Related Ideas**: Links or references to other ideas that are similar or could be related.\n\n### Example Structure\n\n```markdown\n# Idea Title\n\n## Description\nA brief overview of the idea and its intended purpose.\n\n## Benefits\n- Benefit 1\n- Benefit 2\n\n## Challenges\n- Challenge 1\n- Challenge 2\n\n## Related Ideas\n- [Related Idea 1](#)\n- [Related Idea 2](#)\n```\n\n## How It Works\n\nThe **ideas.md** module does not contain any executable code or functions. Instead, it relies on markdown syntax to format the content. Developers can edit this file using any text editor that supports markdown, making it accessible and easy to update.\n\n### Collaboration\n\nTeam members are encouraged to contribute to the **ideas.md** file by:\n\n- Adding new ideas as they arise.\n- Commenting on existing ideas to provide feedback or suggestions.\n- Updating the status of ideas that have been implemented or discarded.\n\n## Connection to the Codebase\n\nWhile the **ideas.md** module does not directly interact with other parts of the codebase, it plays a crucial role in the development process. The ideas documented here can lead to new features, enhancements, or refactoring efforts in the codebase. \n\n### Workflow Integration\n\nThe ideas documented in this module can be integrated into the development workflow by:\n\n- Reviewing ideas during sprint planning meetings.\n- Prioritizing ideas based on team feedback and project goals.\n- Assigning team members to explore and implement viable ideas.\n\n## Conclusion\n\nThe **ideas.md** module is a vital component of the project, serving as a collaborative space for innovation and creativity. By documenting ideas, the team can ensure that valuable suggestions are not lost and can be revisited as the project evolves. Developers are encouraged to actively participate in maintaining this module to foster a culture of continuous improvement.","other-images":"# Other — images\n\n# Other — Images Module Documentation\n\n## Overview\n\nThe **Other — images** module is designed to handle the representation and manipulation of images in a specific format known as Sixel. Sixel is a bitmap graphics format that allows for the transmission of images in a text-based environment, such as terminal emulators. This module provides the necessary functionality to decode Sixel data and render images accordingly.\n\n## Purpose\n\nThe primary purpose of this module is to facilitate the display of images encoded in the Sixel format within applications that support terminal graphics. It allows developers to integrate image rendering capabilities into their terminal-based applications, enhancing the user experience by providing visual content.\n\n## Key Components\n\n### Sixel Data Structure\n\nThe Sixel data is represented as a series of commands and parameters that dictate how the image should be rendered. The data is typically structured in a compact format, which includes color definitions, pixel positions, and other rendering instructions.\n\n### Image Rendering Functionality\n\nThe module includes functions that parse the Sixel data and convert it into a format that can be displayed in a terminal. This involves:\n\n1. **Decoding Sixel Commands**: The module interprets the Sixel commands to extract pixel data and color information.\n2. **Rendering to Terminal**: Once the data is decoded, the module uses terminal escape sequences to render the image on the screen.\n\n### Example Sixel Data\n\nThe Sixel data is typically stored in a format similar to the following:\n\n```plaintext\nP0;0;0q\"1;1;600;450#0;2;4;4;2#1;2;8;5;2#2;2;11;8;1...\n```\n\nThis string contains various commands that define the image's properties, such as dimensions and color mappings.\n\n## How It Works\n\nThe module operates by following these steps:\n\n1. **Input Handling**: The Sixel data is received as a string input.\n2. **Parsing**: The module parses the input string to identify commands and parameters.\n3. **Image Construction**: Based on the parsed data, the module constructs an image representation in memory.\n4. **Terminal Output**: The constructed image is then rendered to the terminal using appropriate escape sequences.\n\n### Example Usage\n\nTo use the images module, a developer would typically follow these steps:\n\n1. Import the module into their application.\n2. Provide the Sixel data as input to the rendering function.\n3. Call the rendering function to display the image.\n\n```python\nfrom images import render_sixel\n\nsixel_data = \"P0;0;0q\\\"1;1;600;450#0;2;4;4;2#1;2;8;5;2#2;2;11;8;1...\"\nrender_sixel(sixel_data)\n```\n\n## Integration with the Codebase\n\nThe images module is designed to be modular and can be integrated into larger applications that require image rendering capabilities. It does not have any external dependencies, making it easy to include in various projects.\n\n### Connection to Other Modules\n\nWhile the images module does not have direct internal or outgoing calls to other modules, it can be utilized in conjunction with other components of a terminal application, such as:\n\n- **User Interface Modules**: To enhance the visual aspects of the user interface by displaying images.\n- **Data Processing Modules**: To fetch and decode Sixel data from external sources.\n\n## Conclusion\n\nThe **Other — images** module provides a straightforward and efficient way to render Sixel images in terminal applications. By leveraging this module, developers can enhance their applications with visual content, improving user engagement and experience.\n\n### Mermaid Diagram\n\n```mermaid\ngraph TD;\n A[Input Sixel Data] --> B[Parse Sixel Commands];\n B --> C[Construct Image Representation];\n C --> D[Render to Terminal];\n D --> E[Display Image];\n```\n\nThis diagram illustrates the flow of data through the module, from input to rendering, providing a clear overview of the processing steps involved in displaying Sixel images.","other-install-shaders-sh":"# Other — install_shaders.sh\n\n# Documentation for `install_shaders.sh`\n\n## Overview\n\nThe `install_shaders.sh` script is designed to automate the installation of shader files for the `par-term` terminal emulator. It downloads the latest release of shaders from the official GitHub repository, extracts them, and places them in the appropriate configuration directory based on the operating system. This script is cross-platform compatible, functioning on macOS, Linux, and Windows (via Git Bash or WSL).\n\n## Purpose\n\nThe primary purpose of this script is to simplify the process of obtaining and installing shader files, which enhance the visual appearance of the `par-term` terminal. By automating the download and extraction process, users can quickly set up their terminal environment without manual intervention.\n\n## Key Components\n\n### 1. Configuration Directory Detection\n\nThe script begins by determining the appropriate configuration directory based on the operating system. This is handled by the `detect_config_dir` function:\n\n```sh\ndetect_config_dir() {\n case \"$(uname -s)\" in\n Darwin)\n echo \"$HOME/.config/par-term/shaders\"\n ;;\n Linux)\n echo \"${XDG_CONFIG_HOME:-$HOME/.config}/par-term/shaders\"\n ;;\n MINGW*|MSYS*|CYGWIN*)\n echo \"$APPDATA/par-term/shaders\"\n ;;\n *)\n echo \"$HOME/.config/par-term/shaders\"\n ;;\n esac\n}\n```\n\n### 2. Temporary Directory Management\n\nA temporary directory is created to store the downloaded zip file. The script ensures that this directory is cleaned up after execution using a trap:\n\n```sh\nTEMP_DIR=$(mktemp -d)\n\ncleanup() {\n rm -rf \"$TEMP_DIR\"\n}\ntrap cleanup EXIT\n```\n\n### 3. Dependency Checks\n\nBefore proceeding with the download, the script checks for the presence of required tools: `curl` or `wget` for downloading files, and `unzip` for extracting the downloaded zip file. If any of these tools are missing, the script exits with an error message.\n\n### 4. Downloading the Latest Release\n\nThe script fetches the latest release information from the GitHub API to obtain the download URL for `shaders.zip`. It uses either `curl` or `wget` based on availability:\n\n```sh\nif command -v curl >/dev/null 2>&1; then\n DOWNLOAD_URL=$(curl -sL \"https://api.github.com/repos/$REPO/releases/latest\" | \\\n grep -o '\"browser_download_url\": *\"[^\"]*shaders\\.zip\"' | \\\n sed 's/\"browser_download_url\": *\"//' | sed 's/\"$//')\nelse\n DOWNLOAD_URL=$(wget -qO- \"https://api.github.com/repos/$REPO/releases/latest\" | \\\n grep -o '\"browser_download_url\": *\"[^\"]*shaders\\.zip\"' | \\\n sed 's/\"browser_download_url\": *\"//' | sed 's/\"$//')\nfi\n```\n\n### 5. Downloading and Extracting Shaders\n\nOnce the download URL is obtained, the script downloads the zip file and extracts it into the determined configuration directory:\n\n```sh\nmkdir -p \"$CONFIG_DIR\"\nunzip -o \"$TEMP_DIR/shaders.zip\" -d \"$PARENT_DIR\"\n```\n\n### 6. Installation Summary\n\nAfter extraction, the script counts the number of installed shader files and provides a summary to the user, including instructions on how to configure the shaders in `config.yaml`.\n\n## Execution Flow\n\nThe execution flow of the script can be summarized as follows:\n\n1. **Detect OS and Set Config Directory**: The script determines the appropriate configuration directory based on the operating system.\n2. **Check for Required Tools**: It verifies that necessary tools (`curl`, `wget`, `unzip`) are installed.\n3. **Warning for Overwriting**: If the target directory already contains files, the user is prompted for confirmation to overwrite.\n4. **Fetch Latest Release**: The script retrieves the latest release information from GitHub to find the download URL for `shaders.zip`.\n5. **Download and Extract**: The zip file is downloaded and extracted to the configuration directory.\n6. **Display Installation Summary**: The script counts the installed shaders and provides usage instructions.\n\n```mermaid\ngraph TD;\n A[Start] --> B[Detect OS and Set Config Directory]\n B --> C[Check for Required Tools]\n C --> D{Existing Shaders?}\n D -->|Yes| E[Prompt for Overwrite]\n D -->|No| F[Fetch Latest Release]\n E --> F\n F --> G[Download and Extract Shaders]\n G --> H[Display Installation Summary]\n H --> I[End]\n```\n\n## Conclusion\n\nThe `install_shaders.sh` script is a crucial utility for users of the `par-term` terminal emulator, streamlining the process of installing shaders. By understanding its components and execution flow, developers can contribute to its improvement or troubleshoot issues effectively. For further customization, users can refer to the shader configuration options provided in the installation summary.","other-makefile":"# Other — Makefile\n\n# Makefile Documentation for par-term\n\n## Overview\n\nThe **Makefile** for the `par-term` project serves as a build automation tool for a cross-platform terminal emulator frontend. It defines a series of commands (or targets) that streamline the development, testing, and deployment processes. This document provides a comprehensive overview of the Makefile's structure, key components, and usage.\n\n## Purpose\n\nThe primary purpose of this Makefile is to facilitate the following tasks:\n\n- **Building** the project in various configurations (debug, release, etc.)\n- **Running** the application with different logging levels\n- **Testing** the codebase and ensuring quality through linting and formatting\n- **Generating** documentation and coverage reports\n- **Creating** macOS application bundles\n- **Deploying** the application via GitHub Actions\n\n## Key Components\n\n### Targets\n\nThe Makefile is organized into several targets, each serving a specific function. Below is a summary of the most important targets:\n\n#### 1. Build Targets\n\n- **`build`**: Compiles the project in development release mode (optimized, no full LTO).\n- **`build-full`**: Compiles the project with full release optimizations (LTO).\n- **`build-debug`**: Compiles the project in debug mode.\n- **`release`**: Alias for `build-full`, outputs the release binary.\n\n#### 2. Run Targets\n\n- **`run`**: Executes the application in development release mode.\n- **`run-debug`**: Executes the application with debug logging enabled.\n- **`run-error`, `run-warn`, `run-info`**: Execute the application with different logging levels.\n- **`run-bundle`**: Runs the application as a macOS app bundle.\n\n#### 3. Testing and Quality Assurance\n\n- **`test`**: Runs all tests in the workspace.\n- **`check`**: Checks the code without building.\n- **`fmt`**: Formats the code using `rustfmt`.\n- **`lint`**: Runs the Clippy linter to catch common mistakes.\n\n#### 4. Documentation and Coverage\n\n- **`doc`**: Generates documentation for the project.\n- **`coverage`**: Generates a test coverage report using `cargo-tarpaulin`.\n\n#### 5. Deployment\n\n- **`deploy`**: Triggers the Release and Deploy GitHub Action.\n\n### Additional Features\n\n- **Pre-commit Checks**: The `pre-commit` target runs formatting, linting, and testing to ensure code quality before committing changes.\n- **CI Checks**: The `ci` target runs checks that would typically be executed in a Continuous Integration environment.\n\n## Usage\n\nTo use the Makefile, navigate to the project directory in your terminal and run `make <target>`. For example:\n\n```bash\nmake build\n```\n\nThis command will compile the project in development release mode. You can view all available targets by running:\n\n```bash\nmake help\n```\n\n### Example Workflows\n\n1. **Building and Running the Application**:\n ```bash\n make build\n make run\n ```\n\n2. **Testing and Quality Checks**:\n ```bash\n make checkall\n ```\n\n3. **Generating Documentation**:\n ```bash\n make doc-open\n ```\n\n4. **Deploying the Application**:\n ```bash\n make deploy\n ```\n\n## Architecture Overview\n\nThe Makefile does not have internal or outgoing calls to other modules, but it serves as a central point for managing the build and deployment processes of the `par-term` project. Below is a simple representation of how the Makefile interacts with various components of the project.\n\n```mermaid\ngraph TD;\n A[Makefile] -->|build| B[Cargo]\n A -->|run| C[par-term Application]\n A -->|test| D[Unit Tests]\n A -->|lint| E[Clippy]\n A -->|format| F[rustfmt]\n A -->|doc| G[Documentation]\n A -->|deploy| H[GitHub Actions]\n```\n\n## Conclusion\n\nThe Makefile for `par-term` is a powerful tool that simplifies the development workflow by providing a structured way to build, run, test, and deploy the application. By understanding the various targets and their purposes, developers can efficiently contribute to the project and maintain high-quality code.","other-par-term-acp":"# Other — par-term-acp\n\n# par-term-acp Module Documentation\n\n## Overview\n\nThe **par-term-acp** module implements the Agent Communication Protocol (ACP) for the `par-term` project. This module is designed to facilitate communication between agents in a terminal environment, leveraging JSON-RPC for message formatting and transmission. The module is built on top of the Tokio asynchronous runtime, allowing for efficient handling of concurrent tasks.\n\n### Key Features\n- **Asynchronous Communication**: Utilizes Tokio for non-blocking I/O operations.\n- **JSON-RPC Support**: Implements JSON-RPC for structured communication between agents.\n- **Logging**: Integrates the `log` crate for logging purposes, aiding in debugging and monitoring.\n\n## Dependencies\n\nThe module relies on several key dependencies, which are specified in the `Cargo.toml` file:\n\n- **Tokio**: The asynchronous runtime for Rust, enabling concurrent programming.\n- **Serde**: A framework for serializing and deserializing Rust data structures, used here for JSON handling.\n- **Serde JSON**: Provides JSON serialization and deserialization capabilities.\n- **TOML**: Used for configuration file parsing.\n- **Log**: A logging facade for Rust, allowing for flexible logging strategies.\n- **Tempfile**: A development dependency for creating temporary files during testing.\n\n## Architecture\n\nThe architecture of the **par-term-acp** module is straightforward, focusing on the core functionalities of agent communication. The module does not have any internal or outgoing calls, which simplifies its design. \n\n### Core Components\n\n1. **Agent**: Represents an entity that can send and receive messages. The agent is responsible for initiating communication and processing incoming messages.\n2. **Message**: A struct that encapsulates the data structure for messages exchanged between agents. This includes fields for the method, parameters, and any necessary metadata.\n3. **RPC Client**: A component that handles the sending of JSON-RPC requests to other agents. It manages the serialization of messages and the handling of responses.\n4. **RPC Server**: A component that listens for incoming JSON-RPC requests from other agents. It processes these requests and sends back appropriate responses.\n\n### Execution Flow\n\nWhile there are no explicit execution flows detected for this module, the general flow of communication can be summarized as follows:\n\n1. An **Agent** sends a message using the **RPC Client**.\n2. The **RPC Client** serializes the message into JSON format.\n3. The message is transmitted to the target agent's **RPC Server**.\n4. The **RPC Server** receives the message, deserializes it, and processes the request.\n5. A response is generated and sent back to the originating agent.\n\n## Example Usage\n\nTo use the **par-term-acp** module in your project, you would typically follow these steps:\n\n1. **Add the Dependency**: Include the module in your `Cargo.toml` file.\n ```toml\n [dependencies]\n par-term-acp = { git = \"https://github.com/paulrobello/par-term\" }\n ```\n\n2. **Initialize an Agent**: Create an instance of an agent and set up the necessary components.\n ```rust\n use par_term_acp::{Agent, Message};\n\n let agent = Agent::new(\"Agent1\");\n ```\n\n3. **Send a Message**: Use the agent to send a message to another agent.\n ```rust\n let message = Message::new(\"method_name\", params);\n agent.send(message).await?;\n ```\n\n4. **Receive a Message**: Implement a listener in the agent to handle incoming messages.\n ```rust\n agent.listen().await?;\n ```\n\n## Conclusion\n\nThe **par-term-acp** module provides a robust foundation for implementing agent communication in terminal applications. By leveraging asynchronous programming and structured message formats, it enables efficient and scalable communication patterns. Developers looking to extend or contribute to this module should familiarize themselves with the core components and the overall architecture to effectively implement new features or enhancements.\n\nFor further details, please refer to the [GitHub repository](https://github.com/paulrobello/par-term) for source code and additional documentation.","other-par-term-config":"# Other — par-term-config\n\n# par-term-config Module Documentation\n\n## Overview\n\nThe `par-term-config` module is a configuration management system designed specifically for the `par-term` terminal emulator. It provides a structured way to define, load, and manage configuration settings, allowing users to customize their terminal experience. The module supports various serialization formats, including JSON, YAML, and TOML, and integrates with the terminal emulator's core functionalities.\n\n### Key Features\n- **Serialization Support**: Utilizes `serde` for easy serialization and deserialization of configuration files in multiple formats.\n- **UUID Management**: Generates unique identifiers for terminal profiles using the `uuid` crate.\n- **Error Handling**: Implements robust error handling with the `anyhow` crate.\n- **Hot Reloading**: Supports configuration hot reloading through file watching, enhancing user experience by applying changes without restarting the terminal.\n- **Platform Compatibility**: Adapts to different operating systems, ensuring consistent behavior across environments.\n\n## Architecture\n\nThe `par-term-config` module is structured to facilitate easy integration with the `par-term` terminal emulator. Below is a high-level overview of its architecture:\n\n```mermaid\ngraph TD;\n A[par-term-config] --> B[Configuration Loader]\n A --> C[Profile Manager]\n A --> D[Serialization]\n A --> E[Hot Reloading]\n A --> F[Error Handling]\n A --> G[Logging]\n```\n\n### Components\n\n1. **Configuration Loader**: Responsible for loading configuration files from various formats (JSON, YAML, TOML). It uses the `serde` library to parse these files into Rust data structures.\n\n2. **Profile Manager**: Manages terminal profiles, including creating, updating, and deleting profiles. Each profile is identified by a UUID, ensuring uniqueness.\n\n3. **Serialization**: Leverages `serde_json`, `serde_yaml`, and `toml` for serialization and deserialization of configuration data. This allows users to define their settings in a format of their choice.\n\n4. **Hot Reloading**: Implements file watching using the `notify` crate. When a configuration file is modified, the changes are automatically detected and applied, allowing for a seamless user experience.\n\n5. **Error Handling**: Utilizes the `anyhow` crate for error management, providing clear and concise error messages throughout the configuration loading and management processes.\n\n6. **Logging**: Integrates with the `log` crate to provide logging capabilities, which can be useful for debugging and monitoring configuration changes.\n\n## Usage\n\n### Loading Configuration\n\nTo load a configuration file, you can use the `load_config` function, which takes the file path as an argument and returns a parsed configuration object.\n\n```rust\nuse par_term_config::load_config;\n\nlet config = load_config(\"config.toml\").expect(\"Failed to load configuration\");\n```\n\n### Managing Profiles\n\nProfiles can be created and managed through the `ProfileManager` class. Here’s an example of how to create a new profile:\n\n```rust\nuse par_term_config::ProfileManager;\n\nlet mut profile_manager = ProfileManager::new();\nlet profile_id = profile_manager.create_profile(\"MyProfile\").expect(\"Failed to create profile\");\n```\n\n### Hot Reloading\n\nTo enable hot reloading, ensure that the `notify` feature is enabled in your `Cargo.toml`. The configuration loader will automatically watch for changes in the specified configuration file.\n\n```rust\nlet watcher = config.enable_hot_reloading(\"config.toml\").expect(\"Failed to enable hot reloading\");\n```\n\n## Integration with par-term\n\nThe `par-term-config` module is tightly integrated with the `par-term` terminal emulator. It provides the necessary configuration management capabilities that the terminal relies on for user settings, appearance, and behavior. The configuration data loaded by this module is used throughout the terminal's core functionalities, ensuring a cohesive user experience.\n\n### Dependencies\n\nThe module relies on several external crates for its functionality:\n\n- **serde**: For serialization and deserialization.\n- **uuid**: For generating unique identifiers.\n- **anyhow**: For error handling.\n- **log**: For logging.\n- **notify**: For file watching and hot reloading.\n- **dirs**: For platform-specific directory management.\n\n## Conclusion\n\nThe `par-term-config` module is a crucial component of the `par-term` terminal emulator, providing a flexible and user-friendly configuration management system. By leveraging modern Rust libraries, it ensures that users can easily customize their terminal experience while maintaining robust error handling and logging capabilities. Developers looking to contribute to this module should familiarize themselves with the key components and usage patterns outlined in this documentation.","other-par-term-fonts":"# Other — par-term-fonts\n\n# par-term-fonts Module Documentation\n\n## Overview\n\nThe **par-term-fonts** module is a Rust library designed for font management and text shaping specifically tailored for the **par-term** terminal emulator. It provides essential functionalities for rendering text with various fonts, handling complex scripts, and ensuring proper text shaping, which is crucial for a visually appealing terminal interface.\n\n### Key Features\n- **Font Rasterization**: Utilizes the `swash` crate for rendering fonts with support for colored glyphs.\n- **Font Discovery**: Leverages the `fontdb` crate to discover system fonts and manage fallbacks.\n- **Text Shaping**: Implements `rustybuzz` for advanced text shaping, including ligatures and complex script handling.\n- **Grapheme Clustering**: Uses `unicode-segmentation` to accurately detect text boundaries.\n- **Caching**: Employs `lru` for caching text shaping results to improve performance.\n- **Configuration Management**: Integrates with the `par-term-config` module for managing font configurations.\n\n## Architecture\n\nThe module is structured to facilitate easy integration with the rest of the **par-term** codebase while maintaining a clear separation of concerns. Below is a high-level overview of the module's architecture:\n\n```mermaid\ngraph TD;\n A[par-term-fonts] --> B[swash]\n A --> C[fontdb]\n A --> D[rustybuzz]\n A --> E[unicode-segmentation]\n A --> F[lru]\n A --> G[par-term-config]\n```\n\n### Components\n\n1. **Font Management**:\n - **Font Discovery**: The `fontdb` crate is used to scan the system for available fonts. This allows the terminal to dynamically load and fallback to different fonts as needed.\n - **Font Rasterization**: The `swash` crate is responsible for rendering the glyphs of the selected fonts, including support for colored glyphs.\n\n2. **Text Shaping**:\n - **HarfBuzz Integration**: The `rustybuzz` crate is utilized for shaping text, which is essential for rendering ligatures and handling complex scripts. This ensures that text is displayed correctly according to the rules of the language being rendered.\n\n3. **Text Boundary Detection**:\n - The `unicode-segmentation` crate is employed to detect grapheme clusters, ensuring that text boundaries are respected when rendering and manipulating text.\n\n4. **Caching**:\n - The `lru` crate provides a least-recently-used cache for storing text shaping results. This optimizes performance by reducing the need to re-shape text that has already been processed.\n\n5. **Configuration**:\n - The module interacts with the `par-term-config` module to manage font configurations, such as specifying font ranges and styles.\n\n## Usage\n\nTo use the **par-term-fonts** module, you will typically follow these steps:\n\n1. **Add Dependency**: Ensure that your `Cargo.toml` includes the `par-term-fonts` module.\n ```toml\n [dependencies]\n par-term-fonts = { path = \"../par-term-fonts\" }\n ```\n\n2. **Initialize Font Manager**: Create an instance of the font manager to load and manage fonts.\n ```rust\n use par_term_fonts::FontManager;\n\n let font_manager = FontManager::new();\n ```\n\n3. **Load Fonts**: Use the font manager to load the desired fonts from the system.\n ```rust\n font_manager.load_fonts();\n ```\n\n4. **Render Text**: Utilize the text shaping capabilities to render text correctly.\n ```rust\n let shaped_text = font_manager.shape_text(\"Hello, World!\");\n ```\n\n5. **Display in Terminal**: Finally, render the shaped text in the terminal using the terminal's rendering functions.\n\n## Conclusion\n\nThe **par-term-fonts** module is a critical component of the **par-term** terminal emulator, providing robust font management and text shaping capabilities. By leveraging various crates, it ensures that text is rendered accurately and efficiently, enhancing the overall user experience. Developers looking to contribute to this module should familiarize themselves with the dependencies and the architecture outlined in this documentation.","other-par-term-input":"# Other — par-term-input\n\n# par-term-input Module Documentation\n\n## Overview\n\nThe `par-term-input` module is designed to facilitate input sequence generation for the `par-term` terminal emulator. This module is responsible for handling keyboard input, including escape sequences, and ensuring that user interactions are processed correctly within the terminal environment. \n\n### Purpose\n\nThe primary purpose of the `par-term-input` module is to provide a robust interface for capturing and interpreting user input in a terminal setting. This includes handling special key events, managing input states, and generating the appropriate escape sequences that the terminal emulator needs to render user commands and interactions.\n\n## Key Components\n\n### 1. Dependencies\n\nThe `par-term-input` module relies on several external crates to function effectively:\n\n- **par-term-config**: This dependency provides configuration types, specifically `OptionKeyMode`, which are essential for managing key input modes.\n- **arboard**: This crate is used for clipboard access, allowing users to copy and paste text within the terminal.\n- **winit**: This library handles window and key event types, enabling the module to respond to user input events.\n- **log**: This crate is utilized for logging purposes, helping developers track the flow of input events and debug issues.\n\n### 2. Input Handling\n\nThe core functionality of the `par-term-input` module revolves around capturing keyboard input and translating it into meaningful commands for the terminal. The module listens for key events and processes them according to the defined input modes.\n\n#### Key Functions\n\nWhile the module does not expose a detailed API, it is structured to handle input through a series of internal functions that manage the state of the input and generate the necessary escape sequences. Here are some of the key functions you might encounter:\n\n- **process_key_event**: This function is responsible for interpreting individual key events. It checks the state of the input and determines how to respond to each key press.\n- **generate_escape_sequence**: This function constructs the appropriate escape sequence based on the key event and the current input mode.\n\n### 3. Input Modes\n\nThe `OptionKeyMode` configuration type from the `par-term-config` module allows the terminal to switch between different input modes. This is crucial for handling various types of input, such as normal text input, command sequences, and special key combinations (e.g., function keys, arrow keys).\n\n## Integration with the Codebase\n\nThe `par-term-input` module is designed to work seamlessly with the rest of the `par-term` codebase. It interacts primarily with the terminal rendering components and the configuration settings defined in the `par-term-config` module. \n\n### Execution Flow\n\nAlthough there are no explicit execution flows detected for this module, it is important to understand how it fits into the overall architecture of the terminal emulator. The input module is typically invoked during the event loop of the terminal, where it listens for user input and processes it accordingly.\n\n```mermaid\ngraph TD;\n A[User Input] --> B[Key Event Listener];\n B --> C[process_key_event];\n C --> D[generate_escape_sequence];\n D --> E[Terminal Rendering];\n```\n\n## Conclusion\n\nThe `par-term-input` module is a critical component of the `par-term` terminal emulator, providing the necessary functionality to handle user input effectively. By understanding its dependencies, key functions, and integration points, developers can contribute to its development and enhance the overall user experience of the terminal emulator. \n\nFor further contributions or issues, please refer to the [GitHub repository](https://github.com/paulrobello/par-term) for the `par-term` project.","other-par-term-keybindings":"# Other — par-term-keybindings\n\n# par-term-keybindings Module Documentation\n\n## Overview\n\nThe `par-term-keybindings` module provides a keybinding system for the `par-term` terminal emulator. It allows users to define and manage keyboard shortcuts, enhancing the usability and efficiency of the terminal interface. This module is designed to work seamlessly with the `par-term-config` module, which handles configuration types related to keybindings and modifier remappings.\n\n## Purpose\n\nThe primary purpose of the `par-term-keybindings` module is to facilitate the creation, modification, and management of keybindings within the terminal emulator. By providing a structured way to handle keyboard inputs, it allows users to customize their terminal experience according to their preferences.\n\n## Key Components\n\n### 1. KeyBinding Struct\n\nThe `KeyBinding` struct represents a single keybinding configuration. It typically includes the following fields:\n\n- `key`: The key or key combination that triggers the action.\n- `action`: The action to be performed when the keybinding is activated.\n- `description`: A human-readable description of the keybinding.\n\n### 2. ModifierRemapping Struct\n\nThe `ModifierRemapping` struct is used to define how modifier keys (like Shift, Ctrl, and Alt) are remapped. This is particularly useful for users who want to customize their keyboard layout or behavior.\n\n### 3. Configuration Management\n\nThe module relies on the `par-term-config` dependency to manage configurations. This includes loading, saving, and applying keybinding settings. The configuration management ensures that user-defined keybindings persist across sessions.\n\n### 4. Event Handling\n\nWhile the `par-term-keybindings` module does not directly handle input events, it is designed to integrate with the `winit` library, which manages window and input events. The keybindings are triggered based on the events captured by `winit`, allowing for responsive user interactions.\n\n## How It Works\n\nThe `par-term-keybindings` module operates by defining keybindings that are then registered with the terminal emulator. When a key event is detected, the module checks if it matches any of the defined keybindings. If a match is found, the corresponding action is executed.\n\n### Execution Flow\n\n1. **Keybinding Definition**: Users define keybindings using the `KeyBinding` struct.\n2. **Configuration Loading**: The module loads existing keybindings from the configuration file using the `par-term-config` module.\n3. **Event Listening**: The terminal emulator listens for key events through the `winit` library.\n4. **Action Execution**: Upon detecting a key event, the module checks for matching keybindings and executes the associated actions.\n\n## Integration with the Codebase\n\nThe `par-term-keybindings` module is tightly integrated with the `par-term` terminal emulator. It relies on the `par-term-config` module for configuration management and the `winit` library for event handling. This integration allows for a cohesive user experience where keybindings can be easily customized and managed.\n\n### Mermaid Diagram\n\nThe following diagram illustrates the relationship between the `par-term-keybindings` module, the `par-term-config` module, and the `winit` library:\n\n```mermaid\ngraph TD;\n A[par-term-keybindings] -->|uses| B[par-term-config]\n A -->|integrates with| C[winit]\n B -->|loads configurations| D[User Configurations]\n```\n\n## Conclusion\n\nThe `par-term-keybindings` module is a crucial component of the `par-term` terminal emulator, providing users with the ability to customize their keyboard interactions. By leveraging the `par-term-config` module for configuration management and the `winit` library for event handling, it creates a flexible and user-friendly keybinding system. Developers looking to contribute to this module should focus on enhancing the keybinding definitions, improving configuration management, and ensuring seamless integration with the terminal's event handling system.","other-par-term-mcp":"# Other — par-term-mcp\n\n# par-term-mcp Module Documentation\n\n## Overview\n\nThe **par-term-mcp** module implements a Model Context Protocol (MCP) server designed for the `par-term` terminal emulator. This module facilitates communication between the terminal emulator and other components using the JSON-RPC protocol over standard input/output (stdio). The primary goal of this module is to provide a structured way to handle commands and responses in a terminal environment, enhancing the user experience by enabling real-time interactions.\n\n## Purpose\n\nThe MCP server serves as a bridge between the terminal emulator and external clients, allowing for the exchange of structured data in a standardized format. This is particularly useful for applications that require dynamic updates or interactions, such as real-time logging, configuration changes, or command execution.\n\n## Key Components\n\n### 1. Dependencies\n\nThe module relies on several key dependencies to function effectively:\n\n- **Serde**: Used for serializing and deserializing JSON data, which is essential for the JSON-RPC protocol.\n- **Serde JSON**: Provides JSON serialization capabilities specifically for the JSON-RPC messages.\n- **Log**: A logging library that helps in tracking the server's operations and debugging.\n- **Dirs**: A library for resolving platform-specific directories, which is useful for configuration file management.\n\n### 2. Core Functionality\n\nThe core functionality of the **par-term-mcp** module revolves around handling JSON-RPC requests and responses. The server listens for incoming requests, processes them, and sends back appropriate responses. \n\n#### Key Functions\n\n- **start_server**: This function initializes the MCP server, setting up the necessary input/output streams and preparing to handle incoming requests.\n- **handle_request**: This function processes individual JSON-RPC requests, executing the corresponding command and generating a response.\n- **send_response**: After processing a request, this function formats the response as a JSON object and sends it back to the client.\n\n### 3. Execution Flow\n\nWhile there are no explicit execution flows detected in this module, the general flow of operations can be summarized as follows:\n\n1. The server starts and begins listening for incoming requests.\n2. Upon receiving a request, the server parses the JSON data.\n3. The server processes the request using the `handle_request` function.\n4. A response is generated and sent back to the client using the `send_response` function.\n\n### 4. Integration with the Codebase\n\nThe **par-term-mcp** module is designed to be integrated with the `par-term` terminal emulator. It acts as a standalone server that can be invoked by the terminal application. The communication between the terminal and the MCP server occurs through standard input and output, allowing for seamless interaction.\n\n## Example Usage\n\nTo use the **par-term-mcp** module, you would typically start the server in your terminal application as follows:\n\n```rust\nfn main() {\n par_term_mcp::start_server();\n}\n```\n\nThis call initializes the server and begins listening for JSON-RPC requests. The server will handle requests as they come in, allowing for real-time interaction with the terminal emulator.\n\n## Conclusion\n\nThe **par-term-mcp** module is a crucial component of the `par-term` terminal emulator, providing a robust framework for handling JSON-RPC communications. By leveraging the power of Serde for JSON serialization and the logging capabilities of the Log library, this module enhances the terminal's functionality and user experience. Developers looking to contribute to this module should focus on extending the request handling capabilities and improving the overall performance of the server.\n\nFor further details, please refer to the [GitHub repository](https://github.com/paulrobello/par-term) for the source code and additional documentation.","other-par-term-render":"# Other — par-term-render\n\n# par-term-render Module Documentation\n\n## Overview\n\nThe **par-term-render** module is a GPU-accelerated rendering engine designed specifically for the **par-term** terminal emulator. This module leverages modern graphics APIs to efficiently render terminal content, including text and background images, while supporting advanced features like custom shaders and font rasterization.\n\n### Key Features\n- **GPU Acceleration**: Utilizes the `wgpu` library for high-performance rendering.\n- **Custom Shaders**: Supports GLSL to WGSL transpilation via the `naga` library, allowing for flexible shader programming.\n- **Font Rendering**: Integrates with the `swash` library for high-quality glyph rendering.\n- **Image Support**: Capable of loading and rendering images for backgrounds and textures using the `image` crate.\n- **Concurrency**: Employs the `parking_lot` crate for efficient synchronization in a multi-threaded environment.\n\n## Architecture\n\nThe architecture of the **par-term-render** module is designed to be modular and extensible. It interacts with several other components of the **par-term** ecosystem, including configuration management, font handling, and core terminal functionalities.\n\n### Component Interaction\n\n```mermaid\ngraph TD;\n A[par-term-render] -->|depends on| B[par-term-config]\n A -->|depends on| C[par-term-fonts]\n A -->|uses| D[par-term-emu-core-rust]\n A -->|renders with| E[wgpu]\n A -->|loads images with| F[image]\n A -->|handles fonts with| G[swash]\n A -->|transpiles shaders with| H[naga]\n A -->|overlays with| I[egui]\n```\n\n## Key Components\n\n### 1. Rendering Pipeline\n\nThe rendering pipeline is the core of the **par-term-render** module. It is responsible for managing the rendering process, including setting up the GPU context, compiling shaders, and issuing draw calls.\n\n- **Initialization**: The pipeline initializes the `wgpu` device and swap chain.\n- **Shader Management**: Uses `naga` to compile GLSL shaders into WGSL for use in the rendering process.\n- **Draw Calls**: Issues draw calls to render text and images based on the current terminal state.\n\n### 2. Font Rendering\n\nFont rendering is handled through the `swash` library, which provides high-quality rasterization of glyphs. The module interfaces with `par-term-fonts` to load and manage font resources.\n\n- **Glyph Rasterization**: Converts font glyphs into bitmap representations for rendering.\n- **Text Layout**: Manages the layout of text within the terminal, ensuring proper alignment and spacing.\n\n### 3. Image Handling\n\nThe module utilizes the `image` crate to load and manage images for backgrounds and textures. This allows for rich visual customization of the terminal emulator.\n\n- **Image Loading**: Supports various image formats and handles loading asynchronously.\n- **Texture Management**: Manages GPU textures for efficient rendering.\n\n### 4. GUI Integration\n\nThe **par-term-render** module integrates with `egui` and `egui-wgpu` to provide GUI overlays. This allows for additional user interface elements to be rendered on top of the terminal content.\n\n- **Overlay Rendering**: Renders GUI elements without interfering with the terminal's rendering pipeline.\n- **Event Handling**: Manages user input for GUI components.\n\n## Dependencies\n\nThe **par-term-render** module relies on several external crates, as specified in the `Cargo.toml` file. Key dependencies include:\n\n- **wgpu**: For GPU rendering.\n- **swash**: For font rasterization.\n- **naga**: For shader transpilation.\n- **image**: For image loading.\n- **egui**: For GUI rendering.\n\n## Conclusion\n\nThe **par-term-render** module is a critical component of the **par-term** terminal emulator, providing the necessary infrastructure for high-performance rendering. By leveraging modern graphics technologies and libraries, it enables a visually rich terminal experience. Developers looking to contribute to this module should familiarize themselves with the rendering pipeline, font handling, and image management to effectively enhance its capabilities.","other-par-term-scripting":"# Other — par-term-scripting\n\n# par-term-scripting Module Documentation\n\n## Overview\n\nThe **par-term-scripting** module provides a scripting and observer system for the par-term terminal emulator. It allows users to define scripts that can interact with terminal events, enhancing the terminal's functionality through automation and customization. This module is designed to work seamlessly with the par-term ecosystem, leveraging other modules for configuration and event handling.\n\n### Key Features\n- **Scripting Support**: Enables users to write scripts that can respond to terminal events.\n- **Observer System**: Implements an observer pattern to listen for and react to terminal events.\n- **Integration with Configuration**: Utilizes the `par-term-config` module for script configuration management.\n- **JSON Serialization**: Supports JSON serialization for script data exchange using `serde` and `serde_json`.\n\n## Architecture\n\nThe architecture of the **par-term-scripting** module is straightforward, focusing on the interaction between scripts and terminal events. The module does not have any internal calls or execution flows, making it a lightweight addition to the par-term ecosystem.\n\n### Dependencies\nThe module relies on several key dependencies:\n- **par-term-config**: Provides configuration types for scripts.\n- **par-term-emu-core-rust**: Offers the terminal event observer trait, which is essential for listening to terminal events.\n- **serde** and **serde_json**: Used for serializing and deserializing script data in JSON format.\n- **log**: For logging purposes, aiding in debugging and monitoring script execution.\n\n## Key Components\n\n### 1. Script Configuration\nThe module utilizes the `ScriptConfig` type from the `par-term-config` module to manage script settings. This configuration allows users to define parameters such as script paths, execution conditions, and event triggers.\n\n### 2. Observer Trait\nThe core functionality of the module is built around the observer pattern. The `par-term-emu-core-rust` module provides the necessary traits to implement observers that can listen for terminal events. Scripts can register as observers to receive notifications about specific events, such as input changes or terminal state updates.\n\n### 3. Scripting Interface\nWhile the specific scripting interface is not detailed in the provided code, it is expected that the module will expose functions or classes that allow users to define and manage their scripts. This interface should facilitate:\n- Loading scripts from specified paths.\n- Registering scripts as observers.\n- Executing scripts in response to terminal events.\n\n## Integration with the par-term Ecosystem\n\nThe **par-term-scripting** module is designed to integrate closely with other modules in the par-term ecosystem. The following diagram illustrates the high-level interaction between the scripting module and its dependencies:\n\n```mermaid\ngraph TD;\n A[par-term-scripting] -->|uses| B[par-term-config]\n A -->|implements| C[Observer Trait]\n A -->|serializes| D[serde]\n A -->|serializes| E[serde_json]\n A -->|logs| F[log]\n```\n\n### Interaction Flow\n1. **Script Loading**: When a script is loaded, it reads its configuration from `par-term-config`.\n2. **Event Registration**: The script registers itself as an observer for specific terminal events using the observer trait.\n3. **Event Handling**: Upon triggering of an event, the observer pattern notifies the script, which can then execute its defined actions.\n\n## Conclusion\n\nThe **par-term-scripting** module is a powerful tool for enhancing the par-term terminal emulator through scripting and event observation. By leveraging existing modules for configuration and event handling, it provides a flexible and extensible framework for users to automate their terminal interactions. Developers looking to contribute to this module should focus on expanding the scripting interface and improving the observer system to support more complex event handling scenarios.","other-par-term-settings-ui":"# Other — par-term-settings-ui\n\n# Documentation for the **par-term-settings-ui** Module\n\n## Overview\n\nThe **par-term-settings-ui** module provides a graphical user interface (GUI) for configuring settings in the **par-term** terminal emulator. Built using the **egui** library, this module allows users to modify terminal settings in a user-friendly manner. The module is designed to work seamlessly with the **par-term-config** module, which handles the underlying configuration logic.\n\n### Key Features\n- User-friendly settings interface for terminal configuration.\n- Integration with the **par-term-config** module for managing settings.\n- Support for file dialogs, serialization, and logging.\n- Asynchronous operations for improved performance.\n\n## Dependencies\n\nThe module relies on several external crates to provide its functionality:\n\n- **egui**: A simple and fast GUI library for Rust.\n- **serde** and **serde_json**: For serialization and deserialization of configuration data.\n- **rfd**: For file dialog support.\n- **log**: For logging purposes.\n- **tokio**: For asynchronous operations.\n- **uuid**: For generating unique identifiers for profiles.\n- **chrono**: For handling date and time, particularly for screenshots.\n\n## Architecture\n\nThe architecture of the **par-term-settings-ui** module is straightforward, focusing on the interaction between the GUI and the configuration system. Below is a simplified representation of the module's structure:\n\n```mermaid\ngraph TD;\n A[par-term-settings-ui] -->|uses| B[par-term-config]\n A -->|uses| C[egui]\n A -->|uses| D[rfd]\n A -->|uses| E[serde]\n A -->|uses| F[log]\n A -->|uses| G[uuid]\n A -->|uses| H[chrono]\n```\n\n### Components\n\n1. **Main Application Entry Point**: \n - The main function initializes the GUI and sets up the event loop using **egui**.\n\n2. **Settings Window**:\n - This component is responsible for rendering the settings interface. It allows users to modify various terminal settings such as appearance, behavior, and profiles.\n\n3. **Configuration Management**:\n - The module interacts with the **par-term-config** module to load and save settings. It uses **serde** for serialization and deserialization of configuration data.\n\n4. **File Dialogs**:\n - The **rfd** crate is utilized to open file dialogs for importing and exporting settings.\n\n5. **Logging**:\n - The **log** crate is used to log important events and errors, aiding in debugging and monitoring the application.\n\n6. **Asynchronous Operations**:\n - The module leverages **tokio** for handling asynchronous tasks, ensuring that the UI remains responsive during long-running operations.\n\n## Usage\n\nTo use the **par-term-settings-ui** module, follow these steps:\n\n1. **Add the Module to Your Project**:\n Ensure that the **par-term-settings-ui** module is included in your Cargo.toml file.\n\n2. **Initialize the GUI**:\n Call the main function to start the settings UI. This function sets up the event loop and renders the settings window.\n\n3. **Modify Settings**:\n Users can interact with the GUI to change terminal settings. Changes are automatically saved to the configuration file using the **par-term-config** module.\n\n4. **Logging and Error Handling**:\n Utilize the logging features to monitor application behavior and handle errors gracefully using the **anyhow** crate.\n\n## Conclusion\n\nThe **par-term-settings-ui** module is a crucial component of the **par-term** terminal emulator, providing an intuitive interface for users to configure their terminal settings. By leveraging modern Rust libraries, it ensures a responsive and user-friendly experience. Developers looking to contribute to this module should familiarize themselves with the **egui** library and the configuration management patterns established in the **par-term-config** module.","other-par-term-ssh":"# Other — par-term-ssh\n\n# par-term-ssh Module Documentation\n\n## Overview\n\nThe `par-term-ssh` module is designed to facilitate SSH host management and discovery for the `par-term` terminal emulator. It leverages mDNS (Multicast DNS) for automatic detection of SSH hosts on the local network, making it easier for users to connect to remote systems without manually entering host details.\n\n### Key Features\n- **SSH Host Management**: Simplifies the process of managing SSH connections.\n- **Automatic Discovery**: Utilizes mDNS for discovering SSH hosts on the network.\n- **Cross-Platform Support**: Integrates with platform-specific directories to locate SSH configuration files.\n\n## Dependencies\n\nThe module relies on several external crates to provide its functionality:\n\n- **serde**: For serialization and deserialization of data structures.\n- **mdns-sd**: For mDNS service discovery, enabling automatic detection of SSH hosts.\n- **dirs**: To handle platform-specific directories, particularly for accessing the user's SSH configuration.\n- **log**: For logging purposes, allowing for better debugging and monitoring of the module's operations.\n\n## Architecture\n\nThe architecture of the `par-term-ssh` module is relatively straightforward, focusing on the integration of mDNS for host discovery and the management of SSH connections. Below is a high-level overview of the module's components:\n\n```mermaid\ngraph TD;\n A[par-term-ssh] --> B[mdns-sd]\n A --> C[serde]\n A --> D[dirs]\n A --> E[log]\n```\n\n### Components\n\n1. **mDNS Discovery**: \n - The `mdns-sd` crate is used to listen for mDNS announcements on the local network. When an SSH service is detected, the module can automatically add it to the list of available hosts.\n - This component is crucial for enabling users to connect to devices without needing to know their IP addresses or hostnames.\n\n2. **SSH Configuration Management**:\n - The module interacts with the user's SSH configuration files, typically located in the `~/.ssh` directory. The `dirs` crate helps in locating this directory across different operating systems.\n - It can read existing configurations and manage new entries as users connect to discovered hosts.\n\n3. **Logging**:\n - The `log` crate is integrated to provide logging capabilities. This is essential for debugging and understanding the flow of operations, especially during the discovery process or when establishing connections.\n\n## Usage\n\n### Initialization\n\nTo use the `par-term-ssh` module, you will typically initialize the mDNS service and set up logging. Here’s a basic example of how to start the discovery process:\n\n```rust\nuse par_term_ssh::mdns::MdnsService;\nuse par_term_ssh::log::init_logging;\n\nfn main() {\n init_logging();\n let mdns_service = MdnsService::new();\n mdns_service.start_discovery();\n}\n```\n\n### Connecting to a Host\n\nOnce the mDNS service has discovered available SSH hosts, you can connect to one of them using the SSH client of your choice. The module can provide a list of discovered hosts, which can be displayed in the terminal emulator.\n\n### Error Handling\n\nThe module should handle errors gracefully, particularly when dealing with network issues or file access problems. Ensure that you implement appropriate error handling when using the module's functions.\n\n## Contribution Guidelines\n\nIf you wish to contribute to the `par-term-ssh` module, please follow these guidelines:\n\n1. **Fork the Repository**: Create a personal fork of the repository on GitHub.\n2. **Create a Feature Branch**: Use a descriptive name for your branch.\n3. **Write Tests**: Ensure that your changes are covered by tests.\n4. **Submit a Pull Request**: Provide a clear description of your changes and the motivation behind them.\n\n## Conclusion\n\nThe `par-term-ssh` module is a powerful tool for managing SSH connections and discovering hosts on a local network. By leveraging mDNS and providing a user-friendly interface, it enhances the overall experience of using the `par-term` terminal emulator. For further information, refer to the module's source code and the associated documentation in the repository.","other-par-term-terminal":"# Other — par-term-terminal\n\n# par-term-terminal Module Documentation\n\n## Overview\n\nThe **par-term-terminal** module serves as a terminal manager for the **par-term** terminal emulator. It is designed to facilitate the management of terminal sessions, providing features that enhance user interaction with the terminal environment. This module is built on top of the **par-term-emu-core-rust** library, which provides the core functionalities of the terminal emulator.\n\n### Key Features\n- **Terminal Session Management**: Handles multiple terminal sessions efficiently.\n- **Configuration Support**: Integrates with the **par-term-config** module for customizable themes, colors, and cell types.\n- **Clipboard Functionality**: Utilizes the **arboard** library for clipboard operations.\n- **Asynchronous Operations**: Leverages the **tokio** runtime for non-blocking operations, such as pasting text with a delay.\n\n## Dependencies\n\nThe module relies on several external libraries to function effectively:\n\n- **par-term-emu-core-rust**: Core terminal emulator functionalities.\n- **par-term-config**: Configuration management for themes and colors.\n- **parking_lot**: Provides synchronization primitives.\n- **tokio**: Asynchronous runtime for handling delays and non-blocking operations.\n- **anyhow**: Simplifies error handling.\n- **log**: For logging purposes.\n- **arboard**: Clipboard support for copying and pasting text.\n\n## Architecture\n\nThe architecture of the **par-term-terminal** module is straightforward, focusing on terminal session management without complex internal or outgoing calls. The module primarily interacts with the core terminal emulator and configuration modules.\n\n### Component Overview\n\n1. **TerminalManager**: The main class responsible for managing terminal sessions. It handles the creation, destruction, and switching of terminal instances.\n2. **Session**: Represents an individual terminal session, encapsulating its state and behavior.\n3. **Config**: Interfaces with the **par-term-config** module to apply user-defined settings for themes and colors.\n4. **Clipboard**: Manages clipboard operations using the **arboard** library, allowing users to copy and paste text seamlessly.\n\n### Execution Flow\n\nCurrently, there are no detected execution flows within this module, indicating that it operates primarily through direct method calls and event handling without complex asynchronous flows.\n\n## Example Usage\n\nHere’s a simple example of how to use the **TerminalManager** to create and manage terminal sessions:\n\n```rust\nuse par_term_terminal::TerminalManager;\n\nfn main() {\n let mut manager = TerminalManager::new();\n\n // Create a new terminal session\n let session_id = manager.create_session();\n\n // Switch to the created session\n manager.switch_to_session(session_id);\n\n // Perform operations in the terminal...\n}\n```\n\n## Integration with the Codebase\n\nThe **par-term-terminal** module is designed to work closely with the **par-term-emu-core-rust** and **par-term-config** modules. It acts as a bridge between the user interface and the core functionalities of the terminal emulator. \n\n### Mermaid Diagram\n\nThe following diagram illustrates the relationship between the **par-term-terminal** module and its dependencies:\n\n```mermaid\ngraph TD;\n A[par-term-terminal] -->|uses| B[par-term-emu-core-rust]\n A -->|configures| C[par-term-config]\n A -->|manages| D[Clipboard (arboard)]\n A -->|async operations| E[tokio]\n A -->|error handling| F[anyhow]\n A -->|logging| G[log]\n```\n\n## Conclusion\n\nThe **par-term-terminal** module is a crucial component of the **par-term** terminal emulator, providing essential functionalities for managing terminal sessions. By leveraging various libraries for configuration, clipboard support, and asynchronous operations, it enhances the overall user experience. Developers looking to contribute to this module should familiarize themselves with the dependencies and the overall architecture to effectively implement new features or fix issues.","other-par-term-terminfo":"# Other — par-term.terminfo\n\n# Documentation for the **par-term.terminfo** Module\n\n## Overview\n\nThe **par-term.terminfo** module defines terminal capabilities for the Par Term Emulator, a feature-rich terminal emulator that supports advanced graphics features such as Sixel, iTerm2, and Kitty graphics. This module is essential for ensuring that the terminal can interpret and utilize various terminal control sequences effectively.\n\n## Purpose\n\nThe primary purpose of the **par-term.terminfo** module is to provide a comprehensive set of terminal capabilities that enhance the user experience in the Par Term Emulator. By defining these capabilities, the terminal can support a wide range of features, including:\n\n- 256 colors and true color (RGB) support\n- Sixel graphics for advanced image rendering\n- Compatibility with other terminal types (e.g., xterm)\n- Support for various terminal control sequences\n\n## Installation\n\nTo install the terminal capabilities defined in this module, use the following command:\n\n```bash\ntic -x par-term.terminfo\n```\n\nThis command compiles the terminfo source file into a binary format that the terminal can use.\n\n## Key Components\n\nThe **par-term.terminfo** module consists of several key components, each defining specific terminal capabilities:\n\n### Terminal Name\n\n```plaintext\npar-term|Par Term Emulator with Graphics Support,\n```\n\nThis line defines the terminal name and provides a brief description of its capabilities.\n\n### Terminal Capabilities\n\nThe following capabilities are defined within the module:\n\n- **use=xterm-256color**: Inherits capabilities from the xterm-256color terminal type.\n- **Tc**: Indicates that the terminal supports true color.\n- **colors#0x1000000**: Specifies the number of colors supported (16 million).\n- **pairs#0x10000**: Indicates the number of color pairs supported (65,536).\n- **kbs=\\177**: Defines the backspace key sequence.\n- **setab** and **setaf**: Control sequences for setting background and foreground colors, respectively, with support for 256 colors and true color.\n- **setrgbf** and **setrgbb**: Control sequences for setting foreground and background colors using RGB values.\n- **hs**: Indicates that the terminal supports hard status lines.\n- **tsl**, **fsl**, **dsl**: Control sequences for setting and clearing the title of the terminal window.\n- **Sync**, **BE**, **BD**, **PS**, **PE**: Control sequences for handling bracketed paste mode and other advanced features.\n\n### Control Sequences\n\nControl sequences are defined using escape sequences (e.g., `\\E[...`) that the terminal interprets to perform specific actions. For example:\n\n- **setab**: \n ```plaintext\n setab=\\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48\\:2\\:\\:%p1%{65536}%/%d\\:%p1%{256}%/%{255}%&%d\\:%p1%{255}%&%d%;m\n ```\n This sequence sets the background color based on the provided parameters.\n\n- **setrgbf**:\n ```plaintext\n setrgbf=\\E[38\\:2\\:%p1%d\\:%p2%d\\:%p3%dm\n ```\n This sequence sets the foreground color using RGB values.\n\n## Integration with the Codebase\n\nThe **par-term.terminfo** module does not have direct internal or outgoing calls, as it primarily serves as a configuration file for terminal capabilities. However, it is crucial for the overall functionality of the Par Term Emulator, as it allows the terminal to interpret and respond to various control sequences defined in the module.\n\n### Execution Flow\n\nThere are no specific execution flows detected for this module, as it is a static definition of terminal capabilities. The terminal emulator reads this configuration at startup to determine how to handle various terminal control sequences.\n\n## Conclusion\n\nThe **par-term.terminfo** module is a vital component of the Par Term Emulator, providing the necessary definitions for terminal capabilities that enhance user experience and graphical support. Understanding this module is essential for developers looking to contribute to the Par Term Emulator or extend its functionality. \n\nFor further contributions, developers should familiarize themselves with the control sequences and capabilities defined in this module, as well as how they interact with the terminal's rendering engine.","other-par-term-tmux":"# Other — par-term-tmux\n\n# par-term-tmux Module Documentation\n\n## Overview\n\nThe **par-term-tmux** module provides integration with the tmux terminal multiplexer, specifically focusing on control mode functionality. This module is designed to enhance the **par-term** terminal emulator by allowing it to communicate with tmux, enabling advanced terminal management features.\n\n### Purpose\n\nThe primary purpose of the **par-term-tmux** module is to facilitate seamless interaction between the **par-term** terminal emulator and tmux. This integration allows users to leverage tmux's powerful session management capabilities directly within the **par-term** environment.\n\n## Key Components\n\n### 1. Dependencies\n\nThe module relies on several key dependencies to function effectively:\n\n- **par-term-config**: Provides configuration management for pane and tab identifiers.\n- **par-term-emu-core-rust**: The core terminal emulator library that includes the tmux control mode parser.\n- **winit**: Handles window event types, particularly for prefix key handling in tmux.\n- **chrono**: Used for formatting date and time in the status line.\n- **regex**: Utilized for sanitizing tmux output to ensure clean and safe display.\n- **hostname**: A cross-platform library for detecting the hostname of the machine.\n- **log**: A logging library for debugging and monitoring.\n\n### 2. Module Structure\n\nThe **par-term-tmux** module is structured to encapsulate all functionalities related to tmux integration. The main components include:\n\n- **TmuxControl**: A class responsible for managing the communication with tmux in control mode.\n- **TmuxCommand**: A utility for constructing and sending commands to tmux.\n- **StatusFormatter**: A helper for formatting the status line with date, time, and other relevant information.\n\n### 3. TmuxControl Class\n\nThe `TmuxControl` class is the heart of the module. It handles the initialization of tmux sessions, command execution, and event handling. Key methods include:\n\n- **new()**: Initializes a new instance of `TmuxControl`, setting up necessary configurations.\n- **send_command(command: &str)**: Sends a command to the tmux session. This method constructs the command using `TmuxCommand` and handles the response.\n- **update_status()**: Updates the terminal status line with the current time and session information.\n\n### 4. TmuxCommand Utility\n\nThe `TmuxCommand` utility simplifies the process of creating tmux commands. It provides methods to:\n\n- **create_command(command: &str)**: Constructs a tmux command string.\n- **sanitize_output(output: &str)**: Cleans the output received from tmux to prevent any unwanted characters or formatting issues.\n\n### 5. StatusFormatter Helper\n\nThe `StatusFormatter` class is responsible for formatting the status line displayed in the terminal. It uses the `chrono` library to fetch the current date and time and formats it according to user preferences.\n\n## Execution Flow\n\nWhile there are no explicit execution flows detected for this module, the typical interaction pattern can be summarized as follows:\n\n1. **Initialization**: The `TmuxControl` class is instantiated, initializing the connection to tmux.\n2. **Command Execution**: The user sends a command through the terminal, which is processed by `TmuxControl` and executed via `TmuxCommand`.\n3. **Status Update**: The status line is updated periodically using the `update_status()` method, reflecting the current session state.\n\n### Mermaid Diagram\n\nThe following diagram illustrates the interaction between the main components of the **par-term-tmux** module:\n\n```mermaid\ngraph TD;\n A[TmuxControl] -->|sends command| B[TmuxCommand]\n B -->|sanitizes output| C[regex]\n A -->|updates status| D[StatusFormatter]\n D -->|formats time| E[chrono]\n```\n\n## Conclusion\n\nThe **par-term-tmux** module is a crucial component of the **par-term** terminal emulator, enabling robust integration with tmux. By understanding its structure and key components, developers can effectively contribute to its development and enhance its functionality. For further contributions, please refer to the [repository](https://github.com/paulrobello/par-term) for guidelines and best practices.","other-par-term-update":"# Other — par-term-update\n\n# par-term-update Module Documentation\n\n## Overview\n\nThe **par-term-update** module is designed to facilitate self-updating and update-checking for the **par-term** terminal emulator. This module ensures that users can easily keep their terminal emulator up to date with the latest features and security patches. It leverages various dependencies to handle HTTP requests, version comparisons, and file manipulations, making the update process seamless and efficient.\n\n### Key Features\n- **Self-Update Mechanism**: Automatically checks for and applies updates to the terminal emulator.\n- **Update Check Frequency**: Configurable intervals for checking for updates.\n- **Secure Downloading**: Utilizes HTTPS for secure downloads and SHA-256 hashing for verification.\n- **ZIP Archive Handling**: Supports extraction of updates packaged in ZIP files.\n\n## Architecture\n\nThe module is structured around a few key components that work together to perform update checks and apply updates. Below is a high-level overview of the architecture:\n\n```mermaid\ngraph TD;\n A[par-term-update] --> B[UpdateChecker]\n A --> C[Updater]\n B --> D[Config]\n B --> E[HTTP Client]\n C --> F[ZIP Extractor]\n C --> G[Hash Verifier]\n```\n\n### Components\n\n1. **UpdateChecker**\n - Responsible for checking if a new version of the terminal emulator is available.\n - Utilizes the `par-term-config` module to read configuration settings, such as the frequency of update checks.\n - Makes HTTP requests using the `ureq` library to fetch the latest release information.\n\n2. **Updater**\n - Handles the actual process of downloading and applying updates.\n - Uses the `zip` crate to extract the downloaded update files.\n - Verifies the integrity of the downloaded files using the `sha2` crate.\n\n3. **Configuration (Config)**\n - The configuration settings are managed through the `par-term-config` module, which defines types for configuration management.\n - This includes settings for update check frequency and other user preferences.\n\n4. **HTTP Client**\n - The `ureq` library is used to perform HTTP requests to check for updates and download new versions.\n - Configured to use native TLS for secure connections.\n\n5. **ZIP Extractor**\n - Utilizes the `zip` crate to handle the extraction of ZIP files containing the updates.\n\n6. **Hash Verifier**\n - Uses the `sha2` crate to compute and verify the SHA-256 hash of the downloaded binaries to ensure they have not been tampered with.\n\n## Dependencies\n\nThe **par-term-update** module relies on several external crates to function effectively:\n\n- **par-term-config**: For configuration management.\n- **ureq**: For making HTTP requests.\n- **chrono**: For handling timestamps related to update checks.\n- **semver**: For comparing semantic versions.\n- **sha2**: For hashing and verifying downloaded files.\n- **zip**: For extracting ZIP archives.\n- **serde** and **serde_json**: For serialization and deserialization of configuration and manifest data.\n- **anyhow**: For error handling.\n- **log**: For logging events and errors.\n\n## Usage\n\nTo use the **par-term-update** module, you will typically follow these steps:\n\n1. **Initialize Configuration**: Load the configuration settings from the `par-term-config` module.\n2. **Check for Updates**: Use the `UpdateChecker` to determine if a new version is available.\n3. **Download Update**: If an update is available, the `Updater` will download the new version.\n4. **Verify and Extract**: The downloaded file will be verified using SHA-256, and if valid, extracted using the ZIP extractor.\n5. **Apply Update**: Finally, the new version will replace the old version of the terminal emulator.\n\n### Example Code Snippet\n\nHere is a simplified example of how you might implement an update check in your application:\n\n```rust\nuse par_term_update::{UpdateChecker, Updater};\n\nfn main() {\n let config = load_config(); // Load configuration settings\n let update_checker = UpdateChecker::new(config);\n \n if update_checker.check_for_updates().is_ok() {\n let updater = Updater::new();\n if let Err(e) = updater.download_and_apply_update() {\n log::error!(\"Failed to update: {}\", e);\n }\n }\n}\n```\n\n## Conclusion\n\nThe **par-term-update** module is a crucial part of the **par-term** terminal emulator, providing a robust mechanism for keeping the software up to date. By leveraging various libraries and a clear architecture, it ensures that users can easily receive updates while maintaining security and integrity. Developers looking to contribute to this module should familiarize themselves with the key components and dependencies outlined in this documentation.","other-run-log":"# Other — run.log\n\n# Documentation for the **Other — run.log** Module\n\n## Overview\n\nThe **run.log** module is designed to handle logging functionalities within the application. It serves as a centralized point for managing log entries, which can be crucial for debugging, monitoring, and auditing purposes. This module does not have any internal or outgoing calls, indicating that it operates independently without dependencies on other modules.\n\n## Purpose\n\nThe primary purpose of the **run.log** module is to provide a simple and effective way to log messages during the execution of the application. This includes:\n\n- Capturing error messages for troubleshooting.\n- Logging informational messages to track application flow.\n- Storing warning messages to alert developers of potential issues.\n\n## Key Components\n\n### 1. Logging Functions\n\nThe module contains several key functions that facilitate logging:\n\n- **log_info(message: str)**: Logs an informational message. This function is typically used to track the normal operation of the application.\n \n- **log_warning(message: str)**: Logs a warning message. This function is used to indicate potential issues that do not stop the execution but may require attention.\n\n- **log_error(message: str)**: Logs an error message. This function captures critical issues that may cause the application to fail or behave unexpectedly.\n\n### 2. Log Format\n\nThe log entries generated by the module follow a consistent format, which typically includes:\n\n- Timestamp: The date and time when the log entry was created.\n- Log Level: The severity of the log (INFO, WARNING, ERROR).\n- Message: The actual log message provided by the developer.\n\n### 3. Configuration\n\nThe module may include configuration options to customize logging behavior, such as:\n\n- Log file path: Where the log entries are stored.\n- Log level: The minimum severity level of messages to be logged (e.g., INFO, WARNING, ERROR).\n\n## How It Works\n\nThe **run.log** module operates by providing a set of functions that can be called throughout the application. When a developer wants to log a message, they simply call the appropriate logging function with the desired message. The module then formats the message according to the specified log format and writes it to the designated log file.\n\n### Example Usage\n\nHere’s a simple example of how to use the **run.log** module:\n\n```python\nfrom run.log import log_info, log_warning, log_error\n\ndef main():\n log_info(\"Application started.\")\n \n try:\n # Some application logic\n pass\n except Exception as e:\n log_error(f\"An error occurred: {str(e)}\")\n \n log_warning(\"This is a warning message.\")\n log_info(\"Application finished.\")\n\nif __name__ == \"__main__\":\n main()\n```\n\n## Integration with the Codebase\n\nWhile the **run.log** module does not have direct dependencies or outgoing calls, it is an essential part of the overall application architecture. It can be integrated into various components of the application where logging is necessary. Developers should ensure that logging is used consistently across the codebase to maintain a clear and comprehensive log history.\n\n### Logging Flow\n\nThe following diagram illustrates the flow of logging within the application:\n\n```mermaid\ngraph TD;\n A[Application] -->|Calls| B[run.log];\n B -->|Logs| C[Log File];\n```\n\nIn this diagram:\n- The **Application** represents any part of the code that requires logging.\n- The **run.log** module is called to log messages.\n- The **Log File** is where all log entries are stored.\n\n## Conclusion\n\nThe **run.log** module is a straightforward yet powerful tool for managing logging within the application. By providing a consistent interface for logging messages, it helps developers track application behavior and troubleshoot issues effectively. Proper integration and usage of this module can significantly enhance the maintainability and observability of the codebase.","other-rust-toolchain-toml":"# Other — rust-toolchain.toml\n\n# Documentation for the `rust-toolchain.toml` Module\n\n## Overview\n\nThe `rust-toolchain.toml` file is a configuration file used in Rust projects to specify the toolchain version that should be used for building and running the project. This file is part of the Rust toolchain management system and is essential for ensuring that developers are using a consistent version of Rust across different environments.\n\n## Purpose\n\nThe primary purpose of the `rust-toolchain.toml` file is to define the Rust toolchain channel that the project should use. By specifying the toolchain in this file, developers can avoid discrepancies that may arise from using different versions of Rust, which can lead to compatibility issues, especially in larger projects or when collaborating with multiple developers.\n\n## Key Components\n\nThe `rust-toolchain.toml` file consists of a single section:\n\n### Toolchain Section\n\n- **channel**: This key specifies the Rust toolchain channel to be used. The value can be one of the following:\n - `stable`: The latest stable release of Rust.\n - `beta`: The latest beta release of Rust.\n - `nightly`: The latest nightly build of Rust.\n - A specific version (e.g., `1.56.0`): This allows for pinning the project to a specific version of Rust.\n\n#### Example\n\n```toml\n[toolchain]\nchannel = \"stable\"\n```\n\nIn this example, the project is configured to use the latest stable version of Rust.\n\n## How It Works\n\nWhen a Rust project is initialized with a `rust-toolchain.toml` file, the Rust toolchain manager (rustup) reads this configuration to determine which version of Rust to use. This ensures that all developers working on the project are using the same version, which is crucial for maintaining compatibility and avoiding build errors.\n\n### Interaction with Rustup\n\nThe `rust-toolchain.toml` file is directly utilized by `rustup`, the Rust toolchain installer and version manager. When a developer runs commands like `cargo build` or `cargo run`, `rustup` checks the `rust-toolchain.toml` file to determine the appropriate toolchain to activate for that session.\n\n## Connection to the Codebase\n\nWhile the `rust-toolchain.toml` file does not contain any executable code or functions, it plays a critical role in the development workflow. It ensures that the Rust compiler and associated tools are consistent across different environments, which is particularly important in collaborative projects.\n\n### Example Workflow\n\n1. A developer clones a repository containing a `rust-toolchain.toml` file.\n2. Upon running any Rust command (e.g., `cargo build`), `rustup` reads the `rust-toolchain.toml` file.\n3. `rustup` activates the specified toolchain (e.g., `stable`).\n4. The developer can now build and run the project using the correct version of Rust.\n\n## Conclusion\n\nThe `rust-toolchain.toml` file is a simple yet powerful tool for managing Rust toolchain versions in a project. By specifying the desired channel, it helps maintain consistency and compatibility across different development environments, making it an essential component of any Rust project.\n\nThis module does not have any internal or outgoing calls, nor does it have any execution flows, as it serves solely as a configuration file. Understanding its purpose and usage is crucial for developers working with Rust projects to ensure a smooth development experience.","other-scripts":"# Other — scripts\n\n# par-term Test Scripts Module Documentation\n\n## Overview\n\nThe **par-term Test Scripts** module is designed to facilitate the testing and benchmarking of various features within the par-term terminal emulator. This module includes scripts that verify font rendering, text shaping, graphics rendering, and other terminal functionalities. The tests ensure that the terminal behaves as expected across different content types and configurations.\n\n## Purpose\n\nThe primary purpose of this module is to provide a comprehensive suite of tests that can be executed to validate the functionality of par-term. This includes:\n\n- **Text Shaping & Font Tests**: Verifying the rendering of different font styles, characters, and emojis.\n- **Graphics Tests**: Testing the rendering of graphics, such as Sixel graphics.\n- **Bell Notification Tests**: Ensuring that the terminal's bell notification system works correctly.\n- **Performance Benchmarks**: Measuring the performance of text shaping and rendering.\n\n## Key Components\n\n### 1. Text Shaping & Font Tests\n\n#### `test_fonts.sh`\n\nThis script runs a comprehensive suite of tests to verify font features and text shaping capabilities. It tests 21 different features, including:\n\n- Regular ASCII characters\n- Styled fonts (bold, italic, bold+italic)\n- CJK characters and emojis\n- Complex scripts (Arabic, Devanagari, Thai)\n- Bidirectional text\n- Combining diacritics\n- Performance of shaped glyph caching\n\n**Usage:**\n```bash\n# Inside par-term terminal\n./scripts/test_fonts.sh\n\n# Or use Makefile\nmake test-fonts\n```\n\n**Verification Checklist:**\n- Ensure styled fonts render correctly.\n- Verify emoji skin tones and flag emojis.\n- Check complex scripts for proper shaping.\n- Validate performance during rendering.\n\n#### `benchmark_text_shaping.sh`\n\nThis script benchmarks the performance of text shaping against non-shaped rendering. It tests 14 content types, including ASCII, CJK characters, and complex emojis.\n\n**Usage:**\n```bash\n# Inside par-term terminal\n./scripts/benchmark_text_shaping.sh\n\n# Or use Makefile\nmake benchmark-shaping\n```\n\n**Expected Results:**\n- Minimal performance difference for ASCII.\n- Slightly slower performance for complex scripts.\n- Improved quality for multi-component emojis.\n\n### 2. Graphics Tests\n\n#### `test_sixel.sh`\n\nThis script tests the rendering of Sixel graphics, which is a graphics protocol used in terminals.\n\n**Usage:**\n```bash\n./scripts/test_sixel.sh\n```\n\n### 3. Bell Notification Tests\n\n#### `test_bells.sh`\n\nThis script tests the terminal's bell notification system, including visual, audio, and desktop notifications.\n\n**Usage:**\n```bash\n./scripts/test_bells.sh\n```\n\n### 4. Configuration\n\nAll tests assume a default configuration for par-term, which can be found in `~/.config/par-term/config.yaml`. Key configuration options include:\n\n```yaml\nenable_text_shaping: true\nenable_ligatures: true\nenable_kerning: true\nfont_family: \"JetBrains Mono\"\n```\n\n### 5. Requirements\n\n#### Font Requirements\n\nTo achieve optimal results, the following fonts are recommended:\n\n- **Monospace**: JetBrains Mono, Fira Code\n- **CJK**: Noto Sans CJK, Source Han Sans\n- **Emoji**: Noto Color Emoji, Apple Color Emoji\n- **Complex Scripts**: Noto Sans Arabic, Noto Sans Devanagari\n\n#### System Requirements\n\n- par-term built in release mode (`make release`)\n- Terminal with color support\n- Sufficient scrollback buffer for viewing results\n\n## Execution Flow\n\nThe execution flow of the test scripts can be summarized as follows:\n\n1. **Initialization**: The script is executed within the par-term terminal.\n2. **Test Execution**: Each test script runs a series of tests, outputting results to the terminal.\n3. **Verification**: The results are compared against expected outcomes, and any discrepancies are logged.\n4. **Performance Measurement**: For benchmarking scripts, performance metrics are collected and displayed.\n\n### Mermaid Diagram\n\n```mermaid\ngraph TD;\n A[Start Test Script] --> B{Test Type}\n B -->|Text Shaping| C[test_fonts.sh]\n B -->|Benchmarking| D[benchmark_text_shaping.sh]\n B -->|Graphics| E[test_sixel.sh]\n B -->|Bell Notifications| F[test_bells.sh]\n C --> G[Output Results]\n D --> G\n E --> G\n F --> G\n G --> H[End Test Script]\n```\n\n## Troubleshooting\n\nCommon issues and their solutions include:\n\n- **Emoji Not Rendering**: Ensure the emoji font is installed and configured correctly.\n- **Complex Scripts Not Shaping**: Verify that text shaping is enabled in the configuration.\n- **Performance Issues**: Run benchmarks to identify slow content types and check cache hit rates.\n\n## Contributing\n\nTo contribute to the test scripts:\n\n1. Add new tests to the appropriate script or create a new script.\n2. Update this documentation with the new test descriptions.\n3. Ensure tests are run on all supported platforms (macOS, Linux, Windows).\n\n## See Also\n\n- `examples/` - Configuration file examples\n- `QUICK_START_FONTS.md` - Font setup guide\n- `IMPLEMENTATION_SUMMARY.md` - Technical architecture reference\n- `README.md` - Main project documentation\n\nThis documentation provides a comprehensive overview of the par-term Test Scripts module, detailing its purpose, components, execution flow, and troubleshooting tips. Developers can use this information to understand, contribute to, and effectively utilize the testing capabilities of the par-term terminal emulator.","other-search":"# Other — search\n\n# Search Module Documentation\n\n## Overview\n\nThe **search** module provides functionality for searching through terminal scrollback content. It includes a search engine capable of performing both plain text and regex searches, as well as a user interface (UI) for interacting with the search functionality. This module is designed to enhance the user experience by allowing users to quickly find text within the terminal output.\n\n## Key Components\n\n### 1. Search Engine (`SearchEngine`)\n\nThe `SearchEngine` struct is the core component responsible for executing search queries. It supports both plain text and regex searches and caches compiled regex patterns for efficiency.\n\n#### Key Functions\n\n- **`new()`**: Creates a new instance of `SearchEngine`.\n- **`search<I>(&mut self, lines: I, query: &str, config: &SearchConfig) -> Vec<SearchMatch>`**: Searches through the provided lines of text based on the given query and configuration options. Returns a vector of `SearchMatch` instances representing the matches found.\n- **`search_plain<I>(&self, lines: I, query: &str, config: &SearchConfig, matches: &mut Vec<SearchMatch>)`**: Performs a plain text search.\n- **`search_regex<I>(&mut self, lines: I, query: &str, config: &SearchConfig, matches: &mut Vec<SearchMatch>)`**: Performs a regex search.\n- **`clear_cache(&mut self)`**: Clears the cached regex pattern.\n\n#### Caching Mechanism\n\nThe `SearchEngine` caches compiled regex patterns to avoid recompiling them for identical queries. This is managed by the `get_or_compile_regex` function, which checks if the current query matches the cached pattern and recompiles it if necessary.\n\n### 2. Search Configuration (`SearchConfig`)\n\nThe `SearchConfig` struct defines the configuration options for the search behavior, including:\n\n- **`case_sensitive`**: Indicates whether the search should be case-sensitive.\n- **`use_regex`**: Indicates whether to use regex for the search.\n- **`whole_word`**: Indicates whether to match whole words only.\n- **`wrap_around`**: Indicates whether to wrap around when navigating matches.\n\n### 3. Search Match (`SearchMatch`)\n\nThe `SearchMatch` struct represents a single match found during a search. It contains:\n\n- **`line`**: The index of the line in the scrollback buffer where the match was found.\n- **`column`**: The character position of the match within the line.\n- **`length`**: The length of the match in characters.\n\n### 4. Search UI (`SearchUI`)\n\nThe `SearchUI` struct provides the user interface for the search functionality. It allows users to input search queries, toggle search options, and navigate through matches.\n\n#### Key Functions\n\n- **`new()`**: Creates a new instance of `SearchUI`.\n- **`toggle()`**: Toggles the visibility of the search UI.\n- **`update_search<I>(&mut self, lines: I)`**: Updates the search results based on the current query and terminal content.\n- **`show(&mut self, ctx: &Context, terminal_rows: usize, scrollback_len: usize) -> SearchAction`**: Displays the search UI and handles user interactions.\n\n### 5. Search Actions (`SearchAction`)\n\nThe `SearchAction` enum defines the possible actions that can result from user interactions with the search UI:\n\n- **`None`**: No action needed.\n- **`ScrollToMatch(usize)`**: Scroll to make a match visible at the given scroll offset.\n- **`Close`**: Close the search UI.\n\n## Execution Flow\n\nThe execution flow of the search functionality can be summarized as follows:\n\n1. The user opens the search UI and enters a query.\n2. The `update_search` method is called to process the query and search through the terminal content.\n3. Depending on the configuration (plain text or regex), the appropriate search method (`search_plain` or `search_regex`) is invoked.\n4. Matches are collected and stored in the `matches` vector.\n5. The user can navigate through the matches using the UI, which updates the current match index and triggers scrolling actions as needed.\n\n### Mermaid Diagram\n\n```mermaid\ngraph TD;\n A[SearchUI] -->|update_search| B[SearchEngine]\n B -->|search| C[search_plain]\n B -->|search| D[search_regex]\n C -->|collect matches| E[SearchMatch]\n D -->|collect matches| E\n A -->|show| F[User Interface]\n F -->|toggle| A\n```\n\n## Integration with the Codebase\n\nThe search module is integrated into the terminal application, allowing users to search through the scrollback buffer. It interacts with other components of the application, such as the terminal rendering and input handling systems. The `SearchUI` is designed to be displayed as an overlay, ensuring that it does not obstruct the terminal output while providing a seamless user experience.\n\n### Testing\n\nThe module includes a comprehensive suite of tests to ensure the correctness of the search functionality. Tests cover various scenarios, including case sensitivity, regex patterns, whole word matching, and handling of empty queries.\n\n## Conclusion\n\nThe **search** module is a powerful tool for enhancing terminal usability by providing efficient search capabilities. Its design allows for flexibility in search options and a user-friendly interface, making it an essential component of the terminal application. Developers can extend or modify the search functionality as needed, leveraging the well-defined structure and clear separation of concerns within the module.","other-shader-debug-md":"# Other — shader_debug.md\n\n# Shader Y-Axis Debug Log Documentation\n\n## Overview\n\nThe **Shader Y-Axis Debug Log** module is designed to facilitate the integration of Shadertoy shaders into the `par-term` terminal emulator without requiring modifications to the shaders themselves. This module addresses the differences in coordinate systems between Shadertoy and the `wgpu` graphics API, specifically the orientation of the Y-axis.\n\n### Purpose\n\n- **Coordinate System Alignment**: Shadertoy uses a coordinate system where `fragCoord.y = 0` at the bottom of the screen and increases towards the top. In contrast, `wgpu` uses a system where `@builtin(position).y = 0` at the top and increases downwards. This module aims to bridge that gap.\n- **Debugging Shader Behavior**: The module provides a framework for testing various approaches to flipping the Y-axis in shaders, allowing developers to identify the most effective method for ensuring correct rendering.\n\n## Key Components\n\n### 1. Coordinate Flipping Approaches\n\nThe module explores multiple strategies for flipping the Y-axis in shaders. Each approach is tested for its effectiveness in rendering the correct output. Below is a summary of the key approaches attempted:\n\n- **Direct Flipping in `fs_main`**: Attempts to flip the Y-coordinate directly in the fragment shader's main function.\n- **Global Variable Workarounds**: Various methods to pass flipped coordinates between functions using global variables.\n- **GLSL Preprocessing**: Attempts to manipulate shader parameters and inject flip calculations through preprocessing directives.\n- **Manual Flipping in `mainImage`**: Directly applying the flip calculation within the `mainImage` function, which has shown to work correctly.\n\n### 2. Testing and Validation\n\nThe module includes a series of tests to validate the effectiveness of each approach. Key tests include:\n\n- **Raw Coordinate Read**: Confirming that `mainImage` can read `gl_FragCoord_st` correctly without any flipping.\n- **Flip Calculation Tests**: Testing various methods of flipping the Y-coordinate and observing the output.\n- **Debugging Outputs**: Using color outputs to visually confirm the correctness of the Y-axis orientation.\n\n### 3. Current State and Findings\n\nThe module is currently in a state where GLSL preprocessing is disabled, and attempts to flip coordinates in the `mainImage` function have been made. Key findings include:\n\n- **Manual Flipping Works**: Directly flipping coordinates in `mainImage` yields the correct output.\n- **Injection Failures**: Attempts to inject flip calculations through preprocessing or other methods result in `mainImage` seeing the original (unflipped) values, indicating a potential issue with variable visibility across function boundaries.\n\n## Execution Flow\n\nThe module does not have any internal or outgoing calls, and no execution flows have been detected. The primary focus is on the interaction between the shader functions and the handling of coordinate transformations.\n\n### Mermaid Diagram\n\n```mermaid\ngraph TD;\n A[fs_main] -->|sets| B[gl_FragCoord_st]\n B -->|reads| C[mainImage]\n C -->|outputs| D[Final Render]\n A -->|flips| B\n C -->|manual flip| D\n```\n\n## Integration with the Codebase\n\nThis module connects with the broader `par-term` codebase by providing a mechanism for rendering shaders correctly within the terminal environment. It relies on the `wgpu` API for graphics rendering and interacts with the shader compilation and execution pipeline.\n\n### Next Steps\n\n1. **Re-evaluate Flipping Logic**: Further investigate the flipping logic to ensure that it works consistently across different shader configurations.\n2. **Debugging Cursor Shader**: Address the issue with the cursor shader not being applied, as indicated by the lack of initialization logs.\n3. **Testing with Different Backends**: Consider testing with Vulkan or other backends to determine if the issue is specific to the `wgpu` implementation.\n\n## Conclusion\n\nThe Shader Y-Axis Debug Log module is a critical component for ensuring that Shadertoy shaders can be utilized effectively within the `par-term` terminal. By systematically testing various approaches to coordinate flipping, the module aims to provide a robust solution for shader integration while highlighting areas for further investigation and improvement.","other-shaders":"# Other — shaders\n\n# Other — Shaders Module Documentation\n\n## Overview\n\nThe **Other — Shaders** module is a collection of GLSL shaders designed to enhance visual effects in a graphical application. These shaders provide a variety of effects, including animated gradients, bloom effects, and cursor animations, among others. The shaders are optimized for performance and are intended to be used in a rendering pipeline that supports OpenGL or WebGL.\n\n## Purpose\n\nThe primary purpose of this module is to provide reusable shader programs that can be applied to various graphical elements within the application. Each shader is designed to achieve specific visual effects, enhancing the overall user experience. The shaders can be used for backgrounds, cursor effects, and other visual enhancements that require real-time rendering.\n\n## Key Components\n\n### Shader Files\n\nThe module consists of multiple shader files, each implementing a specific effect. Below is a brief description of some of the key shaders included in this module:\n\n1. **animated-gradient-shader.glsl**\n - **Purpose**: Creates a smooth animated color gradient background.\n - **Key Features**: Uses sine and cosine functions to animate colors over time.\n\n2. **arcane-portal.glsl**\n - **Purpose**: Simulates a magical portal effect with depth and reflection.\n - **Key Features**: Implements signed distance functions (SDF) for 3D shapes and uses ray marching for rendering.\n\n3. **bloom.glsl**\n - **Purpose**: Applies a bloom effect to bright areas of the scene.\n - **Key Features**: Utilizes a set of samples to create a soft glow around bright pixels.\n\n4. **cursor_effects.glsl**\n - **Purpose**: Contains various cursor effects, including glow, trails, and animations.\n - **Key Features**: Uses cursor position and movement to create dynamic visual feedback.\n\n5. **dither.glsl**\n - **Purpose**: Implements an ordered dithering effect to reduce color banding.\n - **Key Features**: Uses a Bayer matrix for dithering based on pixel intensity.\n\n6. **cubemap-skybox.glsl**\n - **Purpose**: Renders a skybox using a cubemap texture.\n - **Key Features**: Supports animated rotation of the skybox for dynamic backgrounds.\n\n### Shader Structure\n\nEach shader file typically follows a similar structure:\n\n- **Metadata Block**: Contains shader metadata such as name, author, description, version, and default parameters.\n- **Main Function**: The `mainImage` function is the entry point for the shader, where the rendering logic is implemented.\n- **Utility Functions**: Additional functions may be defined to assist with specific calculations, such as distance functions or color manipulations.\n\n### Shader Parameters\n\nShaders often accept parameters that can be configured to customize their behavior. Common parameters include:\n\n- **animation_speed**: Controls the speed of animations within the shader.\n- **brightness**: Adjusts the overall brightness of the rendered output.\n- **text_opacity**: Sets the opacity level for text elements rendered with the shader.\n- **cubemap**: Specifies the texture used for cubemap reflections.\n\n## Execution Flow\n\nThe shaders in this module are executed in the rendering pipeline, typically as part of a frame rendering loop. The following steps outline the general execution flow:\n\n1. **Initialization**: The application initializes the shaders and loads the necessary textures and parameters.\n2. **Rendering Loop**: For each frame:\n - The application updates the time and any relevant parameters (e.g., cursor position).\n - Each shader's `mainImage` function is called, where the rendering logic is executed.\n - The output color from the shader is blended with the terminal content or other graphical elements.\n3. **Final Output**: The final rendered image is displayed on the screen.\n\n### Mermaid Diagram\n\nThe following diagram illustrates the relationship between the shaders and their execution flow:\n\n```mermaid\ngraph TD;\n A[Application] -->|Initializes| B[Shaders]\n B --> C[animated-gradient-shader.glsl]\n B --> D[arcane-portal.glsl]\n B --> E[bloom.glsl]\n B --> F[cursor_effects.glsl]\n B --> G[dither.glsl]\n B --> H[cubemap-skybox.glsl]\n A -->|Rendering Loop| B\n C -->|Renders Gradient| I[Output]\n D -->|Renders Portal| I\n E -->|Applies Bloom| I\n F -->|Handles Cursor Effects| I\n G -->|Applies Dithering| I\n H -->|Renders Skybox| I\n```\n\n## Integration with the Codebase\n\nThe shaders in this module are designed to be easily integrated into the existing rendering pipeline of the application. They can be called from the main rendering loop, and their parameters can be dynamically adjusted based on user input or application state.\n\n### Usage Example\n\nTo use a shader, you would typically:\n\n1. Load the shader file into the application.\n2. Set any required parameters (e.g., animation speed, brightness).\n3. Call the shader's `mainImage` function during the rendering loop, passing in the necessary fragment coordinates and other context.\n\n### Conclusion\n\nThe **Other — Shaders** module provides a versatile set of GLSL shaders that enhance the visual quality of the application. By leveraging these shaders, developers can create rich graphical effects that improve user engagement and experience. The modular design allows for easy integration and customization, making it a valuable asset in any graphics-focused application.","other-src":"# Other — src\n\n# Documentation for the `par-term-config` Module\n\nThe `par-term-config` module is a critical component of the terminal emulator's configuration management system. It provides the necessary structures and functions to load, save, and manage user configurations, including themes, keybindings, and terminal behavior settings. This documentation outlines the key components of the module, their purposes, and how they interact with the rest of the codebase.\n\n## Overview\n\nThe `par-term-config` module is responsible for:\n\n- Defining configuration structures for terminal settings.\n- Loading and saving configurations from/to YAML files.\n- Providing default values for various settings.\n- Supporting dynamic updates and merging of user-defined configurations with defaults.\n\n## Key Components\n\n### 1. Configuration Structures\n\nThe module defines several key structures that represent different aspects of the terminal configuration:\n\n- **`Config`**: The main configuration structure that holds all terminal settings, including display options, keybindings, themes, and more.\n- **`TriggerConfig`**: Defines triggers that match terminal output patterns and specify actions to be executed when a match occurs.\n- **`CoprocessDefConfig`**: Represents configurations for coprocesses that can be managed by the terminal.\n- **`RestartPolicy`**: An enumeration that defines how coprocesses should be restarted based on their exit status.\n\n### 2. Default Values\n\nThe module provides default values for various configuration settings through functions defined in the `crate::defaults` module. These defaults ensure that the terminal has sensible initial settings even if the user configuration is incomplete or missing.\n\n### 3. Configuration Management Functions\n\nThe module includes several functions for managing configurations:\n\n- **`load()`**: Loads the configuration from a specified file path. If the file does not exist, it creates a default configuration and saves it.\n- **`save()`**: Saves the current configuration to a file.\n- **`substitute_variables()`**: Replaces environment variable placeholders in configuration strings with their actual values.\n- **`apply_tab_style()`**: Applies a selected tab style preset to the configuration, adjusting colors and sizes accordingly.\n\n### 4. Serialization and Deserialization\n\nThe module uses the `serde` library to serialize and deserialize configuration data to and from YAML format. This allows for easy reading and writing of configuration files.\n\n### 5. Keybinding Management\n\nThe `Config` structure includes a list of keybindings that can be customized by the user. The module provides functions to merge default keybindings into the user's configuration and to generate keybindings for snippets and actions.\n\n## Execution Flow\n\nThe execution flow for loading a configuration typically follows these steps:\n\n1. **Load Configuration**: The `load()` function is called, which checks for the existence of a configuration file.\n2. **Substitute Variables**: If the file exists, the contents are read, and any environment variable placeholders are substituted using `substitute_variables()`.\n3. **Deserialize**: The modified configuration string is deserialized into a `Config` structure.\n4. **Merge Defaults**: Default keybindings and widgets are merged into the user's configuration.\n5. **Return Configuration**: The fully populated `Config` structure is returned for use in the terminal application.\n\n### Mermaid Diagram\n\nThe following diagram illustrates the relationship between the key components of the `par-term-config` module:\n\n```mermaid\ngraph TD;\n A[Config] -->|contains| B[TriggerConfig]\n A -->|contains| C[CoprocessDefConfig]\n A -->|contains| D[RestartPolicy]\n A -->|manages| E[Keybindings]\n A -->|loads| F[Configuration File]\n F -->|uses| G[Substitute Variables]\n F -->|deserializes to| A\n A -->|saves| H[Configuration File]\n```\n\n## Integration with the Codebase\n\nThe `par-term-config` module is integrated with other parts of the terminal emulator codebase in the following ways:\n\n- **Themes**: The configuration module interacts with the `themes` module to apply user-selected themes to the terminal.\n- **Keybindings**: The keybindings defined in the configuration are used throughout the terminal application to handle user input and actions.\n- **Triggers and Coprocesses**: The `TriggerConfig` and `CoprocessDefConfig` structures allow for advanced automation and process management within the terminal, enabling users to define custom behaviors based on terminal output.\n\n## Conclusion\n\nThe `par-term-config` module is a foundational component of the terminal emulator, providing robust configuration management capabilities. By defining clear structures, default values, and management functions, it enables users to customize their terminal experience effectively. Understanding this module is essential for developers looking to contribute to the terminal emulator's configuration features or to extend its functionality.","other-test-cr-rs":"# Other — test_cr.rs\n\n# Documentation for the `test_cr.rs` Module\n\n## Overview\n\nThe `test_cr.rs` module is a simple test harness designed to validate the handling of carriage return (`\\r`) and line feed (`\\n`) characters in a pseudo-terminal (PTY) session. It utilizes the `PtySession` class from the `par_term_emu_core_rust` crate to simulate terminal behavior, allowing developers to ensure that cursor movements are correctly implemented in response to these control characters.\n\n## Purpose\n\nThe primary purpose of this module is to:\n- Verify that the cursor returns to the beginning of the line when a carriage return is sent.\n- Confirm that a line feed moves the cursor down to the next line.\n\nThis module serves as a basic unit test for the terminal emulator's handling of these essential control characters, which are critical for text-based user interfaces.\n\n## Key Components\n\n### 1. `PtySession`\n\nThe `PtySession` class is the core component used in this module. It provides methods to interact with a pseudo-terminal, including:\n- `new(width: usize, height: usize, timeout: u64)`: Initializes a new PTY session with specified dimensions and a timeout.\n- `spawn_shell()`: Launches a shell within the PTY session.\n- `write_str(&self, s: &str)`: Sends a string to the PTY.\n- `cursor_position(&self) -> (usize, usize)`: Retrieves the current cursor position as a tuple of column and row.\n\n### 2. Execution Flow\n\nThe execution flow of the `test_cr.rs` module is straightforward. The main function orchestrates the sequence of operations to test the carriage return and line feed functionality. Below is a high-level overview of the flow:\n\n1. **Initialize PTY Session**: A new `PtySession` is created with specified dimensions.\n2. **Spawn Shell**: A shell is spawned within the PTY session.\n3. **Write Text**: The string \"hello\" is written to the PTY.\n4. **Check Cursor Position**: The cursor position is checked after writing \"hello\".\n5. **Send Carriage Return**: A carriage return is sent to the PTY.\n6. **Check Cursor Position**: The cursor position is checked again to verify it has returned to column 0.\n7. **Send Line Feed**: A line feed is sent to the PTY.\n8. **Check Cursor Position**: The cursor position is checked to ensure it has moved down a row.\n\n### 3. Code Snippet\n\nHere is a simplified version of the main function to illustrate the key operations:\n\n```rust\nfn main() {\n let mut pty = PtySession::new(80, 24, 1000);\n pty.spawn_shell().expect(\"Failed to spawn shell\");\n thread::sleep(Duration::from_millis(200));\n\n pty.write_str(\"hello\").expect(\"Failed to write\");\n thread::sleep(Duration::from_millis(100));\n let (col1, row1) = pty.cursor_position();\n\n pty.write(b\"\\r\").expect(\"Failed to write CR\");\n thread::sleep(Duration::from_millis(100));\n let (col2, row2) = pty.cursor_position();\n\n pty.write(b\"\\n\").expect(\"Failed to write LF\");\n thread::sleep(Duration::from_millis(100));\n let (col3, row3) = pty.cursor_position();\n}\n```\n\n## Connection to the Codebase\n\nThe `test_cr.rs` module interacts with the following components of the `par_term_emu_core_rust` codebase:\n\n- **`src/terminal/mod.rs`**: Contains the implementation of the `PtySession` class, including methods for writing to the terminal and retrieving cursor positions.\n- **`src/terminal/spawn.rs`**: Implements the `spawn_shell` function, which is responsible for launching a shell in the PTY session.\n\n### Call Graph\n\nThe following Mermaid diagram illustrates the call relationships within the `test_cr.rs` module:\n\n```mermaid\ngraph TD;\n A[main] --> B[cursor_position]\n A --> C[write_str]\n A --> D[spawn_shell]\n```\n\n## Conclusion\n\nThe `test_cr.rs` module is a focused test utility that ensures the correct behavior of carriage return and line feed handling in a terminal emulator context. By leveraging the `PtySession` class, it provides a straightforward way to validate cursor movements, which is essential for any text-based interface. Developers can extend this module to include additional tests or integrate it into a larger testing framework as needed.","other-test-grid-rs":"# Other — test_grid.rs\n\n# Documentation for `test_grid.rs` Module\n\n## Overview\n\nThe `test_grid.rs` module is designed to test and visualize the content of a terminal grid managed by a `PtySession`. It simulates user interactions with a terminal, such as typing commands and pressing Enter, while capturing and printing the state of the terminal grid at various stages. This module is particularly useful for debugging and verifying the behavior of terminal emulation in the `par_term_emu_core_rust` library.\n\n## Purpose\n\nThe primary purpose of this module is to:\n- Examine the content of the terminal grid before and after specific user actions.\n- Validate the rendering of characters in the terminal grid.\n- Identify potential bugs related to cursor positioning and character rendering.\n\n## Key Components\n\n### 1. `print_grid_row`\n\n```rust\nfn print_grid_row(pty: &PtySession, row: usize, cols: usize)\n```\n\n- **Parameters**:\n - `pty`: A reference to a `PtySession` instance, which manages the terminal state.\n - `row`: The specific row in the terminal grid to print.\n - `cols`: The total number of columns in the terminal grid.\n\n- **Functionality**:\n - Locks the terminal to access the active grid.\n - Iterates through each column of the specified row, retrieving the corresponding cell.\n - Constructs a string representation of the row, replacing control characters with spaces.\n - Prints the formatted row to the console.\n\n### 2. `main`\n\n```rust\nfn main()\n```\n\n- **Functionality**:\n - Initializes a new `PtySession` with a specified width and height.\n - Spawns a shell within the terminal session.\n - Executes a series of commands to manipulate the terminal state and prints the grid content at various stages:\n - Initial state\n - After sending a Ctrl+C command\n - After typing \"test\"\n - After pressing Enter\n - After typing \"abc\"\n - Each stage includes a cursor position check and a grid printout to visualize changes.\n\n## Execution Flow\n\nThe execution flow of the `test_grid.rs` module can be summarized as follows:\n\n1. The `main` function initializes a `PtySession` and spawns a shell.\n2. It captures the initial cursor position and prints the first five rows of the terminal grid.\n3. The module simulates user actions (Ctrl+C, typing \"test\", pressing Enter, typing \"abc\") and prints the grid state after each action.\n4. Finally, it analyzes the output to check for rendering correctness.\n\n### Call Graph\n\n```mermaid\ngraph TD;\n A[main] -->|calls| B[print_grid_row]\n A -->|calls| C[cursor_position]\n A -->|calls| D[spawn_shell]\n A -->|calls| E[write_str]\n B -->|calls| F[get]\n```\n\n## Integration with the Codebase\n\nThe `test_grid.rs` module interacts with several components of the `par_term_emu_core_rust` library:\n\n- **PtySession**: The core class that manages the pseudo-terminal session, including the terminal state and user input.\n- **Terminal**: Provides methods to access the active grid and cursor position.\n- **Grid**: Represents the terminal's character grid, allowing retrieval of individual cells.\n\n### Important Functions and Methods\n\n- `PtySession::new(width: usize, height: usize, timeout: u64)`: Initializes a new pseudo-terminal session.\n- `PtySession::spawn_shell()`: Spawns a shell process within the terminal.\n- `PtySession::write(data: &[u8])`: Sends raw byte data to the terminal.\n- `Terminal::active_grid()`: Returns the current grid of the terminal.\n- `Grid::get(col: usize, row: usize)`: Retrieves the cell at the specified column and row.\n\n## Conclusion\n\nThe `test_grid.rs` module serves as a valuable tool for testing and debugging terminal emulation. By simulating user interactions and visualizing the terminal grid, developers can ensure that the terminal behaves as expected. Understanding this module is crucial for anyone looking to contribute to the `par_term_emu_core_rust` library, especially in areas related to terminal rendering and user input handling.","other-tests":"# Other — tests\n\n# Documentation for the **Other — tests** Module\n\n## Overview\n\nThe **Other — tests** module provides integration tests for the `par-term-fonts` crate, specifically focusing on the functionality of font management and text shaping. This module ensures that the core components of the crate, such as `FontData`, `FontManager`, and `TextShaper`, behave as expected under various conditions. The tests validate the loading of fonts, glyph retrieval, text shaping, and caching mechanisms.\n\n## Purpose\n\nThe primary purpose of this module is to verify the correctness and reliability of the font handling and text shaping functionalities in the `par-term-fonts` crate. By running these tests, developers can ensure that changes to the codebase do not introduce regressions or unexpected behavior.\n\n## Key Components\n\n### 1. FontData\n\n- **Functionality**: Represents the data structure for font information.\n- **Tests**:\n - `test_font_data_from_embedded`: Validates successful loading of embedded font data.\n - `test_font_data_invalid_bytes`: Ensures that invalid byte sequences return `None`.\n - `test_font_data_empty_bytes`: Checks that empty data also returns `None`.\n - `test_font_data_clone`: Confirms that cloning a `FontData` instance retains the same underlying data.\n - `test_font_data_debug`: Tests the debug representation of `FontData`.\n\n### 2. FontManager\n\n- **Functionality**: Manages font loading and glyph retrieval.\n- **Tests**:\n - `test_font_manager_with_embedded`: Verifies that a `FontManager` can be created with embedded fonts.\n - `test_font_manager_find_ascii_glyph`: Ensures that ASCII glyphs can be found in the primary font.\n - `test_font_manager_find_space_glyph`: Checks that space glyphs are retrievable.\n - `test_font_manager_get_font`: Validates access to the primary font.\n\n### 3. TextShaper\n\n- **Functionality**: Shapes text into glyphs based on specified options.\n- **Tests**:\n - `test_text_shaper_creation`: Confirms that a new `TextShaper` starts with an empty cache.\n - `test_text_shaper_with_cache_size`: Tests the creation of a `TextShaper` with a specified cache size.\n - `test_text_shaper_shape_with_embedded_font`: Validates that text can be shaped using an embedded font.\n - `test_text_shaper_caching`: Ensures that repeated shaping of the same text utilizes the cache.\n - `test_text_shaper_clear_cache`: Confirms that the cache can be cleared.\n - `test_text_shaper_grapheme_clusters`: Tests detection of grapheme clusters in ASCII text.\n - `test_text_shaper_emoji_graphemes`: Validates that emoji are treated as single graphemes.\n\n### 4. ShapingOptions\n\n- **Functionality**: Configures options for text shaping.\n- **Tests**:\n - `test_shaping_options_default`: Verifies default values for shaping options.\n\n## Execution Flow\n\nThe tests in this module do not have complex execution flows or internal calls, as they primarily focus on validating the behavior of the public APIs of the `par-term-fonts` crate. Each test is self-contained and directly interacts with the respective components.\n\n## Integration with the Codebase\n\nThe tests in this module interact with the following components of the `par-term-fonts` crate:\n\n- **FontData**: Loaded from embedded font files and validated for correctness.\n- **FontManager**: Utilized to manage and retrieve glyphs from fonts.\n- **TextShaper**: Used to shape text into glyphs based on the specified options.\n\nThe tests ensure that these components work together seamlessly, providing a robust foundation for font handling and text rendering in terminal applications.\n\n## Conclusion\n\nThe **Other — tests** module is essential for maintaining the integrity of the `par-term-fonts` crate. By covering various scenarios and edge cases, these tests help developers ensure that the font management and text shaping functionalities are reliable and perform as expected. As the codebase evolves, these tests will serve as a safety net, catching potential regressions and ensuring a high-quality user experience.","other-textures":"# Other — textures\n\n# Other — Textures Module Documentation\n\n## Overview\n\nThe **Other — Textures** module is a dedicated folder within the project that contains artistic assets, specifically wallpapers, created by the artist Paul Rebello. This module is licensed under the MIT License, ensuring that it can be freely used and modified within the bounds of the license.\n\n## Purpose\n\nThe primary purpose of this module is to provide high-quality texture assets that can be utilized throughout the project. These textures enhance the visual appeal of the application, contributing to a more immersive user experience. The wallpapers are designed to be versatile and can be applied in various contexts within the application.\n\n## Key Components\n\n### 1. Art Assets\n\nThe main component of this module is the collection of wallpaper textures. Each texture is a digital artwork that can be referenced and used in different parts of the application. The textures are stored in a structured manner, allowing for easy access and integration.\n\n### 2. Licensing\n\nAll artwork in this module is created by Paul Rebello and is distributed under the MIT License. This allows developers to use, modify, and distribute the textures freely, provided that the original license is included in any derivative works.\n\n## How It Works\n\nWhile there are no direct function calls or execution flows associated with this module, the textures can be integrated into the application through various rendering or UI components. Developers can reference the textures in their code, typically in the following manner:\n\n```javascript\nimport wallpaper from 'shaders/textures/wallpaper/textureName.png';\n\n// Usage in a rendering context\ncontext.drawImage(wallpaper, x, y, width, height);\n```\n\nThis example demonstrates how a texture can be imported and used in a rendering context, such as a canvas or a UI component.\n\n## Integration with the Codebase\n\nThe **Other — Textures** module does not have any direct dependencies or outgoing calls to other modules. However, it serves as a resource for other parts of the application that require visual assets. Developers working on UI components, game scenes, or any visual representation can leverage the textures provided in this module.\n\n### Example Usage in the Codebase\n\nTo illustrate how this module can be utilized, consider the following example where a wallpaper texture is applied to a background in a UI component:\n\n```javascript\nimport React from 'react';\nimport wallpaper from 'shaders/textures/wallpaper/background.png';\n\nconst BackgroundComponent = () => {\n return (\n <div style={{ backgroundImage: `url(${wallpaper})`, height: '100vh', width: '100vw' }}>\n {/* Other UI elements */}\n </div>\n );\n};\n\nexport default BackgroundComponent;\n```\n\nIn this example, the wallpaper texture is used as a background image for a React component, showcasing how easily textures can be integrated into the application.\n\n## Conclusion\n\nThe **Other — Textures** module is a straightforward yet essential part of the project, providing artistic assets that enhance the overall user experience. By understanding how to access and utilize these textures, developers can contribute to the visual richness of the application while adhering to the licensing terms set forth by the creator. \n\nFor any further questions or contributions regarding this module, please refer to the project's contribution guidelines or reach out to the project maintainers.","other":"# Other\n\n# Overview of the **Other** Module\n\nThe **Other** module serves as a comprehensive collection of configuration, build, and utility components for the `par-term` terminal emulator. This module is essential for managing various aspects of the terminal's functionality, from build automation to cross-compilation, and user interface settings. The sub-modules work together to create a cohesive environment that enhances the user experience and streamlines development processes.\n\n## Purpose\n\nThe primary purpose of the **Other** module is to provide a structured framework for managing the configuration, build processes, and additional functionalities of the `par-term` terminal emulator. This includes:\n\n- **Configuration Management**: Through modules like `[par-term-config](par-term-config.md)` and `[par-term-settings-ui](par-term-settings-ui.md)`, users can customize their terminal experience, including themes, keybindings, and other settings.\n- **Build Automation**: The `[Makefile](Makefile.md)` and `[Cargo.toml](Cargo.toml.md)` modules facilitate the building and packaging of the terminal emulator, ensuring that all dependencies are correctly managed.\n- **Cross-Compilation**: The `[Cross.toml](Cross.toml.md)` module automates the setup for building applications targeting different architectures, particularly ARM64.\n- **User Interaction**: Modules like `[par-term-input](par-term-input.md)` and `[par-term-keybindings](par-term-keybindings.md)` enhance user interaction by managing input sequences and keyboard shortcuts.\n\n## Key Workflows\n\nThe sub-modules within the **Other** module interact to support several key workflows:\n\n1. **Building and Configuration**:\n - The `[Cargo.toml](Cargo.toml.md)` and `[Makefile](Makefile.md)` modules define how the project is built and what dependencies are required.\n - The `[par-term-config](par-term-config.md)` module loads user configurations, which can be modified through the `[par-term-settings-ui](par-term-settings-ui.md)` for a graphical interface.\n\n2. **Cross-Platform Support**:\n - The `[Cross.toml](Cross.toml.md)` module ensures that the terminal can be built for different architectures, while the `[Casks](Casks.md)` module provides a Homebrew Cask definition for easy installation on macOS.\n\n3. **User Input and Interaction**:\n - The `[par-term-input](par-term-input.md)` module captures user input, while the `[par-term-keybindings](par-term-keybindings.md)` module allows users to define custom keyboard shortcuts, enhancing usability.\n\n4. **Shader and Graphics Management**:\n - The `[install_shaders.sh](install_shaders.sh.md)` script automates the installation of shaders, which are essential for rendering graphics in the terminal, while the `[gallery](gallery.md)` module showcases shader effects.\n\n5. **Logging and Debugging**:\n - The `[run.log](run.log.md)` module centralizes logging functionalities, aiding in debugging and monitoring the terminal's performance.\n\n## Conclusion\n\nThe **Other** module is a vital part of the `par-term` ecosystem, providing the necessary tools and configurations to enhance the terminal emulator's functionality and user experience. Each sub-module plays a specific role, and together they create a robust environment for both developers and users. For detailed information on each component, please refer to the linked sub-module documentation.","overview":"# par-term — Wiki\n\n# Welcome to the par-term Project Wiki\n\nWelcome to the **par-term** project! This repository hosts a cross-platform, GPU-accelerated terminal emulator designed for high performance, modern typography, and rich graphics support. Built with Rust, **par-term** is engineered to provide a seamless terminal experience across Linux, macOS, and Windows.\n\n## Project Overview\n\n**par-term** is not just a terminal emulator; it’s a powerful tool that integrates various functionalities to enhance user experience. The architecture is modular, allowing developers to easily navigate and contribute to specific components. Key modules include:\n\n- **[Application](application.md)**: The central hub that orchestrates the terminal's functionalities, managing state and user interactions.\n- **[Terminal](terminal.md)**: Manages terminal interactions and state, enabling a tabbed interface for multiple sessions.\n- **[Rendering](rendering.md)**: Handles the visual output, efficiently rendering text and graphical elements using GPU capabilities.\n- **[Input](input.md)**: Captures keyboard events and manages input processing, ensuring a responsive user experience.\n- **[Scripting](scripting.md)**: Provides a bridge to scripting capabilities, allowing for enhanced flexibility in terminal interactions.\n\n## Key Features\n\n- **GPU Acceleration**: Leverages GPU for high-performance rendering.\n- **Inline Graphics Support**: Supports advanced graphics features, including Sixel.\n- **Customizable Keybindings**: Users can define their own shortcuts for a personalized experience.\n- **SSH Integration**: Facilitates quick connections to remote hosts with built-in SSH management.\n- **Status Bar**: Displays real-time session information, enhancing usability.\n\n## Architecture Overview\n\nThe architecture of **par-term** is designed to be intuitive and modular. Below is a high-level overview of the key modules and their relationships:\n\n```mermaid\ngraph TD;\n A[Application] -->|manages| B[Terminal]\n A -->|controls| C[Rendering]\n A -->|handles| D[Input]\n A -->|integrates| E[Scripting]\n A -->|displays| F[Status Bar]\n A -->|connects| G[SSH]\n A -->|configures| H[Profiles]\n A -->|manages| I[Arrangements]\n A -->|utilizes| J[Miscellaneous]\n```\n\n## Getting Started\n\nTo get started with **par-term**, clone the repository and set up your development environment:\n\n1. Clone the repository:\n ```bash\n git clone https://github.com/paulrobello/par-term.git\n cd par-term\n ```\n\n2. Ensure you have Rust installed. If not, you can install it from [rustup.rs](https://rustup.rs/).\n\n3. Build the project:\n ```bash\n cargo build\n ```\n\n4. Run the terminal emulator:\n ```bash\n cargo run\n ```\n\n## Contributing\n\nWe welcome contributions! Please check the documentation for each module to understand how you can help improve **par-term**. For detailed guidelines, refer to the [Contributing](contributing.md) page.\n\n## Conclusion\n\nWe hope you find **par-term** to be a powerful and flexible terminal emulator that meets your needs. Dive into the module documentation to explore the capabilities and start building! If you have any questions or need assistance, feel free to reach out to the community. Happy coding!","plans-plans":"# Plans — plans\n\n# Plans Module Documentation\n\n## Overview\n\nThe **Plans** module is designed to manage and implement various features and enhancements for the terminal application. This module encompasses several design documents that outline the implementation of new functionalities, including shell exit actions, triggers, coprocesses, and SSH features. Each feature is aimed at improving user experience and enhancing the capabilities of the terminal application.\n\n## Key Features\n\n### 1. Shell Exit Actions\n\nThe shell exit actions feature allows users to configure how the terminal behaves when a shell process exits. This replaces the previous boolean configuration with a more flexible enum that provides multiple options:\n\n- **Close**: Closes the tab/pane when the shell exits.\n- **Keep**: Keeps the pane open, displaying the terminated shell.\n- **RestartImmediately**: Immediately restarts the shell in the same pane.\n- **RestartWithPrompt**: Prompts the user to press Enter before restarting.\n- **RestartAfterDelay**: Restarts the shell after a specified delay.\n\n#### Implementation Details\n\n- **Enum Definition**: The `ShellExitAction` enum is defined in `src/config/types.rs`.\n- **Configuration Changes**: The configuration structure is updated to replace the old boolean field with the new enum and a custom deserializer for backward compatibility.\n- **Handler Logic**: The exit handling logic in `src/app/handler.rs` is refactored to accommodate the new enum values.\n\n### 2. Triggers and Coprocesses\n\nThis feature introduces a mechanism for defining triggers that respond to specific patterns in terminal output and coprocesses that can run alongside the terminal.\n\n#### Implementation Details\n\n- **Trigger Configuration**: Defined in `src/config/automation.rs`, allowing users to specify regex patterns and associated actions (e.g., highlight, notify, run command).\n- **Coprocess Management**: Allows users to define subprocesses that can interact with the terminal.\n- **Settings UI**: A new \"Automation\" tab in the settings UI provides a user-friendly interface for managing triggers and coprocesses.\n\n### 3. SSH Features\n\nThe SSH features enhance the terminal's ability to manage SSH connections, including host profiles, quick connect functionality, and mDNS discovery.\n\n#### Implementation Details\n\n- **SSH Config Parser**: Parses the `~/.ssh/config` file to extract host entries and their parameters.\n- **Quick Connect Dialog**: Provides a modal overlay for quickly connecting to SSH hosts, with fuzzy search capabilities.\n- **Profile Auto-Switching**: Automatically switches profiles based on the current SSH connection or command being executed.\n- **mDNS Discovery**: Uses the `mdns-sd` crate to discover SSH hosts on the local network.\n\n## Architecture\n\nThe Plans module is structured to facilitate the addition of new features while maintaining a clear separation of concerns. Below is a high-level overview of the architecture:\n\n```mermaid\ngraph TD;\n A[Plans Module] --> B[Shell Exit Actions]\n A --> C[Triggers and Coprocesses]\n A --> D[SSH Features]\n B --> E[ShellExitAction Enum]\n B --> F[Configuration Changes]\n B --> G[Handler Logic]\n C --> H[Trigger Configuration]\n C --> I[Coprocess Management]\n C --> J[Settings UI]\n D --> K[SSH Config Parser]\n D --> L[Quick Connect Dialog]\n D --> M[Profile Auto-Switching]\n D --> N[mDNS Discovery]\n```\n\n## Key Components\n\n### Shell Exit Actions\n\n- **Enum**: `ShellExitAction` in `src/config/types.rs`\n- **Configuration**: Updated in `src/config/mod.rs`\n- **Handler Logic**: Refactored in `src/app/handler.rs`\n\n### Triggers and Coprocesses\n\n- **Trigger Configuration**: Defined in `src/config/automation.rs`\n- **Coprocess Management**: Handled in `src/app/triggers.rs`\n- **Settings UI**: Implemented in `src/settings_ui/automation_tab.rs`\n\n### SSH Features\n\n- **SSH Config Parser**: Implemented in `src/ssh/config_parser.rs`\n- **Quick Connect Dialog**: Implemented in `src/ssh_connect_ui.rs`\n- **mDNS Discovery**: Implemented in `src/ssh/mdns.rs`\n\n## Conclusion\n\nThe Plans module serves as a comprehensive framework for implementing new features in the terminal application. By organizing functionalities into distinct components, the module ensures maintainability and scalability. Developers can easily extend the module with additional features while adhering to the established architecture and design principles.","plans":"# Plans\n\n# Plans Module Overview\n\nThe **Plans** module serves as a comprehensive framework for managing enhancements and features within the terminal application. It integrates several sub-modules, each focusing on specific functionalities that collectively improve user experience and operational efficiency.\n\n## Sub-Modules\n\n1. **Shell Exit Actions**: This sub-module allows users to define the behavior of the terminal upon shell exit, offering options such as closing the tab or keeping it open for further interaction. For detailed information, visit the [Shell Exit Actions](shell-exit-actions.md) page.\n\n2. **Triggers**: This component enables the execution of predefined actions based on specific events within the terminal. It enhances automation and responsiveness, allowing users to customize their terminal experience. More details can be found on the [Triggers](triggers.md) page.\n\n3. **Coprocesses**: This sub-module facilitates the management of background processes that can run concurrently with the main shell. It allows for more complex workflows and multitasking capabilities. For further insights, refer to the [Coprocesses](coprocesses.md) documentation.\n\n4. **SSH Features**: This component enhances the terminal's capabilities for secure shell connections, providing users with improved options for remote access and management. For specifics, see the [SSH Features](ssh-features.md) page.\n\n## Integration and Workflows\n\nThe sub-modules within the Plans module are designed to work in tandem, creating a cohesive user experience. For instance, the Shell Exit Actions can be configured to trigger specific actions defined in the Triggers sub-module, allowing for a seamless transition between tasks. Additionally, Coprocesses can leverage SSH Features to manage remote tasks efficiently.\n\n### Key Workflows\n\n- **Shell Management**: Users can configure shell exit behaviors that trigger subsequent actions, enhancing workflow continuity.\n- **Automated Responses**: Triggers can initiate coprocesses based on shell events, allowing for automated task management.\n- **Remote Operations**: SSH Features can be utilized in conjunction with Coprocesses to execute commands on remote systems, streamlining operations.\n\nBy integrating these functionalities, the Plans module not only enhances the terminal's capabilities but also provides users with a customizable and efficient working environment. For more detailed information on each sub-module, please refer to their respective documentation pages.","profiles":"# Profiles\n\n# Profiles Module Documentation\n\nThe **Profiles** module is designed to manage terminal session configurations, allowing users to create, edit, and manage profiles that define various settings for terminal sessions. This module supports dynamic profiles fetched from remote sources, caching mechanisms, and a user interface for profile management.\n\n## Overview\n\nThe Profiles module consists of several components that work together to provide a comprehensive profile management system. The key functionalities include:\n\n- **Dynamic Profile Management**: Fetching profiles from remote URLs, caching them, and merging them with local profiles.\n- **Profile Storage**: Saving and loading profiles from a persistent storage file.\n- **User Interface**: Providing a graphical interface for users to manage their profiles.\n\n## Key Components\n\n### 1. Dynamic Profile Management\n\nThe dynamic profile management is primarily handled in the `dynamic.rs` file. It includes the following key functions and structures:\n\n- **DynamicProfileManager**: This struct manages background fetching of dynamic profiles from remote sources. It uses Tokio tasks to periodically fetch profiles and send updates to the main thread.\n\n- **fetch_profiles**: This function fetches profiles from a specified remote URL. It handles HTTP requests, caching, and error management.\n\n- **merge_dynamic_profiles**: This function merges fetched profiles into a local `ProfileManager`, applying conflict resolution strategies to handle name conflicts.\n\n- **Cache Management**: Functions like `read_cache`, `write_cache`, and `url_to_cache_filename` manage the caching of profiles and their metadata.\n\n### 2. Profile Storage\n\nThe storage utilities are defined in `storage.rs`, which provides functions to load and save profiles to a YAML file located at `~/.config/par-term/profiles.yaml`.\n\n- **load_profiles**: Loads profiles from the default location, returning a `ProfileManager` instance.\n\n- **save_profiles**: Saves the current profiles to the specified file, ensuring the directory structure exists.\n\n### 3. User Interface\n\nThe user interface components are defined in `profile_modal_ui.rs` and `profile_drawer_ui.rs`. They provide a graphical interface for managing profiles.\n\n- **ProfileModalUI**: This struct manages the modal dialog for creating, editing, and managing profiles. It includes methods for rendering the UI, handling user input, and managing the state of the modal.\n\n- **ProfileDrawerUI**: This struct provides a collapsible drawer for quick access to profiles. It allows users to open profiles and manage them from a side panel.\n\n### 4. Profile Types\n\nThe module re-exports profile types from the `par-term-config` crate, including `Profile`, `ProfileManager`, and `ProfileSource`. These types are essential for defining and managing profiles.\n\n## Execution Flow\n\nThe execution flow of the Profiles module can be summarized as follows:\n\n1. **Initialization**: The `DynamicProfileManager` is initialized, setting up channels for communication between background tasks and the main thread.\n\n2. **Fetching Profiles**: The `start` method of `DynamicProfileManager` triggers background tasks that fetch profiles from remote sources using the `fetch_profiles` function.\n\n3. **Caching**: Fetched profiles are cached using `write_cache`, and existing profiles are read from the cache using `read_cache`.\n\n4. **Merging Profiles**: The `merge_dynamic_profiles` function is called to integrate fetched profiles into the local `ProfileManager`, applying conflict resolution strategies.\n\n5. **User Interaction**: The user interacts with the `ProfileModalUI` and `ProfileDrawerUI` to create, edit, and manage profiles. Changes are validated and saved using the `save_profiles` function.\n\n6. **Rendering**: The UI components render the current state of profiles, allowing users to view and manage their configurations.\n\n### Mermaid Diagram\n\nThe following diagram illustrates the interaction between key components in the Profiles module:\n\n```mermaid\ngraph TD;\n A[DynamicProfileManager] -->|fetches| B[fetch_profiles]\n B -->|caches| C[write_cache]\n B -->|reads| D[read_cache]\n A -->|merges| E[merge_dynamic_profiles]\n E -->|updates| F[ProfileManager]\n F -->|saves| G[save_profiles]\n F -->|loads| H[load_profiles]\n F -->|interacts with| I[ProfileModalUI]\n F -->|interacts with| J[ProfileDrawerUI]\n```\n\n## Conclusion\n\nThe Profiles module provides a robust framework for managing terminal session configurations, integrating dynamic profiles from remote sources, and offering a user-friendly interface for profile management. By understanding the key components and execution flow, developers can effectively contribute to and extend the functionality of this module.","rendering-src":"# Rendering — src\n\n# Rendering Module Documentation\n\nThe **Rendering** module is a core component of the terminal emulator, responsible for rendering text, backgrounds, and graphical elements on the screen. It leverages the GPU for efficient rendering using the `wgpu` library, providing a high-performance experience for users.\n\n## Overview\n\nThe rendering module is designed to handle various aspects of rendering, including:\n\n- **Text Rendering**: Efficiently rendering text with support for different fonts and styles.\n- **Background Management**: Handling solid colors and images as backgrounds.\n- **Block Character Rendering**: Rendering Unicode block characters geometrically to avoid gaps.\n- **Dynamic State Management**: Managing the state of the terminal, including cursor position, opacity, and visual effects.\n\n## Key Components\n\n### 1. **CellRenderer Struct**\n\nThe `CellRenderer` struct is the main entry point for rendering operations. It encapsulates all necessary resources and state for rendering, including:\n\n- **Device and Queue**: Handles GPU operations.\n- **Surface Configuration**: Manages the rendering surface and its properties.\n- **Pipelines**: Contains render pipelines for backgrounds, text, and visual effects.\n- **Buffers**: Manages vertex and instance buffers for rendering.\n- **Glyph Cache**: Caches rendered glyphs to optimize performance.\n- **Dynamic State**: Tracks the state of the terminal, including cursor position and background settings.\n\n### 2. **Background Management**\n\nThe module supports both solid color and image backgrounds. The `load_background_image` function loads an image from a specified path and creates a texture for rendering. The `set_background` function allows switching between different background modes (default, color, or image).\n\n### 3. **Text Rendering**\n\nText rendering is handled through the `rasterize_glyph` function, which rasterizes glyphs based on the selected font and rendering options. The `upload_glyph` function uploads the rasterized glyph to the GPU texture atlas, managing the layout of glyphs efficiently.\n\n### 4. **Block Character Rendering**\n\nThe module includes utilities for detecting and rendering Unicode block characters. The `classify_char` function determines the type of character (e.g., box drawing, solid block) and the `get_box_drawing_geometry` function generates the geometric representation for rendering.\n\n### 5. **Dynamic State Management**\n\nThe `CellRenderer` maintains various dynamic states, such as cursor position, opacity, and visual effects. Functions like `update_bg_image_uniforms` and `snap_glyph_to_cell` ensure that the rendering adapts to changes in state, such as resizing or changing the cursor style.\n\n## Execution Flow\n\nThe rendering process typically follows these steps:\n\n1. **Initialization**: The `CellRenderer` is initialized with the necessary parameters, including window size, font settings, and background configurations.\n2. **Rendering Loop**: During each frame, the rendering loop:\n - Clears the previous frame.\n - Updates the background based on the current settings.\n - Renders text and graphical elements based on the current state.\n - Handles cursor rendering and any visual effects.\n3. **Dynamic Updates**: The renderer responds to user input and state changes, updating the display as needed.\n\n### Mermaid Diagram\n\n```mermaid\ngraph TD;\n A[CellRenderer] -->|initializes| B[Device & Queue]\n A -->|configures| C[Surface Configuration]\n A -->|manages| D[Pipelines]\n A -->|handles| E[Buffers]\n A -->|caches| F[Glyph Cache]\n A -->|tracks| G[Dynamic State]\n D -->|renders| H[Text]\n D -->|renders| I[Background]\n D -->|renders| J[Block Characters]\n```\n\n## Integration with the Codebase\n\nThe rendering module interacts with various parts of the codebase:\n\n- **Font Management**: It relies on the `FontManager` to load and manage fonts.\n- **Scrollbar**: Integrates with the `Scrollbar` component to manage scrolling behavior.\n- **Custom Shader Renderer**: Works with the custom shader renderer for advanced visual effects.\n- **Configuration**: Uses settings from `par_term_config` to adapt rendering behavior based on user preferences.\n\n## Conclusion\n\nThe Rendering module is a vital part of the terminal emulator, providing the necessary functionality to render text, backgrounds, and graphical elements efficiently. Its design allows for flexibility and performance, making it suitable for a wide range of terminal applications. Developers contributing to this module should focus on maintaining performance while adding new features and ensuring compatibility with existing functionality.","rendering":"# Rendering\n\n# Rendering Module Overview\n\nThe **Rendering** module is a pivotal part of the terminal emulator, orchestrating the visual output by efficiently rendering text, backgrounds, and graphical elements. It utilizes the `wgpu` library to leverage GPU capabilities, ensuring high performance and responsiveness.\n\n## Purpose\n\nThe Rendering module is designed to manage various rendering tasks, including:\n\n- **Text Rendering**: Supports multiple fonts and styles for dynamic text display.\n- **Background Management**: Handles both solid colors and images as backgrounds.\n- **Block Character Rendering**: Renders Unicode block characters to eliminate visual gaps.\n- **Dynamic State Management**: Maintains the terminal's state, including cursor position and opacity.\n\n## Sub-module Interactions\n\nThe Rendering module is composed of several sub-modules that work together to achieve a cohesive rendering experience:\n\n- **Text Rendering** and **Block Character Rendering** collaborate to ensure that text is displayed clearly and without gaps, utilizing geometric calculations for block characters.\n- **Background Management** interacts with the **Custom Shader Renderer** to apply textures and manage background states, ensuring that visual elements are rendered correctly based on user settings.\n- **Dynamic State Management** is crucial for maintaining the terminal's visual integrity during user interactions, such as cursor movements and background updates.\n\n### Key Workflows\n\n1. **Rendering Process**: The main rendering flow begins with the `render` function, which coordinates calls to create samplers and manage background textures. This process is essential for displaying the terminal's content accurately.\n \n2. **Instance Buffer Management**: The `build_pane_instance_buffers` function is responsible for preparing the necessary buffers for rendering, which involves creating geometry for box drawing and other visual elements.\n\n3. **Background Updates**: The workflow for updating backgrounds involves multiple steps, including checking the background mode and applying the appropriate textures, ensuring that the visual output remains consistent with user preferences.\n\n4. **Shader Management**: The module manages shader states, enabling or disabling custom shaders based on the rendering context, which is crucial for achieving the desired visual effects.\n\nFor detailed information on each sub-module, please refer to the following links:\n\n- [Text Rendering](src/text_rendering.md)\n- [Background Management](src/background_management.md)\n- [Block Character Rendering](src/block_character_rendering.md)\n- [Custom Shader Renderer](src/custom_shader_renderer.md)\n- [Dynamic State Management](src/dynamic_state_management.md)\n\nBy integrating these sub-modules, the Rendering module provides a robust framework for rendering in the terminal emulator, ensuring a seamless and visually appealing user experience.","research":"# Research\n\n# Research Module Documentation\n\n## Overview\n\nThe **Research** module focuses on the exploration and documentation of private macOS APIs for managing Spaces (virtual desktops) and window management. This module is essential for developers looking to implement advanced window management features in macOS applications, particularly for terminal emulators and productivity tools. The module provides insights into the evolution of these APIs, their current state, and practical usage patterns.\n\n## Purpose\n\nThe primary purpose of this module is to document the private APIs available for managing Spaces in macOS, particularly after Apple deprecated public APIs in macOS 10.7. It serves as a guide for developers who need to understand how to interact with these APIs, the risks involved, and best practices for implementation.\n\n## Key Components\n\n### API Evolution\n\nThe module outlines the historical context of Space management APIs in macOS, detailing the transition from public to private APIs and the implications of these changes. Key milestones include:\n\n- **Pre-10.7**: Public APIs available for Space management.\n- **10.7 (Lion)**: Introduction of private APIs, leading to the need for alternative solutions.\n- **14.5 (Sonoma)**: Introduction of breaking changes requiring compatibility workarounds.\n- **15.x (Sequoia)**: Continued support for the modern API patterns established in Sonoma.\n\n### Core API Functions\n\nThe module documents several core functions that are critical for Space and window management. These functions are categorized into several sections:\n\n1. **Connection Management**\n - `SLSMainConnectionID()`: Establishes a connection to the Window Server.\n\n2. **Space Information**\n - Functions like `SLSManagedDisplayGetCurrentSpace()`, `SLSCopyManagedDisplayForSpace()`, and `SLSCopyManagedDisplaySpaces()` provide information about the current Spaces and their properties.\n\n3. **Window Management**\n - Functions such as `SLSCopyWindowsWithOptionsAndTags()` and `SLSCopySpacesForWindows()` allow querying and managing windows across Spaces.\n\n4. **Moving Windows Between Spaces**\n - The module details both modern and legacy methods for moving windows between Spaces, highlighting the need for compatibility IDs in macOS 14.5 and later.\n\n5. **Process-Level Space Assignment**\n - Functions like `SLSProcessAssignToSpace()` and `SLSProcessAssignToAllSpaces()` allow developers to assign processes to specific Spaces.\n\n6. **Space Visibility and Window Positioning**\n - Functions to show/hide Spaces and manipulate window positioning are also documented.\n\n### Rust FFI Implementation\n\nThe module provides a comprehensive guide on how to use Rust's Foreign Function Interface (FFI) to interact with the private SLS APIs. This includes:\n\n- Manual declarations of the SLS functions.\n- Example implementations for moving windows and querying Space information.\n- Best practices for error handling and version detection.\n\n### Alternative Approaches\n\nThe module discusses alternative public API approaches, such as using `NSWindow.collectionBehavior` for limited Space management and CGEvent-based workarounds for App Store compliance. It also highlights the limitations of these approaches compared to the private APIs.\n\n### Risks and Limitations\n\nThe documentation outlines the risks associated with using private APIs, including:\n\n- **App Store Rejection**: High risk of rejection for apps using private APIs.\n- **API Stability**: Medium risk due to potential changes in private APIs across macOS versions.\n- **System Integrity Protection (SIP)**: Medium risk for certain operations requiring SIP modifications.\n\n### Best Practices\n\nThe module concludes with best practices for developers, emphasizing the importance of version detection, graceful error handling, and the use of compatibility layers to abstract API calls.\n\n## Architecture Overview\n\nThe following Mermaid diagram illustrates the key components and their relationships within the Research module:\n\n```mermaid\ngraph TD;\n A[Research Module] --> B[API Evolution]\n A --> C[Core API Functions]\n A --> D[Rust FFI Implementation]\n A --> E[Alternative Approaches]\n A --> F[Risks and Limitations]\n A --> G[Best Practices]\n \n C --> C1[Connection Management]\n C --> C2[Space Information]\n C --> C3[Window Management]\n C --> C4[Moving Windows]\n C --> C5[Process-Level Assignment]\n C --> C6[Visibility & Positioning]\n```\n\n## Conclusion\n\nThe **Research** module serves as a comprehensive resource for developers looking to implement Space management features in macOS applications. By understanding the private APIs, their evolution, and the associated risks, developers can create robust applications that enhance user productivity while navigating the complexities of macOS's window management system.","scripting":"# Scripting\n\n# Scripting Module Documentation\n\n## Overview\n\nThe **Scripting** module serves as a bridge to the `par-term-scripting` crate, providing a streamlined interface for developers to access its functionalities. This module is designed to facilitate the integration of scripting capabilities into applications, allowing for enhanced flexibility and extensibility in handling terminal interactions.\n\n## Purpose\n\nThe primary purpose of the Scripting module is to re-export key components from the `par-term-scripting` crate, ensuring backward compatibility while allowing developers to leverage the powerful features of the crate without needing to directly reference it. This encapsulation simplifies the usage of scripting functionalities in the broader codebase.\n\n## Key Components\n\nThe Scripting module re-exports the following submodules from `par-term-scripting`:\n\n1. **manager**: This submodule is responsible for managing the lifecycle of scripts, including loading, executing, and unloading them. It provides an interface for script registration and management.\n\n2. **observer**: The observer submodule allows for the monitoring of script events and state changes. It provides hooks for developers to respond to various scripting events, enabling a reactive programming model.\n\n3. **process**: This submodule handles the execution of scripts, including the management of input and output streams. It ensures that scripts can run in a controlled environment, with access to necessary resources.\n\n4. **protocol**: The protocol submodule defines the communication standards and data formats used between scripts and the host application. It ensures that scripts can interact seamlessly with the application, adhering to defined protocols.\n\n## How It Works\n\nThe Scripting module does not contain any internal logic or execution flows; instead, it acts as a conduit for the functionalities provided by the `par-term-scripting` crate. By re-exporting these submodules, the Scripting module allows developers to access the scripting capabilities without needing to understand the underlying implementation details of the `par-term-scripting` crate.\n\n### Example Usage\n\nTo utilize the Scripting module in your application, you can import the necessary components as follows:\n\n```rust\nuse scripting::manager;\nuse scripting::observer;\nuse scripting::process;\nuse scripting::protocol;\n\n// Example of using the manager to load a script\nlet script_manager = manager::ScriptManager::new();\nscript_manager.load(\"path/to/script\");\n```\n\n## Integration with the Codebase\n\nThe Scripting module is designed to be easily integrated into existing applications that require scripting capabilities. By providing a unified interface to the `par-term-scripting` crate, it allows developers to focus on implementing their application logic without worrying about the complexities of the underlying scripting engine.\n\n### Architecture Overview\n\nThe following diagram illustrates the relationship between the Scripting module and the `par-term-scripting` crate:\n\n```mermaid\ngraph TD;\n A[Scripting Module] -->|Re-exports| B[manager]\n A -->|Re-exports| C[observer]\n A -->|Re-exports| D[process]\n A -->|Re-exports| E[protocol]\n B -->|Interacts with| F[par-term-scripting]\n C -->|Interacts with| F\n D -->|Interacts with| F\n E -->|Interacts with| F\n```\n\n## Conclusion\n\nThe Scripting module is a crucial part of the codebase that enables developers to incorporate scripting functionalities easily. By re-exporting the components of the `par-term-scripting` crate, it provides a clean and efficient interface for managing scripts, observing events, processing executions, and adhering to communication protocols. This design promotes modularity and maintainability, making it easier for developers to extend and enhance their applications.","shell-integration":"# Shell Integration\n\n# Shell Integration Module Documentation\n\n## Overview\n\nThe **Shell Integration** module enhances terminal functionality by embedding semantic markers in the shell's prompt and command output. This integration allows for improved user experience through features such as working directory tracking, command exit status indicators, and file transfer utilities.\n\n## Purpose\n\nThe primary purpose of the Shell Integration module is to provide a seamless interaction between the terminal and the par-term application. It leverages the OSC 133 protocol, which is compatible with various terminal emulators, to facilitate advanced features that enhance productivity and usability.\n\n## Key Features\n\n- **Working Directory Tracking**: Automatically updates the terminal's tab title with the current working directory.\n- **Command Exit Status Indicators**: Displays the exit status of the last executed command in the prompt.\n- **Prompt Navigation**: Allows users to navigate between commands easily.\n- **File Transfer Utilities**: Includes tools for downloading (`pt-dl`), uploading (`pt-ul`), and displaying images inline (`pt-imgcat`).\n\n## Installation\n\n### From par-term\n\n1. Open Settings (F12).\n2. Navigate to Integrations.\n3. Click on \"Install Shell Integration\".\n\n### Manual Installation\n\nYou can also install the shell integration manually using the following command:\n\n```bash\ncurl -fsSL https://paulrobello.github.io/par-term/install-shell-integration.sh | bash\n```\n\n## Technical Details\n\nThe Shell Integration module utilizes the OSC 133 protocol, which is also used by iTerm2, VSCode, and WezTerm. This protocol allows for the transmission of control sequences that enhance terminal capabilities.\n\n### Shell Integration Scripts\n\nThe module includes shell integration scripts for different shells:\n\n- **Bash**: `par_term_shell_integration.bash`\n- **Fish**: `par_term_shell_integration.fish`\n- **Zsh**: `par_term_shell_integration.zsh`\n\nEach script must be sourced in the respective shell configuration file (e.g., `~/.bashrc`, `~/.config/fish/config.fish`, or `~/.zshrc`).\n\n## File Transfer Utilities\n\nThe module provides three utilities for file transfer, which are installed in `~/.config/par-term/bin/` and added to your PATH automatically.\n\n### 1. pt-dl — Download Files\n\nThe `pt-dl` utility allows users to download files from a remote host to the local machine. It encodes files as base64 and sends them via OSC 1337.\n\n**Usage:**\n\n```bash\n# Download a single file\npt-dl report.pdf\n\n# Download multiple files\npt-dl file1.txt file2.txt file3.log\n\n# Pipe data from stdin\ncat /var/log/syslog | pt-dl --name syslog.txt\nmysqldump mydb | pt-dl --name backup.sql\n```\n\n### 2. pt-ul — Upload Files\n\nThe `pt-ul` utility enables users to upload files from the local machine to a remote host. It sends an OSC 1337 `RequestUpload` escape sequence, prompting the user to select a file.\n\n**Usage:**\n\n```bash\n# Upload to the current directory\npt-ul\n\n# Upload to a specific directory\npt-ul /tmp/uploads\n```\n\n### 3. pt-imgcat — Display Inline Images\n\nThe `pt-imgcat` utility allows users to display images inline in the terminal. It encodes images as base64 and sends them via OSC 1337.\n\n**Usage:**\n\n```bash\n# Display an image\npt-imgcat photo.png\n\n# Display with size constraints\npt-imgcat --width 80 --height 24 diagram.png\n\n# Display from stdin\ncat screenshot.png | pt-imgcat\n\n# Pixel-based sizing\npt-imgcat --width 400px --height 300px image.jpg\n\n# Allow stretching (disable aspect ratio preservation)\npt-imgcat --no-preserve-aspect-ratio banner.png\n```\n\n## SSH Usage\n\nAll utilities work transparently over SSH. To use the utilities on a remote host, install the shell integration on that host as well:\n\n```bash\n# On remote host\ncurl -fsSL https://paulrobello.github.io/par-term/install-shell-integration.sh | bash\nsource ~/.bashrc\n\n# Now use the utilities\npt-dl /var/log/app.log\npt-imgcat /tmp/chart.png\n```\n\n## tmux/screen Support\n\nThe utilities automatically detect when running inside tmux or screen and wrap escape sequences in the appropriate passthrough format. No additional configuration is required.\n\n## Architecture Overview\n\nThe following diagram illustrates the interaction between the shell integration scripts and the par-term application:\n\n```mermaid\ngraph TD;\n A[User Shell] -->|Sourcing| B[Shell Integration Script]\n B -->|OSC 133 Protocol| C[par-term Application]\n C -->|File Transfer| D[pt-dl, pt-ul, pt-imgcat]\n C -->|Prompt Markers| E[Command Status, Working Directory]\n```\n\n## Conclusion\n\nThe Shell Integration module significantly enhances the terminal experience by providing advanced features that improve usability and productivity. By leveraging the OSC 133 protocol, it allows for seamless interaction between the terminal and the par-term application, making it a valuable tool for developers and users alike.","ssh":"# SSH\n\n# SSH Module Documentation\n\n## Overview\n\nThe SSH module provides functionality for managing SSH connections, including parsing SSH configuration files, discovering hosts from various sources, and facilitating user interactions for quick connections. It integrates with local SSH configurations, known hosts, shell history, and mDNS for discovering SSH services on the local network.\n\n## Key Components\n\n### 1. **Types**\n\nThe `types.rs` file defines the core data structures used throughout the module:\n\n- **`SshHost`**: Represents an SSH host with attributes such as alias, hostname, user, port, identity file, proxy jump, and source of the host entry.\n- **`SshHostSource`**: An enumeration that categorizes the source of an SSH host entry, which can be from the SSH config, known hosts, shell history, or mDNS.\n\n### 2. **Configuration Parsing**\n\nThe `config_parser.rs` file is responsible for parsing the SSH configuration file located at `~/.ssh/config`. It provides two main functions:\n\n- **`parse_ssh_config(path: &Path) -> Vec<SshHost>`**: Reads the SSH config file and returns a vector of `SshHost` entries, skipping wildcard-only hosts.\n- **`parse_ssh_config_str(content: &str) -> Vec<SshHost>`**: Parses SSH configuration from a string, useful for testing.\n\nThe parsing logic handles multi-host lines, user and port specifications, and identity file expansions.\n\n### 3. **Known Hosts Parsing**\n\nThe `known_hosts.rs` file handles the parsing of the `~/.ssh/known_hosts` file. It provides:\n\n- **`parse_known_hosts(path: &Path) -> Vec<SshHost>`**: Reads the known hosts file and extracts hostnames, handling both plain and hashed formats.\n\n### 4. **Shell History Scanning**\n\nThe `history.rs` file scans shell history files (Bash, Zsh, Fish) for SSH commands. It provides:\n\n- **`scan_history() -> Vec<SshHost>`**: Scans the history files and returns a vector of `SshHost` entries derived from SSH commands.\n- **`parse_ssh_command(line: &str) -> Option<SshHost>`**: Parses a single SSH command line to extract host information.\n\n### 5. **mDNS Discovery**\n\nThe `mdns.rs` file implements mDNS (Multicast DNS) discovery for SSH services on the local network. It includes:\n\n- **`MdnsDiscovery`**: A struct that manages the state of mDNS discovery, including discovered hosts and scanning status.\n- **`start_scan(timeout_secs: u32)`**: Initiates an mDNS scan for SSH services.\n- **`poll() -> bool`**: Polls for newly discovered hosts and returns whether new hosts were found.\n\n### 6. **Host Discovery Aggregation**\n\nThe `discovery.rs` file aggregates host discovery from various sources:\n\n- **`discover_local_hosts() -> Vec<SshHost>`**: Combines hosts from the SSH config, known hosts, and shell history into a single list, ensuring no duplicates.\n\n### 7. **User Interface for Quick Connect**\n\nThe `ssh_connect_ui.rs` file provides a user interface for quickly connecting to SSH hosts. It includes:\n\n- **`SshConnectUI`**: Manages the state of the quick connect dialog, including host filtering and selection.\n- **`show(ctx: &Context) -> SshConnectAction`**: Renders the UI and handles user interactions.\n\n## Execution Flow\n\nThe SSH module operates through a series of interconnected components. The following diagram illustrates the flow of data and function calls within the module:\n\n```mermaid\ngraph TD;\n A[User Interface] -->|Open| B[SshConnectUI];\n B -->|Discover| C[discover_local_hosts];\n C -->|Parse Config| D[parse_ssh_config];\n C -->|Parse Known Hosts| E[parse_known_hosts];\n C -->|Scan History| F[scan_history];\n B -->|Poll mDNS| G[MdnsDiscovery];\n G -->|Run Scan| H[run_mdns_scan];\n H -->|Send Hosts| I[SshHost];\n B -->|Show Hosts| J[Display Hosts];\n```\n\n## How It Works\n\n1. **User Interaction**: The user opens the quick connect dialog, which initializes the `SshConnectUI`.\n2. **Host Discovery**: Upon opening, the UI triggers the discovery of local hosts by calling `discover_local_hosts()`, which aggregates hosts from the SSH config, known hosts, and shell history.\n3. **mDNS Scanning**: If enabled, the UI starts an mDNS scan for SSH services, allowing for dynamic discovery of hosts on the local network.\n4. **Display**: The UI displays the discovered hosts, allowing the user to filter and select a host to connect to.\n5. **Connection**: Upon selection, the UI constructs the SSH command arguments using the selected `SshHost` and initiates the connection.\n\n## Conclusion\n\nThe SSH module provides a comprehensive solution for managing SSH connections, integrating various sources of host information, and offering a user-friendly interface for quick connections. Its modular design allows for easy extension and maintenance, making it a valuable component of the overall application. Developers can contribute by enhancing existing features, adding new sources for host discovery, or improving the user interface.","status-bar":"# Status Bar\n\n# Status Bar Module Documentation\n\n## Overview\n\nThe **Status Bar** module provides a configurable panel that displays real-time session and system information, such as the current time, username, git branch, CPU/memory usage, and more. It is designed to enhance user experience by providing essential information at a glance while allowing customization of the displayed widgets.\n\n## Key Components\n\nThe Status Bar module consists of several key components:\n\n1. **Configuration (`config.rs`)**: Defines types and constants for configuring the status bar, including widget settings and default values.\n2. **System Monitor (`system_monitor.rs`)**: A background service that polls system resource usage (CPU, memory, network) and provides this data to the status bar.\n3. **Widgets (`widgets.rs`)**: Functions for generating display text for various widgets based on the current context.\n4. **Status Bar UI (`mod.rs`)**: The main interface for rendering the status bar and managing its state.\n\n### Component Diagram\n\n```mermaid\ngraph TD;\n A[Status Bar Module] --> B[Configuration]\n A --> C[System Monitor]\n A --> D[Widgets]\n A --> E[Status Bar UI]\n C --> F[SystemMonitorData]\n D --> G[WidgetContext]\n E --> H[StatusBarAction]\n```\n\n## Module Structure\n\n### 1. Configuration (`config.rs`)\n\nThis module re-exports types from the `par-term-config` crate for backward compatibility. It defines the following key types:\n\n- `StatusBarSection`: Enum representing different sections of the status bar (Left, Center, Right).\n- `StatusBarWidgetConfig`: Configuration structure for individual widgets.\n- `WidgetId`: Enum representing different widget types (e.g., Clock, CPU Usage, Git Branch).\n- `default_widgets`: Function to retrieve default widget configurations.\n\n### 2. System Monitor (`system_monitor.rs`)\n\nThe System Monitor is responsible for polling system resource usage in a background thread. It provides the following functionalities:\n\n- **Data Structure**: `SystemMonitorData` holds the latest CPU, memory, and network usage statistics.\n- **Polling Mechanism**: The `start` method initiates a polling thread that updates the `SystemMonitorData` at specified intervals.\n- **Thread Management**: Methods like `signal_stop` and `stop` control the lifecycle of the polling thread.\n\n### 3. Widgets (`widgets.rs`)\n\nThis module contains functions for generating display text for each widget type. The main function is `widget_text`, which takes a `WidgetId`, a `WidgetContext`, and an optional format override. It handles various widgets, including:\n\n- **Clock**: Displays the current time formatted according to user settings.\n- **Git Branch**: Shows the current git branch along with ahead/behind counts and dirty status.\n- **CPU and Memory Usage**: Displays current CPU usage and memory statistics.\n\n### 4. Status Bar UI (`mod.rs`)\n\nThe `StatusBarUI` struct manages the rendering and state of the status bar. Key methods include:\n\n- **`new`**: Initializes a new status bar instance with default settings.\n- **`render`**: Renders the status bar UI, returning its height and any user actions (e.g., clicking an update widget).\n- **`sync_monitor_state`**: Starts or stops the system monitor and git poller based on the enabled widgets.\n- **`on_mouse_activity`**: Resets the auto-hide timer when mouse activity is detected.\n\n## Execution Flow\n\nThe execution flow of the Status Bar module can be summarized as follows:\n\n1. **Initialization**: The `StatusBarUI` is created, initializing the system monitor and git poller.\n2. **Rendering**: The `render` method is called to display the status bar. It checks the configuration and determines if the bar should be visible.\n3. **Polling**: The system monitor and git poller run in the background, updating their respective data.\n4. **User Interaction**: User actions (like clicking on widgets) are handled, triggering appropriate responses (e.g., showing an update dialog).\n\n### Example Usage\n\nHere’s a simple example of how to create and render a status bar:\n\n```rust\nlet mut status_bar = StatusBarUI::new();\nlet (height, action) = status_bar.render(&ctx, &config, &session_vars, is_fullscreen);\n```\n\n## Integration with the Codebase\n\nThe Status Bar module interacts with various parts of the codebase:\n\n- **Session Variables**: The status bar uses session variables to display user-specific information (e.g., username, current directory).\n- **Configuration Management**: It relies on the configuration module to determine which widgets to display and their settings.\n- **System Monitoring**: The system monitor provides real-time data that is displayed in the status bar, ensuring users have up-to-date information about system resources.\n\n## Conclusion\n\nThe Status Bar module is a vital component of the application, providing users with essential information in a customizable format. Its architecture allows for easy extension and integration with other parts of the codebase, making it a flexible solution for displaying real-time data. Developers can contribute by adding new widgets, enhancing existing functionality, or improving the overall user experience.","terminal-src":"# Terminal — src\n\n# Terminal Module Documentation\n\n## Overview\n\nThe **Terminal** module is responsible for managing terminal state and handling pseudo-terminal (PTY) interactions. It serves as a bridge between the terminal UI and the underlying terminal management functionalities provided by the `par-term-terminal` crate. This module is crucial for rendering terminal content, managing clipboard operations, and handling user interactions through a tabbed interface.\n\n## Key Components\n\n### 1. Terminal Management\n\nThe module re-exports various types and functions from the `par-term-terminal` crate, ensuring backward compatibility while providing a unified interface for terminal management. The key exports include:\n\n- **Clipboard Management**: Functions for clipboard operations.\n- **Coprocess Environment**: Management of environment variables for coprocesses.\n- **Graphics and Rendering**: Functions for rendering graphics in the terminal.\n- **Hyperlinks**: Support for hyperlinking within terminal content.\n- **Tab Management**: Functions for spawning and managing terminal tabs.\n\n### 2. Tab Bar UI\n\nThe **TabBarUI** struct is a central component of the terminal's user interface, providing a visual representation of open terminal tabs. It allows users to switch between tabs, create new tabs, and manage tab properties such as renaming and coloring.\n\n#### Key Fields\n\n- `hovered_tab`: Tracks the currently hovered tab.\n- `dragging_tab`: Manages the state of a tab being dragged.\n- `context_menu_tab`: Stores the ID of the tab for which the context menu is open.\n- `show_new_tab_profile_menu`: Indicates if the new tab profile menu is visible.\n\n#### Key Methods\n\n- `new()`: Initializes a new instance of the TabBarUI.\n- `render()`: Renders the tab bar and handles user interactions.\n- `should_show()`: Determines if the tab bar should be displayed based on the current configuration and tab count.\n- `get_height()`: Returns the height of the tab bar based on the configuration and tab count.\n\n### 3. Tab Bar Actions\n\nThe **TabBarAction** enum defines various actions that can be triggered from the tab bar, including:\n\n- **SwitchTo(TabId)**: Switch to a specific tab.\n- **Close(TabId)**: Close a specific tab.\n- **NewTab**: Create a new tab.\n- **Reorder(TabId, usize)**: Reorder a tab to a new position.\n- **SetColor(TabId, [u8; 3])**: Set a custom color for a tab.\n- **RenameTab(TabId, String)**: Rename a specific tab.\n\n### 4. Rendering Logic\n\nThe rendering logic is divided into horizontal and vertical layouts, allowing for flexible UI configurations. The `render_horizontal` and `render_vertical` methods handle the layout and rendering of tabs based on the current configuration.\n\n### 5. Context Menu and Drag-and-Drop\n\nThe module supports a context menu for tab options, allowing users to rename tabs, set icons, and change colors. Additionally, it implements drag-and-drop functionality for reordering tabs, enhancing the user experience.\n\n## Execution Flow\n\nThe execution flow of the terminal module can be summarized as follows:\n\n1. **Initialization**: The `TabBarUI` is initialized using the `new()` method.\n2. **Rendering**: The `render()` method is called to display the tab bar. This method checks the visibility of the tab bar and renders it based on the current configuration.\n3. **User Interaction**: User interactions such as clicking, dragging, and right-clicking trigger various actions defined in the `TabBarAction` enum.\n4. **Context Menu**: If a tab is right-clicked, the context menu is displayed, allowing for additional actions.\n5. **Drag-and-Drop**: If a tab is dragged, the drag feedback is rendered, and the tab can be reordered based on the drop position.\n\n### Mermaid Diagram\n\nThe following diagram illustrates the interaction between key components of the Terminal module:\n\n```mermaid\ngraph TD;\n A[Terminal Module] -->|Re-exports| B[par-term-terminal]\n A --> C[TabBarUI]\n C --> D[Render]\n C --> E[Context Menu]\n C --> F[Drag-and-Drop]\n D -->|SwitchTo| G[Tab Management]\n D -->|Close| H[Tab Management]\n D -->|NewTab| I[Tab Management]\n E -->|RenameTab| J[Tab Management]\n E -->|SetColor| K[Tab Management]\n```\n\n## Conclusion\n\nThe Terminal module is a vital part of the terminal application, providing a robust interface for managing terminal states and user interactions. Its design allows for flexibility in UI rendering and user experience, making it easy to extend and maintain. Developers contributing to this module should focus on enhancing the rendering logic, improving user interactions, and ensuring compatibility with the underlying `par-term-terminal` functionalities.","terminal-tab":"# Terminal — tab\n\n# Terminal Tab Module Documentation\n\n## Overview\n\nThe **Terminal Tab** module provides the infrastructure for managing multiple terminal tabs within a single window. It allows users to create, manipulate, and interact with terminal sessions in a tabbed interface. This module is essential for applications that require multi-tab support, enabling users to run multiple terminal sessions concurrently.\n\n### Key Components\n\n1. **Tab**: Represents a single terminal session, encapsulating its state, configuration, and behavior.\n2. **TabManager**: Coordinates multiple tabs, managing their lifecycle, state transitions, and interactions.\n3. **TabId**: A unique identifier for each tab, facilitating easy reference and management.\n\n## Module Structure\n\nThe module is organized into several files, each serving a specific purpose:\n\n- **initial_text.rs**: Contains functions for processing initial text configurations, including unescaping escape sequences and normalizing line endings.\n- **manager.rs**: Implements the `TabManager` struct, which handles the creation, deletion, and switching of tabs.\n- **mod.rs**: The main entry point for the module, re-exporting key components and providing utility functions.\n\n## Functionality\n\n### Tab Management\n\nThe `TabManager` struct is responsible for managing the collection of tabs. It provides methods to create, close, and switch between tabs. The following key methods are defined:\n\n- **new_tab**: Creates a new tab with the specified configuration and makes it the active tab.\n- **close_tab**: Closes a tab by its ID and returns whether it was the last tab.\n- **switch_to**: Switches the active tab to the one specified by its ID.\n- **next_tab** and **prev_tab**: Navigate through the tabs in a circular manner.\n\n### Tab Lifecycle\n\nEach `Tab` instance represents a terminal session and maintains its own state, including:\n\n- **TerminalManager**: The core terminal session handling, responsible for executing commands and managing input/output.\n- **PaneManager**: Supports split panes within a tab, allowing for multiple terminal views in a single tab.\n- **Session Logger**: Optionally records the terminal session for later review.\n\n### Initial Text Processing\n\nThe `initial_text.rs` file contains functions that handle the initial text configuration for tabs. This includes:\n\n- **unescape_initial_text**: Converts escape sequences in the initial text into their literal values.\n- **normalize_line_endings**: Ensures consistent line endings across different platforms.\n- **build_initial_text_payload**: Constructs the byte payload to be sent to the terminal based on the initial text configuration.\n\n### Configuration and Environment\n\nThe module also includes functions to configure terminal settings based on user preferences, such as:\n\n- **configure_terminal_from_config**: Applies various settings from the configuration, including theme, clipboard limits, and cursor style.\n- **build_shell_env**: Constructs the environment variables for the terminal, augmenting the PATH as necessary.\n\n## Execution Flow\n\nThe following diagram illustrates the key interactions within the Terminal Tab module, focusing on the creation of a new tab and its initial configuration:\n\n```mermaid\ngraph TD;\n A[TabManager] -->|new_tab| B[Tab]\n B -->|new| C[TerminalManager]\n C -->|configure_terminal_from_config| D[Config]\n C -->|build_initial_text_payload| E[initial_text.rs]\n E -->|unescape_initial_text| F[Escape Sequences]\n E -->|normalize_line_endings| G[Line Endings]\n```\n\n## Usage Example\n\nTo create a new tab, a developer would typically interact with the `TabManager` as follows:\n\n```rust\nlet mut tab_manager = TabManager::new();\nlet config = Config::default(); // Load or create a configuration\nlet runtime = Arc::new(Runtime::new().unwrap());\nlet tab_id = tab_manager.new_tab(&config, runtime, true, None).unwrap();\n```\n\nThis code initializes a new `TabManager`, creates a new tab with the specified configuration, and makes it the active tab.\n\n## Testing\n\nThe module includes a comprehensive suite of tests to ensure the functionality of tab management, initial text processing, and configuration handling. Tests are located in the `tests` module within each respective file.\n\n### Example Test\n\nHere’s an example of a test for the `unescape_initial_text` function:\n\n```rust\n#[test]\nfn test_unescape_supported_sequences() {\n let raw = \"echo \\\\x1b[0m\\\\nready\\\\tgo\\\\r\";\n let unescaped = unescape_initial_text(raw);\n assert_eq!(unescaped, \"echo \\u{1b}[0m\\nready\\tgo\\r\");\n}\n```\n\n## Conclusion\n\nThe Terminal Tab module is a critical component of the terminal application, providing robust support for managing multiple terminal sessions in a user-friendly tabbed interface. Its design allows for easy extension and integration with other parts of the application, making it a versatile choice for developers looking to implement multi-tab functionality.","terminal":"# Terminal\n\n# Terminal Module Overview\n\nThe **Terminal** module is a comprehensive system designed to manage terminal interactions and state, facilitating a seamless user experience through a tabbed interface. It is composed of two primary sub-modules: **Terminal Management** and **Terminal Tab**. Together, these components enable users to efficiently handle multiple terminal sessions, manage clipboard operations, and render terminal content.\n\n## Sub-module Integration\n\n### 1. [Terminal Management](src/terminal/src.md)\n\nThis sub-module serves as the backbone of the terminal functionality, leveraging the `par-term-terminal` crate to provide essential features such as clipboard management and terminal state handling. It ensures that all terminal operations are executed smoothly and consistently, allowing for a unified interface that abstracts the complexities of terminal management.\n\n### 2. [Terminal Tab](src/terminal/tab.md)\n\nThe **Terminal Tab** sub-module is responsible for managing multiple terminal sessions within a single window. It allows users to create, manipulate, and interact with individual terminal tabs. Key components include the **Tab**, which encapsulates the state of each terminal session, and the **TabManager**, which coordinates the lifecycle and interactions of these tabs.\n\n## Key Workflows\n\nThe integration of these sub-modules enables several key workflows:\n\n- **Creating and Managing Tabs**: Users can create new tabs through the **TabManager**, which interacts with the **Terminal Management** to initialize terminal sessions.\n- **Clipboard Operations**: Clipboard functionalities are handled by the **Terminal Management** module, allowing users to copy and paste content across different tabs seamlessly.\n- **Rendering and Interaction**: The rendering of terminal content and tab interfaces is managed through cross-module calls, ensuring that user interactions are reflected in real-time across all active tabs.\n\n## Conclusion\n\nThe **Terminal** module, through its sub-modules, provides a robust framework for terminal management and user interaction. By combining the functionalities of terminal management and tabbed interfaces, it enhances the overall user experience, making it easier to work with multiple terminal sessions concurrently. For more detailed information, please refer to the respective sub-module documentation: [Terminal Management](src/terminal/src.md) and [Terminal Tab](src/terminal/tab.md).","update":"# Update\n\n# Update Module Documentation\n\n## Overview\n\nThe **Update** module is responsible for managing the self-update and update-checking functionality of the par-term terminal emulator. It provides mechanisms for downloading updates, checking for new releases, and maintaining a manifest of bundled files. This module is crucial for ensuring that users have the latest features and security updates without manual intervention.\n\n### Key Components\n\nThe Update module consists of several components, each serving a specific purpose:\n\n1. **HTTP Client (`http.rs`)**: Provides functions to create an HTTP agent and download files from URLs.\n2. **Manifest Management (`manifest.rs`)**: Handles the creation, loading, saving, and validation of a manifest file that tracks bundled assets.\n3. **Self-Updater (`self_updater.rs`)**: Manages the process of downloading and installing updates, including platform-specific installation logic.\n4. **Update Checker (`update_checker.rs`)**: Periodically checks for new releases on GitHub and notifies users of available updates.\n\n## Architecture\n\nThe Update module interacts with various parts of the codebase, including configuration management and the HTTP client. Below is a simplified view of the module's architecture:\n\n```mermaid\ngraph TD;\n A[Update Module] -->|uses| B[HTTP Client]\n A -->|manages| C[Manifest]\n A -->|performs| D[Self-Updater]\n A -->|checks| E[Update Checker]\n B -->|downloads| F[Files]\n C -->|tracks| G[Bundled Assets]\n D -->|installs| H[Updates]\n E -->|fetches| I[Release Info]\n```\n\n## Component Details\n\n### 1. HTTP Client (`http.rs`)\n\nThe HTTP client provides a simple interface for making HTTP requests with TLS support. It includes the following key functions:\n\n- **`agent()`**: Creates a new HTTP agent configured with native TLS.\n- **`download_file(url: &str) -> Result<Vec<u8>, String>`**: Downloads a file from the specified URL and returns its bytes. It handles errors gracefully, returning a descriptive error message if the download fails.\n\n### 2. Manifest Management (`manifest.rs`)\n\nThe manifest system tracks bundled files and their states. It includes:\n\n- **`Manifest` struct**: Represents the manifest, including version, generation timestamp, and a list of files.\n- **`load(dir: &Path) -> Result<Self, String>`**: Loads a manifest from a specified directory.\n- **`save(&self, dir: &Path) -> Result<(), String>`**: Saves the current manifest to a specified directory.\n- **`check_file_status(file_path: &Path, relative_path: &str, manifest: &Manifest) -> FileStatus`**: Compares a file against the manifest to determine its status (e.g., unchanged, modified, user-created, or missing).\n\n### 3. Self-Updater (`self_updater.rs`)\n\nThe self-updater handles the downloading and installation of updates. Key functions include:\n\n- **`perform_update(new_version: &str) -> Result<UpdateResult, String>`**: Orchestrates the update process, including detecting the installation type, fetching the latest release, downloading the binary, and performing the installation.\n- **`detect_installation() -> InstallationType`**: Determines how par-term was installed (e.g., Homebrew, Cargo, macOS bundle, or standalone binary).\n- **`install_macos_bundle(current_exe: &Path, zip_data: &[u8]) -> Result<PathBuf, String>`**: Installs updates for macOS applications by extracting the downloaded zip file.\n- **`install_standalone(current_exe: &Path, data: &[u8]) -> Result<PathBuf, String>`**: Handles the installation of updates for standalone binaries on Linux and Windows.\n\n### 4. Update Checker (`update_checker.rs`)\n\nThe update checker periodically checks for new releases and manages the update frequency. Key functions include:\n\n- **`check_now(&self, config: &Config, force: bool) -> (UpdateCheckResult, bool)`**: Performs an update check and returns the result, along with a flag indicating if the configuration should be updated.\n- **`fetch_latest_release() -> Result<UpdateInfo, String>`**: Fetches the latest release information from the GitHub API.\n- **`should_check(&self, config: &Config) -> bool`**: Determines if an update check should be performed based on the configured frequency and the time since the last check.\n\n## Integration with the Codebase\n\nThe Update module integrates with other parts of the par-term codebase as follows:\n\n- **Configuration Management**: The update checker uses configuration settings to determine how often to check for updates and whether to skip certain versions.\n- **User Interface**: The results of update checks can be displayed to users, allowing them to take action based on the availability of new versions.\n- **File Management**: The manifest system ensures that bundled files are tracked and validated, preventing issues with user modifications.\n\n## Error Handling\n\nThe Update module employs a consistent error handling strategy, returning `Result` types with descriptive error messages. This approach allows developers to understand the context of failures and take appropriate actions.\n\n## Conclusion\n\nThe Update module is a critical component of the par-term terminal emulator, providing seamless self-update capabilities and ensuring that users have access to the latest features and fixes. By leveraging a structured approach to HTTP requests, manifest management, and update checking, this module enhances the overall user experience and maintainability of the application."}; | |
| var TREE = [{"name":"Agents","slug":"agents","files":["agents/ampcode.com.toml","agents/augmentcode.com.toml","agents/claude.com.toml","agents/copilot.github.com.toml","agents/docker.com.toml","agents/geminicli.com.toml","agents/openai.com.toml","agents/openhands.dev.toml"]},{"name":"Documentation","slug":"documentation","files":[],"children":[{"name":"Documentation — AGENTS.md","slug":"documentation-agents-md","files":["AGENTS.md"]},{"name":"Documentation — CLAUDE.md","slug":"documentation-claude-md","files":["CLAUDE.md"]},{"name":"Documentation — GEMINI.md","slug":"documentation-gemini-md","files":["GEMINI.md"]},{"name":"Documentation — MATRIX.md","slug":"documentation-matrix-md","files":["MATRIX.md"]},{"name":"Documentation — PANES.md","slug":"documentation-panes-md","files":["PANES.md"]},{"name":"Documentation — QUICK_START_FONTS.md","slug":"documentation-quick-start-fonts-md","files":["QUICK_START_FONTS.md"]},{"name":"Documentation — README.md","slug":"documentation-readme-md","files":["README.md"]},{"name":"Documentation — docs","slug":"documentation-docs","files":["docs/ACCESSIBILITY.md","docs/ARCHITECTURE.md","docs/ARRANGEMENTS.md","docs/ASSISTANT_PANEL.md","docs/AUTOMATION.md","docs/BADGES.md","docs/COMMAND_HISTORY.md","docs/COMMAND_SEPARATORS.md","docs/COMPOSITOR.md","docs/COPY_MODE.md","docs/CUSTOM_SHADERS.md","docs/DOCUMENTATION_STYLE_GUIDE.md","docs/FILE_TRANSFERS.md","docs/INTEGRATIONS.md","docs/KEYBOARD_SHORTCUTS.md","docs/LOGGING.md","docs/MOUSE_FEATURES.md","docs/PASTE_SPECIAL.md","docs/PREFERENCES_IMPORT_EXPORT.md","docs/PROFILES.md","docs/PROGRESS_BARS.md","docs/SCROLLBACK.md","docs/SEARCH.md","docs/SELF_UPDATE.md","docs/SEMANTIC_HISTORY.md","docs/SESSION_LOGGING.md","docs/SESSION_MANAGEMENT.md","docs/SHADERS.md","docs/SNIPPETS.md","docs/SSH.md","docs/STATUS_BAR.md","docs/TABS.md","docs/WINDOW_MANAGEMENT.md"]}]},{"name":"Plans","slug":"plans","files":[],"children":[{"name":"Plans — plans","slug":"plans-plans","files":["docs/plans/2026-02-04-shell-exit-action-design.md","docs/plans/2026-02-05-triggers-coprocesses-design.md","docs/plans/2026-02-05-triggers-coprocesses-plan.md","docs/plans/2026-02-13-macos-target-space-design.md","docs/plans/2026-02-13-new-tab-profile-selection-design.md","docs/plans/2026-02-13-new-tab-profile-selection-plan.md","docs/plans/2026-02-13-remote-shell-integration-design.md","docs/plans/2026-02-13-remote-shell-integration.md","docs/plans/2026-02-13-shell-selection-per-profile-design.md","docs/plans/2026-02-13-ssh-features-design.md","docs/plans/2026-02-13-ssh-features-plan.md","docs/plans/2026-02-13-status-bar-design.md","docs/plans/2026-02-13-status-bar-plan.md","docs/plans/2026-02-14-auto-tab-style-design.md","docs/plans/2026-02-14-auto-tab-style-plan.md","docs/plans/2026-02-14-configurable-link-handler.md","docs/plans/2026-02-14-dynamic-profiles-design.md","docs/plans/2026-02-14-dynamic-profiles-plan.md","docs/plans/2026-02-14-per-pane-background-design.md","docs/plans/2026-02-14-per-pane-background-impl.md","docs/plans/2026-02-14-scripting-manager-design.md","docs/plans/2026-02-14-scripting-manager.md","docs/plans/2026-02-15-ai-inspector-design.md","docs/plans/2026-02-15-ai-inspector-plan.md","docs/plans/2026-02-15-file-transfer-ui-design.md","docs/plans/2026-02-15-file-transfer-ui-plan.md","docs/plans/2026-02-15-file-transfer-utilities-design.md","docs/plans/2026-02-15-file-transfer-utilities-plan.md","docs/plans/2026-02-16-shader-acp-agent-design.md","docs/plans/2026-02-16-shader-acp-agent-plan.md","docs/plans/2026-02-19-hourly-update-check-design.md","docs/plans/2026-02-19-hourly-update-check-plan.md","docs/plans/2026-02-20-nerd-font-icons-design.md","docs/plans/2026-02-20-nerd-font-icons-plan.md","docs/plans/2026-02-20-tab-icon-context-menu-design.md","docs/plans/2026-02-20-tab-icon-context-menu-plan.md","docs/plans/2026-02-20-tab-naming-design.md","docs/plans/2026-02-20-tab-naming-plan.md"]}]},{"name":"Research","slug":"research","files":["docs/research/macos-space-apis-2026-02-13.md"]},{"name":"Examples","slug":"examples","files":["examples/README.md","examples/config-complete.yaml","examples/config-font-ranges.yaml","examples/config-styled-fonts.yaml","examples/config-text-shaping.yaml"]},{"name":"Shell Integration","slug":"shell-integration","files":["shell_integration/README.md","shell_integration/par_term_shell_integration.bash","shell_integration/par_term_shell_integration.fish","shell_integration/par_term_shell_integration.zsh","shell_integration/pt-dl","shell_integration/pt-imgcat","shell_integration/pt-ul"]},{"name":"AI Inspector","slug":"ai-inspector","files":[],"children":[{"name":"AI Inspector — ai_inspector","slug":"ai-inspector-ai-inspector","files":["src/ai_inspector/chat.rs","src/ai_inspector/mod.rs","src/ai_inspector/panel.rs","src/ai_inspector/shader_context.rs","src/ai_inspector/snapshot.rs"]}]},{"name":"Application","slug":"application","files":[],"children":[{"name":"Application — app","slug":"application-app","files":["src/app/anti_idle.rs","src/app/bell.rs","src/app/config_updates.rs","src/app/copy_mode_handler.rs","src/app/debug_state.rs","src/app/file_transfers.rs","src/app/handler.rs","src/app/input_events.rs","src/app/keyboard_handlers.rs","src/app/mod.rs","src/app/mouse.rs","src/app/mouse_events.rs","src/app/notifications.rs","src/app/render_cache.rs","src/app/renderer_init.rs","src/app/scroll_ops.rs","src/app/search_highlight.rs","src/app/tab_ops.rs","src/app/text_selection.rs","src/app/tmux_handler.rs","src/app/triggers.rs","src/app/url_hover.rs","src/app/window_manager.rs","src/app/window_state.rs"]}]},{"name":"Arrangements","slug":"arrangements","files":["src/arrangements/capture.rs","src/arrangements/mod.rs","src/arrangements/restore.rs","src/arrangements/storage.rs"]},{"name":"Profiles","slug":"profiles","files":["src/profile/dynamic.rs","src/profile/mod.rs","src/profile/storage.rs","src/profile_drawer_ui.rs","src/profile_modal_ui.rs"]},{"name":"Terminal","slug":"terminal","files":[],"children":[{"name":"Terminal — src","slug":"terminal-src","files":["src/terminal.rs","src/tab_bar_ui.rs","src/scrollback_metadata.rs","src/styled_content.rs"]},{"name":"Terminal — tab","slug":"terminal-tab","files":["src/tab/initial_text.rs","src/tab/manager.rs","src/tab/mod.rs"]}]},{"name":"Scripting","slug":"scripting","files":["src/scripting/mod.rs"]},{"name":"SSH","slug":"ssh","files":["src/ssh/config_parser.rs","src/ssh/discovery.rs","src/ssh/history.rs","src/ssh/known_hosts.rs","src/ssh/mdns.rs","src/ssh/mod.rs","src/ssh/types.rs","src/ssh_connect_ui.rs"]},{"name":"Status Bar","slug":"status-bar","files":["src/status_bar/config.rs","src/status_bar/mod.rs","src/status_bar/system_monitor.rs","src/status_bar/widgets.rs"]},{"name":"Rendering","slug":"rendering","files":[],"children":[{"name":"Rendering — src","slug":"rendering-src","files":["par-term-render/src/cell_renderer/atlas.rs","par-term-render/src/cell_renderer/background.rs","par-term-render/src/cell_renderer/block_chars.rs","par-term-render/src/cell_renderer/mod.rs","par-term-render/src/cell_renderer/pipeline.rs","par-term-render/src/cell_renderer/render.rs","par-term-render/src/cell_renderer/types.rs","par-term-render/src/custom_shader_renderer/cubemap.rs","par-term-render/src/custom_shader_renderer/cursor.rs","par-term-render/src/custom_shader_renderer/mod.rs","par-term-render/src/custom_shader_renderer/pipeline.rs","par-term-render/src/custom_shader_renderer/textures.rs","par-term-render/src/custom_shader_renderer/transpiler.rs","par-term-render/src/custom_shader_renderer/types.rs","par-term-render/src/gpu_utils.rs","par-term-render/src/graphics_renderer.rs","par-term-render/src/lib.rs","par-term-render/src/renderer/graphics.rs","par-term-render/src/renderer/mod.rs","par-term-render/src/renderer/shaders.rs","par-term-render/src/scrollbar.rs","par-term-render/src/shaders/background_image.wgsl","par-term-render/src/shaders/cell_bg.wgsl","par-term-render/src/shaders/cell_text.wgsl","par-term-render/src/shaders/scrollbar.wgsl","par-term-render/src/shaders/sixel.wgsl"]}]},{"name":"Fonts","slug":"fonts","files":["par-term-fonts/src/font_manager/fallbacks.rs","par-term-fonts/src/font_manager/loader.rs","par-term-fonts/src/font_manager/mod.rs","par-term-fonts/src/font_manager/types.rs","par-term-fonts/src/lib.rs","par-term-fonts/src/text_shaper.rs"]},{"name":"Input","slug":"input","files":["par-term-input/src/lib.rs"]},{"name":"Keybindings","slug":"keybindings","files":["par-term-keybindings/src/lib.rs","par-term-keybindings/src/matcher.rs","par-term-keybindings/src/parser.rs"]},{"name":"Update","slug":"update","files":["par-term-update/src/http.rs","par-term-update/src/lib.rs","par-term-update/src/manifest.rs","par-term-update/src/self_updater.rs","par-term-update/src/update_checker.rs"]},{"name":"Miscellaneous","slug":"miscellaneous","files":[],"children":[{"name":"Miscellaneous — src","slug":"miscellaneous-src","files":["src/audio_bell.rs","src/badge.rs","src/cell_renderer.rs","src/cli.rs","src/clipboard_history_ui.rs","src/close_confirmation_ui.rs","src/command_history.rs","src/command_history_ui.rs","src/copy_mode.rs","src/custom_shader_renderer.rs","src/debug.rs","src/font_manager.rs","src/font_metrics.rs","src/help_ui.rs","src/http.rs","src/input.rs","src/integrations_ui.rs","src/lib.rs","src/macos_blur.rs","src/macos_metal.rs","src/macos_space.rs","src/main.rs","src/manifest.rs","src/paste_special_ui.rs","src/paste_transform.rs","src/progress_bar.rs","src/quit_confirmation_ui.rs","src/remote_shell_install_ui.rs","src/renderer.rs","src/scroll_state.rs","src/scrollbar.rs","src/selection.rs","src/self_updater.rs","src/session_logger.rs","src/settings_window.rs","src/shader_install_ui.rs","src/shader_installer.rs","src/shader_watcher.rs","src/shell_detection.rs","src/shell_integration_installer.rs","src/shell_quote.rs","src/smart_selection.rs","src/update_checker.rs","src/update_dialog.rs","src/url_detection.rs"]},{"name":"Miscellaneous — config","slug":"miscellaneous-config","files":["src/config/mod.rs"]},{"name":"Miscellaneous — keybindings","slug":"miscellaneous-keybindings","files":["src/keybindings/mod.rs"]},{"name":"Miscellaneous — menu","slug":"miscellaneous-menu","files":["src/menu/actions.rs","src/menu/mod.rs"]},{"name":"Miscellaneous — pane","slug":"miscellaneous-pane","files":["src/pane/manager.rs","src/pane/mod.rs","src/pane/types.rs"]},{"name":"Miscellaneous — session","slug":"miscellaneous-session","files":["src/session/capture.rs","src/session/mod.rs","src/session/restore.rs","src/session/storage.rs"]},{"name":"Miscellaneous — snippets","slug":"miscellaneous-snippets","files":["src/snippets/mod.rs"]}]},{"name":"Other","slug":"other","files":[],"children":[{"name":"Other — Cargo.toml","slug":"other-cargo-toml","files":["Cargo.toml"]},{"name":"Other — Cross.toml","slug":"other-cross-toml","files":["Cross.toml"]},{"name":"Other — Makefile","slug":"other-makefile","files":["Makefile"]},{"name":"Other — build.rs","slug":"other-build-rs","files":["build.rs"]},{"name":"Other — gallery","slug":"other-gallery","files":["gh-pages/gallery/index.html"]},{"name":"Other — gh-pages","slug":"other-gh-pages","files":["gh-pages/index.html","gh-pages/install-shaders.sh","gh-pages/install-shell-integration.sh"]},{"name":"Other — Casks","slug":"other-casks","files":["homebrew/Casks/par-term.rb"]},{"name":"Other — ideas.md","slug":"other-ideas-md","files":["ideas.md"]},{"name":"Other — images","slug":"other-images","files":["images/snake.sixel","images/snake_tui.sixel"]},{"name":"Other — install_shaders.sh","slug":"other-install-shaders-sh","files":["install_shaders.sh"]},{"name":"Other — par-term-acp","slug":"other-par-term-acp","files":["par-term-acp/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-acp/src/agent.rs","par-term-acp/src/agents.rs","par-term-acp/src/fs_ops.rs","par-term-acp/src/jsonrpc.rs","par-term-acp/src/lib.rs","par-term-acp/src/protocol.rs"]},{"name":"Other — par-term-config","slug":"other-par-term-config","files":["par-term-config/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-config/src/automation.rs","par-term-config/src/cell.rs","par-term-config/src/config.rs","par-term-config/src/defaults.rs","par-term-config/src/lib.rs","par-term-config/src/profile.rs","par-term-config/src/profile_types.rs","par-term-config/src/scripting.rs","par-term-config/src/scrollback_mark.rs","par-term-config/src/shader_config.rs","par-term-config/src/shader_metadata.rs","par-term-config/src/snippets.rs","par-term-config/src/status_bar.rs","par-term-config/src/themes.rs","par-term-config/src/types.rs","par-term-config/src/watcher.rs"]},{"name":"Other — par-term-fonts","slug":"other-par-term-fonts","files":["par-term-fonts/Cargo.toml"]},{"name":"Other — tests","slug":"other-tests","files":["par-term-fonts/tests/font_tests.rs"]},{"name":"Other — par-term-input","slug":"other-par-term-input","files":["par-term-input/Cargo.toml"]},{"name":"Other — par-term-keybindings","slug":"other-par-term-keybindings","files":["par-term-keybindings/Cargo.toml"]},{"name":"Other — par-term-mcp","slug":"other-par-term-mcp","files":["par-term-mcp/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-mcp/src/lib.rs"]},{"name":"Other — par-term-render","slug":"other-par-term-render","files":["par-term-render/Cargo.toml"]},{"name":"Other — par-term-scripting","slug":"other-par-term-scripting","files":["par-term-scripting/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-scripting/src/lib.rs","par-term-scripting/src/manager.rs","par-term-scripting/src/observer.rs","par-term-scripting/src/process.rs","par-term-scripting/src/protocol.rs"]},{"name":"Other — par-term-settings-ui","slug":"other-par-term-settings-ui","files":["par-term-settings-ui/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-settings-ui/src/actions_tab.rs","par-term-settings-ui/src/advanced_tab.rs","par-term-settings-ui/src/ai_inspector_tab.rs","par-term-settings-ui/src/appearance_tab.rs","par-term-settings-ui/src/arrangements.rs","par-term-settings-ui/src/arrangements_tab.rs","par-term-settings-ui/src/automation_tab.rs","par-term-settings-ui/src/background_tab.rs","par-term-settings-ui/src/badge_tab.rs","par-term-settings-ui/src/cursor_shader_editor.rs","par-term-settings-ui/src/effects_tab.rs","par-term-settings-ui/src/input_tab.rs","par-term-settings-ui/src/integrations_tab.rs","par-term-settings-ui/src/lib.rs","par-term-settings-ui/src/nerd_font.rs","par-term-settings-ui/src/notifications_tab.rs","par-term-settings-ui/src/profile_modal_ui.rs","par-term-settings-ui/src/profiles_tab.rs","par-term-settings-ui/src/progress_bar_tab.rs","par-term-settings-ui/src/quick_settings.rs","par-term-settings-ui/src/scripts_tab.rs","par-term-settings-ui/src/section.rs","par-term-settings-ui/src/shader_dialogs.rs","par-term-settings-ui/src/shader_editor.rs","par-term-settings-ui/src/shader_utils.rs","par-term-settings-ui/src/shell_detection.rs","par-term-settings-ui/src/sidebar.rs","par-term-settings-ui/src/snippets_tab.rs","par-term-settings-ui/src/ssh_tab.rs","par-term-settings-ui/src/status_bar_tab.rs","par-term-settings-ui/src/terminal_tab.rs","par-term-settings-ui/src/traits.rs","par-term-settings-ui/src/window_tab.rs"]},{"name":"Other — par-term-ssh","slug":"other-par-term-ssh","files":["par-term-ssh/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-ssh/src/config_parser.rs","par-term-ssh/src/discovery.rs","par-term-ssh/src/history.rs","par-term-ssh/src/known_hosts.rs","par-term-ssh/src/lib.rs","par-term-ssh/src/mdns.rs","par-term-ssh/src/types.rs"]},{"name":"Other — par-term-terminal","slug":"other-par-term-terminal","files":["par-term-terminal/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-terminal/src/lib.rs","par-term-terminal/src/scrollback_metadata.rs","par-term-terminal/src/styled_content.rs","par-term-terminal/src/terminal/clipboard.rs","par-term-terminal/src/terminal/graphics.rs","par-term-terminal/src/terminal/hyperlinks.rs","par-term-terminal/src/terminal/mod.rs","par-term-terminal/src/terminal/rendering.rs","par-term-terminal/src/terminal/spawn.rs"]},{"name":"Other — par-term-tmux","slug":"other-par-term-tmux","files":["par-term-tmux/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-tmux/src/commands.rs","par-term-tmux/src/lib.rs","par-term-tmux/src/parser_bridge.rs","par-term-tmux/src/prefix.rs","par-term-tmux/src/session.rs","par-term-tmux/src/status_format.rs","par-term-tmux/src/sync.rs","par-term-tmux/src/types.rs"]},{"name":"Other — par-term-update","slug":"other-par-term-update","files":["par-term-update/Cargo.toml"]},{"name":"Other — par-term.terminfo","slug":"other-par-term-terminfo","files":["par-term.terminfo"]},{"name":"Other — run.log","slug":"other-run-log","files":["run.log"]},{"name":"Other — rust-toolchain.toml","slug":"other-rust-toolchain-toml","files":["rust-toolchain.toml"]},{"name":"Other — scripts","slug":"other-scripts","files":["scripts/README.md","scripts/benchmark_text_shaping.sh","scripts/generate_manifest.py","scripts/generate_shader_gallery.sh","scripts/install-windows.bat","scripts/simple_sixel.sh","scripts/test_bells.sh","scripts/test_coprocess.py","scripts/test_emoji.txt","scripts/test_fonts.sh","scripts/test_progress_bar.sh","scripts/test_script_observer.py","scripts/test_sixel.sh"]},{"name":"Other — examples","slug":"other-examples","files":["scripts/examples/hello_observer.py"]},{"name":"Other — shader_debug.md","slug":"other-shader-debug-md","files":["shader_debug.md"]},{"name":"Other — shaders","slug":"other-shaders","files":["shaders/animated-gradient-shader.glsl","shaders/arcane-portal.glsl","shaders/bloom.glsl","shaders/bumped_sinusoidal_warp.glsl","shaders/cineShader-Lava.glsl","shaders/clouds.glsl","shaders/convergence.glsl","shaders/crt.glsl","shaders/cubemap-skybox.glsl","shaders/cubemap-test.glsl","shaders/cubes.glsl","shaders/cursor_blaze.glsl","shaders/cursor_glow.glsl","shaders/cursor_orbit.glsl","shaders/cursor_pacman.glsl","shaders/cursor_rectangle_boom.glsl","shaders/cursor_ripple.glsl","shaders/cursor_ripple_rectangle.glsl","shaders/cursor_sonic_boom.glsl","shaders/cursor_sweep.glsl","shaders/cursor_trail.glsl","shaders/cursor_warp.glsl","shaders/cursor_water_tank.glsl","shaders/dither.glsl","shaders/dodecagon-pattern.glsl","shaders/drunkard.glsl","shaders/fireworks-rockets.glsl","shaders/fireworks.glsl","shaders/galaxy.glsl","shaders/gears-and-belts.glsl","shaders/glitchy.glsl","shaders/glow-rgbsplit-twitchy.glsl","shaders/gradient-background.glsl","shaders/gyroid.glsl","shaders/happy_fractal.glsl","shaders/inside-the-matrix.glsl","shaders/just-snow.glsl","shaders/keypress_pulse.glsl","shaders/manifest.json","shaders/rain-glass.glsl","shaders/rain.glsl","shaders/retro-terminal.glsl","shaders/sin-interference.glsl","shaders/singularity.glsl","shaders/sparks-from-fire.glsl","shaders/spotlight.glsl","shaders/starfield-colors.glsl","shaders/starfield.glsl","shaders/underwater.glsl","shaders/universe-within.glsl","shaders/water.glsl"]},{"name":"Other — textures","slug":"other-textures","files":["shaders/textures/wallpaper/README.md"]},{"name":"Other — src","slug":"other-src","files":["src/gpu_utils.rs","src/graphics_renderer.rs","src/text_shaper.rs","src/themes.rs","src/tmux_session_picker_ui.rs","src/tmux_status_bar_ui.rs"]},{"name":"Other — search","slug":"other-search","files":["src/search/engine.rs","src/search/mod.rs","src/search/types.rs"]},{"name":"Other — test_cr.rs","slug":"other-test-cr-rs","files":["test_cr.rs"]},{"name":"Other — test_grid.rs","slug":"other-test-grid-rs","files":["test_grid.rs"]},{"name":"Other — tests","slug":"other-tests","files":["tests/activity_notification_tests.rs","tests/automation_config_tests.rs","tests/block_chars_tests.rs","tests/config_tests.rs","tests/grapheme_rendering_tests.rs","tests/import_export_tests.rs","tests/input_tests.rs","tests/profile_ui_tests.rs","tests/script_integration_tests.rs","tests/script_manager_tests.rs","tests/script_observer_tests.rs","tests/script_process_tests.rs","tests/script_protocol_tests.rs","tests/scripting_config_tests.rs","tests/session_notification_tests.rs","tests/settings_window_tests.rs","tests/shader_context_tests.rs","tests/shader_watcher_tests.rs","tests/shell_env_tests.rs","tests/snippets_actions_tests.rs","tests/ssh_integration.rs","tests/status_bar_config_test.rs","tests/tab_bar_ui_tests.rs","tests/tab_color_tests.rs","tests/tab_stability_tests.rs","tests/terminal_tests.rs"]}]}]; | |
| var META = {"fromCommit":"99682d590dd355fb08363525b56a417846213acf","generatedAt":"2026-02-22T04:12:49.424Z","model":"gpt-4o-mini","moduleFiles":{"Agents":["agents/ampcode.com.toml","agents/augmentcode.com.toml","agents/claude.com.toml","agents/copilot.github.com.toml","agents/docker.com.toml","agents/geminicli.com.toml","agents/openai.com.toml","agents/openhands.dev.toml"],"Documentation":["AGENTS.md","CLAUDE.md","GEMINI.md","MATRIX.md","PANES.md","QUICK_START_FONTS.md","README.md","docs/ACCESSIBILITY.md","docs/ARCHITECTURE.md","docs/ARRANGEMENTS.md","docs/ASSISTANT_PANEL.md","docs/AUTOMATION.md","docs/BADGES.md","docs/COMMAND_HISTORY.md","docs/COMMAND_SEPARATORS.md","docs/COMPOSITOR.md","docs/COPY_MODE.md","docs/CUSTOM_SHADERS.md","docs/DOCUMENTATION_STYLE_GUIDE.md","docs/FILE_TRANSFERS.md","docs/INTEGRATIONS.md","docs/KEYBOARD_SHORTCUTS.md","docs/LOGGING.md","docs/MOUSE_FEATURES.md","docs/PASTE_SPECIAL.md","docs/PREFERENCES_IMPORT_EXPORT.md","docs/PROFILES.md","docs/PROGRESS_BARS.md","docs/SCROLLBACK.md","docs/SEARCH.md","docs/SELF_UPDATE.md","docs/SEMANTIC_HISTORY.md","docs/SESSION_LOGGING.md","docs/SESSION_MANAGEMENT.md","docs/SHADERS.md","docs/SNIPPETS.md","docs/SSH.md","docs/STATUS_BAR.md","docs/TABS.md","docs/WINDOW_MANAGEMENT.md"],"Documentation — AGENTS.md":["AGENTS.md"],"Documentation — CLAUDE.md":["CLAUDE.md"],"Documentation — GEMINI.md":["GEMINI.md"],"Documentation — MATRIX.md":["MATRIX.md"],"Documentation — PANES.md":["PANES.md"],"Documentation — QUICK_START_FONTS.md":["QUICK_START_FONTS.md"],"Documentation — README.md":["README.md"],"Documentation — docs":["docs/ACCESSIBILITY.md","docs/ARCHITECTURE.md","docs/ARRANGEMENTS.md","docs/ASSISTANT_PANEL.md","docs/AUTOMATION.md","docs/BADGES.md","docs/COMMAND_HISTORY.md","docs/COMMAND_SEPARATORS.md","docs/COMPOSITOR.md","docs/COPY_MODE.md","docs/CUSTOM_SHADERS.md","docs/DOCUMENTATION_STYLE_GUIDE.md","docs/FILE_TRANSFERS.md","docs/INTEGRATIONS.md","docs/KEYBOARD_SHORTCUTS.md","docs/LOGGING.md","docs/MOUSE_FEATURES.md","docs/PASTE_SPECIAL.md","docs/PREFERENCES_IMPORT_EXPORT.md","docs/PROFILES.md","docs/PROGRESS_BARS.md","docs/SCROLLBACK.md","docs/SEARCH.md","docs/SELF_UPDATE.md","docs/SEMANTIC_HISTORY.md","docs/SESSION_LOGGING.md","docs/SESSION_MANAGEMENT.md","docs/SHADERS.md","docs/SNIPPETS.md","docs/SSH.md","docs/STATUS_BAR.md","docs/TABS.md","docs/WINDOW_MANAGEMENT.md"],"Plans":["docs/plans/2026-02-04-shell-exit-action-design.md","docs/plans/2026-02-05-triggers-coprocesses-design.md","docs/plans/2026-02-05-triggers-coprocesses-plan.md","docs/plans/2026-02-13-macos-target-space-design.md","docs/plans/2026-02-13-new-tab-profile-selection-design.md","docs/plans/2026-02-13-new-tab-profile-selection-plan.md","docs/plans/2026-02-13-remote-shell-integration-design.md","docs/plans/2026-02-13-remote-shell-integration.md","docs/plans/2026-02-13-shell-selection-per-profile-design.md","docs/plans/2026-02-13-ssh-features-design.md","docs/plans/2026-02-13-ssh-features-plan.md","docs/plans/2026-02-13-status-bar-design.md","docs/plans/2026-02-13-status-bar-plan.md","docs/plans/2026-02-14-auto-tab-style-design.md","docs/plans/2026-02-14-auto-tab-style-plan.md","docs/plans/2026-02-14-configurable-link-handler.md","docs/plans/2026-02-14-dynamic-profiles-design.md","docs/plans/2026-02-14-dynamic-profiles-plan.md","docs/plans/2026-02-14-per-pane-background-design.md","docs/plans/2026-02-14-per-pane-background-impl.md","docs/plans/2026-02-14-scripting-manager-design.md","docs/plans/2026-02-14-scripting-manager.md","docs/plans/2026-02-15-ai-inspector-design.md","docs/plans/2026-02-15-ai-inspector-plan.md","docs/plans/2026-02-15-file-transfer-ui-design.md","docs/plans/2026-02-15-file-transfer-ui-plan.md","docs/plans/2026-02-15-file-transfer-utilities-design.md","docs/plans/2026-02-15-file-transfer-utilities-plan.md","docs/plans/2026-02-16-shader-acp-agent-design.md","docs/plans/2026-02-16-shader-acp-agent-plan.md","docs/plans/2026-02-19-hourly-update-check-design.md","docs/plans/2026-02-19-hourly-update-check-plan.md","docs/plans/2026-02-20-nerd-font-icons-design.md","docs/plans/2026-02-20-nerd-font-icons-plan.md","docs/plans/2026-02-20-tab-icon-context-menu-design.md","docs/plans/2026-02-20-tab-icon-context-menu-plan.md","docs/plans/2026-02-20-tab-naming-design.md","docs/plans/2026-02-20-tab-naming-plan.md"],"Plans — plans":["docs/plans/2026-02-04-shell-exit-action-design.md","docs/plans/2026-02-05-triggers-coprocesses-design.md","docs/plans/2026-02-05-triggers-coprocesses-plan.md","docs/plans/2026-02-13-macos-target-space-design.md","docs/plans/2026-02-13-new-tab-profile-selection-design.md","docs/plans/2026-02-13-new-tab-profile-selection-plan.md","docs/plans/2026-02-13-remote-shell-integration-design.md","docs/plans/2026-02-13-remote-shell-integration.md","docs/plans/2026-02-13-shell-selection-per-profile-design.md","docs/plans/2026-02-13-ssh-features-design.md","docs/plans/2026-02-13-ssh-features-plan.md","docs/plans/2026-02-13-status-bar-design.md","docs/plans/2026-02-13-status-bar-plan.md","docs/plans/2026-02-14-auto-tab-style-design.md","docs/plans/2026-02-14-auto-tab-style-plan.md","docs/plans/2026-02-14-configurable-link-handler.md","docs/plans/2026-02-14-dynamic-profiles-design.md","docs/plans/2026-02-14-dynamic-profiles-plan.md","docs/plans/2026-02-14-per-pane-background-design.md","docs/plans/2026-02-14-per-pane-background-impl.md","docs/plans/2026-02-14-scripting-manager-design.md","docs/plans/2026-02-14-scripting-manager.md","docs/plans/2026-02-15-ai-inspector-design.md","docs/plans/2026-02-15-ai-inspector-plan.md","docs/plans/2026-02-15-file-transfer-ui-design.md","docs/plans/2026-02-15-file-transfer-ui-plan.md","docs/plans/2026-02-15-file-transfer-utilities-design.md","docs/plans/2026-02-15-file-transfer-utilities-plan.md","docs/plans/2026-02-16-shader-acp-agent-design.md","docs/plans/2026-02-16-shader-acp-agent-plan.md","docs/plans/2026-02-19-hourly-update-check-design.md","docs/plans/2026-02-19-hourly-update-check-plan.md","docs/plans/2026-02-20-nerd-font-icons-design.md","docs/plans/2026-02-20-nerd-font-icons-plan.md","docs/plans/2026-02-20-tab-icon-context-menu-design.md","docs/plans/2026-02-20-tab-icon-context-menu-plan.md","docs/plans/2026-02-20-tab-naming-design.md","docs/plans/2026-02-20-tab-naming-plan.md"],"Research":["docs/research/macos-space-apis-2026-02-13.md"],"Examples":["examples/README.md","examples/config-complete.yaml","examples/config-font-ranges.yaml","examples/config-styled-fonts.yaml","examples/config-text-shaping.yaml"],"Shell Integration":["shell_integration/README.md","shell_integration/par_term_shell_integration.bash","shell_integration/par_term_shell_integration.fish","shell_integration/par_term_shell_integration.zsh","shell_integration/pt-dl","shell_integration/pt-imgcat","shell_integration/pt-ul"],"AI Inspector":["src/ai_inspector/chat.rs","src/ai_inspector/mod.rs","src/ai_inspector/panel.rs","src/ai_inspector/shader_context.rs","src/ai_inspector/snapshot.rs"],"AI Inspector — ai_inspector":["src/ai_inspector/chat.rs","src/ai_inspector/mod.rs","src/ai_inspector/panel.rs","src/ai_inspector/shader_context.rs","src/ai_inspector/snapshot.rs"],"Application":["src/app/anti_idle.rs","src/app/bell.rs","src/app/config_updates.rs","src/app/copy_mode_handler.rs","src/app/debug_state.rs","src/app/file_transfers.rs","src/app/handler.rs","src/app/input_events.rs","src/app/keyboard_handlers.rs","src/app/mod.rs","src/app/mouse.rs","src/app/mouse_events.rs","src/app/notifications.rs","src/app/render_cache.rs","src/app/renderer_init.rs","src/app/scroll_ops.rs","src/app/search_highlight.rs","src/app/tab_ops.rs","src/app/text_selection.rs","src/app/tmux_handler.rs","src/app/triggers.rs","src/app/url_hover.rs","src/app/window_manager.rs","src/app/window_state.rs"],"Application — app":["src/app/anti_idle.rs","src/app/bell.rs","src/app/config_updates.rs","src/app/copy_mode_handler.rs","src/app/debug_state.rs","src/app/file_transfers.rs","src/app/handler.rs","src/app/input_events.rs","src/app/keyboard_handlers.rs","src/app/mod.rs","src/app/mouse.rs","src/app/mouse_events.rs","src/app/notifications.rs","src/app/render_cache.rs","src/app/renderer_init.rs","src/app/scroll_ops.rs","src/app/search_highlight.rs","src/app/tab_ops.rs","src/app/text_selection.rs","src/app/tmux_handler.rs","src/app/triggers.rs","src/app/url_hover.rs","src/app/window_manager.rs","src/app/window_state.rs"],"Arrangements":["src/arrangements/capture.rs","src/arrangements/mod.rs","src/arrangements/restore.rs","src/arrangements/storage.rs"],"Profiles":["src/profile/dynamic.rs","src/profile/mod.rs","src/profile/storage.rs","src/profile_drawer_ui.rs","src/profile_modal_ui.rs"],"Terminal":["src/terminal.rs","src/tab_bar_ui.rs","src/scrollback_metadata.rs","src/styled_content.rs","src/tab/initial_text.rs","src/tab/manager.rs","src/tab/mod.rs"],"Terminal — src":["src/terminal.rs","src/tab_bar_ui.rs","src/scrollback_metadata.rs","src/styled_content.rs"],"Terminal — tab":["src/tab/initial_text.rs","src/tab/manager.rs","src/tab/mod.rs"],"Scripting":["src/scripting/mod.rs"],"SSH":["src/ssh/config_parser.rs","src/ssh/discovery.rs","src/ssh/history.rs","src/ssh/known_hosts.rs","src/ssh/mdns.rs","src/ssh/mod.rs","src/ssh/types.rs","src/ssh_connect_ui.rs"],"Status Bar":["src/status_bar/config.rs","src/status_bar/mod.rs","src/status_bar/system_monitor.rs","src/status_bar/widgets.rs"],"Rendering":["par-term-render/src/cell_renderer/atlas.rs","par-term-render/src/cell_renderer/background.rs","par-term-render/src/cell_renderer/block_chars.rs","par-term-render/src/cell_renderer/mod.rs","par-term-render/src/cell_renderer/pipeline.rs","par-term-render/src/cell_renderer/render.rs","par-term-render/src/cell_renderer/types.rs","par-term-render/src/custom_shader_renderer/cubemap.rs","par-term-render/src/custom_shader_renderer/cursor.rs","par-term-render/src/custom_shader_renderer/mod.rs","par-term-render/src/custom_shader_renderer/pipeline.rs","par-term-render/src/custom_shader_renderer/textures.rs","par-term-render/src/custom_shader_renderer/transpiler.rs","par-term-render/src/custom_shader_renderer/types.rs","par-term-render/src/gpu_utils.rs","par-term-render/src/graphics_renderer.rs","par-term-render/src/lib.rs","par-term-render/src/renderer/graphics.rs","par-term-render/src/renderer/mod.rs","par-term-render/src/renderer/shaders.rs","par-term-render/src/scrollbar.rs","par-term-render/src/shaders/background_image.wgsl","par-term-render/src/shaders/cell_bg.wgsl","par-term-render/src/shaders/cell_text.wgsl","par-term-render/src/shaders/scrollbar.wgsl","par-term-render/src/shaders/sixel.wgsl"],"Rendering — src":["par-term-render/src/cell_renderer/atlas.rs","par-term-render/src/cell_renderer/background.rs","par-term-render/src/cell_renderer/block_chars.rs","par-term-render/src/cell_renderer/mod.rs","par-term-render/src/cell_renderer/pipeline.rs","par-term-render/src/cell_renderer/render.rs","par-term-render/src/cell_renderer/types.rs","par-term-render/src/custom_shader_renderer/cubemap.rs","par-term-render/src/custom_shader_renderer/cursor.rs","par-term-render/src/custom_shader_renderer/mod.rs","par-term-render/src/custom_shader_renderer/pipeline.rs","par-term-render/src/custom_shader_renderer/textures.rs","par-term-render/src/custom_shader_renderer/transpiler.rs","par-term-render/src/custom_shader_renderer/types.rs","par-term-render/src/gpu_utils.rs","par-term-render/src/graphics_renderer.rs","par-term-render/src/lib.rs","par-term-render/src/renderer/graphics.rs","par-term-render/src/renderer/mod.rs","par-term-render/src/renderer/shaders.rs","par-term-render/src/scrollbar.rs","par-term-render/src/shaders/background_image.wgsl","par-term-render/src/shaders/cell_bg.wgsl","par-term-render/src/shaders/cell_text.wgsl","par-term-render/src/shaders/scrollbar.wgsl","par-term-render/src/shaders/sixel.wgsl"],"Fonts":["par-term-fonts/src/font_manager/fallbacks.rs","par-term-fonts/src/font_manager/loader.rs","par-term-fonts/src/font_manager/mod.rs","par-term-fonts/src/font_manager/types.rs","par-term-fonts/src/lib.rs","par-term-fonts/src/text_shaper.rs"],"Input":["par-term-input/src/lib.rs"],"Keybindings":["par-term-keybindings/src/lib.rs","par-term-keybindings/src/matcher.rs","par-term-keybindings/src/parser.rs"],"Update":["par-term-update/src/http.rs","par-term-update/src/lib.rs","par-term-update/src/manifest.rs","par-term-update/src/self_updater.rs","par-term-update/src/update_checker.rs"],"Miscellaneous":["src/audio_bell.rs","src/badge.rs","src/cell_renderer.rs","src/cli.rs","src/clipboard_history_ui.rs","src/close_confirmation_ui.rs","src/command_history.rs","src/command_history_ui.rs","src/copy_mode.rs","src/custom_shader_renderer.rs","src/debug.rs","src/font_manager.rs","src/font_metrics.rs","src/help_ui.rs","src/http.rs","src/input.rs","src/integrations_ui.rs","src/lib.rs","src/macos_blur.rs","src/macos_metal.rs","src/macos_space.rs","src/main.rs","src/manifest.rs","src/paste_special_ui.rs","src/paste_transform.rs","src/progress_bar.rs","src/quit_confirmation_ui.rs","src/remote_shell_install_ui.rs","src/renderer.rs","src/scroll_state.rs","src/scrollbar.rs","src/selection.rs","src/self_updater.rs","src/session_logger.rs","src/settings_window.rs","src/shader_install_ui.rs","src/shader_installer.rs","src/shader_watcher.rs","src/shell_detection.rs","src/shell_integration_installer.rs","src/shell_quote.rs","src/smart_selection.rs","src/update_checker.rs","src/update_dialog.rs","src/url_detection.rs","src/config/mod.rs","src/keybindings/mod.rs","src/menu/actions.rs","src/menu/mod.rs","src/pane/manager.rs","src/pane/mod.rs","src/pane/types.rs","src/session/capture.rs","src/session/mod.rs","src/session/restore.rs","src/session/storage.rs","src/snippets/mod.rs"],"Miscellaneous — src":["src/audio_bell.rs","src/badge.rs","src/cell_renderer.rs","src/cli.rs","src/clipboard_history_ui.rs","src/close_confirmation_ui.rs","src/command_history.rs","src/command_history_ui.rs","src/copy_mode.rs","src/custom_shader_renderer.rs","src/debug.rs","src/font_manager.rs","src/font_metrics.rs","src/help_ui.rs","src/http.rs","src/input.rs","src/integrations_ui.rs","src/lib.rs","src/macos_blur.rs","src/macos_metal.rs","src/macos_space.rs","src/main.rs","src/manifest.rs","src/paste_special_ui.rs","src/paste_transform.rs","src/progress_bar.rs","src/quit_confirmation_ui.rs","src/remote_shell_install_ui.rs","src/renderer.rs","src/scroll_state.rs","src/scrollbar.rs","src/selection.rs","src/self_updater.rs","src/session_logger.rs","src/settings_window.rs","src/shader_install_ui.rs","src/shader_installer.rs","src/shader_watcher.rs","src/shell_detection.rs","src/shell_integration_installer.rs","src/shell_quote.rs","src/smart_selection.rs","src/update_checker.rs","src/update_dialog.rs","src/url_detection.rs"],"Miscellaneous — config":["src/config/mod.rs"],"Miscellaneous — keybindings":["src/keybindings/mod.rs"],"Miscellaneous — menu":["src/menu/actions.rs","src/menu/mod.rs"],"Miscellaneous — pane":["src/pane/manager.rs","src/pane/mod.rs","src/pane/types.rs"],"Miscellaneous — session":["src/session/capture.rs","src/session/mod.rs","src/session/restore.rs","src/session/storage.rs"],"Miscellaneous — snippets":["src/snippets/mod.rs"],"Other":["Cargo.toml","Cross.toml","Makefile","build.rs","gh-pages/gallery/index.html","gh-pages/index.html","gh-pages/install-shaders.sh","gh-pages/install-shell-integration.sh","homebrew/Casks/par-term.rb","ideas.md","images/snake.sixel","images/snake_tui.sixel","install_shaders.sh","par-term-acp/Cargo.toml","par-term-acp/src/agent.rs","par-term-acp/src/agents.rs","par-term-acp/src/fs_ops.rs","par-term-acp/src/jsonrpc.rs","par-term-acp/src/lib.rs","par-term-acp/src/protocol.rs","par-term-config/Cargo.toml","par-term-config/src/automation.rs","par-term-config/src/cell.rs","par-term-config/src/config.rs","par-term-config/src/defaults.rs","par-term-config/src/lib.rs","par-term-config/src/profile.rs","par-term-config/src/profile_types.rs","par-term-config/src/scripting.rs","par-term-config/src/scrollback_mark.rs","par-term-config/src/shader_config.rs","par-term-config/src/shader_metadata.rs","par-term-config/src/snippets.rs","par-term-config/src/status_bar.rs","par-term-config/src/themes.rs","par-term-config/src/types.rs","par-term-config/src/watcher.rs","par-term-fonts/Cargo.toml","par-term-fonts/tests/font_tests.rs","par-term-input/Cargo.toml","par-term-keybindings/Cargo.toml","par-term-mcp/Cargo.toml","par-term-mcp/src/lib.rs","par-term-render/Cargo.toml","par-term-scripting/Cargo.toml","par-term-scripting/src/lib.rs","par-term-scripting/src/manager.rs","par-term-scripting/src/observer.rs","par-term-scripting/src/process.rs","par-term-scripting/src/protocol.rs","par-term-settings-ui/Cargo.toml","par-term-settings-ui/src/actions_tab.rs","par-term-settings-ui/src/advanced_tab.rs","par-term-settings-ui/src/ai_inspector_tab.rs","par-term-settings-ui/src/appearance_tab.rs","par-term-settings-ui/src/arrangements.rs","par-term-settings-ui/src/arrangements_tab.rs","par-term-settings-ui/src/automation_tab.rs","par-term-settings-ui/src/background_tab.rs","par-term-settings-ui/src/badge_tab.rs","par-term-settings-ui/src/cursor_shader_editor.rs","par-term-settings-ui/src/effects_tab.rs","par-term-settings-ui/src/input_tab.rs","par-term-settings-ui/src/integrations_tab.rs","par-term-settings-ui/src/lib.rs","par-term-settings-ui/src/nerd_font.rs","par-term-settings-ui/src/notifications_tab.rs","par-term-settings-ui/src/profile_modal_ui.rs","par-term-settings-ui/src/profiles_tab.rs","par-term-settings-ui/src/progress_bar_tab.rs","par-term-settings-ui/src/quick_settings.rs","par-term-settings-ui/src/scripts_tab.rs","par-term-settings-ui/src/section.rs","par-term-settings-ui/src/shader_dialogs.rs","par-term-settings-ui/src/shader_editor.rs","par-term-settings-ui/src/shader_utils.rs","par-term-settings-ui/src/shell_detection.rs","par-term-settings-ui/src/sidebar.rs","par-term-settings-ui/src/snippets_tab.rs","par-term-settings-ui/src/ssh_tab.rs","par-term-settings-ui/src/status_bar_tab.rs","par-term-settings-ui/src/terminal_tab.rs","par-term-settings-ui/src/traits.rs","par-term-settings-ui/src/window_tab.rs","par-term-ssh/Cargo.toml","par-term-ssh/src/config_parser.rs","par-term-ssh/src/discovery.rs","par-term-ssh/src/history.rs","par-term-ssh/src/known_hosts.rs","par-term-ssh/src/lib.rs","par-term-ssh/src/mdns.rs","par-term-ssh/src/types.rs","par-term-terminal/Cargo.toml","par-term-terminal/src/lib.rs","par-term-terminal/src/scrollback_metadata.rs","par-term-terminal/src/styled_content.rs","par-term-terminal/src/terminal/clipboard.rs","par-term-terminal/src/terminal/graphics.rs","par-term-terminal/src/terminal/hyperlinks.rs","par-term-terminal/src/terminal/mod.rs","par-term-terminal/src/terminal/rendering.rs","par-term-terminal/src/terminal/spawn.rs","par-term-tmux/Cargo.toml","par-term-tmux/src/commands.rs","par-term-tmux/src/lib.rs","par-term-tmux/src/parser_bridge.rs","par-term-tmux/src/prefix.rs","par-term-tmux/src/session.rs","par-term-tmux/src/status_format.rs","par-term-tmux/src/sync.rs","par-term-tmux/src/types.rs","par-term-update/Cargo.toml","par-term.terminfo","run.log","rust-toolchain.toml","scripts/README.md","scripts/benchmark_text_shaping.sh","scripts/generate_manifest.py","scripts/generate_shader_gallery.sh","scripts/install-windows.bat","scripts/simple_sixel.sh","scripts/test_bells.sh","scripts/test_coprocess.py","scripts/test_emoji.txt","scripts/test_fonts.sh","scripts/test_progress_bar.sh","scripts/test_script_observer.py","scripts/test_sixel.sh","scripts/examples/hello_observer.py","shader_debug.md","shaders/animated-gradient-shader.glsl","shaders/arcane-portal.glsl","shaders/bloom.glsl","shaders/bumped_sinusoidal_warp.glsl","shaders/cineShader-Lava.glsl","shaders/clouds.glsl","shaders/convergence.glsl","shaders/crt.glsl","shaders/cubemap-skybox.glsl","shaders/cubemap-test.glsl","shaders/cubes.glsl","shaders/cursor_blaze.glsl","shaders/cursor_glow.glsl","shaders/cursor_orbit.glsl","shaders/cursor_pacman.glsl","shaders/cursor_rectangle_boom.glsl","shaders/cursor_ripple.glsl","shaders/cursor_ripple_rectangle.glsl","shaders/cursor_sonic_boom.glsl","shaders/cursor_sweep.glsl","shaders/cursor_trail.glsl","shaders/cursor_warp.glsl","shaders/cursor_water_tank.glsl","shaders/dither.glsl","shaders/dodecagon-pattern.glsl","shaders/drunkard.glsl","shaders/fireworks-rockets.glsl","shaders/fireworks.glsl","shaders/galaxy.glsl","shaders/gears-and-belts.glsl","shaders/glitchy.glsl","shaders/glow-rgbsplit-twitchy.glsl","shaders/gradient-background.glsl","shaders/gyroid.glsl","shaders/happy_fractal.glsl","shaders/inside-the-matrix.glsl","shaders/just-snow.glsl","shaders/keypress_pulse.glsl","shaders/manifest.json","shaders/rain-glass.glsl","shaders/rain.glsl","shaders/retro-terminal.glsl","shaders/sin-interference.glsl","shaders/singularity.glsl","shaders/sparks-from-fire.glsl","shaders/spotlight.glsl","shaders/starfield-colors.glsl","shaders/starfield.glsl","shaders/underwater.glsl","shaders/universe-within.glsl","shaders/water.glsl","shaders/textures/wallpaper/README.md","src/gpu_utils.rs","src/graphics_renderer.rs","src/text_shaper.rs","src/themes.rs","src/tmux_session_picker_ui.rs","src/tmux_status_bar_ui.rs","src/search/engine.rs","src/search/mod.rs","src/search/types.rs","test_cr.rs","test_grid.rs","tests/activity_notification_tests.rs","tests/automation_config_tests.rs","tests/block_chars_tests.rs","tests/config_tests.rs","tests/grapheme_rendering_tests.rs","tests/import_export_tests.rs","tests/input_tests.rs","tests/profile_ui_tests.rs","tests/script_integration_tests.rs","tests/script_manager_tests.rs","tests/script_observer_tests.rs","tests/script_process_tests.rs","tests/script_protocol_tests.rs","tests/scripting_config_tests.rs","tests/session_notification_tests.rs","tests/settings_window_tests.rs","tests/shader_context_tests.rs","tests/shader_watcher_tests.rs","tests/shell_env_tests.rs","tests/snippets_actions_tests.rs","tests/ssh_integration.rs","tests/status_bar_config_test.rs","tests/tab_bar_ui_tests.rs","tests/tab_color_tests.rs","tests/tab_stability_tests.rs","tests/terminal_tests.rs"],"Other — Cargo.toml":["Cargo.toml"],"Other — Cross.toml":["Cross.toml"],"Other — Makefile":["Makefile"],"Other — build.rs":["build.rs"],"Other — gallery":["gh-pages/gallery/index.html"],"Other — gh-pages":["gh-pages/index.html","gh-pages/install-shaders.sh","gh-pages/install-shell-integration.sh"],"Other — Casks":["homebrew/Casks/par-term.rb"],"Other — ideas.md":["ideas.md"],"Other — images":["images/snake.sixel","images/snake_tui.sixel"],"Other — install_shaders.sh":["install_shaders.sh"],"Other — par-term-acp":["par-term-acp/Cargo.toml"],"Other — src":["src/gpu_utils.rs","src/graphics_renderer.rs","src/text_shaper.rs","src/themes.rs","src/tmux_session_picker_ui.rs","src/tmux_status_bar_ui.rs"],"Other — par-term-config":["par-term-config/Cargo.toml"],"Other — par-term-fonts":["par-term-fonts/Cargo.toml"],"Other — tests":["tests/activity_notification_tests.rs","tests/automation_config_tests.rs","tests/block_chars_tests.rs","tests/config_tests.rs","tests/grapheme_rendering_tests.rs","tests/import_export_tests.rs","tests/input_tests.rs","tests/profile_ui_tests.rs","tests/script_integration_tests.rs","tests/script_manager_tests.rs","tests/script_observer_tests.rs","tests/script_process_tests.rs","tests/script_protocol_tests.rs","tests/scripting_config_tests.rs","tests/session_notification_tests.rs","tests/settings_window_tests.rs","tests/shader_context_tests.rs","tests/shader_watcher_tests.rs","tests/shell_env_tests.rs","tests/snippets_actions_tests.rs","tests/ssh_integration.rs","tests/status_bar_config_test.rs","tests/tab_bar_ui_tests.rs","tests/tab_color_tests.rs","tests/tab_stability_tests.rs","tests/terminal_tests.rs"],"Other — par-term-input":["par-term-input/Cargo.toml"],"Other — par-term-keybindings":["par-term-keybindings/Cargo.toml"],"Other — par-term-mcp":["par-term-mcp/Cargo.toml"],"Other — par-term-render":["par-term-render/Cargo.toml"],"Other — par-term-scripting":["par-term-scripting/Cargo.toml"],"Other — par-term-settings-ui":["par-term-settings-ui/Cargo.toml"],"Other — par-term-ssh":["par-term-ssh/Cargo.toml"],"Other — par-term-terminal":["par-term-terminal/Cargo.toml"],"Other — par-term-tmux":["par-term-tmux/Cargo.toml"],"Other — par-term-update":["par-term-update/Cargo.toml"],"Other — par-term.terminfo":["par-term.terminfo"],"Other — run.log":["run.log"],"Other — rust-toolchain.toml":["rust-toolchain.toml"],"Other — scripts":["scripts/README.md","scripts/benchmark_text_shaping.sh","scripts/generate_manifest.py","scripts/generate_shader_gallery.sh","scripts/install-windows.bat","scripts/simple_sixel.sh","scripts/test_bells.sh","scripts/test_coprocess.py","scripts/test_emoji.txt","scripts/test_fonts.sh","scripts/test_progress_bar.sh","scripts/test_script_observer.py","scripts/test_sixel.sh"],"Other — examples":["scripts/examples/hello_observer.py"],"Other — shader_debug.md":["shader_debug.md"],"Other — shaders":["shaders/animated-gradient-shader.glsl","shaders/arcane-portal.glsl","shaders/bloom.glsl","shaders/bumped_sinusoidal_warp.glsl","shaders/cineShader-Lava.glsl","shaders/clouds.glsl","shaders/convergence.glsl","shaders/crt.glsl","shaders/cubemap-skybox.glsl","shaders/cubemap-test.glsl","shaders/cubes.glsl","shaders/cursor_blaze.glsl","shaders/cursor_glow.glsl","shaders/cursor_orbit.glsl","shaders/cursor_pacman.glsl","shaders/cursor_rectangle_boom.glsl","shaders/cursor_ripple.glsl","shaders/cursor_ripple_rectangle.glsl","shaders/cursor_sonic_boom.glsl","shaders/cursor_sweep.glsl","shaders/cursor_trail.glsl","shaders/cursor_warp.glsl","shaders/cursor_water_tank.glsl","shaders/dither.glsl","shaders/dodecagon-pattern.glsl","shaders/drunkard.glsl","shaders/fireworks-rockets.glsl","shaders/fireworks.glsl","shaders/galaxy.glsl","shaders/gears-and-belts.glsl","shaders/glitchy.glsl","shaders/glow-rgbsplit-twitchy.glsl","shaders/gradient-background.glsl","shaders/gyroid.glsl","shaders/happy_fractal.glsl","shaders/inside-the-matrix.glsl","shaders/just-snow.glsl","shaders/keypress_pulse.glsl","shaders/manifest.json","shaders/rain-glass.glsl","shaders/rain.glsl","shaders/retro-terminal.glsl","shaders/sin-interference.glsl","shaders/singularity.glsl","shaders/sparks-from-fire.glsl","shaders/spotlight.glsl","shaders/starfield-colors.glsl","shaders/starfield.glsl","shaders/underwater.glsl","shaders/universe-within.glsl","shaders/water.glsl"],"Other — textures":["shaders/textures/wallpaper/README.md"],"Other — search":["src/search/engine.rs","src/search/mod.rs","src/search/types.rs"],"Other — test_cr.rs":["test_cr.rs"],"Other — test_grid.rs":["test_grid.rs"]},"moduleTree":[{"name":"Agents","slug":"agents","files":["agents/ampcode.com.toml","agents/augmentcode.com.toml","agents/claude.com.toml","agents/copilot.github.com.toml","agents/docker.com.toml","agents/geminicli.com.toml","agents/openai.com.toml","agents/openhands.dev.toml"]},{"name":"Documentation","slug":"documentation","files":[],"children":[{"name":"Documentation — AGENTS.md","slug":"documentation-agents-md","files":["AGENTS.md"]},{"name":"Documentation — CLAUDE.md","slug":"documentation-claude-md","files":["CLAUDE.md"]},{"name":"Documentation — GEMINI.md","slug":"documentation-gemini-md","files":["GEMINI.md"]},{"name":"Documentation — MATRIX.md","slug":"documentation-matrix-md","files":["MATRIX.md"]},{"name":"Documentation — PANES.md","slug":"documentation-panes-md","files":["PANES.md"]},{"name":"Documentation — QUICK_START_FONTS.md","slug":"documentation-quick-start-fonts-md","files":["QUICK_START_FONTS.md"]},{"name":"Documentation — README.md","slug":"documentation-readme-md","files":["README.md"]},{"name":"Documentation — docs","slug":"documentation-docs","files":["docs/ACCESSIBILITY.md","docs/ARCHITECTURE.md","docs/ARRANGEMENTS.md","docs/ASSISTANT_PANEL.md","docs/AUTOMATION.md","docs/BADGES.md","docs/COMMAND_HISTORY.md","docs/COMMAND_SEPARATORS.md","docs/COMPOSITOR.md","docs/COPY_MODE.md","docs/CUSTOM_SHADERS.md","docs/DOCUMENTATION_STYLE_GUIDE.md","docs/FILE_TRANSFERS.md","docs/INTEGRATIONS.md","docs/KEYBOARD_SHORTCUTS.md","docs/LOGGING.md","docs/MOUSE_FEATURES.md","docs/PASTE_SPECIAL.md","docs/PREFERENCES_IMPORT_EXPORT.md","docs/PROFILES.md","docs/PROGRESS_BARS.md","docs/SCROLLBACK.md","docs/SEARCH.md","docs/SELF_UPDATE.md","docs/SEMANTIC_HISTORY.md","docs/SESSION_LOGGING.md","docs/SESSION_MANAGEMENT.md","docs/SHADERS.md","docs/SNIPPETS.md","docs/SSH.md","docs/STATUS_BAR.md","docs/TABS.md","docs/WINDOW_MANAGEMENT.md"]}]},{"name":"Plans","slug":"plans","files":[],"children":[{"name":"Plans — plans","slug":"plans-plans","files":["docs/plans/2026-02-04-shell-exit-action-design.md","docs/plans/2026-02-05-triggers-coprocesses-design.md","docs/plans/2026-02-05-triggers-coprocesses-plan.md","docs/plans/2026-02-13-macos-target-space-design.md","docs/plans/2026-02-13-new-tab-profile-selection-design.md","docs/plans/2026-02-13-new-tab-profile-selection-plan.md","docs/plans/2026-02-13-remote-shell-integration-design.md","docs/plans/2026-02-13-remote-shell-integration.md","docs/plans/2026-02-13-shell-selection-per-profile-design.md","docs/plans/2026-02-13-ssh-features-design.md","docs/plans/2026-02-13-ssh-features-plan.md","docs/plans/2026-02-13-status-bar-design.md","docs/plans/2026-02-13-status-bar-plan.md","docs/plans/2026-02-14-auto-tab-style-design.md","docs/plans/2026-02-14-auto-tab-style-plan.md","docs/plans/2026-02-14-configurable-link-handler.md","docs/plans/2026-02-14-dynamic-profiles-design.md","docs/plans/2026-02-14-dynamic-profiles-plan.md","docs/plans/2026-02-14-per-pane-background-design.md","docs/plans/2026-02-14-per-pane-background-impl.md","docs/plans/2026-02-14-scripting-manager-design.md","docs/plans/2026-02-14-scripting-manager.md","docs/plans/2026-02-15-ai-inspector-design.md","docs/plans/2026-02-15-ai-inspector-plan.md","docs/plans/2026-02-15-file-transfer-ui-design.md","docs/plans/2026-02-15-file-transfer-ui-plan.md","docs/plans/2026-02-15-file-transfer-utilities-design.md","docs/plans/2026-02-15-file-transfer-utilities-plan.md","docs/plans/2026-02-16-shader-acp-agent-design.md","docs/plans/2026-02-16-shader-acp-agent-plan.md","docs/plans/2026-02-19-hourly-update-check-design.md","docs/plans/2026-02-19-hourly-update-check-plan.md","docs/plans/2026-02-20-nerd-font-icons-design.md","docs/plans/2026-02-20-nerd-font-icons-plan.md","docs/plans/2026-02-20-tab-icon-context-menu-design.md","docs/plans/2026-02-20-tab-icon-context-menu-plan.md","docs/plans/2026-02-20-tab-naming-design.md","docs/plans/2026-02-20-tab-naming-plan.md"]}]},{"name":"Research","slug":"research","files":["docs/research/macos-space-apis-2026-02-13.md"]},{"name":"Examples","slug":"examples","files":["examples/README.md","examples/config-complete.yaml","examples/config-font-ranges.yaml","examples/config-styled-fonts.yaml","examples/config-text-shaping.yaml"]},{"name":"Shell Integration","slug":"shell-integration","files":["shell_integration/README.md","shell_integration/par_term_shell_integration.bash","shell_integration/par_term_shell_integration.fish","shell_integration/par_term_shell_integration.zsh","shell_integration/pt-dl","shell_integration/pt-imgcat","shell_integration/pt-ul"]},{"name":"AI Inspector","slug":"ai-inspector","files":[],"children":[{"name":"AI Inspector — ai_inspector","slug":"ai-inspector-ai-inspector","files":["src/ai_inspector/chat.rs","src/ai_inspector/mod.rs","src/ai_inspector/panel.rs","src/ai_inspector/shader_context.rs","src/ai_inspector/snapshot.rs"]}]},{"name":"Application","slug":"application","files":[],"children":[{"name":"Application — app","slug":"application-app","files":["src/app/anti_idle.rs","src/app/bell.rs","src/app/config_updates.rs","src/app/copy_mode_handler.rs","src/app/debug_state.rs","src/app/file_transfers.rs","src/app/handler.rs","src/app/input_events.rs","src/app/keyboard_handlers.rs","src/app/mod.rs","src/app/mouse.rs","src/app/mouse_events.rs","src/app/notifications.rs","src/app/render_cache.rs","src/app/renderer_init.rs","src/app/scroll_ops.rs","src/app/search_highlight.rs","src/app/tab_ops.rs","src/app/text_selection.rs","src/app/tmux_handler.rs","src/app/triggers.rs","src/app/url_hover.rs","src/app/window_manager.rs","src/app/window_state.rs"]}]},{"name":"Arrangements","slug":"arrangements","files":["src/arrangements/capture.rs","src/arrangements/mod.rs","src/arrangements/restore.rs","src/arrangements/storage.rs"]},{"name":"Profiles","slug":"profiles","files":["src/profile/dynamic.rs","src/profile/mod.rs","src/profile/storage.rs","src/profile_drawer_ui.rs","src/profile_modal_ui.rs"]},{"name":"Terminal","slug":"terminal","files":[],"children":[{"name":"Terminal — src","slug":"terminal-src","files":["src/terminal.rs","src/tab_bar_ui.rs","src/scrollback_metadata.rs","src/styled_content.rs"]},{"name":"Terminal — tab","slug":"terminal-tab","files":["src/tab/initial_text.rs","src/tab/manager.rs","src/tab/mod.rs"]}]},{"name":"Scripting","slug":"scripting","files":["src/scripting/mod.rs"]},{"name":"SSH","slug":"ssh","files":["src/ssh/config_parser.rs","src/ssh/discovery.rs","src/ssh/history.rs","src/ssh/known_hosts.rs","src/ssh/mdns.rs","src/ssh/mod.rs","src/ssh/types.rs","src/ssh_connect_ui.rs"]},{"name":"Status Bar","slug":"status-bar","files":["src/status_bar/config.rs","src/status_bar/mod.rs","src/status_bar/system_monitor.rs","src/status_bar/widgets.rs"]},{"name":"Rendering","slug":"rendering","files":[],"children":[{"name":"Rendering — src","slug":"rendering-src","files":["par-term-render/src/cell_renderer/atlas.rs","par-term-render/src/cell_renderer/background.rs","par-term-render/src/cell_renderer/block_chars.rs","par-term-render/src/cell_renderer/mod.rs","par-term-render/src/cell_renderer/pipeline.rs","par-term-render/src/cell_renderer/render.rs","par-term-render/src/cell_renderer/types.rs","par-term-render/src/custom_shader_renderer/cubemap.rs","par-term-render/src/custom_shader_renderer/cursor.rs","par-term-render/src/custom_shader_renderer/mod.rs","par-term-render/src/custom_shader_renderer/pipeline.rs","par-term-render/src/custom_shader_renderer/textures.rs","par-term-render/src/custom_shader_renderer/transpiler.rs","par-term-render/src/custom_shader_renderer/types.rs","par-term-render/src/gpu_utils.rs","par-term-render/src/graphics_renderer.rs","par-term-render/src/lib.rs","par-term-render/src/renderer/graphics.rs","par-term-render/src/renderer/mod.rs","par-term-render/src/renderer/shaders.rs","par-term-render/src/scrollbar.rs","par-term-render/src/shaders/background_image.wgsl","par-term-render/src/shaders/cell_bg.wgsl","par-term-render/src/shaders/cell_text.wgsl","par-term-render/src/shaders/scrollbar.wgsl","par-term-render/src/shaders/sixel.wgsl"]}]},{"name":"Fonts","slug":"fonts","files":["par-term-fonts/src/font_manager/fallbacks.rs","par-term-fonts/src/font_manager/loader.rs","par-term-fonts/src/font_manager/mod.rs","par-term-fonts/src/font_manager/types.rs","par-term-fonts/src/lib.rs","par-term-fonts/src/text_shaper.rs"]},{"name":"Input","slug":"input","files":["par-term-input/src/lib.rs"]},{"name":"Keybindings","slug":"keybindings","files":["par-term-keybindings/src/lib.rs","par-term-keybindings/src/matcher.rs","par-term-keybindings/src/parser.rs"]},{"name":"Update","slug":"update","files":["par-term-update/src/http.rs","par-term-update/src/lib.rs","par-term-update/src/manifest.rs","par-term-update/src/self_updater.rs","par-term-update/src/update_checker.rs"]},{"name":"Miscellaneous","slug":"miscellaneous","files":[],"children":[{"name":"Miscellaneous — src","slug":"miscellaneous-src","files":["src/audio_bell.rs","src/badge.rs","src/cell_renderer.rs","src/cli.rs","src/clipboard_history_ui.rs","src/close_confirmation_ui.rs","src/command_history.rs","src/command_history_ui.rs","src/copy_mode.rs","src/custom_shader_renderer.rs","src/debug.rs","src/font_manager.rs","src/font_metrics.rs","src/help_ui.rs","src/http.rs","src/input.rs","src/integrations_ui.rs","src/lib.rs","src/macos_blur.rs","src/macos_metal.rs","src/macos_space.rs","src/main.rs","src/manifest.rs","src/paste_special_ui.rs","src/paste_transform.rs","src/progress_bar.rs","src/quit_confirmation_ui.rs","src/remote_shell_install_ui.rs","src/renderer.rs","src/scroll_state.rs","src/scrollbar.rs","src/selection.rs","src/self_updater.rs","src/session_logger.rs","src/settings_window.rs","src/shader_install_ui.rs","src/shader_installer.rs","src/shader_watcher.rs","src/shell_detection.rs","src/shell_integration_installer.rs","src/shell_quote.rs","src/smart_selection.rs","src/update_checker.rs","src/update_dialog.rs","src/url_detection.rs"]},{"name":"Miscellaneous — config","slug":"miscellaneous-config","files":["src/config/mod.rs"]},{"name":"Miscellaneous — keybindings","slug":"miscellaneous-keybindings","files":["src/keybindings/mod.rs"]},{"name":"Miscellaneous — menu","slug":"miscellaneous-menu","files":["src/menu/actions.rs","src/menu/mod.rs"]},{"name":"Miscellaneous — pane","slug":"miscellaneous-pane","files":["src/pane/manager.rs","src/pane/mod.rs","src/pane/types.rs"]},{"name":"Miscellaneous — session","slug":"miscellaneous-session","files":["src/session/capture.rs","src/session/mod.rs","src/session/restore.rs","src/session/storage.rs"]},{"name":"Miscellaneous — snippets","slug":"miscellaneous-snippets","files":["src/snippets/mod.rs"]}]},{"name":"Other","slug":"other","files":[],"children":[{"name":"Other — Cargo.toml","slug":"other-cargo-toml","files":["Cargo.toml"]},{"name":"Other — Cross.toml","slug":"other-cross-toml","files":["Cross.toml"]},{"name":"Other — Makefile","slug":"other-makefile","files":["Makefile"]},{"name":"Other — build.rs","slug":"other-build-rs","files":["build.rs"]},{"name":"Other — gallery","slug":"other-gallery","files":["gh-pages/gallery/index.html"]},{"name":"Other — gh-pages","slug":"other-gh-pages","files":["gh-pages/index.html","gh-pages/install-shaders.sh","gh-pages/install-shell-integration.sh"]},{"name":"Other — Casks","slug":"other-casks","files":["homebrew/Casks/par-term.rb"]},{"name":"Other — ideas.md","slug":"other-ideas-md","files":["ideas.md"]},{"name":"Other — images","slug":"other-images","files":["images/snake.sixel","images/snake_tui.sixel"]},{"name":"Other — install_shaders.sh","slug":"other-install-shaders-sh","files":["install_shaders.sh"]},{"name":"Other — par-term-acp","slug":"other-par-term-acp","files":["par-term-acp/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-acp/src/agent.rs","par-term-acp/src/agents.rs","par-term-acp/src/fs_ops.rs","par-term-acp/src/jsonrpc.rs","par-term-acp/src/lib.rs","par-term-acp/src/protocol.rs"]},{"name":"Other — par-term-config","slug":"other-par-term-config","files":["par-term-config/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-config/src/automation.rs","par-term-config/src/cell.rs","par-term-config/src/config.rs","par-term-config/src/defaults.rs","par-term-config/src/lib.rs","par-term-config/src/profile.rs","par-term-config/src/profile_types.rs","par-term-config/src/scripting.rs","par-term-config/src/scrollback_mark.rs","par-term-config/src/shader_config.rs","par-term-config/src/shader_metadata.rs","par-term-config/src/snippets.rs","par-term-config/src/status_bar.rs","par-term-config/src/themes.rs","par-term-config/src/types.rs","par-term-config/src/watcher.rs"]},{"name":"Other — par-term-fonts","slug":"other-par-term-fonts","files":["par-term-fonts/Cargo.toml"]},{"name":"Other — tests","slug":"other-tests","files":["par-term-fonts/tests/font_tests.rs"]},{"name":"Other — par-term-input","slug":"other-par-term-input","files":["par-term-input/Cargo.toml"]},{"name":"Other — par-term-keybindings","slug":"other-par-term-keybindings","files":["par-term-keybindings/Cargo.toml"]},{"name":"Other — par-term-mcp","slug":"other-par-term-mcp","files":["par-term-mcp/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-mcp/src/lib.rs"]},{"name":"Other — par-term-render","slug":"other-par-term-render","files":["par-term-render/Cargo.toml"]},{"name":"Other — par-term-scripting","slug":"other-par-term-scripting","files":["par-term-scripting/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-scripting/src/lib.rs","par-term-scripting/src/manager.rs","par-term-scripting/src/observer.rs","par-term-scripting/src/process.rs","par-term-scripting/src/protocol.rs"]},{"name":"Other — par-term-settings-ui","slug":"other-par-term-settings-ui","files":["par-term-settings-ui/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-settings-ui/src/actions_tab.rs","par-term-settings-ui/src/advanced_tab.rs","par-term-settings-ui/src/ai_inspector_tab.rs","par-term-settings-ui/src/appearance_tab.rs","par-term-settings-ui/src/arrangements.rs","par-term-settings-ui/src/arrangements_tab.rs","par-term-settings-ui/src/automation_tab.rs","par-term-settings-ui/src/background_tab.rs","par-term-settings-ui/src/badge_tab.rs","par-term-settings-ui/src/cursor_shader_editor.rs","par-term-settings-ui/src/effects_tab.rs","par-term-settings-ui/src/input_tab.rs","par-term-settings-ui/src/integrations_tab.rs","par-term-settings-ui/src/lib.rs","par-term-settings-ui/src/nerd_font.rs","par-term-settings-ui/src/notifications_tab.rs","par-term-settings-ui/src/profile_modal_ui.rs","par-term-settings-ui/src/profiles_tab.rs","par-term-settings-ui/src/progress_bar_tab.rs","par-term-settings-ui/src/quick_settings.rs","par-term-settings-ui/src/scripts_tab.rs","par-term-settings-ui/src/section.rs","par-term-settings-ui/src/shader_dialogs.rs","par-term-settings-ui/src/shader_editor.rs","par-term-settings-ui/src/shader_utils.rs","par-term-settings-ui/src/shell_detection.rs","par-term-settings-ui/src/sidebar.rs","par-term-settings-ui/src/snippets_tab.rs","par-term-settings-ui/src/ssh_tab.rs","par-term-settings-ui/src/status_bar_tab.rs","par-term-settings-ui/src/terminal_tab.rs","par-term-settings-ui/src/traits.rs","par-term-settings-ui/src/window_tab.rs"]},{"name":"Other — par-term-ssh","slug":"other-par-term-ssh","files":["par-term-ssh/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-ssh/src/config_parser.rs","par-term-ssh/src/discovery.rs","par-term-ssh/src/history.rs","par-term-ssh/src/known_hosts.rs","par-term-ssh/src/lib.rs","par-term-ssh/src/mdns.rs","par-term-ssh/src/types.rs"]},{"name":"Other — par-term-terminal","slug":"other-par-term-terminal","files":["par-term-terminal/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-terminal/src/lib.rs","par-term-terminal/src/scrollback_metadata.rs","par-term-terminal/src/styled_content.rs","par-term-terminal/src/terminal/clipboard.rs","par-term-terminal/src/terminal/graphics.rs","par-term-terminal/src/terminal/hyperlinks.rs","par-term-terminal/src/terminal/mod.rs","par-term-terminal/src/terminal/rendering.rs","par-term-terminal/src/terminal/spawn.rs"]},{"name":"Other — par-term-tmux","slug":"other-par-term-tmux","files":["par-term-tmux/Cargo.toml"]},{"name":"Other — src","slug":"other-src","files":["par-term-tmux/src/commands.rs","par-term-tmux/src/lib.rs","par-term-tmux/src/parser_bridge.rs","par-term-tmux/src/prefix.rs","par-term-tmux/src/session.rs","par-term-tmux/src/status_format.rs","par-term-tmux/src/sync.rs","par-term-tmux/src/types.rs"]},{"name":"Other — par-term-update","slug":"other-par-term-update","files":["par-term-update/Cargo.toml"]},{"name":"Other — par-term.terminfo","slug":"other-par-term-terminfo","files":["par-term.terminfo"]},{"name":"Other — run.log","slug":"other-run-log","files":["run.log"]},{"name":"Other — rust-toolchain.toml","slug":"other-rust-toolchain-toml","files":["rust-toolchain.toml"]},{"name":"Other — scripts","slug":"other-scripts","files":["scripts/README.md","scripts/benchmark_text_shaping.sh","scripts/generate_manifest.py","scripts/generate_shader_gallery.sh","scripts/install-windows.bat","scripts/simple_sixel.sh","scripts/test_bells.sh","scripts/test_coprocess.py","scripts/test_emoji.txt","scripts/test_fonts.sh","scripts/test_progress_bar.sh","scripts/test_script_observer.py","scripts/test_sixel.sh"]},{"name":"Other — examples","slug":"other-examples","files":["scripts/examples/hello_observer.py"]},{"name":"Other — shader_debug.md","slug":"other-shader-debug-md","files":["shader_debug.md"]},{"name":"Other — shaders","slug":"other-shaders","files":["shaders/animated-gradient-shader.glsl","shaders/arcane-portal.glsl","shaders/bloom.glsl","shaders/bumped_sinusoidal_warp.glsl","shaders/cineShader-Lava.glsl","shaders/clouds.glsl","shaders/convergence.glsl","shaders/crt.glsl","shaders/cubemap-skybox.glsl","shaders/cubemap-test.glsl","shaders/cubes.glsl","shaders/cursor_blaze.glsl","shaders/cursor_glow.glsl","shaders/cursor_orbit.glsl","shaders/cursor_pacman.glsl","shaders/cursor_rectangle_boom.glsl","shaders/cursor_ripple.glsl","shaders/cursor_ripple_rectangle.glsl","shaders/cursor_sonic_boom.glsl","shaders/cursor_sweep.glsl","shaders/cursor_trail.glsl","shaders/cursor_warp.glsl","shaders/cursor_water_tank.glsl","shaders/dither.glsl","shaders/dodecagon-pattern.glsl","shaders/drunkard.glsl","shaders/fireworks-rockets.glsl","shaders/fireworks.glsl","shaders/galaxy.glsl","shaders/gears-and-belts.glsl","shaders/glitchy.glsl","shaders/glow-rgbsplit-twitchy.glsl","shaders/gradient-background.glsl","shaders/gyroid.glsl","shaders/happy_fractal.glsl","shaders/inside-the-matrix.glsl","shaders/just-snow.glsl","shaders/keypress_pulse.glsl","shaders/manifest.json","shaders/rain-glass.glsl","shaders/rain.glsl","shaders/retro-terminal.glsl","shaders/sin-interference.glsl","shaders/singularity.glsl","shaders/sparks-from-fire.glsl","shaders/spotlight.glsl","shaders/starfield-colors.glsl","shaders/starfield.glsl","shaders/underwater.glsl","shaders/universe-within.glsl","shaders/water.glsl"]},{"name":"Other — textures","slug":"other-textures","files":["shaders/textures/wallpaper/README.md"]},{"name":"Other — src","slug":"other-src","files":["src/gpu_utils.rs","src/graphics_renderer.rs","src/text_shaper.rs","src/themes.rs","src/tmux_session_picker_ui.rs","src/tmux_status_bar_ui.rs"]},{"name":"Other — search","slug":"other-search","files":["src/search/engine.rs","src/search/mod.rs","src/search/types.rs"]},{"name":"Other — test_cr.rs","slug":"other-test-cr-rs","files":["test_cr.rs"]},{"name":"Other — test_grid.rs","slug":"other-test-grid-rs","files":["test_grid.rs"]},{"name":"Other — tests","slug":"other-tests","files":["tests/activity_notification_tests.rs","tests/automation_config_tests.rs","tests/block_chars_tests.rs","tests/config_tests.rs","tests/grapheme_rendering_tests.rs","tests/import_export_tests.rs","tests/input_tests.rs","tests/profile_ui_tests.rs","tests/script_integration_tests.rs","tests/script_manager_tests.rs","tests/script_observer_tests.rs","tests/script_process_tests.rs","tests/script_protocol_tests.rs","tests/scripting_config_tests.rs","tests/session_notification_tests.rs","tests/settings_window_tests.rs","tests/shader_context_tests.rs","tests/shader_watcher_tests.rs","tests/shell_env_tests.rs","tests/snippets_actions_tests.rs","tests/ssh_integration.rs","tests/status_bar_config_test.rs","tests/tab_bar_ui_tests.rs","tests/tab_color_tests.rs","tests/tab_stability_tests.rs","tests/terminal_tests.rs"]}]}]}; | |
| (function() { | |
| var activePage = 'overview'; | |
| document.addEventListener('DOMContentLoaded', function() { | |
| mermaid.initialize({ startOnLoad: false, theme: 'neutral', securityLevel: 'loose' }); | |
| renderMeta(); | |
| renderNav(); | |
| document.getElementById('menu-toggle').addEventListener('click', function() { | |
| document.getElementById('sidebar').classList.toggle('open'); | |
| }); | |
| if (location.hash && location.hash.length > 1) { | |
| activePage = decodeURIComponent(location.hash.slice(1)); | |
| } | |
| navigateTo(activePage); | |
| }); | |
| function renderMeta() { | |
| if (!META) return; | |
| var el = document.getElementById('meta-info'); | |
| var parts = []; | |
| if (META.generatedAt) { | |
| parts.push(new Date(META.generatedAt).toLocaleDateString()); | |
| } | |
| if (META.model) parts.push(META.model); | |
| if (META.fromCommit) parts.push(META.fromCommit.slice(0, 8)); | |
| el.textContent = parts.join(' \u00b7 '); | |
| } | |
| function renderNav() { | |
| var container = document.getElementById('nav-tree'); | |
| var html = '<div class="nav-section">'; | |
| html += '<a class="nav-item overview" data-page="overview" href="#overview">Overview</a>'; | |
| html += '</div>'; | |
| if (TREE.length > 0) { | |
| html += '<div class="nav-group-label">Modules</div>'; | |
| html += buildNavTree(TREE); | |
| } | |
| container.innerHTML = html; | |
| container.addEventListener('click', function(e) { | |
| var target = e.target; | |
| while (target && !target.dataset.page) { target = target.parentElement; } | |
| if (target && target.dataset.page) { | |
| e.preventDefault(); | |
| navigateTo(target.dataset.page); | |
| } | |
| }); | |
| } | |
| function buildNavTree(nodes) { | |
| var html = ''; | |
| for (var i = 0; i < nodes.length; i++) { | |
| var node = nodes[i]; | |
| html += '<div class="nav-section">'; | |
| html += '<a class="nav-item" data-page="' + escH(node.slug) + '" href="#' + encodeURIComponent(node.slug) + '">' + escH(node.name) + '</a>'; | |
| if (node.children && node.children.length > 0) { | |
| html += '<div class="nav-children">' + buildNavTree(node.children) + '</div>'; | |
| } | |
| html += '</div>'; | |
| } | |
| return html; | |
| } | |
| function escH(s) { | |
| var d = document.createElement('div'); | |
| d.textContent = s; | |
| return d.innerHTML; | |
| } | |
| function navigateTo(page) { | |
| activePage = page; | |
| location.hash = encodeURIComponent(page); | |
| var items = document.querySelectorAll('.nav-item'); | |
| for (var i = 0; i < items.length; i++) { | |
| if (items[i].dataset.page === page) { | |
| items[i].classList.add('active'); | |
| } else { | |
| items[i].classList.remove('active'); | |
| } | |
| } | |
| var contentEl = document.getElementById('content'); | |
| var md = PAGES[page]; | |
| if (!md) { | |
| contentEl.innerHTML = '<div class="empty-state"><h2>Page not found</h2><p>' + escH(page) + '.md does not exist.</p></div>'; | |
| return; | |
| } | |
| contentEl.innerHTML = marked.parse(md); | |
| // Rewrite .md links to hash navigation | |
| var links = contentEl.querySelectorAll('a[href]'); | |
| for (var i = 0; i < links.length; i++) { | |
| var href = links[i].getAttribute('href'); | |
| if (href && href.endsWith('.md') && href.indexOf('://') === -1) { | |
| var slug = href.replace(/\.md$/, ''); | |
| links[i].setAttribute('href', '#' + encodeURIComponent(slug)); | |
| (function(s) { | |
| links[i].addEventListener('click', function(e) { | |
| e.preventDefault(); | |
| navigateTo(s); | |
| }); | |
| })(slug); | |
| } | |
| } | |
| // Convert mermaid code blocks into mermaid divs | |
| var mermaidBlocks = contentEl.querySelectorAll('pre code.language-mermaid'); | |
| for (var i = 0; i < mermaidBlocks.length; i++) { | |
| var pre = mermaidBlocks[i].parentElement; | |
| var div = document.createElement('div'); | |
| div.className = 'mermaid'; | |
| div.textContent = mermaidBlocks[i].textContent; | |
| pre.parentNode.replaceChild(div, pre); | |
| } | |
| try { mermaid.run({ querySelector: '.mermaid' }); } catch(e) {} | |
| window.scrollTo(0, 0); | |
| document.getElementById('sidebar').classList.remove('open'); | |
| } | |
| })(); | |
| </script> | |
| </body> | |
| </html> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment