What causes "error using text editor for %s message" in mislav/hub?

Verify EDITOR/VISUAL (or GIT_EDITOR/core.editor) points to an installed program on PATH, e.g. `export EDITOR=vim`.

error using text editor for

Error message

error using text editor for %s message

What it means

openAndEdit launches the configured editor (e.g. via EDITOR) on a temporary file for the given topic (commit message, issue title, etc.). If openEditor returns an error (editor binary missing, non-zero exit, spawn failure), the original error is replaced by this generic message and the temp file is deleted. The underlying cause is discarded, which makes debugging harder.

Solutions

Verify EDITOR/VISUAL (or GIT_EDITOR/core.editor) points to an installed program on PATH, e.g. `export EDITOR=vim`.
Run the editor manually on a test file to see the real underlying error, since this message hides it.
Use a non-interactive fallback (`hub issue create -m "message"`) to bypass the editor entirely.
Check the editor exits with status 0 on normal save/quit.

Example fix

// before
EDITOR="code" hub pull-request   // VS Code without --wait waits/hangs, may error
// after
export EDITOR="code --wait"      // or export EDITOR=vim
hub pull-request

Defensive patterns

Strategy: fallback

Validate before calling

editor := os.Getenv("EDITOR")
if editor == "" { editor = os.Getenv("VISUAL") }
if editor == "" { editor = "vim" }
if _, err := exec.LookPath(strings.Fields(editor)[0]); err != nil {
    log.Fatalf("editor %q not found on PATH; set EDITOR", editor)
}

Try / catch

content, err := github.EditContent(topic, initial)
if err != nil && strings.Contains(err.Error(), "error using text editor") {
    fmt.Fprintln(os.Stderr, "editor failed; falling back to -m flag")
    return useMessageFlag() // e.g. hub issue create -m "text"
}

Prevention

Set EDITOR/VISUAL to a program that exists on PATH and exits 0
For GUI editors use a blocking variant (e.g. `code --wait`)
In CI/headless environments use -m/-F message flags instead of the editor
Note this error masks the root cause: test the editor binary directly when debugging

When it happens

Trigger: Any EditContent call (e.g. hub pull-request, hub issue create) where the editor cannot be opened: EDITOR points to a nonexistent binary, the editor exits non-zero, or the process cannot be started.

Common situations: EDITOR/VISUAL set to a program that isn't installed or isn't on PATH; editors like vim exiting non-zero after a failed write; headless/CI environments with no terminal for interactive editors; git core.editor misconfiguration.

Related errors

AI-assisted analysis of mislav/hub@5c547ed804 (2026-09-01). Data as JSON: /api/errors/e67da2fb07828d11. Report an issue: GitHub.

Appendix: source

Thrown at github/editor.go:110

		unquotedLines = append(unquotedLines, line)
	}
	if err = scanner.Err(); err != nil {
		return
	}

	content = strings.Join(unquotedLines, "\n")
	return
}

func (e *Editor) openAndEdit() (content []byte, err error) {
	err = e.writeContent()
	if err != nil {
		return
	}

	err = e.openEditor(e.Program, e.File)
	if err != nil {
		err = fmt.Errorf("error using text editor for %s message", e.Topic)
		defer e.DeleteFile()
		return
	}

	content, err = e.readContent()

	return
}

func (e *Editor) writeContent() (err error) {
	if !e.isFileExist() {
		err = ioutil.WriteFile(e.File, []byte(e.Message), 0644)
		if err != nil {
			return
		}
	}

	return

View on GitHub (pinned to 5c547ed804)