693 lines
30 KiB
Text
693 lines
30 KiB
Text
*cp.nvim.txt* Competitive programming plugin for Neovim
|
|
|
|
Author: Barrett Ruth <br.barrettruth@gmail.com>
|
|
License: Same terms as Vim itself (see |license|)
|
|
|
|
==============================================================================
|
|
INTRODUCTION *cp.nvim*
|
|
|
|
cp.nvim is a competitive programming plugin that automates problem setup,
|
|
compilation, and testing workflow for online judges.
|
|
|
|
Supported platforms (for now!): AtCoder, Codeforces, CSES
|
|
|
|
==============================================================================
|
|
REQUIREMENTS *cp-requirements*
|
|
|
|
- Neovim 0.10.0+
|
|
- Unix-like operating system
|
|
- uv package manager (https://docs.astral.sh/uv/)
|
|
|
|
==============================================================================
|
|
COMMANDS *cp-commands*
|
|
|
|
:CP *:CP*
|
|
cp.nvim uses a single :CP command with intelligent argument parsing:
|
|
|
|
Setup Commands ~
|
|
:CP {platform} {contest_id}
|
|
Full setup: set platform and load contest metadata.
|
|
Scrapes test cases and creates source file.
|
|
Example: >
|
|
:CP codeforces 1933
|
|
<
|
|
:CP {platform} {contest_id}
|
|
Contest setup: set platform, load contest metadata,
|
|
and scrape all test cases in the contest.
|
|
Opens the first problem after completion.
|
|
Example: >
|
|
:CP atcoder abc324
|
|
<
|
|
View Commands ~
|
|
:CP run [--debug] [n]
|
|
Run tests in I/O view (see |cp-io-view|).
|
|
Lightweight split showing test verdicts.
|
|
Without [n]: runs all tests, shows verdict summary
|
|
With [n]: runs test n, shows detailed output
|
|
--debug: Use debug build (builds to build/<name>.dbg)
|
|
Examples: >
|
|
:CP run " All tests
|
|
:CP run --debug 2 " Test 2, debug build
|
|
<
|
|
:CP panel [--debug] [n]
|
|
Open full-screen test panel (see |cp-panel|).
|
|
Aggregate table with diff modes for detailed analysis.
|
|
Optional [n] focuses on specific test.
|
|
--debug: Use debug build (with sanitizers, etc.)
|
|
Examples: >
|
|
:CP panel " All tests
|
|
:CP panel --debug 3 " Test 3, debug build
|
|
<
|
|
|
|
:CP pick Launch configured picker for interactive
|
|
platform/contest selection.
|
|
|
|
:CP interact [script]
|
|
Open an interactive terminal for the current problem.
|
|
If an executable interactor is provided, runs the compiled
|
|
binary against the source file (see
|
|
*cp-interact*). Otherwise, runs the source
|
|
file. Only valid for interactive problems.
|
|
|
|
Navigation Commands ~
|
|
:CP next Navigate to next problem in current contest.
|
|
Stops at last problem (no wrapping).
|
|
|
|
|
|
:CP prev Navigate to previous problem in current contest.
|
|
Stops at first problem (no wrapping).
|
|
|
|
:CP {problem_id} Jump to problem {problem_id} in a contest.
|
|
Requires that a contest has already been set up.
|
|
|
|
State Restoration ~
|
|
:CP Restore state from current file.
|
|
Automatically detects platform, contest, problem,
|
|
and language from cached state. Use this after
|
|
switching files to restore your CP environment.
|
|
|
|
Cache Commands ~
|
|
:CP cache clear [contest]
|
|
Clear the cache data for the specified contest,
|
|
or all contests if none specified.
|
|
|
|
:CP cache read
|
|
View the cache in a pretty-printed lua buffer.
|
|
Exit with q.
|
|
|
|
Template Variables ~
|
|
*cp-template-vars*
|
|
Command templates support variable substitution using {variable} syntax:
|
|
|
|
• {source} Source file path (e.g. "abc324a.cpp")
|
|
• {binary} Output binary path (e.g. "build/abc324a.run" or
|
|
"build/abc324a.dbg" for debug builds)
|
|
|
|
Example template: >
|
|
build = { 'g++', '{source}', '-o', '{binary}', '-std=c++17' }
|
|
< Would expand to: >
|
|
g++ abc324a.cpp -o build/abc324a.run -std=c++17
|
|
<
|
|
Debug Builds ~
|
|
*cp-debug-builds*
|
|
The --debug flag uses the debug command configuration instead of build:
|
|
|
|
• Normal build: commands.build → outputs to build/<name>.run
|
|
• Debug build: commands.debug → outputs to build/<name>.dbg
|
|
|
|
Debug builds typically include sanitizers (address, undefined behavior) to
|
|
catch memory errors, buffer overflows, and other issues. Both binaries
|
|
coexist, so you can switch between normal and debug mode without
|
|
recompiling.
|
|
|
|
Example debug configuration: >
|
|
languages = {
|
|
cpp = {
|
|
extension = 'cc',
|
|
commands = {
|
|
build = { 'g++', '-std=c++17', '{source}', '-o', '{binary}' },
|
|
run = { '{binary}' },
|
|
debug = { 'g++', '-std=c++17', '-fsanitize=address,undefined',
|
|
'{source}', '-o', '{binary}' },
|
|
}
|
|
}
|
|
}
|
|
<
|
|
|
|
==============================================================================
|
|
CONFIGURATION *cp-config*
|
|
|
|
Here's an example configuration with lazy.nvim:
|
|
>lua
|
|
{
|
|
'barrett-ruth/cp.nvim',
|
|
cmd = 'CP',
|
|
build = 'uv sync',
|
|
opts = {
|
|
languages = {
|
|
cpp = {
|
|
extension = 'cc',
|
|
commands = {
|
|
build = { 'g++', '-std=c++17', '{source}', '-o', '{binary}',
|
|
'-fdiagnostics-color=always' },
|
|
run = { '{binary}' },
|
|
debug = { 'g++', '-std=c++17', '-fsanitize=address,undefined',
|
|
'{source}', '-o', '{binary}' },
|
|
},
|
|
},
|
|
python = {
|
|
extension = 'py',
|
|
commands = {
|
|
run = { 'python', '{source}' },
|
|
debug = { 'python', '{source}' },
|
|
},
|
|
},
|
|
},
|
|
platforms = {
|
|
cses = {
|
|
enabled_languages = { 'cpp', 'python' },
|
|
default_language = 'cpp',
|
|
overrides = {
|
|
cpp = { extension = 'cpp', commands = { build = { ... } } }
|
|
},
|
|
},
|
|
atcoder = {
|
|
enabled_languages = { 'cpp', 'python' },
|
|
default_language = 'cpp',
|
|
},
|
|
codeforces = {
|
|
enabled_languages = { 'cpp', 'python' },
|
|
default_language = 'cpp',
|
|
},
|
|
},
|
|
open_url = true,
|
|
debug = false,
|
|
ui = {
|
|
ansi = true,
|
|
run = {
|
|
width = 0.3,
|
|
next_test_key = '<c-n>', -- or nil to disable
|
|
prev_test_key = '<c-p>', -- or nil to disable
|
|
},
|
|
panel = {
|
|
diff_mode = 'vim',
|
|
max_output_lines = 50,
|
|
},
|
|
diff = {
|
|
git = {
|
|
args = { 'diff', '--no-index', '--word-diff=plain',
|
|
'--word-diff-regex=.', '--no-prefix' },
|
|
},
|
|
},
|
|
picker = 'telescope',
|
|
},
|
|
}
|
|
}
|
|
<
|
|
|
|
By default, C++ (g++ with ISO C++17) and Python are preconfigured under
|
|
'languages'. Platforms select which languages are enabled and which one is
|
|
the default; per-platform overrides can tweak 'extension' or 'commands'.
|
|
|
|
For example, to run CodeForces contests with Python by default:
|
|
>lua
|
|
{
|
|
platforms = {
|
|
codeforces = {
|
|
default_language = 'python',
|
|
},
|
|
},
|
|
}
|
|
<
|
|
Any language is supported provided the proper configuration. For example, to
|
|
run CSES problems with Rust using the single schema:
|
|
>lua
|
|
{
|
|
languages = {
|
|
rust = {
|
|
extension = 'rs',
|
|
commands = {
|
|
build = { 'rustc', '{source}', '-o', '{binary}' },
|
|
run = { '{binary}' },
|
|
},
|
|
},
|
|
},
|
|
platforms = {
|
|
cses = {
|
|
enabled_languages = { 'cpp', 'python', 'rust' },
|
|
default_language = 'rust',
|
|
},
|
|
},
|
|
}
|
|
<
|
|
*cp.Config*
|
|
Fields: ~
|
|
{languages} (table<string,|CpLanguage|>) Global language registry.
|
|
Each language provides an {extension} and {commands}.
|
|
{platforms} (table<string,|CpPlatform|>) Per-platform enablement,
|
|
default language, and optional overrides.
|
|
{hooks} (|cp.Hooks|) Hook functions called at various stages.
|
|
{debug} (boolean, default: false) Show info messages.
|
|
{scrapers} (string[]) Supported platform ids.
|
|
{filename} (function, optional)
|
|
function(contest, contest_id, problem_id, config, language): string
|
|
Should return full filename with extension.
|
|
(default: concatenates contest_id and problem_id, lowercased)
|
|
{ui} (|CpUI|) UI settings: panel, diff backend, picker.
|
|
{open_url} (boolean) Open the contest & problem url in the browser
|
|
when the contest is first opened.
|
|
|
|
*CpPlatform*
|
|
Fields: ~
|
|
{enabled_languages} (string[]) Language ids enabled on this platform.
|
|
{default_language} (string) One of {enabled_languages}.
|
|
{overrides} (table<string,|CpPlatformOverrides|>, optional)
|
|
Per-language overrides of {extension} and/or {commands}.
|
|
|
|
*CpLanguage*
|
|
Fields: ~
|
|
{extension} (string) File extension without leading dot.
|
|
{commands} (|CpLangCommands|) Command templates.
|
|
|
|
*CpLangCommands*
|
|
Fields: ~
|
|
{build} (string[], optional) For compiled languages.
|
|
Must include {source} and {binary}.
|
|
{run} (string[], optional) Runtime command.
|
|
Compiled: must include {binary}.
|
|
Interpreted: must include {source}.
|
|
{debug} (string[], optional) Debug variant; same token rules
|
|
as {build} (compiled) or {run} (interpreted).
|
|
|
|
*CpUI*
|
|
Fields: ~
|
|
{ansi} (boolean, default: true) Enable ANSI color parsing
|
|
and highlighting in both I/O view and panel.
|
|
{run} (|RunConfig|) I/O view configuration.
|
|
{panel} (|PanelConfig|) Test panel behavior configuration.
|
|
{diff} (|DiffConfig|) Diff backend configuration.
|
|
{picker} (string|nil) 'telescope', 'fzf-lua', or nil.
|
|
|
|
*RunConfig*
|
|
Fields: ~
|
|
{width} (number, default: 0.3) Width of I/O view splits as
|
|
fraction of screen (0.0 to 1.0).
|
|
{next_test_key} (string|nil, default: '<c-n>') Keymap to navigate
|
|
to next test in I/O view. Set to nil to disable.
|
|
{prev_test_key} (string|nil, default: '<c-p>') Keymap to navigate
|
|
to previous test in I/O view. Set to nil to disable.
|
|
|
|
*cp.PanelConfig*
|
|
Fields: ~
|
|
{diff_mode} (string, default: "none") Diff backend: "none",
|
|
"vim", or "git".
|
|
{max_output_lines} (number, default: 50) Maximum lines of test output.
|
|
|
|
*cp.DiffConfig*
|
|
Fields: ~
|
|
{git} (|cp.DiffGitConfig|) Git diff backend configuration.
|
|
|
|
*cp.DiffGitConfig*
|
|
Fields: ~
|
|
{args} (string[]) Command-line arguments for git diff.
|
|
Default: { 'diff', '--no-index', '--word-diff=plain',
|
|
'--word-diff-regex=.', '--no-prefix' }
|
|
• --no-index: Compare files outside git repository
|
|
• --word-diff=plain: Character-level diff markers
|
|
• --word-diff-regex=.: Split on every character
|
|
• --no-prefix: Remove a/ b/ prefixes from output
|
|
|
|
*cp.Hooks*
|
|
Fields: ~
|
|
{before_run} (function, optional) Called before test panel opens.
|
|
function(state: cp.State)
|
|
{before_debug} (function, optional) Called before debug build/run.
|
|
function(state: cp.State)
|
|
{setup_code} (function, optional) Called after source file is opened.
|
|
function(state: cp.State)
|
|
{setup_io_input} (function, optional) Called when I/O input buffer created.
|
|
function(bufnr: integer, state: cp.State)
|
|
Default: helpers.clearcol (removes line numbers/columns)
|
|
{setup_io_output} (function, optional) Called when I/O output buffer created.
|
|
function(bufnr: integer, state: cp.State)
|
|
Default: helpers.clearcol (removes line numbers/columns)
|
|
|
|
Hook functions receive the cp.nvim state object (|cp.State|). See
|
|
|lua/cp/state.lua| for available methods and fields.
|
|
|
|
The I/O buffer hooks are called once when the buffers are first created
|
|
during problem setup. Use these to customize buffer appearance (e.g.,
|
|
remove line numbers, set custom options). Access helpers via:
|
|
>lua
|
|
local helpers = require('cp').helpers
|
|
<
|
|
Example usage:
|
|
>lua
|
|
hooks = {
|
|
setup_code = function(state)
|
|
print("Setting up " .. state.get_base_name())
|
|
print("Source file: " .. state.get_source_file())
|
|
end,
|
|
setup_io_input = function(bufnr, state)
|
|
-- Custom setup for input buffer
|
|
vim.api.nvim_set_option_value('number', false, { buf = bufnr })
|
|
end
|
|
}
|
|
<
|
|
|
|
==============================================================================
|
|
WORKFLOW *cp-workflow*
|
|
|
|
For the sake of consistency and simplicity, cp.nvim extracts contest/problem
|
|
identifiers from URLs. This means that, for example, CodeForces/AtCoder
|
|
contests are configured by their round id rather than round number. See below.
|
|
|
|
==============================================================================
|
|
PLATFORM-SPECIFIC USAGE *cp-platforms*
|
|
|
|
AtCoder ~
|
|
*cp-atcoder*
|
|
URL format:
|
|
https://atcoder.jp/contests/{contest_id}/tasks/{contest_id}_{problem_id}
|
|
|
|
Usage examples: >
|
|
:CP atcoder abc324 " Set up atcoder.jp/contests/abc324
|
|
|
|
Codeforces ~
|
|
*cp-codeforces*
|
|
URL format: https://codeforces.com/contest/{contest_id}/problem/{problem_id}
|
|
|
|
Usage examples: >
|
|
:CP codeforces 1934 " Set up codeforces.com/contest/1934
|
|
|
|
CSES ~
|
|
*cp-cses*
|
|
URL format: https://cses.fi/problemset/task/{problem_id}
|
|
|
|
Usage examples: >
|
|
:CP cses dynamic_programming " Set up all problems in dp category
|
|
|
|
==============================================================================
|
|
|
|
COMPLETE WORKFLOW EXAMPLE *cp-example*
|
|
|
|
Example: Setting up and solving AtCoder contest ABC324
|
|
|
|
1. Browse to https://atcoder.jp/contests/abc324
|
|
|
|
2. Set up entire contest (bulk setup): >
|
|
:CP atcoder abc324
|
|
< This scrapes all test case data, downloads all test cases,
|
|
and opens the first problem.
|
|
|
|
3. Code your solution, then test: >
|
|
:CP run
|
|
< View test verdicts in I/O splits. For detailed analysis:
|
|
:CP panel
|
|
< Navigate tests with <c-n>/<c-p>, exit with q
|
|
|
|
4. Move to next problem: >
|
|
:CP next
|
|
< This automatically sets up the next problem (likely problem B)
|
|
|
|
5. Continue solving problems with :CP next/:CP prev navigation
|
|
|
|
6. Switch to another file (e.g. previous contest): >
|
|
:e ~/contests/abc323/a.cpp
|
|
:CP
|
|
< Automatically restores abc323 contest context
|
|
|
|
7. Submit solutions on AtCoder website
|
|
|
|
==============================================================================
|
|
I/O VIEW *cp-io-view*
|
|
|
|
The I/O view provides lightweight test feedback in persistent side splits.
|
|
All test outputs are concatenated with verdict summaries at the bottom.
|
|
The |cp-panel| offers more fine-grained analysis with diff modes.
|
|
|
|
Access the I/O view with :CP run [n]
|
|
|
|
Layout ~
|
|
|
|
The I/O view appears as 30% width splits on the right side: >
|
|
|
|
┌──────────────────────────┬─────────────────────────────────────────────┐
|
|
│ │ Output (Top Split) │
|
|
│ │ 5 510 │
|
|
│ │ │
|
|
│ │ 7 714 │
|
|
│ Solution Code │ │
|
|
│ │ Test 1: WA | 212.07/2000 ms | 1/512 MB |...│
|
|
│ │ Test 2: WA | 81.94/2000 ms | 1/512 MB |...│
|
|
│ ├─────────────────────────────────────────────┤
|
|
│ │ Input (Bottom Split) │
|
|
│ │ 1 2 3 │
|
|
│ │ │
|
|
│ │ 4 5 6 │
|
|
└──────────────────────────┴─────────────────────────────────────────────┘
|
|
<
|
|
The output split shows:
|
|
1. Concatenated test outputs (separated by blank lines)
|
|
2. Space-aligned verdict summary with:
|
|
- Test number and status (AC/WA/TLE/MLE/RTE with color highlighting)
|
|
- Runtime: actual/limit in milliseconds
|
|
- Memory: actual/limit in megabytes
|
|
- Exit code (with signal name for crashes)
|
|
|
|
Usage ~
|
|
|
|
:CP run Run all tests
|
|
:CP run 3 Run test 3 only
|
|
|
|
Navigation ~
|
|
|
|
While in the I/O view buffers, use the configured keymaps to cycle through tests:
|
|
<c-n> Next test (default, see |RunConfig|.next_test_key)
|
|
<c-p> Previous test (default, see |RunConfig|.prev_test_key)
|
|
|
|
Buffer Customization ~
|
|
|
|
Use the setup_io_input and setup_io_output hooks (see |cp.Hooks|) to customize
|
|
buffer appearance. By default, line numbers and columns are removed via
|
|
helpers.clearcol (see |cp-helpers|).
|
|
|
|
==============================================================================
|
|
PICKER INTEGRATION *cp-picker*
|
|
|
|
When picker integration is enabled in configuration, cp.nvim provides interactive
|
|
platform and contest selection using telescope.nvim or fzf-lua.
|
|
|
|
:CP pick *:CP-pick*
|
|
Launch configured picker for interactive problem selection.
|
|
Control Flow: Select Platform → Contest → Code!
|
|
|
|
Requires picker = 'telescope' or picker = 'fzf-lua' in configuration.
|
|
Requires corresponding plugin (telescope.nvim or fzf-lua) to be installed.
|
|
|
|
PICKER KEYMAPS *cp-picker-keys*
|
|
<c-r> Force refresh/update contest list.
|
|
Useful when contest lists are outdated or incomplete
|
|
|
|
==============================================================================
|
|
PANEL *cp-panel*
|
|
|
|
The panel provides full-screen test analysis with diff modes for detailed
|
|
debugging. Problem time/memory limit constraints are in columns Time/Mem
|
|
respectively. Used time/memory are in columns Runtime/RSS respectively.
|
|
|
|
Access with :CP panel or :CP panel --debug (uses debug build configuration).
|
|
|
|
Interface ~
|
|
|
|
The panel uses the following table layout: >
|
|
|
|
┌─────┬────────┬──────────────┬───────────┬──────────┬──────────┬─────────────┐
|
|
│ # │ Status │ Runtime (ms) │ Time (ms) │ RSS (MB) │ Mem (MB) │ Exit Code │
|
|
├─────┼────────┼──────────────┼───────────┼──────────┼──────────┼─────────────┤
|
|
│ 1 │ AC │ 12.0 │ 2000 │ 123 │ 256 │ 0 │
|
|
│ >2 │ WA │ 45.70 │ 2000 │ 100 │ 256 │ 1 │
|
|
├─────┴────────┴──────────────┴───────────┴──────────┴──────────┴─────────────┤
|
|
│ Input: │
|
|
│ 5 3 │
|
|
├─────┬────────┬──────────────┬───────────┬──────────┬──────────┬─────────────┤
|
|
│ 3 │ TLE │ 9.0 │ 2000 │ 256 │ 256 │ 136 (SIGBUS)│
|
|
│ 4 │ RTE │ 0.0 │ 2000 │ 256 │ 256 │139 (SIGUSR2)│
|
|
└─────┴────────┴──────────────┴───────────┴──────────┴──────────┴─────────────┘
|
|
┌─────────────────────────────────────────────────────────────────────────────┐
|
|
│ Expected vs Actual │
|
|
│ 423 │
|
|
│ 100 │
|
|
│ hello world │
|
|
└─────────────────────────────────────────────────────────────────────────────┘
|
|
|
|
Status Indicators ~
|
|
|
|
Test cases use competitive programming terminology with color highlighting:
|
|
|
|
AC Accepted (passed)
|
|
WA Wrong Answer (output mismatch)
|
|
TLE Time Limit Exceeded (timeout)
|
|
MLE Memory Limit Exceeded Error (heuristic)
|
|
RTE Runtime Error (other non-zero exit code)
|
|
NA Any other state
|
|
<
|
|
|
|
==============================================================================
|
|
INTERACTIVE MODE *cp-interact*
|
|
|
|
Run interactive problems manually or with an orchestrator. :CP interact is
|
|
available for interactive problems. Test cases are ignored in interactive mode
|
|
(no run panel, no diffs).
|
|
|
|
When using :CP interact {interactor}, the interactor must be executable
|
|
(chmod +x). Completion after :CP interact suggests executables in CWD.
|
|
|
|
1) Terminal-only ~
|
|
:CP interact
|
|
Execute the current program and open an interactive terminal running
|
|
it directly. Use this for manual testing.
|
|
|
|
2) Orchestrated ~
|
|
:CP interact {interactor}
|
|
Execute the current program and open an interactive terminal that runs
|
|
your interactor script against it.
|
|
{interactor} is an executable file relative to the CWD.
|
|
Example:
|
|
:CP interact my-executable-interactor.py
|
|
|
|
|
|
Keymaps ~
|
|
<c-q> Close the terminal and restore the previous layout.
|
|
|
|
==============================================================================
|
|
ANSI COLORS AND HIGHLIGHTING *cp-ansi*
|
|
|
|
cp.nvim provides comprehensive ANSI color support and highlighting for
|
|
compiler output, program stderr, and diff visualization.
|
|
|
|
If you cannot see color highlighting in your config, it is likely due to an
|
|
erroneous config. Most tools (GCC, Python, Clang, Rustc) color stdout based on
|
|
whether stdout is connected to a terminal. One can usually get aorund this by
|
|
leveraging flags to force colored output. For example, to force colors with GCC,
|
|
alter your config as follows:
|
|
>lua
|
|
{
|
|
commands = {
|
|
build = {
|
|
'g++',
|
|
'-fdiagnostics-color=always',
|
|
...
|
|
}
|
|
}
|
|
}
|
|
<
|
|
|
|
==============================================================================
|
|
HIGHLIGHT GROUPS *cp-highlights*
|
|
|
|
Test Status Groups ~
|
|
|
|
CpTestAC Green foreground for AC status
|
|
CpTestWA Red foreground for WA status
|
|
CpTestTLE Orange foreground for TLE status
|
|
CpTestMLE Orange foreground for MLE status
|
|
CpTestRTE Purple foreground for RTE status
|
|
CpTestNA Gray foreground for remaining state
|
|
|
|
ANSI Color Groups ~
|
|
|
|
cp.nvim preserves ANSI colors from compiler output and program stderr using
|
|
a sophisticated parsing system. Colors are automatically mapped to your
|
|
terminal colorscheme via vim.g.terminal_color_* variables.
|
|
|
|
Diff Highlighting ~
|
|
|
|
The git diff backend uses Neovim's built-in highlight groups that automatically
|
|
adapt to your colorscheme:
|
|
|
|
DiffAdd Highlights added text in git diffs
|
|
DiffDelete Highlights removed text in git diffs
|
|
|
|
==============================================================================
|
|
TERMINAL COLOR INTEGRATION *cp-terminal-colors*
|
|
|
|
ANSI colors automatically use the terminal's color palette through Neovim's
|
|
vim.g.terminal_color_* variables.
|
|
|
|
==============================================================================
|
|
HIGHLIGHT CUSTOMIZATION *cp-highlight-custom*
|
|
|
|
Customize highlight groups after your colorscheme loads:
|
|
>lua
|
|
vim.api.nvim_create_autocmd('ColorScheme', {
|
|
callback = function()
|
|
vim.api.nvim_set_hl(0, 'CpTestAC', { link = 'String' })
|
|
end
|
|
})
|
|
|
|
==============================================================================
|
|
HELPERS *cp-helpers*
|
|
|
|
The helpers module provides utility functions for buffer customization.
|
|
Access via:
|
|
>lua
|
|
local helpers = require('cp').helpers
|
|
<
|
|
Functions ~
|
|
|
|
helpers.clearcol({bufnr}) *helpers.clearcol*
|
|
Remove line numbers, columns, and signs from buffer.
|
|
Sets:
|
|
• number = false
|
|
• relativenumber = false
|
|
• signcolumn = 'no'
|
|
• statuscolumn = ''
|
|
|
|
Parameters: ~
|
|
{bufnr} (integer) Buffer handle
|
|
|
|
==============================================================================
|
|
PANEL KEYMAPS *cp-panel-keys*
|
|
|
|
<c-n> Navigate to next test case
|
|
<c-p> Navigate to previous test case
|
|
t Cycle through diff modes: none → git → vim
|
|
q Exit panel and restore layout
|
|
<c-q> Exit interactive terminal and restore layout
|
|
|
|
Diff Modes ~
|
|
|
|
Three diff backends are available:
|
|
|
|
none Nothing
|
|
vim Built-in vim diff (default, always available)
|
|
git Character-level git word-diff (requires git, more precise)
|
|
|
|
The git backend shows character-level changes with [-removed-] and {+added+}
|
|
markers.
|
|
|
|
Execution Details ~
|
|
|
|
Test cases are executed individually using the same compilation and
|
|
execution pipeline, but with isolated input/output for
|
|
precise failure analysis.
|
|
|
|
==============================================================================
|
|
FILE STRUCTURE *cp-files*
|
|
|
|
cp.nvim creates the following file structure upon problem setup: >
|
|
|
|
{problem_id}.{ext} " Source file
|
|
build/
|
|
{problem_id}.run " Compiled binary
|
|
io/
|
|
{problem_id}.n.cpin " nth test input
|
|
{problem_id}.n.cpout " nth test expected output
|
|
<
|
|
==============================================================================
|
|
HEALTH CHECK *cp-health*
|
|
|
|
Run |:checkhealth| cp to verify your setup.
|
|
|
|
vim:tw=78:ts=8:ft=help:norl:
|