# godit: a text editor with no settings and a strong opinion

> godit is a small Go text editor with an emacs-like key binding set, a micromode system borrowed from emacs, and no configuration file at all: the tab size is fixed at eight spaces, files are always UTF-8, and lines always end with a newline. It is MIT licensed, and the author writes his own code, commits and configs in it.

**nsf/godit** — A very religious text editor

- Repository: https://github.com/nsf/godit
- Stars: 581 · Forks: 75
- Language: Go
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/nsf-godit

## What religious means for this editor

The project calls itself a very religious text editor, and the documentation explains exactly what that means. There is a strong faith in the one true way of doing things, and the examples given are specific: the tab size is always equivalent to 8 spaces or characters, each line ends with the newline symbol and someone should end the carriage return plus newline madness, and text files are always UTF-8 encoded.

Then comes the punchline. Most editors provide customizable options for these things, but godit takes a different approach in that area and has no settings at all. That concludes the ideology behind godit, as the author puts it.

So the absence of a config file is the feature. There is no settings.json, no dotfile, no per-directory override. The same binary on two machines does the same thing.

The author is also candid that the trade cuts both ways. The documentation says most editors let you choose, and godit simply does not, and the character of the project comes through in the phrasing, which is informal and self-aware rather than formal. It is a small Go program by a developer who wanted a specific thing and did not want to maintain a preferences system.

The users are people who already know what they want and want a fast editor with predictable behaviour. It is not a beginner editor and it is not an IDE.

## The emacs heritage and how micromodes work

The documentation describes godit as an emacsish lightweight text editor, and the mechanics are borrowed directly from emacs. It uses many of the emacs key bindings and operates using a notion of micromodes.

The example given is the keyboard macro feature, and it is worth following because it explains the whole system. You start recording a macro with the C-x ( key combination. When you are ready to start repeating it, you do C-x e followed by the macro keys. C-x e ends the recording of a macro, but it also executes the macro once and enters a micromode, where typing e again repeats that action. As soon as some other key was pressed you quit this micromode and everything is back to normal.

So a micromode is a temporary mode entered by a key, in which one further key performs a related action, and any other key cancels it. That is the entire mechanism, and the documentation says the idea of micromode is used in godit a lot.

You can see it in the key binding list. M-d kills a word, M-u converts the following word to upper case, M-l to lower case and M-c capitalizes it, all as single keypresses that do not need a mode entry. The view operations mode is entered with C-x C-w, and inside it v splits the active view vertically, h splits horizontally, k kills the active view, C-f and C-b expand and shrink the view to the right and left, and the digits select a view. M-g goes to a line with a prompt.

The practical consequence is that godit is a modal editor without looking like one, and that the only way to learn it is to read the binding list.

## The key bindings, and what is missing from them

The binding list in the documentation is the manual, and it is organised in sections. The basics are C-g as a universal cancel button, C-x C-c to quit, C-x C-s to save with a prompt, C-x S to save raw, C-x M-s and C-x M-S for save as with and without a prompt, C-x C-f to open a file, M-g to go to a line, C-/ to undo and C-x C-/ to redo.

Movement and editing are the emacs set. C-f and C-b move by character, M-f and M-b by word, C-n and C-p by line, C-e to the end of the line, C-a to the beginning, C-v and M-v to move the view by half a screen, and C-l to centre the view on the cursor's line. C-s and C-r search forward and backward with an interactive prompt, C-j inserts a newline and autoindents, and M-d, M-<backspace>, C-k handle word and line kills. M-u, M-l and M-c change the case of the following word, and any other key inserts that character.

Regions work the way emacs users expect. C-<space> sets the mark, C-x C-x swaps the cursor and mark locations, C-x > and C-x < indent and deindent the region, C-x C-r searches and replaces within it, C-x C-u and C-x C-l change its case, C-w kills it, M-w copies it, C-y yanks it back, and M-q fills it.

What is absent is as informative as what is present. There is no syntax highlighting in the binding list, no multiple cursors, no line numbers command, no find and replace across the file, and no session restore. A few of those may exist in the implementation, but the documentation does not claim them, and the project is a work in progress.

The advanced section has the pieces that suggest the editor's ambitions. M-/ does local words autocompletion, C-x C-a invokes a buffer specific autocompletion menu, C-x ( and C-x ) start and stop macro recording, C-x = gives information about the character under the cursor, and C-x ! filters a region through an external command, which is the hook that lets you wire in an external formatter.

## How the code is put together

The repository layout maps almost one to one onto the feature list, and the file names are the design.

There is a buffer.go and a view.go, with view_tree.go and a llrb_tree.go providing a left leaning red black tree, which is the structure used to keep the view and buffer trees ordered. A cursor_location.go tracks where the cursor is.

Then every mode has its own file. isearch_mode.go is the incremental search mode behind C-s and C-r. line_edit_mode.go is the line editing mode. key_press_mode.go is the generic key press handling. view_op_mode.go is the C-x C-w view operations mode. region_indent_mode.go is the C-x > and C-x < indentation. fill_region_mode.go is M-q. macro_repeat_mode.go is the micromode entered by C-x e. extended_mode.go and overlay_mode.go cover the longer modes, and autocomplete.go with autocomplete_mode.go cover the two completion paths, M-/ and C-x C-a.

The action layer is action.go, utils.go holds the helpers, and suspend.go and suspend_posix.go handle suspending the editor, which is what you need in a terminal program that has to hand the terminal back to the shell.

The dependencies are minimal. The module and its requirements are declared like this:

```toml
module github.com/nsf/godit

go 1.26.5

require (
	github.com/nsf/termbox-go v1.1.2
	github.com/nsf/tulib v1.0.1
)
```

termbox-go is the terminal UI layer, and tulib is a terminal utility library from the same author, with clipperhouse/uax29, mattn/go-runewidth and golang.org/x/sys as indirect dependencies. The Go version declared is 1.26.5.

That is a very small dependency tree for a text editor, and it is a direct consequence of the design. There are no settings to parse, no plugin system to load, and no language definitions to fetch, so there is nothing that needs a large tree of dependencies.

## Where godit is the wrong choice

The first limit is that no settings is a real constraint, not a quirk. A team that works across projects with different tab conventions, or a person who has to open a file with CRLF line endings without rewriting it, has nowhere to go in godit. The documentation is explicit that each line ends with the newline symbol and that someone should end the carriage return plus newline madness, which means a Windows file is either rewritten on load or displayed awkwardly, and there is no preference to change that.

The second is the missing feature set. There is no syntax highlighting in the documented key bindings, no plugin system, no file tree, no multi cursor, no session persistence, and no find and replace across the whole file beyond the search prompt and the region based one. Some of that may exist in the code, but it is not part of the documented interface, and for an editor that is meant to be used for everything on a system, that is a narrow surface.

The third is the maturity. The documentation says plainly that the author is still in the process of designing some parts of it, that bits of functionality are missing, and that while the editor is definitely usable, it is certain that some corner cases are not covered. There is one release, v1.0.1, on 2026-08-23, and the last push was on the same day, so the project is young.

The fourth is the attitude to contributions. The author says he is very picky about feature suggestions at the moment, and to suggest but not expect too much. That is an honest warning for anyone planning to depend on a roadmap.

Compare that with a conventional editor that writes a configuration file. The difference in approach is that a settings-based editor moves the decision to the user and grows a schema to store it, while godit removes the decision and the schema with it. For a machine you control completely, where the same rules everywhere are what you want, that is a clean trade. For a shared configuration across a team with different projects, it is a limitation you cannot configure away.

## Licence, project state and how to try it

godit is released under the MIT licence, with the text in the LICENSE file at the repository root. The MIT terms are permissive, so for a small self contained Go program there is little friction in using it, and you should read the LICENSE file yourself for the exact wording.

The state of the project is best judged from the release history and the last push. There is a single release, v1.0.1, on 2026-08-23, and the repository is not archived, with the last push on the same date, so the tree is about two months old relative to today. The README file in the tree is the short one, and the documentation is the README itself, which is unusual and tells you the project intends to stay small in scope.

The author's own usage is the best evidence of how it is meant to be used. The documentation says that the author writes godit in godit already and uses it for everything else on the system, with EDITOR=godit, and that this README was written in godit from scratch, and that the commit messages, the code, the configs and the scripts are all written in it. That is a strong signal for how the editor behaves in practice, and it is also a signal about the risk profile, since the person who wrote the tool is also its most demanding user.

The documentation does not describe an installation procedure, so the practical entry points are the source tree and the tagged release v1.0.1, and the module path is the one in the go.mod file above, which is what you fetch to build it.

If you want to try it, the sensible route is to set EDITOR=godit for one shell rather than your whole system, and edit a real file rather than a scratch one, so you feel the cursor movement and the undo behaviour under a real workload. Read the key binding list before you start, because the interface is entirely keyboard driven and there is no menu, and remember that C-g is the universal cancel button, which is what you will reach for when a mode surprises you.

## Conclusion

godit fits a developer who wants an editor that starts instantly, never surprises them with a config file, and behaves the same on every machine, and who is already comfortable with emacs bindings. It does not fit a team that needs per-project settings, plugins, or a syntax highlighter for an unfamiliar language, because the absence of settings is the design rather than a missing feature. Before adopting it, set EDITOR=godit for a shell and try it on a real file rather than a scratch file, expect CRLF files to be an argument rather than an option, and read the key binding list first, because the emacs bindings are the interface and there is no menu to discover them from.

## FAQ

### What does godit mean by being a very religious text editor?

It means there is a strong faith in the one true way of doing things: the tab size is always equivalent to 8 spaces, each line ends with the newline symbol, and text files are always UTF-8 encoded. Most editors let you customise these, and godit has no settings at all.

### What is a micromode in godit?

It is a temporary mode entered by a key, in which one further key performs a related action and any other key cancels out of it. The documentation uses the emacs keyboard macro feature as the example, where C-x e ends a recording, runs it once and enters a micromode where typing e repeats the action.

### Which key bindings does godit use?

It uses many of the emacs bindings, including C-g as a universal cancel, C-x C-c to quit, C-x C-s to save, C-x C-f to open, M-g to go to a line, C-f and C-b for character movement, M-f and M-b for word movement, C-k to kill a line and C-y to yank text back. The view operations mode is entered with C-x C-w.

### Does godit have a configuration file?

No. The project explicitly states that most editors provide customizable options for tab size, line endings and encoding, while godit takes a different approach and has no settings at all. The behaviour is therefore fixed rather than configurable.

### What is godit written in and what does it depend on?

It is written in Go, with the module named github.com/nsf/godit and the go.mod declaring Go 1.26.5. The direct dependencies are github.com/nsf/termbox-go for the terminal interface and github.com/nsf/tulib, with clipperhouse/uax29, mattn/go-runewidth and golang.org/x/sys as indirect ones.

### What licence does godit use and how mature is it?

godit is released under the MIT licence, with the terms in the LICENSE file at the repository root. There is a single release, v1.0.1, on 2026-08-23, and the documentation states that the author is still designing parts of it and that some corner cases are not covered.

## Sources

- [Issues](https://github.com/nsf/godit/issues)
- [License: MIT](https://github.com/nsf/godit/blob/master/LICENSE)
- [nsf/godit on GitHub](https://github.com/nsf/godit)
- [README](https://github.com/nsf/godit/blob/master/README.md)
- [Releases](https://github.com/nsf/godit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nsf-godit