Hi,
as long as we would
state in doc that the transaction was started before the given action.
I don't think that exposing this is helpful. Client code does not
currently know about there being separate startAction records and the
implementation could replace them with a startAction flag on actions
instead. From the client's point of view this would be invisible.
yes that's OK, the user must just know that the associated modification
occured inside the actual action, but whatever, it could not be really
different than that.
I need to send the notification from BeginUndoAction because first it is
an
homogenous behaviour (all transaction starts get their notification),
second
because Scintilla opens its own transactions (for example when calling
SetEol or such).
Empty begin/end pairs are not retained. I thought you were after
one SC_START_ACTION notification for each point that would be hit by a
stream of undo operations. The notification should be on the first
real modification to match undo behaviour.
interesting, i'll have to find test cases to see how my code behaves when
the BeginUndoAction gets finally ignored, it should give bad results as I
expect to have exactly one undo action each time I make a BeginUndoAction ;(
it is probably impossible however to obtain these cases in my soft.
could we have from the high level something to tell ? such as
BeginUndoAction(forceRetain)?
The term "action" is used in Scintilla to avoid the conceptual
baggage that comes with "transaction". There is no abandon or commit
and there is certainly no attempt at isolation.
yes :) fine for me
Thanks for your interest
Armel
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
