wxMEdit is a hex and text editor that opens files up to 32GB

A hex editor and a text editor in one window

wxMEdit is a cross platform text and hex editor written in C++ and wxWidgets, and it is an improved version of MadEdit, which has been discontinued. That lineage explains the shape of the project. MadEdit was a capable editor with a large set of encodings and a hex mode, and when it was discontinued the community needed a maintained fork, so wxMEdit continues the code and the feature set rather than reinventing it. The feature list in the project description is the pitch. Bookmark, syntax highlightings, word wraps, encodings, column and hex modes, and updates checking. The one number worth pausing on is the file size. In HexMode, wxMEdit can open large files whose size is up to 32GB, which the documentation puts as INT_MAX times 16, and that is the practical reason a hex editor is still worth having rather than a hex viewer. When you are looking at a disk image or a large binary, a tool that loads the whole thing into a view model behaves very differently from one that streams it.

The build is where the real friction is

The supported platform list is thorough, and the requirements are explicit. On Linux, BSD, macOS, OpenIndiana, other Unix-like systems and Haiku OS, using the GTK build, you need GNU C++ 3.x or higher or clang++ 2.8 or higher, and the libraries are wxWidgets 2.8, 3.0 or 3.2 with Unicode enabled, Boost 1.53.0 or higher, ICU4C 50 or higher and libcurl 7.15.5 or higher, with autoconf 2.63 or higher and automake 1.11.1 or higher as optional tools. On Windows, ReactOS and Wine, with the MSW build, you need MinGW or MinGW-w64 GNU C++ 3.x or higher, or Visual C++ 2005, 2008 or 2010 through 2022 by upgrading from the 2008 solution and project files, plus Bakefile 0.2.9 to 0.2.11 for the MinGW route. The library set is the same on both. The Visual C++ path is the friendlier one for Windows developers because the solution and project files already exist, and the MinGW path needs a Bakefile, which is a build tool that is not widely available, and the documentation links to a page for the old version of it. The repository also carries autogen.sh, configure.ac, aclocal.m4 and the usual autotools files, so a Unix build is a standard configure and make cycle.

Unicode work is the reason this editor is different

The change log is where this project reveals its priorities, and they are not the usual editor priorities. The 3.1 release added word boundary handling for Chinese, Japanese, Thai, Lao, Khmer and Burmese characters, and a word wrap that follows the Unicode Standard Annex number 14, the Unicode Line Breaking Algorithm. The 3.2 release updated the GB18030 support to the GB18030-2022 standard and updated the Unicode block descriptions for Unicode 15.0, which requires ICU 72 or higher. Those two requirements, ICU4C 50 for the base build and ICU 72 for the newer block data, tell you the project tracks the Unicode standard closely rather than shipping a stale copy of it. A long list of translation updates over the same releases, with named contributors adding French, German, Polish, Spanish, Japanese, Simplified and Traditional Chinese and Russian, shows the same thing for languages. The interface is localised by translators, and the text handling is written by someone who read the specifications.

Syntax files, locale files and where settings live

The configuration story is documented in detail, which is helpful because the search path has four possible answers. Syntax files live in the path $(wxMEditConfigPath)/syntax/ and locale files in $(wxMEditConfigPath)/locale/, and the configuration path is one of the following. The wxMEdit execution file directory under Windows and Unix-like systems. The $(HOME)/.wxmedit/ directory under Unix-like systems. The $(PREFIX)/share/wxmedit/ directory under Unix-like systems. Or %APPDATA%\wxmedit\ under Windows, according to settings. If wxMEdit does not find any files in those paths it can also execute standalone using default settings, which is a sensible fallback for a portable install. On exit it saves the settings to the configuration file location, and the FontWidth.dat file is saved to the same path. That last file is worth knowing about, because the documentation describes it as a cache of font width data that can speed up wxMEdit a lot, and it explains why the first launch after a fresh install is slower than later ones.

Version 3.2 changed the shortcuts and the display

There is a prominent note in the project documentation that wxMEdit 3.2 changed some keyboard shortcuts, with a link to a wiki page describing the change. That is the kind of break that annoys people, so it is worth knowing before you upgrade an installation you rely on. The 3.2 change log is otherwise a mix of additions and crash fixes. Additions include showing the file size in human readable format, an option to always use a certain encoding to open files, GTK+ 3 and Wayland support, and High DPI support under Windows. The icons were redesigned. The fixes are the kind that come from real use, such as a crash in text mode when a line exceeded the limit of line length, a crash when pressing OK in the About window, a not responding hang when wrapping by window on text containing tab characters, fonts and encodings not restored after restart, an inability to type characters via the AltGr key, cursor and selection rendering problems under Linux, and an IME candidate window that did not follow the caret under Windows 10. That is a long tail of small papercuts, which is what a mature editor accumulates.

Editorial conclusion

Adopt wxMEdit when you need a single tool that handles both text and binary editing, when your files use legacy or Asian encodings that other editors mangle, and when you are comfortable building a wxWidgets application. Do not adopt it if you need a modern editor with a maintained plugin ecosystem, and do not expect the build to be trivial on a current distribution. Verify first that wxWidgets with Unicode enabled, Boost 1.53 or newer, ICU4C 50 or newer and libcurl 7.15.5 or newer are available for your platform, that the ICU version meets the Unicode block data requirement of your release, and that the 3.2 keyboard shortcut changes do not collide with your muscle memory.

Frequently asked questions

Official sources

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