Cudatext: change the way how Undo-limit is applied

[Alexey-T]

from @tmsg-gh -

Hm... either I misunderstood @Jairo-Martinez' post or you did. My impression is that he wants to completely switch off undo information recording as long as there are more than undo_max_carets defined, NOT have them collected into a single operation.

And given that every single action in a N-caret scenario produces N undo events this does not seem to be an unreasonable idea.

And further... I assume that other operations have that very same "feature". What if I replace say all "a"s in a text with "A"s, perhaps 10,000 of them? I assume this will generate 10,000 undo events and so probably destroy the complete undo information so far collected?!

As it stands Cud's default Undo limit of 5,000 is not as generous as one might think and that will certainly change the way I use some Cud operations as a result.

[tmsg-gh]

Decades ago (under MS-DOS), I used an editor called Slick. This editor had some clever tricks re Undo and for this discussion, I think there are two that are most interesting.

1. It was possible to configure a number of edits of the EXACT SAME TYPE (ie adding characters, or deleteing characters) that would be lumped into a single undo event, so the undo system was not burdened by too many events. This option could also work in a time-based fashion, ie all events of the EXACT SAME TYPE done in quick succession could be lumped together (so if you typed "test me" in one go and then waited for a second or two this would generate just one undo event and Ctrl-Z would remove the whole "test me". That is basically what @Jairo-Martinez referred to in the other thread if I understood his post correctly.

2. All multi-line events (ie multiple-caret edits or text replacements) were equally bundled into into a single event. So you could replace 10,000 "a"s with "A"s and with one Ctrl-Z you'd be back to 10,000 "a"s.

Slick had no immediate way to suspend undo event generation (its scripting language could do that) but with those two optimisations this never was something I missed (or even thought about).

Just some food for thought.

[Alexey-T]

I missed the question:

What if I replace say all "a"s in a text with "A"s, perhaps 10,000 of them? I assume this will generate 10,000 undo events and so probably destroy the complete undo information so far collected?!

yes, this will make 10K undo events, so undo info (5K items) will be lost.
you must adjust "undo_limit" first. sorry.

[Alexey-T]

about Slick's idea. maybe its possible to make smth similar, --limit 5K will apply to not primitive edits, but to GROUPS of edits (one group has all multi-caret editions, one group has all 'replace all' changes);
not simple though.
maybe later.

[Alexey-T]

today I had the idea, about this work. idea how to write this.
made the work. maybe incomplete yet.
tested for

• simple commands
• multi-caret edits
• 'replace all'

tests: I set "undo_limit" to 10 and checked after commands the undo-data-- in console-
ed.get_prop(PROP_UNDO_DATA)

putting beta, pls test! http://uvviewsoft.com/c/
you see I cannot sometimes do the work immediately.
per request.

@tmsg-gh @jairomartineza

[JairoMartinezA]

I tested _replace all_ with default config undo_limit = 5000 and using a file of 40K lines, the undo - redo operation is working as expected, (the replace function is affecting around 10K matches)

The multi-caret edit doesn't work.

What kind of simple-commands do you mean?

[Alexey-T]

undo_max_carets - did you test big value? for 10K carets typing you need 10000.

[Alexey-T]

beta updated. changed def value of 'undo_max_carets' to 20K. Jairo, pls see. and #3301 .

[Alexey-T]

added info to default.json:

[JairoMartinezA]

Testing with small values, I confused the undo_limit and undo_max_caret options.

[JairoMartinezA]

Results:

• Replace action works now regardless number of lines (carets) affected, CudaText realizes the Undo operation without problems. I suppose this operation now is taking no notice of undo_max_caret
• undo_max_caret is still present in multi-caret edition, if carets are more than this value the Undo operation is paused.

Alex, I took the same test file of 40K lines, trying to modify 10K carets but using ST, I can see ST manage in better way the editing, it takes 2 seconds maybe of unresponsive status but at the end, it proceeds with writing and undo-redo operation, trying to do the same with CudaText, it consumes all my 5GB of RAM :) and remains unresponsive (Tested with Lite Lexer and no-Lexer getting the same result).

Taking a previous comment of @tmsg-gh about Slick editor and considering that CudaText has now the functionality discussed in #3272 and undo_grouped option, I don't know how CudaText manages internally now the multi-carets editing.

All multi-line events (ie multiple-caret edits or text replacements) were equally bundled into into a single event. So you could replace 10,000 "a"s with "A"s and with one Ctrl-Z you'd be back to 10,000 "a"s.

[Alexey-T]

trying to do the same with CudaText, it consumes all my 5GB of RAM

so we have an issue. with that old SQL file? what are the repro steps? better post it to a __new topic__.

[Alexey-T]

Jairo,in the new topic pls test - what count of mul-carets do the memory-overflow. 10K carets with many typing after that? with one editing after that?
because now Cud has "undo_max_carets":20K

[JairoMartinezA]

Sure Alex, let me prepare the repro and the issue.

[Alexey-T]

Done in prev versions. @tmsg-gh , I hope you saw that---

1.131.0 (2021/04)

• add: improved the way how option "undo_limit" is applied. Now Undo limit is not N simple memory-items, but N 'actions', where 'action' is one simple command (typing a char, Del, BkSp etc), one multi-caret editing, or one mass-replacement.