Perhaps Editor.Modified should be spelled CanUndo in case we ever want the same for redo.

Good idea
Would-you like me to add the CanRedo as well ?

I did some tests and I can adapt my application by replacing the underlying widget.Editor instance and keeping in memory only those widget.Editor that have been modified.

To do this, I still need undo and redo to be exported and also

• that Editor.SetText resets the modification history
• a new Editor.Modified function (or whatever name you prefer) that returns a bool indicating if the text has been modified. If the history is not exported, we need to be able to detect if the text is back to its initial state even if it has been modified and the modifications have all been undone.

~eliasnaur if you agree with this approach, I will modify the PR accordingly.

It seems to me that History is a part fix for a general issue (that Editor don't work well with very large texts). It seems more natural to somehow abstract the underlying text storage so that the user can provide a storage method.

I understand. Unfortunately, I don't have the time to get into it.

Context: I have a large number of texts in a database.
The titles of these texts are displayed in a tree-list and the content of the text selected in this list is loaded from the database into the editor.
A modified text is written to the database as soon as another text is selected (or when the program exits). But if you reselect a text that has been modified since the opening of the application, the modification history is reassociated with the text.
I had developed this function outside of the editor, but the introduction of undo/redo inside the editor, forces me to modify my application.

Compared to replacing the underlying widget.Editor instance when switching between content, the use of the History field avoids to keep in memory the whole text and IME for all the modified texts (except for the one selected of course).

I realized that History() and SetHistory() had to make a deep copy, otherwise the copied versions of the history were also modified by the subsequent changes made in the editor.
I made the changes in GitHub but I don't know how to do /modify the pull request, knowing that the previous one has not been validated yet.
I've also added the corresponding tests

I tried on GitHub which gives more information about what is going on
The problem seems to come from this check

• builds.sr.ht: apple.yml — builds.sr.ht job failed

test_macos

+ cd gio
+ export PATH=/home/build/appletools/bin:/home/build/sdk/go/bin:/home/build/go/bin:/usr/bin
+ PATH=/home/build/appletools/bin:/home/build/sdk/go/bin:/home/build/go/bin:/usr/bin
+ CC=/home/build/appletools/tools/clang-macos
+ GOOS=darwin
+ CGO_ENABLED=1
+ go build ./...
go: downloading golang.org/x/image v0.0.0-20210628002857-a66eb6448b8d
go: downloading github.com/benoitkugler/textlayout v0.1.1
go: downloading github.com/go-text/typesetting v0.0.0-20220411150340-35994bc27a7b
go: downloading github.com/gioui/uax v0.2.1-0.20220325163150-e3d987515a12
go: downloading gioui.org/cpu v0.0.0-20210817075930-8d6a761490d2
go: downloading gioui.org/shader v1.0.6
go: downloading golang.org/x/exp v0.0.0-20210722180016-6781d3edade3
go: downloading golang.org/x/text v0.3.7
# gioui.org/app
os_darwin.m:3:9: fatal error: 'Dispatch/Dispatch.h' file not found`

I'm not sure if this has anything to do with the patch I submitted

I give up, it's been 5 tries and still no answer.
However, I'm doing exactly the same thing as when I sent my previous patch which worked well.
And I can't do it with the web-based flow either.

If you are interested, I can send you the editor.go and editor_test.go files.

I sent the patch back 2,5 hours ago, but again I didn't get a return.
However, I received the email as a copy, so it's gone.

I submitted a patch yesterday, but I haven't received any feedback from the build yet.

I assume that nextHistoryIdx also needs to be saved and that's why I proposed a HistoryData type that encompasses both.

If you are OK with that, I can submit a patch with tests.