Edit text like Emacs in FreeDOS

If you're already familiar with GNU Emacs, you should feel right at home in Freemacs.
29 readers like this.
Typewriter in the grass

Original photo by jetheriot. Modified by Rikki Endsley. CC BY-SA 2.0.

On Linux, I often use the GNU Emacs editor to write the source code for new programs. I learned GNU Emacs long ago when I was an undergraduate student, and I still have the "finger memory" for all the keyboard shortcuts.

When I started work on FreeDOS in 1994, I wanted to include an Emacs-like text editor. You can find many editors similar to Emacs, such as MicroEmacs, but these all take some shortcuts to fit into the 16-bit address space on DOS. However, I was very pleased to find Freemacs, by Russell "Russ" Nelson.

You can find Freemacs in FreeDOS 1.3 RC4, on the Bonus CD. You can use FDIMPLES to install the package, which will install to \APPS\EMACS.

installing Freemacs

Installing Freemacs from the FreeDOS 1.3 RC4 Bonus CD

(Jim Hall, CC-BY SA 4.0)

Initial setup

The first time you run Freemacs, the editor will need to "compile" all of the setup files into a form that Freemacs can quickly process. This will take a few minutes to run, depending on your system's speed and memory, but fortunately, you only need to do it once.

Running Freemacs for the first time

Press Y to build the Freemacs MINT files

(Jim Hall, CC-BY SA 4.0)

Freemacs actually processes the editor files in two passes. When Freemacs has successfully completed the first pass, it prompts you to restart the editor so it can finish processing. So don't be surprised that the process seems to start up again—it's just "part 2" of the compilation process.

Using Freemacs

To edit a file with Freemacs, start the program with the text file as an argument on the command line. For example, emacs readme.doc will open the Readme file for editing in Freemacs. Typing emacs at the command line, without any options, will open an empty "scratch" buffer in Freemacs.


Starting Freemacs without any files opens a "scratch" buffer

(Jim Hall, CC-BY SA 4.0)

Or, you can start Freemacs without any command-line options, and use the Emacs shortcuts C-x C-f (or M-x find-file). Freemacs then prompts you for a new file to load into the editor. The shortcut prefix C- means you should press the Ctrl key and some other key, so C-x is Ctrl and the x key together. And M-x is shorthand for "press the 'Meta' key (usually Esc) then hit x."


Opening a new file with C-x C-f

(Jim Hall, CC-BY SA 4.0)

Freemacs automatically detects the file type and attempts to load the correct support. For example, opening a C source file will also set Freemacs to "C-mode."


Editing a C source file in Freemacs

(Jim Hall, CC-BY SA 4.0)

If you also use GNU Emacs (like me), then you are probably curious to get Freemacs to match the C indentation that GNU Emacs uses (2 spaces.) Here is how to set Freemacs to use 2 spaces in C-mode:

  1. Open a C source file in Freemacs.
  2. Enter M-x edit-options to edit Freemacs settings.
  3. Use the settings to change both "C-brace-offset" and "C-indent-level" to 2.
  4. Save and exit Freemacs; you'll be prompted to save settings.

A few limitations

Much of the rest of Freemacs operates like GNU Emacs. If you're already familiar with GNU Emacs, you should feel right at home in Freemacs. However, Freemacs does have a few limitations that you might need to know:

The extension language is not LISP. The biggest difference between GNU Emacs on Linux and Freemacs on FreeDOS is that Freemacs uses a different extension language. Where GNU Emacs implements a LISP-like interpreter, Freemacs implements a different extension language called MINT—based on the string processing language, TRAC. The name "MINT" is an acronym, meaning "MINT Is Not TRAC."

You shouldn't expect to evaluate LISP code in Freemacs. The MINT language is completely different from LISP. For more information on MINT, see the reference manual. We provide the full documentation via the FreeDOS files archive on Ibiblio, at /freedos/files/edit/emacs/docs. In particular, the MINT language is defined in mint.txt and mint2.txt.

Freemacs cannot open files larger than 64 kilobytes. This is a common limitation in many programs. 64kb is the maximum size of the data space for programs that do not leverage extended memory.

There is no "Undo" feature. Be careful in editing. If you make a mistake, you will have to re-edit your file to get it back to the old version. Also, save early and often. For very large mistakes, your best path might be to abandon the version you're editing in Freemacs, and load the last saved version.

The rest is up to you! You can find more information about Freemacs on Ibiblio, at /freedos/files/edit/emacs/docs. For a quick-start guide to Freemacs, read quickie.txt. The full manual is in tutorial.txt.

What to read next

How FreeDOS boots

An overview of how your computer boots up and starts a simple operating system like FreeDOS.

Why FreeDOS has 16 colors

Why does text only come in this limited palette, and why does FreeDOS use those colors and shades, instead of some other colors? The answer, like many things in technology, is…

June 17, 2021
photo of Jim Hall
Jim Hall is an open source software advocate and developer, best known for usability testing in GNOME and as the founder + project coordinator of FreeDOS.

1 Comment

The 64K document limit isn't a function of "extended" memory (which is one of several mechanisms for DOS PCs to access more than 640K of RAM, "extended" being one that uses a 286+ processor's protected mode), but of the various memory models used by software running in an x86 processor's "real mode".

In real mode, memory is managed using segments and offsets. A segment is a 64K region of memory. A segment register is a 16-bit value that represents a physical memory location divided by 16. An offset is a 16-bit offset from the start of a segment. And yes, there is lots of overlap between the 64K possible segments. This is also what defines the 1MB conventional address space.

Any memory pointer may be "near", meaning it is a 16-bit offset from one of the CPU's segment registers (code segment and data segment) or it may be "far", meaning it is a 32-bit value containing a segment address and an offset from the start of that segment.

Compilers for DOS and real-mode define memory models that specify what kinds of pointers are used by an application by default (apps could always explicitly declare a pointer to be near or far as well).

The "tiny" model means that all pointers are near and furthermore, the code and data segment registers have same value. So the entire app must fit within 64K of RAM.

The "small" model has all pointers as near, but with different code and date segments. So apps are limited to 64K of code and 64K of data.

The "compact" model has near code pointers but far data pointers. So apps can have up to 64K of code, but can use all available RAM for data.

The "medium" model has far code pointers and near data pointers. So apps can use all available RAM for code, but up to 64K of data.

The "large" model has far code pointers and far data pointers. So apps can use all available RAM for both code and data. But standard libraries (like the C runtime library) will limit any single memory object to 64K.

The "huge" model is like the large model, but the standard libraries include code to allow individual objects to be as large as available RAM, but at a cost of more complicated pointer arithmetic (and therefore lower performance) when accessing objects.

Freemacs was probably written using the large model and is using a single memory buffer object for the document, hence the 64K document size limit. This was the most popular memory model for DOS apps, so I'm not surprised that Freemacs uses it.

See also https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=104012

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.