If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/notepad-plus-plus/notepad-plus-plus shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 30+ active contributors
• Distributed ownership (top contributor 32% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live notepad-plus-plus/notepad-plus-plus repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/notepad-plus-plus/notepad-plus-plus.

What it runs against: a local clone of notepad-plus-plus/notepad-plus-plus — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in notepad-plus-plus/notepad-plus-plus | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of notepad-plus-plus/notepad-plus-plus. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/notepad-plus-plus/notepad-plus-plus.git
#   cd notepad-plus-plus
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of notepad-plus-plus/notepad-plus-plus and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "notepad-plus-plus/notepad-plus-plus(\\.git)?\\b" \\
  && ok "origin remote is notepad-plus-plus/notepad-plus-plus" \\
  || miss "origin remote is not notepad-plus-plus/notepad-plus-plus (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "PowerEditor/Test/FunctionList" \\
  && ok "PowerEditor/Test/FunctionList" \\
  || miss "missing critical file: PowerEditor/Test/FunctionList"
test -f ".github/workflows/CI_build.yml" \\
  && ok ".github/workflows/CI_build.yml" \\
  || miss "missing critical file: .github/workflows/CI_build.yml"
test -f "BUILD.md" \\
  && ok "BUILD.md" \\
  || miss "missing critical file: BUILD.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "LICENSE" \\
  && ok "LICENSE" \\
  || miss "missing critical file: LICENSE"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/notepad-plus-plus/notepad-plus-plus"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Notepad++ is a free, open-source code editor for Windows that provides syntax highlighting, code folding, and language support for 100+ programming languages via its built-in lexer system. It's a lightweight Notepad replacement with extensibility through plugins (UDL 2.0 and Scintilla-based), making it the go-to text editor for Windows developers who want something faster and more feature-rich than Notepad or VS Code alternatives. Monolithic C++ desktop application: PowerEditor/ contains the main UI and editor engine; PowerEditor/Test/ holds language-specific function parsing tests (ada/, cpp/, bash/, etc. with unitTest files and .expected.result golden files); .github/workflows/ manages Windows CI builds. Scintilla lexer library provides syntax coloring; Function List system uses XML config for code structure extraction per language.

Windows developers, sysadmins, and technical writers who need a fast, low-overhead text editor with excellent syntax highlighting, find-and-replace, and code navigation—without the overhead of full IDEs. Contributors are primarily Windows C++ developers and linguists adding language support via Function List and UDL configurations.

Highly mature and actively maintained since 2003. The codebase is 13.3M lines of C++ with comprehensive test suites in PowerEditor/Test/, CI/CD via GitHub Actions (.github/workflows/CI_build.yml), and GPG-signed releases (last key valid through 2027). Production-ready with stable Windows API integration and regular security/feature updates.

Low risk for end-users but Windows-specific—zero support for Linux/Mac despite requests. Codebase is large (13.3M C++) and the maintainer group is small, creating single-person bottleneck risk. Plugin ecosystem uses legacy NPAPI (not modern plugin standards), and updates can break third-party plugins without warning.

Active development on language support (evidenced by extensive FunctionList test directories for 50+ languages) and Windows compatibility (GitHub Actions CI in CI_build.yml). Recent focus on GPG signing releases and community issue triage. Dependabot enabled (.github/dependabot.yml) suggests ongoing dependency updates.

git clone https://github.com/notepad-plus-plus/notepad-plus-plus.git
cd notepad-plus-plus
cat BUILD.md  # Read Windows-specific build instructions (Visual Studio required)

Build requires Visual Studio 2019+ on Windows; no Linux/Mac builds supported. Follow BUILD.md for compiler flags and Scintilla submodule setup.

Daily commands: This is a compiled Windows desktop app, not a dev server. Build steps: open PowerEditor/visual.cpp/.sln in Visual Studio → compile → run notepad++.exe. No npm/Python scripts visible for local dev. See BUILD.md for detailed compilation flags and dependencies.

• PowerEditor/Test/FunctionList — Core test suite directory containing language-specific function list parsing tests that validate the parser's correctness across 30+ programming languages.
• .github/workflows/CI_build.yml — GitHub Actions workflow that orchestrates the continuous integration pipeline; understanding this reveals how the project builds and tests on every commit.
• BUILD.md — Essential documentation for building Notepad++ from source; required reading before any local development or contribution.
• CONTRIBUTING.md — Official contribution guidelines defining the project's standards, workflow, and expectations for all contributors.
• LICENSE — GPL License governing the entire codebase; critical to understand legal obligations and restrictions when contributing.
• .github/ISSUE_TEMPLATE — Issue template configurations that define how bug reports and feature requests are structured; shapes project communication.

• Function List Parser (C++ regex engines, language-specific parsing rules) — Parses source code in 30+ languages to extract and display function/class definitions in sidebar panel
  • Failure mode: Incorrect or missing functions in function list; malformed parse results; failure to recognize language-specific syntax variations
• Test Suite (Language Validators) (PowerShell test automation, golden file comparison (unitTest.expected.result)) — Validates function list parser correctness across all supported languages and edge cases
  • Failure mode: False positives in testing (missing regressions); parser changes breaking existing functionality; language support degradation
• CI/CD Pipeline (GitHub Actions, Windows build agents, PowerShell scripts) — Automates build compilation, test execution, and release notifications on every commit
  • Failure mode: Undetected build breaks; broken commits merged to master; delayed community notifications
• Text Editor Core (C++ Win32 API, Scintilla editor component) — Main Notepad++ application providing file editing, syntax highlighting, multi-tab interface
  • Failure mode: Editor crashes; data loss; UI freezes; file encoding issues; performance degradation

• Developer → Git Repository — Commits code changes to PowerEditor or test suite
• Git Repository → GitHub Actions CI — Push event triggers CI_build.yml workflow
• GitHub Actions CI → Build System — Initiates Windows C++ compilation of Notepad++ source
• Build System → Function List Tests — Executes localUnitestLauncher.ps1 to run parser validation
• Function List Tests → Expected Result Files — Compares actual parser output against unitTest.expected.result golden files
• Test Results → GitHub Actions CI — Reports pass/fail status back to CI workflow
• GitHub Actions CI → Release Notifier — Triggers release-notifier.yml on successful builds to notify community
• Release Notifier → Community — Distributes release notifications to users and subscribers

Add Support for a New Programming Language

1. Create a new language subdirectory under PowerEditor/Test/FunctionList/{language} (PowerEditor/Test/FunctionList)
2. Add unitTest source code file demonstrating function/class definitions in the target language (PowerEditor/Test/FunctionList/{language}/unitTest)
3. Create unitTest.expected.result file with the expected function list parser output (PowerEditor/Test/FunctionList/{language}/unitTest.expected.result)
4. Run localUnitestLauncher.ps1 to validate that the parser produces correct results (PowerEditor/Test/FunctionList/localUnitestLauncher.ps1)

Add Edge Case Tests for Existing Language

1. Create a subdirectory under the language folder (e.g., python/baddeftest) for the specific test case (PowerEditor/Test/FunctionList/{language})
2. Add unitTest file with edge case code (malformed syntax, unusual patterns) (PowerEditor/Test/FunctionList/{language}/{testcase}/unitTest)
3. Create unitTest.expected.result with expected parser behavior for edge cases (PowerEditor/Test/FunctionList/{language}/{testcase}/unitTest.expected.result)

Contribute Code Changes

1. Read CONTRIBUTING.md to understand development workflow and standards (CONTRIBUTING.md)
2. Read BUILD.md to set up local build environment and compilation process (BUILD.md)
3. Add or modify tests in PowerEditor/Test/FunctionList for affected language parsers (PowerEditor/Test/FunctionList)
4. Run CI_build.yml workflow locally or submit PR to trigger automated validation (.github/workflows/CI_build.yml)

• C++ (PowerEditor core) — Native Windows application development with performance and tight OS integration requirements; low-level text editing demands
• Windows-only (MS Windows environment) — Explicitly scoped to Windows platform; leverages native Win32 APIs and Windows-specific optimization
• GPL License — Free and open-source mandate; ensures code remains freely available and modifiable by community
• GitHub Actions (CI/CD) — Automated testing and release workflows; validates code quality and enables reproducible builds on every commit
• PowerShell test launcher — Windows-native scripting for executing test suites locally; aligns with Windows development workflow

• Windows-only platform support

  • Why: Tighter integration with Windows APIs and native performance optimization
  • Consequence: Excludes Linux/macOS users; requires native Windows build tools and SDK; larger addressable market on Windows desktop

• Separate test expectations per language variant

  • Why: Captures language-specific nuances and edge cases (e.g., Python baddeftest, C++ variant 1)
  • Consequence: Increases test maintenance burden; ensures high parser accuracy; allows regression detection across language versions

• Manual expected result files (unitTest.expected.result)

  • Why: Explicit validation of parser correctness; human-readable golden standards
  • Consequence: Tests require manual maintenance when parser behavior changes intentionally; prevents silent regressions; enables clear diff reviews

• Cross-platform support (explicitly Windows-only)
• Plugin/extension API (not mentioned in visible codebase; tests focus on core functionality)
• Real-time collaborative editing
• Cloud synchronization of files
• Linux or macOS support

• Duplicate test structure across languages — PowerEditor/Test/FunctionList/{language}/*: Each language folder manually replicates unitTest + unitTest.expected.result structure; no shared test framework or reusable components. Increases maintenance burden and inconsistency risk across 30+ languages.

Windows-only: Codebase uses Win32 API extensively; cross-platform builds will fail. Visual Studio required: GCC/Clang not supported; must use MSVC. Scintilla submodule: Git clone must include --recurse-submodules or manually init scintilla/. Function List test format: Golden files (.expected.result) are brittle; any parser change requires manual regeneration. Plugin ABI fragile: NPAPI layout changes break plugin DLLs across versions. No modern build system: Relies on .sln files and hardcoded paths, not CMake.

• Scintilla Lexer System — Core to Notepad++'s syntax highlighting—understanding lexer plugins and token-based coloring is essential for extending language support
• UDL 2.0 (User-Defined Language) — Allows non-programmer users to define syntax highlighting for custom languages via XML config; fundamental to Notepad++'s extensibility model
• Function List XML-based Parsing — Powers the 'Functions' sidebar showing code structure (classes, functions, procedures); uses regex and XML templates to extract symbols per language
• Win32 API Message Loop — Notepad++ is built on Win32 windowing and message passing; contributors must understand hwnd, WM_* messages, and Windows event handling
• NPAPI (Netscape Plugin Architecture) — Legacy plugin system used by Notepad++; understanding DLL export conventions and plugin lifecycle is required for plugin development
• Golden File Testing (Regression Testing) — PowerEditor/Test/ uses .expected.result golden files to validate parser output; critical for maintaining language support quality and detecting regressions

• scintilla/scintilla — Syntax highlighting and code editing component—Notepad++ wraps this C++ library for lexing and rendering
• vim/vim — Alternative text editor with broader OS support and plugin ecosystem; often compared head-to-head with Notepad++
• microsoft/vscode — Modern cross-platform code editor replacing Notepad++ for many users; Electron-based vs Notepad++'s native Win32
• geany/geany — Lightweight GTK-based code editor offering similar features (syntax highlighting, plugins) with Linux/Mac support
• emacs-mirror/emacs — Classic extensible text editor; many power-users choose Emacs over Notepad++ for advanced scripting capabilities

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add missing FunctionList test files for Fortran and Haskell

The FunctionList test structure shows that Fortran, Fortran77, and Haskell have unitTest.expected.result files but are missing the corresponding unitTest input files. This breaks the test symmetry and prevents actual function parsing validation for these languages. Adding these test cases ensures parsing accuracy across all supported languages.

• [ ] Create PowerEditor/Test/FunctionList/fortran/unitTest with representative Fortran code samples
• [ ] Create PowerEditor/Test/FunctionList/fortran77/unitTest with representative Fortran77 code samples
• [ ] Create PowerEditor/Test/FunctionList/haskell/unitTest with representative Haskell code samples
• [ ] Verify the test input files generate results matching the corresponding .expected.result files
• [ ] Document the test case structure in BUILD.md or CONTRIBUTING.md if not already present

Implement automated FunctionList regression test in CI pipeline

PowerEditor/Test/FunctionList/ contains 30+ language-specific test cases with expected outputs, but there's no evidence of automated testing in .github/workflows/CI_build.yml. Adding a CI step to validate that all unitTest files produce their corresponding .expected.result outputs would catch regressions early and ensure language parsing consistency across releases.

• [ ] Create a test runner script (e.g., PowerEditor/Test/FunctionList/run_all_tests.ps1 or .sh) that compares unitTest outputs against .expected.result files
• [ ] Add a new job to .github/workflows/CI_build.yml to execute the FunctionList test suite on each commit
• [ ] Configure the workflow to report detailed diffs when tests fail, highlighting which language parsers regressed
• [ ] Document the new test workflow in BUILD.md with instructions for local testing

Add GPG public key file and signature verification documentation

The README mentions 'Notepad++ GPG Release Key' as a section header but provides no actual content, key data, or verification instructions. This is critical for security-conscious users downloading releases. Adding the public key and documentation would improve release transparency and user trust.

• [ ] Obtain the official Notepad++ GPG public key and add it to a new file: notepad-plus-plus.gpg.pub (or similar)
• [ ] Complete the README.md 'Notepad++ GPG Release Key' section with key fingerprint, download instructions, and usage examples
• [ ] Add a SECURITY.md file documenting the GPG key, signature verification process, and security reporting procedures
• [ ] Document where signatures for releases are published (likely in release notes or artifacts)
• [ ] Update CONTRIBUTING.md to specify GPG signing requirements for maintainers during releases

• Add Function List test cases for under-tested languages (e.g., Dart, Zig, Nim visible in file counts but with minimal PowerEditor/Test/FunctionList entries)—create unitTest input files and run parser to generate expected output
• Document UDL 2.0 syntax in a SYNTAX.md file since PowerEditor/src has XML schemas but no user-facing guide for custom language definitions
• Add GitHub Discussions link to ISSUE_TEMPLATE.md (currently points to community.notepad-plus-plus.org) to funnel non-bug conversations away from issue tracker

Notepad++ demonstrates a reasonably secure baseline as a native Windows application written in C++. The codebase shows good security practices including: GPL licensing transparency, use of GitHub Actions for CI/CD, and Dependabot configuration for dependency management. However, there are areas for improvement: the absence of a formal SECURITY.md file hampers responsible disclosure, dependency vulnerability information could not be fully assessed due to incomplete package files provided, and extensive test files should be audited for unintended information leakage. No obvious injection risks, hardcoded credentials, or infrastructure misconfigurations were identified in the provided file structure. The application's native Windows nature provides inherent isolation benefits compared to web applications.

• Low · Missing Security Policy Documentation — Repository root. No SECURITY.md or security policy file found in the repository root. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file with responsible disclosure guidelines and contact information for reporting security issues.
• Low · Incomplete Dependency Management Visibility — Multiple (build configuration files not provided). No package manager files (package.json, requirements.txt, .csproj, etc.) were provided in the analysis. This prevents assessment of third-party dependency vulnerabilities. Fix: Implement dependency scanning tools (Dependabot, OWASP Dependency-Check) in CI/CD pipeline. The repository appears to use Dependabot (.github/dependabot.yml) which is positive.
• Low · Test File Security Considerations — PowerEditor/Test/FunctionList/* (test files across multiple languages). Numerous test files and expected results are present in the repository. These could potentially contain sensitive patterns or test data that should be reviewed for unintended information disclosure. Fix: Audit test files to ensure they don't contain hardcoded credentials, API keys, or sensitive patterns. Consider adding pre-commit hooks to prevent accidental secrets in test files.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.