CP Editor: six verbs in a tagline and an index for a README

Fetch, Code, Compile, Run, Check, Submit: none of it is in the README

The repository description is the whole feature specification: The IDE for competitive programming, followed by six verbs, Fetch, Code, Compile, Run, Check, Submit.

Read as a workflow, those six verbs are a complete description of a competitive programming session. You fetch the problem statement, you write the code, you compile it, you run it, you check it against the problem's sample tests, and you submit it to the judge. That is the loop, and the ordering is the point: the tool is built around the judge's contract rather than around general editing.

Now read the README. It is an index. The features link goes to cpeditor.org, the documentation to cpeditor.org/docs, the changelog to CHANGELOG.md, the contributing guide to CONTRIBUTING.md and the FAQ to a website page. The Get Started section is four links: Releases, Installation, Get Started, Preferences, Tips. The rest is a release table, a donate section, a contributing section, a feedback section, a packaging badge and an all-contributors table.

So an evaluator gets a tagline and a table of contents. There is no feature description, no keyboard shortcut list, no description of the supported judges, no statement of which compilers it invokes, and no explanation of what Check actually does. The repository topics do fill in some of the gap: acm, acm-icpc, algorithm-competitions, codeforces, competitive-programming, icpc, oi, cpp, java, python and cross-platform. That tells you the intended contests and the three languages, and it tells you this is a desktop application rather than a web tool, since the primary language is C++ and qt5 is in the topic list.

Whether that is a problem depends on what you are looking for. A user who already knows the domain will find the workflow obvious and will go to the documentation. A user evaluating a competitive programming IDE for the first time has to take the tagline on trust, and there is nothing in the repository to corroborate it. That is an unusual amount of trust to ask, and the repository listing is where the rest of the evidence has to come from.

Three release branches, and the beta train ships nowhere

The release table in the README is the most information-dense thing in it, and it has a column that is easy to miss.

There are three release trains, each on its own branch. master is labelled alpha, with the GitHub Actions build badge, an AUR package called cpeditor-git and a snap channel on edge. v7.1 is labelled beta, with its own branch, its own build badge and a download count for release 7.1.1, but its AUR column is a dash and its snap column is a dash. v7.0 is labelled stable, with the release 7.0.2 download count, a non-git AUR package called cpeditor and a snap channel on stable.

So the stable and alpha trains each have two distribution channels beyond GitHub releases, and the beta train has none. A user who reads the table, installs the AUR package on Arch and then decides to try the beta gets nothing to install. The only route is the GitHub release for 7.1.1, which means a manual download and, on Linux, a binary the user has to trust without a distribution channel's review behind it.

Whether that is a defect or a policy is not stated. Some projects deliberately keep beta out of package managers to avoid shipping something half-finished to users who did not ask for it. Others simply have not got to it. The repology badge at the bottom of the README reports packaging status across repositories, and the line beneath it invites package maintainers to get in touch, offering to add scripts to the CI/CD workflow. That is a collaborative posture, and a project with that posture is more likely to have chosen the beta gap deliberately than to have missed it. The README does not say.

The three-branch scheme itself is a good design for a desktop application, and the naming is unambiguous. Getting the wrong one is a matter of reading the table rather than understanding the project: master is not where stable users should be, and v7.0 is not where you find the newest code.

Two tags two seconds apart, and six months of nothing since

The release timestamps in this repository are unusual enough to be worth reading twice.

The three most recent releases are 7.0.1 dated 2024-02-17, then 7.0.2 and 7.1.1 both dated 2026-04-05, at 13:14:10 and 13:14:12. Two tags, cut two seconds apart, on the same afternoon more than two years after the previous release.

That pattern says a release was prepared, then almost immediately adjusted. The 7.0.2 patch and the 7.1.1 minor were both published from the same preparation run, which usually means something in the packaging or metadata needed a correction after the first tag went out. The 7.0.1 gap before it is the other half of the picture: the stable line went two years and change without a patch release, which for a desktop application means either that nothing needed fixing or that fixes were accumulating on master and not backported to v7.0 until this release.

The last push was on 2026-09-24, so the default branch is being worked on. That is roughly six months of commits after 7.1.1, and the release table's alpha row still points at master with the cpeditor-git AUR package and the edge snap channel, so the untagged work is reachable through two package channels even though it has no version number.

Two consequences follow. If you are on the stable channel, the AUR or snap package gives you 7.0.2 and you are six months behind the alpha packages. If you are on alpha, you have code that has never been through a release cut, which means no changelog entry, no announcement and no tag to diff against. The CHANGELOG.md at the repository root is the place to check what has accumulated, and it is one of the few substantive documents the repository actually contains.

VERSIONING.md sits alongside it, and its existence is a positive signal. A project that publishes a release branches, a stable branch, a beta branch, a changelog, an all-contributors table and a versioning policy has thought about how a user should move between them. The dates in the tag list are the part that does not quite match the tidiness of the arrangement.

CMake, clang-format, clang-tidy, and a third_party from submodules

The repository listing describes a C++ project that takes its build hygiene seriously, and the specific tools tell you what kind of project it is.

The build is CMake. There is a CMakeLists.txt at the root and a cmake/ directory, which is the modern layout where version, toolchain and helper modules are kept out of the top-level file. For a Qt5 application that has to build on Linux, Windows and macOS, CMake is the expected choice, and the cross-platform topic is consistent with it.

The C++ tooling is configured rather than assumed. Both .clang-format and .clang-tidy are at the root, which means formatting is mechanical and enforced by a tool rather than by reviewer memory, and static analysis is configured with an explicit rule set. That is a stronger position than most desktop applications of this size hold, and it is invisible in the README.

Then there is .gitmodules, alongside a third_party/ directory. Vendored dependencies tracked as submodules is a deliberate choice with a specific cost. It keeps the dependency history visible in the project's own tree and pins exact upstream revisions, which is good for reproducibility and bad for supply-chain surface, because you now have to trust a set of pinned commits that nobody re-reviews when upstream publishes a security fix. The alternative, a manifest of versions resolved at build time, inverts that trade. Neither is wrong, and the README does not say which philosophy is behind this one.

The rest of the tree is ordinary and informative. src/ is the application, ui/ is the interface, resources/ holds assets including the icon.ico the README displays, translations/ holds the localisation catalogues, dist/ is packaging output, and tools/ is the scripts that produce it. A tools/ directory in a project that invites distribution maintainers to ask for CI changes is where those scripts would live, which is a coherent structure rather than a coincidence.

Seventeen translated files and a written versioning policy

The translation effort here is larger than the code base of most projects this size, and the pattern of it is worth naming precisely.

There are seven READMEs: README.md plus README_el-GR.md for Greek, README_ja-JP.md for Japanese, README_pt-BR.md for Brazilian Portuguese, README_ru-RU.md for Russian, README_zh-CN.md for Simplified Chinese and README_zh-TW.md for Traditional Chinese. There are five CONTRIBUTING files covering Japanese, Brazilian Portuguese, Russian, Simplified Chinese and Traditional Chinese. There are five DONATE files for the same five languages. That is seventeen translated or translation-adjacent files, and the asymmetry is the interesting part: Greek and Russian get a translated README but not a translated contributing guide or donation page, while the five Asian and Portuguese languages get all three.

That maps onto where the project's contributors and users are. The all-contributors block at the bottom of the README shows a maintenance and translation emoji legend per contributor, and the first entry links a commit history under a maintenance-ouuan anchor for Yufan You. The translation effort has an owner, which is the difference between a project with seventeen translation files and a project with three abandoned ones.

The single most valuable document in the repository is not any of those. It is VERSIONING.md, sitting next to CHANGELOG.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, DONATE.md and DONORS.md. A project with three release branches, a stable and a beta channel, an alpha package and a versioning policy has answered the question that trips up most desktop application users, which is what they are supposed to install and what happens when they upgrade. The README links the changelog and the contributing guide but not the versioning guide, which is an omission in an otherwise careful index.

The .all-contributorsrc file at the root is the configuration for the contributors table, and .misspell-fixer.ignore lists paths excluded from automated spelling correction. That second file is a small human touch: it says someone hit a spell checker on a word that was correct and decided to record the exception rather than reword the text.

Sponsors, donors, and a discussion board titled Make complaints

The funding and feedback sections are the two most unusual parts of this README, and both are worth reading for what they reveal about the project's posture.

Funding runs through four channels, which is a lot of channels. There is a GitHub Sponsors badge, a DONATE.md explaining how to donate, a DONORS.md listing donors, and a Product Hunt featured badge for a specific post. The DONORS.md file, the existence of which is the point, means the project publishes who funds it. That is a transparency choice, and for a GPL-3.0 application distributed through package managers as well as releases it is a reasonable one: you can see whether the money comes from one person, a company, or a scattering of individuals.

The feedback section is the part I would single out. It gives four routes with different purposes: a Q&A discussion category where you are asked to mark an answer when you get a helpful reply, an Ideas discussion category, a formal feature request or bug report as an issue with a detailed description, and then two specific discussions with titles. One is titled Say thanks, linking discussion 755. The other is titled Make complaints, linking discussion 760.

A permanent, pinned discussion titled Make complaints is an unusual thing to find. Most projects have a code of conduct and a support channel, and both are transactional: something has gone wrong and here is where to say so. A standing complaints thread, with a fixed number, that a project points at from its own front page is a different gesture. It says the complaints are expected, that there is somewhere to put them that is not a bug tracker, and that raising one is a normal use of the project rather than an escalation.

The two discussions being numbered in the seven hundreds also tells you the discussion board is where the community lives, and the numbers imply a long history of questions and ideas. For a project with a single visible maintainer, that is the mechanism by which a community accumulates, and CODE_OF_CONDUCT.md sitting alongside it is the other half of the arrangement.

GPL-3.0, a repology badge, and an open door to packagers

The licence is GPL-3.0 with a LICENSE file at the root, and for a desktop application distributed through GitHub releases, an AUR package and a snap channel, that is the constraint that governs redistribution.

GPL-3.0 requires that anyone distributing a modified version publishes the corresponding source, and it requires that the licence travels with the work. For end users installing a binary from an official channel, that costs nothing. For a distribution that wants to patch it, bundle it with a proprietary application or embed parts of it in a larger product, the obligation is real and it is the kind of thing that gets discovered late. This is not a defect in the choice; a competitive programming IDE is exactly the sort of project that should be copyleft, and the presence of the licence file means the terms are discoverable.

The packaging story is the more useful part for an adopter. There is a repology badge reporting packaging status across all repositories, which is the standard way to find out whether your distribution already carries the software and at what version. And the line under it is an unusual sentence: package maintainers can contact us if any help is needed, for example we may add some scripts in our CI/CD workflow.

That is a maintainer offering to modify their own CI so a downstream distribution's build works better. It is a small thing and it is a strong signal, because most projects make downstream packagers reverse-engineer their release process from a tarball. Offering to add scripts means the release artefacts and the build are expected to be a conversation rather than a hand-off. It also explains the beta channel gap as a deliberate choice rather than an oversight: a project that coordinates packaging this closely is unlikely to have accidentally omitted one channel.

The last push was on 2026-09-24 and the newest release is 7.1.1 from 2026-04-05, so the pattern is a project with steady development and periodic releases, three supported channels, and a documentation site rather than a repository that tells you what the software does. For someone who knows competitive programming that is a perfectly reasonable arrangement. For someone deciding whether to adopt it, the questions to ask are about the branch you want and where you will get it, and both are answerable from the table at the top of the README.

Editorial conclusion

Adopt CP Editor if you compete on Codeforces, the ICPC or national OI circuits and you want problem fetching, test-case checking and judge submission in one Qt5 window with a built-in compiler, rather than assembling that from a browser, an editor and a script. Do not adopt it if you are on the beta train expecting a packaged build, because the release table in the README shows v7.1 with no AUR package and no snap channel, only GitHub releases. Do not package it for a distribution without reading VERSIONING.md and the packaging status badge, because the project asks maintainers to get in touch and offers CI changes, which is a collaboration invitation rather than a finished integration guide. Verify four things. Pick a branch deliberately: master is alpha, v7.0 is stable and v7.1 is beta, and the last push was on 2026-09-24 while the newest release is 7.1.1 from 2026-04-05, so the branches are at different states of completion. Read the installation documentation before installing, since the README links it and contains no install steps itself. Confirm the language toolchain your contest allows, since the topic list names C++, Java and Python alongside a Qt5 C++ host application. And check the repology packaging status for your distribution rather than assuming a package exists. The deciding fact is that this is a single-maintainer-shaped desktop tool with a strong translation and packaging culture, and the six verbs in the tagline are its entire feature claim.

Frequently asked questions

Official sources

1. cpeditor/cpeditor on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases