mg: a small public domain Emacs clone that still builds from a tarball

What mg is: Micro Emacs, public domain, and deliberately not GNU Emacs

mg is a clone of Micro Emacs created in 1987, based on the original MicroEMACS v30 released by Dave Conroy in 1985. The history in the README includes the small legal detail that makes the name: Micro GNU Emacs was disputed early on by the FSF, so today the program simply goes by mg. The software is fully free and in the public domain, and the repository carries an UNLICENSE file rather than a conventional licence, with the project description saying the same.

The stated intention is to be a small, fast and portable Emacs-like editor for users who cannot, or do not want to, run the real Emacs for one reason or another. That is a narrower and more honest goal than most editors in this space claim.

The design commitment is compatibility with GNU Emacs, and the README is explicit that this is what separates mg from other ErsatzEmacs clones: there should never be any reason to learn more than one Emacs flavour. In practice that means the Meta and Ctrl conventions, the same key notation, the same command names, and the same muscle memory. The key table in the README is short because the point is familiarity: Meta is written M-, Ctrl is written C-, and the built-in Quick Help is reached with C-h q, with the note that the dash carries meaning in that notation.

The project is a fork of upstream OpenBSD Mg with features added on top, and the README links to a section that spells out the differences. The releases come in quick succession, v4.4 on 2026-10-15, v4.3 on 2026-10-12 and v4.2 on 2026-10-07, with the last push to the repository on 2026-10-16 and the repository not archived.

Building from a release tarball: configure, make, install

The README's advice about releases is specific and worth following. Try the latest release, use the tarball with a version in the name and the sha256 checksum next to it, and avoid the GitHub generated links. The reason for the last point is that releases come with a configure script, so you do not need autotools: only a C compiler, make and you are set to go.

The one system dependency is a terminal description library. By default you need a termcap library such as Ncurses to provide the APIs setupterm(), tgoto() and tputs(), and the README notes that the project is completely self hosting otherwise, with a documented way to build without Ncurses at all.

On recent Debian and Ubuntu systems the header-only library is enough:

    sudo apt install libtinfo-dev

On older ones the term.h header is missing, so the full development package is used instead:

    sudo apt install libncurses-dev

On RHEL, CentOS and Fedora the full library is needed:

    sudo yum install ncurses-devel

and on macOS the command line tools:

    xcode-select --install

The build itself is three commands from the unpacked tarball:

    ./configure
    make
    sudo make install

The README flags a detail that bites people: this installs to /usr/local/bin, next to any mg from your distribution in /usr/bin. If UTF-8 text shows up as octal escapes like \303\251, run command -v mg to check which one you are starting. That symptom is exactly what happens when the terminal does not speak UTF-8 to the older binary, and the diagnosis in the README is that you launched the wrong mg.

For anyone working from a Git checkout instead of a release, the README says to run ./autogen.sh first to create the configure script, which requires GNU autotools on the build system.

Building without curses and with a smaller feature set

The configure script exposes a long list of feature switches, and the README explains the purpose: to reduce the size, or to remove features so that you are on par with the official Mg. By default all of the listed features are enabled, and ./configure --help prints the full set.

The switches are granular, which is unusual and useful:

    ./configure --help
    [..]
    --disable-autoexec   Disable auto-execute support
    --disable-autorevert Disable auto-revert-mode and tail mode
    --disable-cmode      Disable C-mode support
    --disable-compile    Disable C compile & grep mode, used by C-mode
    --disable-cscope     Disable Cscope support

Further down the list come the switches for ctags, dired, the help system, ido-mode, full regexp search, syntax highlighting and comment-dwim, and a toggle-newline-prompt extension that the README notes is not in OpenBSD. There is also --disable-all to turn off every optional feature at once, and --without-curses for the fully stand-alone build.

The stand-alone sequence is documented separately, and the point is that mg can be built with no terminal library at all:

    make clean
    ./configure --without-curses

That is a genuinely unusual property for a terminal editor: the same program that normally needs a termcap library can be compiled without one, which makes it usable on a system with a minimal userland or a serial console.

There are also switches for the startup file and for debugging. --with-startup=FILE names an init file to run at startup if ~/.mg is missing, and --with-mglog enables debugging to a log file, by default in ./log/*.log.

File modes: which languages mg knows about out of the box

The --with-modes switch takes a list, separated by commas or spaces, and each name builds one mode. The README's table maps every mode to the files it is turned on for, and it can also be turned on by hand with its M-x command.

The list covers cmake, conf, diff, git, m4, make, markdown, python, sh, text and yaml. The conf mode is the broadest of them, covering *.conf, *.ini, *.toml, systemd units, fstab, ssh_config and .gitconfig. The git mode is tied to the files git itself writes, including COMMIT_EDITMSG, MERGE_MSG, TAG_EDITMSG and git-rebase-todo. The sh mode covers *.sh, .bashrc and .profile, and is described as the mode for scripts run by sh or bash.

The practical reason to care is size. A build with only the modes for a small system's shell scripts and configuration files is one configure flag away:

    ./configure --with-modes=sh,conf

C is deliberately absent from the list, and the README explains why: C mode has its own switch, --disable-cmode. That is a good example of the project's philosophy, where a heavyweight feature is separated from the language modes so that turning it off does not disturb the rest.

The modes also do more than colour. Without --disable-syntax the modes colour what they recognise, and without syntax highlighting they still set up indentation, tabs and fill for their files. So a minimal build keeps the indentation behaviour and loses only the colour.

The container image and where mg is the wrong choice

The repository includes a Dockerfile that GitHub uses to generate an Alpine Linux based container with the latest Mg, and its header comment gives the run command for editing files in your home directory:

#    docker run -ti --rm -v $HOME:/root troglobit/mg:latest some-filename

The build is a two-stage image. The first stage starts from alpine:latest, installs the build dependencies with apk, including alpine-sdk, autoconf and automake, runs ./autogen.sh, configures with the prefix set to /usr and CFLAGS=-static, and installs a stripped binary. The second stage is FROM scratch, so the runtime image contains only the mg binary and its documentation, with OCI labels for the title, description, documentation URL and the Unlicense. The container is minimal enough that the editor is essentially the whole system.

With that in mind, the wrong cases are clear. The first is a workflow that depends on Emacs Lisp packages, because mg is a Micro Emacs descendant and deliberately does not grow into GNU Emacs. The second is a workflow that needs a modern completion engine, a language server, or a project-aware refactoring tool, none of which exist here. The third is a workstation where a full Emacs is perfectly acceptable, since the argument for mg is that Emacs is too heavy or unwanted for a reason.

There is also a portability caveat in the other direction. mg is compiled against your terminal's description database, and the README's note about octal escapes shows how quietly a mismatch can appear. On a remote system where the terminal type is unusual, the editor will look wrong even when it works.

The realistic alternative is GNU Emacs itself, and the interesting question is which flavour you end up using. Mg's argument is compatibility, and it is a real one: if you already know Emacs keys, you do not learn anything new. The difference in approach is that mg is a 1980s editor with a modern build system and a handful of added conveniences, where Emacs is a Lisp runtime with an ecosystem. People choose mg when they want the keys without the runtime.

Editorial conclusion

mg is the right choice for a Unix system where a full Emacs is too heavy, where the operating system ships its own copy that is stale, or where you want the original Micro Emacs behaviour with a few conveniences added. It is the wrong choice for editing where you depend on Emacs Lisp packages, on a modern completion engine, or on a terminal multiplexer with a full editor inside it. Verify first that your terminal has the terminfo entries the build needs, that the mg you end up running is the one you installed rather than the one your distribution ships in /usr/bin, and that the features you rely on are still enabled in the version you build, since the upstream project removes and adds modes between releases.

Frequently asked questions

Official sources

1. License: Unlicense
2. Project website
3. README
4. Releases
5. troglobit/mg on GitHub