Зачем другой? Undo - это движение по стеку операций вниз, redo - вверх. Если ты сделал несколько undo, а потом внёс изменения, все операции выше этого изменения уничтожаются. Ещё можно делать форк, но тогда буфер undo становится бинарным деревом, и превращается фактически в систему контроля версий с инкрементальным логированием по типу svn.

(Reply to this) (Thread)

потому что redo и undo — разные операции. у меня не persistent struct, в стеке лежит операция, которую надо выполнить, чтобы привести текст к нужному виду. соответственно, операция «удалить» в undo превращается во «вставить» в redo. и наоборот.

сделать persistent struct — это теоретически красиво. но в случае сей — атомная пиздецома.

в принципе, можно хранить именно «выполненое» действие, но какой смысл? функции изменения текста сами заполняют undo-стек, так пусть и redo заполняют. в итоге операции undo/redo — один и тот же код, фактически. всё, что надо — свитчнуть указатель на стеки.

(Reply to this) (Parent)

Да, здесь достаточно двусвязного списка.

(Reply to this) (Parent) (Thread)

undo уже работало. чем меньше лишнего кода вносится в библиотеки самого низкого уровня — тем лучше. в данном случае механизмы записи undo, уже протестированые в низкоуровневой библиотеке, можно на халяву использовать и для redo, для этого достаточно свопнуть хранилище. один своп — это сильно меньше кода, чем выкидывание уже готового механизма и вписывание нового. тем более если учесть, что тесты я успешно похерил.

(Reply to this) (Parent)

вообще, как я писал, самый красивый подход тут — immutable data structure. но я заебусь на сях сраное цветное дерево в это превращать.

(Reply to this) (Parent)