Re-Editor: a Flutter text and code editor widget built without TextField

Why a Flutter team would not just use TextField

Re-Editor is a Flutter widget and a module inside the Reqable project, meant to be dropped into an app as a text entry surface or developed into a code editor. The README positions it directly against Flutter's built-in TextField, arguing that Re-Editor is tailored to the display and input of multi-line text rather than general purpose single line entry. The feature list is what makes the argument concrete: two-way horizontal and vertical scrolling, syntax highlighting, content collapsing and expanding, input hints and auto-completion, search and replace, a custom context menu builder, shortcut keys, large text handling, line numbers and a focus line builder, and what the README calls smart input. The important architectural claim sits right after that list. The README states that Re-Editor is not a secondary encapsulation based on TextField but independently implements layout, drawing and event processing, and that it is optimized for large texts.

The widget exposes extension points instead of finished panels

Read the README closely and a pattern emerges. For search and replace, Re-Editor implements the control logic but provides no default user interface; the developer writes a search panel and supplies it through the findBuilder attribute. The same split applies to the context menu, where the desktop right-click menu and the mobile long-press selection menu are handled by the package, while the visible toolbar must be built by the developer through the SelectionToolbarController interface. Autocomplete works the same way: the CodeAutocomplete widget provides the mechanism and the basic control logic, but the prompt content, the completion rules and the display view are the developer's job. The result is a widget that owns behavior and hands you appearance. That is a deliberate trade-off, and it suits teams that already have a design system, but it means a prototype built on Re-Editor still has UI work in it.

Syntax highlighting runs through the separate Re-Highlight project

Highlighting is not built into the editor itself. The README states that the text highlighting of Re-Editor is based on Re-Highlight, which supports nearly a hundred languages and theme styles, and that developers can choose and configure the code highlight freely. The configuration nests three levels: a CodeEditorStyle on the editor, a CodeHighlightTheme carrying the theme, and a languages map that maps a language key to a CodeHighlightThemeMode. A concrete JSON example is given in the README, pairing the json language with the Atom One Light theme.

CodeEditor(
  style: CodeEditorStyle(
    codeTheme: CodeHighlightTheme(
      languages: {
        'json': CodeHighlightThemeMode(
          mode: langJson
        )
      },
      theme: atomOneLightTheme
    ),
  ),
);

This also explains why the widget is small. The expensive part of syntax highlighting lives in a separate package that Re-Editor depends on, so a team that wants a different highlighting engine is not locked into this one.

Adding the package and creating a first editor

The README gives one dependency line for pubspec.yaml, and no other installation path is needed since Re-Editor ships as a Dart package on pub.dev.

dependencies:
  re_editor: ^0.10.0

The simplest usage mirrors a TextField, because the controller type is the same kind of thing. As the README puts it, like TextField, Re-Editor uses CodeLineEditingController as the controller, and the minimal sample creates a multi-line input area.

Widget build(BuildContext context) {
  return CodeEditor(
    controller: CodeLineEditingController.fromText('Hello Reqable'),
  );
}

The repository ships an example project covering Android, iOS, Linux, macOS, web and Windows directories, and the README invites you to run it to see the widget in action. Line numbers and fold markers are not hardcoded: they come from an indicatorBuilder callback that receives the editing controller, a chunk controller and a notifier, and the default row is composed of DefaultCodeLineNumber and DefaultCodeChunkIndicator, the latter with a width of 20.

Folding detection is pluggable, and the default only knows braces

Re-Editor detects foldable regions automatically for curly brace and square bracket pairs, and the default detector is named DefaultCodeChunkAnalyzer. Developers can switch the analyzer off with NonCodeChunkAnalyzer, or implement the CodeChunkAnalyzer interface to write their own detection rules. The interface itself is tiny, one method returning a list of CodeChunk from a list of CodeLines.

abstract class CodeChunkAnalyzer {

  List<CodeChunk> run(CodeLines codeLines);

}

The same level of control applies to scrolling, where two ScrollController instances back the two-way scrolling and are assembled through CodeScrollController, and to the indicator column, where the layout of line numbers and fold markers is entirely the caller's Row. For a widget that claims to be independent of TextField, this is consistent: the package gives you the machinery and lets you decide how it looks.

What the widget will not do: IDE analysis and default panels

The README is unusually candid about the limits. It says Re-Editor is only a lightweight editor and does not have IDE dynamic syntax analysis, so code prompts and completion have many limitations, and it points to the example project for a simple prompt and completion implementation. The shortcut table has the same character: a solid set of editing bindings from select all through indent, comment toggling, transpose, search, replace and save, but the README notes that shortcut keys only work on the desktop. On mobile the shortcut table is irrelevant, and the long-press selection menu has to be implemented by the application. The trap for a new user is assuming that find and replace panels, context menus and completion popups appear for free, because the behaviour is there but the widgets are not.

A young package with no tagged releases

The licence is MIT, which is permissive for commercial and closed source products, and the README points to a LICENSE file for the exact terms. The repository is not archived and the last push was on 2026-10-09, so the code is being worked on. What is missing is a release trail: the project publishes to pub.dev rather than through GitHub releases, and there is no GitHub release history to point at. The package therefore versions through pub.dev, where the README shows re_editor at ^0.10.0, meaning the public API is still on a zero major version and breaking changes remain possible. The CHANGELOG.md file at the repository root is the place to look before pinning a version for a production app.

Editorial conclusion

Re-Editor fits Flutter developers who need a code or long text editing surface with highlighting, folding, line numbers and two-way scrolling, and who accept writing their own find panel, context menu and completion rules. It does not fit projects expecting a drop-in replacement for TextField with IDE level analysis, since the README states there is no dynamic syntax analysis and no default UI for search or the selection toolbar. Before adopting it, add the dependency at the version the README shows, run the example project, and confirm that the highlighting languages and theme you need are configurable through CodeHighlightTheme.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. reqable/re-editor on GitHub