Skylark Editor: a C text and hex editor with a Lua engine and a SQL client

What Skylark Editor is trying to be

Skylark Editor is a customizable text and hex editor, described as small, portable and fast, and the project makes a startup-time comparison explicitly: compared with vs code, atom, and more editors, it can start up in less than a second. The editor is written in C, and the project description calls it a high performance text and hex editor.

What makes it more than an editor is the list of things built into the same binary. The feature list covers a built in file manager and an SFTP remote manager, a binary and hex viewer for files of unlimited size, encryption and decryption of common key algorithms, Perl Compatible Regular Expression, AI-powered chat integration, support for many encodings, syntax highlighting for a lot of languages, SumatraPDF plugin support, clang-format support, code snippet support, and dark mode.

Several of those are not editor features at all. An embedded database client, a Redis client and a Lua engine live in the same process, and the project description says you can run Lua scripts and SQL files directly. Screenshots in the documentation show the editor executing a Lua script, executing SQL, parsing JSON, viewing a hex file, running under Wine on Linux, and an AI chat panel.

The audience is a Windows developer or administrator who wants a single portable tool rather than a suite of applications. A C binary that starts in under a second and runs on a machine with nothing installed is a different proposition from an Electron editor.

The project is hosted on SourceForge, under the libportable project, which is where the release archives live, and the source is mirrored in this repository.

The build is nmake against a vendored dependency tree

Building Skylark Editor uses Microsoft's nmake, and the documentation gives two configurations, vc14 or above with the standard toolchain, and the same build driven by clang-cl.

For the standard toolchain the two commands are:

      nmake clean
      nmake

And with clang-cl the compiler is passed on the make command line:

      nmake CC=clang-cl clean
      nmake CC=clang-cl

Passing the compiler through CC rather than a separate target is the detail that makes the second configuration work at all, and it is the only difference between the two.

The root Makefile is a thin wrapper. It includes a system.mak file, then the all target walks the vendored third party libraries one at a time, invoking nmake in each of their directories before descending into src, then into plugins/pdfview, then into locales. The library list in the Makefile is the clearest statement of what the editor is built on: sqlite3 for the database client, pcre for the regular expression support, libiconv for the encoding handling, luajit as the Lua engine, chardet for character detection, qrencode, tinyexpr, expat for XML parsing, and scintilla as the editing component itself.

Scintilla is the reason the editor behaves the way it does. It is the same component behind many other editors, and it explains both the syntax highlighting for a lot of languages and the fact that the interface has its own conventions rather than the ones you would find in a mainstream editor.

The build is Windows native. The Makefile uses nmake syntax throughout, including the !IF and !include directives and backslash paths, so the Linux build path visible in the documentation is the Wine screenshot rather than a native build.

The Lua engine and the example hooks

The most distinctive capability in the feature list is the Lua engine, and the repository documents it through a set of example scripts rather than through prose.

The examples/ directory holds a README and a group of scripts named after the editor event they hook: editor_init.lua, editor_keyup.lua, editor_minimize.lua, editor_mouseup.lua, editor_restored.lua, editor_save.lua, editor_saveas.lua, editor_seletion.lua, editor_shutdown.lua, plus a loader/ directory. The naming is the documentation. A script binds to a lifecycle event, and the editor calls it when that event fires.

That is a scripting model for automating the editor itself rather than for running a task inside it. A keyup hook can react as you type, a save hook can run a formatter or a linter over the file, a save-as hook can rewrite a path, and an init hook can configure the session when the editor opens.

The feature list mentions code snippet support alongside this, and the repository topics include code-snippets, so snippets and the event hooks appear to be two ways of building the same kind of automation.

The tinyexpr dependency in the Makefile is the expression evaluator, and the clang-format support in the feature list pairs with the same automation story: a save hook that shells out to clang-format is exactly the kind of thing these hooks exist for, and the documentation has a screenshot of clang-format in use.

The embedded clients: SQL, Redis, SFTP and encryption

The database and remote access features are what make Skylark Editor more than a text editor with a hex view.

The SQL client is built on the vendored sqlite3, and the documentation shows a screenshot of executing SQL directly, plus a separate one of JSON parsing. The project description also names a Redis client alongside the embedded database client, and the repository topics list database-client, which covers both.

The SFTP remote manager is the other half. You open remote files over SFTP in the same window you edit local ones, and the topics list sftp-client. For someone working on configuration files on a server, that removes the step of downloading, editing and uploading.

The hex viewer is described as handling files of unlimited size, which is the interesting claim in that list. A hex view is normally a memory problem, because the naive implementation maps the whole file, and the fact that the documentation calls this out suggests the implementation streams rather than loads. Combined with the binary viewer and the editor's own Scintilla base, you can flip between a structured text view and the raw bytes of the same file.

The encryption feature covers common key algorithms, and Perl Compatible Regular Expression is a separate line in the feature list, which is a separate regular expression library rather than the platform regex.

What is missing from the feature list is as informative as what is in it. There is no mention of collaborative editing, of plugin ecosystems beyond the plugins/ directory, of version control integration, of a language server, or of a test runner. The SumatraPDF plugin and the clang-format integration are named, but they are integrations rather than a framework.

Where Skylark Editor is the wrong tool

The first limit is the release model. The recent releases are named 20260709065830, 20260325063123 and 20260317110257, which are build timestamps rather than version numbers. There is no semantic versioning, no changelog to diff and no tag you can pin to a known state. For a tool you distribute to a team, that is a real problem, and it is the shape of a project that ships whatever the last build produced.

The second is the platform. The build is nmake with Windows paths, the Makefile is full of !IF and !include directives, and the Linux evidence in the documentation is a screenshot of the editor running under Wine. So the portability claim in the project description means a single Windows binary that can run on other platforms through a compatibility layer, not a native build for each one. If you are on Linux and want a native editor, this is not the one.

The third is the editing model. Scintilla gives you a fast editing component, but the interface around it is the author's own, and the documentation's own framing, a customizable editor compared against vs code and atom, concedes that you are learning a different set of conventions. The plugins/ directory holds a pdfview plugin, and the topics list an npapi-plugin, so extension points exist, but there is no visible marketplace or large plugin set to lean on.

The fourth is the combination of features as a design risk. A single binary that opens local files, remote SFTP files, SQL databases, Redis, binary blobs and runs Lua in the same address space has a large surface. That is what makes it useful as a field tool for a sysadmin, and it is also why the AI chat integration, which the feature list describes only as enabled, is worth evaluating carefully on a machine that holds credentials.

Compare that with running a general purpose editor plus separate tools. The difference in approach is that Skylark collapses the toolchain into one process, so a change to a remote file, a database query and a Lua script all happen in one window, at the cost of a component layout that a small project maintains alone.

Licence, packaging and what an upgrade looks like

Skylark Editor is released under the GPL-3.0 licence, with the text in the LICENSE file at the repository root. The strong copyleft terms are the part to think about before you ship the binary: the obligation to offer source applies to a distributed binary, which includes the vendored libraries compiled into it. Read the LICENSE file yourself and take your own advice on the specifics, because this is not legal advice and the practical question depends on how you distribute the tool.

The packaging is handled by a separate target. The package target depends on all, and under a 64-bit configuration it removes any previous package directory, recreates it, and copies the built binaries into a skylark_x64 folder while deleting the .pdb symbol files, and there is a matching archive step for a .7z. The Release History file in the tree, along with the date-stamped release names, is how the project records what changed.

The repository layout matches a project that bundles its dependencies rather than fetching them. The src/ directory holds the editor, src/3rdparty holds the vendored libraries that the Makefile walks, plugins/ holds the pdfview plugin, locales/ holds the translations and is built as its own step, conf/ holds configuration, resources/ holds shared resources, share/ holds data, and there is a system.mak included at the top of the Makefile.

The repository is not archived, and the last push was on 2026-07-09, which is the same day as the most recent release, 20260709065830. So the tree is a little over three months old relative to today and the project is still being worked on, but the version naming means you cannot say which state you are running beyond a date.

For an upgrade, the practical step is to take the new archive, note its timestamp, and diff the configuration and plugins you carry yourself, because the project gives you no version numbers to compare.

Editorial conclusion

Skylark Editor fits a Windows developer or sysadmin who wants one small binary that opens text, binary files and remote files over SFTP, and who wants to script the editor with Lua or run SQL against a database from the same window. It does not fit a team that expects a conventional release cadence or a familiar text editing model, because the releases are named after their build timestamp and the interface is a Scintilla based editor with its own conventions. Before adopting it, build it with the compiler you intend to ship with, since the Makefile is nmake and Windows specific, and check the LICENSE file yourself, because GPL-3.0 obligations follow any binary you redistribute.

Frequently asked questions

Official sources

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