Margin markers not restored with Undo/Redo

54 views
Skip to first unread message

David

unread,
Jan 7, 2009, 2:28:16 PM1/7/09
to scintilla-interest
Hello, I have written a modification of PyCrust that makes heavy use
of margin markers (PyCrust uses Scintilla's code via the
wxStyledTextControl). Essentially, I use markers for code
organization and code folding. The problem is that undo or redo can
destroy the markers and I can't think of a way to handle it on my end.

How hard would it be to make scintilla itself store and manage marker
information during undo and redo processes? I have looked at the code
and could not easily tell for myself...

Alternatively, is it possible to easily track the undo history
externally so I can manage this information myself (essentially by
copying what scintilla does)? I would prefer to build it into
Scintilla so others can use it, but this would suffice for my
purposes.

Thanks!
-David

Eric Promislow

unread,
Jan 7, 2009, 5:25:31 PM1/7/09
to scintilla...@googlegroups.com
Hey David,

You can track changes to the buffer using notifications like
SC_MOD_BEFOREDELETE, SC_MOD_INSERTTEXT,
SC_PERFORMED_USER, and SC_PERFORMED_UNDO
to capture the markers before they're about to be deleted,
and then work out ways to restore them if necessary.
I would squirrel away the markers with the actual associated
text on a BEFOREDELETE, and then if I see that I'm
about to insert text on an UNDO, and the line-numbers
and actual text match a saved marker, I'd restore it.
This sounds a bit hairy -- how long do you have to store these
markers for -- but there might be some potential here.

- Eric

David Mashburn

unread,
Jan 7, 2009, 7:34:30 PM1/7/09
to scintilla...@googlegroups.com
Eric,

Thanks for getting back to me so quickly. My main concern is still to
be able to either monitor or duplicate the undo history... I don't have
any problems monitoring when text is inserted or removed or when
undo/redo's occur (PyCrust manually manages all keyed inputs, so I can
just catch everything there). And I really want to be able to make
multiple undo/redo work properly or else the same problems will arise
anyway after the first undo...

I guess the main issue is knowing for sure WHAT text is actually being
included at each point in the undo buffer history. I know scintilla
uses a fairly sophisticated system for tracking which changes are
considered to be part of the same action and which changes are part of a
new action (my understanding of this is summarized below).

This was the reason that I wondered if duplicating this entire system
(AND making sure everything matches up properly) might be more
complicated than just adding marker memory to the CellBuffer's
UndoHistory directly.

Any thoughts? I'll be glad to help with coding changes to the scintilla
source. I'm pretty good with C++. Or is scintilla's marker behavior
that way intentionally? It seems like other apps would benefit from
this change, too...


Otherwise, would it be safe to say that I can assume that these are the
rules for undo actions if I try to mimic the behavior myself in Python:

A: If I add text in sequence, it remains part of the same action.
B: If I delete text in sequence (all deletes or backspaces occur with
the cursor at the same position it ended at from the previous removal)
then it is part of the same action.
C: Cut/Paste/Selection Deleting actions are considered insertions or
deletions.
D: I need to record the initial position of the cursor and the final
position of the cursor for each action. Upon undo, I go to the final
position of the cursor and remove text backward (if inserted) or insert
text forward (if deleted)
E: As for markers, I will need to store the markers in an array along
with the text and then restore them when undo and redo events are called.

Do you see my dilemma? Which option seems better to you? Is there an
easier way around this that I'm missing? I can provide more specifics
about my problem if that's not clear.

Thanks,
-David

Neil Hodgson

unread,
Jan 7, 2009, 9:03:20 PM1/7/09
to scintilla...@googlegroups.com
David Mashburn:

> Any thoughts? I'll be glad to help with coding changes to the scintilla
> source. I'm pretty good with C++. Or is scintilla's marker behavior
> that way intentionally? It seems like other apps would benefit from
> this change, too...

The current behaviour is intentional. For many uses of markers,
including them in Undo would be wrong. For example, in a debugging
session, I am unlikely to want a breakpoint reinstated if I return to
an earlier version. I am not opposed to adding a very simple way to
insert application actions into the Undo history.

> C: Cut/Paste/Selection Deleting actions are considered insertions or
> deletions.

From the point of view of Undo all actions are insertions or deletions.

> D: I need to record the initial position of the cursor and the final
> position of the cursor for each action. Upon undo, I go to the final
> position of the cursor and remove text backward (if inserted) or insert
> text forward (if deleted)

The cursor position is not remembered in Undo. The position of the
insertion/deletion is. Not all actions are performed on the selection.
SCI_REPLACETARGET is often used because it doesn't affect the cursor.

Neil

David Mashburn

unread,
Jan 20, 2009, 4:14:44 PM1/20/09
to scintilla...@googlegroups.com
Neil,

Thanks for writing me back! I have no problem if the marker code is
supposed to be that way. I'll just do it on my end.

The only thing I would really like to have is a way to be notified when
UndoHistory switches actions. I can do it without this but this would
give me verification that my choices are correct to catch errors... I
have been surprised by this upon testing sometimes...

Is it possible to get this info using the existing API? If not it isn't
that big a deal...

Thanks,
-David

Neil Hodgson wrote:
> The current behaviour is intentional. For many uses of markers,
> including them in Undo would be wrong. For example, in a debugging
> session, I am unlikely to want a breakpoint reinstated if I return to
> an earlier version. I am not opposed to adding a very simple way to
> insert application actions into the Undo history.
>

> From the point of view of Undo all actions are insertions or deletions.
>
>

Neil Hodgson

unread,
Jan 20, 2009, 5:28:41 PM1/20/09
to scintilla...@googlegroups.com
David Mashburn:

> The only thing I would really like to have is a way to be notified when
> UndoHistory switches actions. I can do it without this but this would
> give me verification that my choices are correct to catch errors... I
> have been surprised by this upon testing sometimes...

I'm unsure exactly what you mean by switching actions. Is
SC_STARTACTION what you are seeking? Unfortunately it is not possible
to have an equivalent SC_ENDACTION flag since you don't know at the
time of typing one character whether the user will type another which
belongs in the same undo step.

Neil

David Mashburn

unread,
Jan 20, 2009, 7:16:08 PM1/20/09
to scintilla...@googlegroups.com
Ah, great! I think that is just what I need. Thank you!
Reply all
Reply to author
Forward
0 new messages