determinate editing line undo status

48 views
Skip to first unread message

Don

unread,
Feb 13, 2009, 5:38:06 AM2/13/09
to scintilla-interest, do...@free.fr

Hi Neil,

I'm implementing the side margin to display modified line markers
(like
in Visual Studio 2005) by processing SCN_MODIFIED notification.

This feature needs to know the current editing line undo status while
user press Ctrl+Z, in order to remove the maker if the current line is
on its original status.
I didn't see the message to get current line undo status in Scintilla
document. Is there anyway to get such information?

Thank you in advance.

Don

Neil Hodgson

unread,
Feb 13, 2009, 6:40:41 AM2/13/09
to scintilla...@googlegroups.com
Don:

> This feature needs to know the current editing line undo status

If you mean whether the line has been modified and whether the
modification has been saved (Visual Studio yellow / green margin
states) then Scintilla does not keep such information.

I wrote up an attempt at a change bar feature a while ago as
"Experimental change bar feature" (can be found with google). The
conclusion is that I couldn't find a way to do this that worked well
enough to include in Scintilla.

Neil

Don

unread,
Feb 15, 2009, 5:58:55 PM2/15/09
to scintilla-interest
Neil,

>
>    If you mean whether the line has been modified and whether the
> modification has been saved (Visual Studio yellow / green margin
> states) then Scintilla does not keep such information.
>
>    I wrote up an attempt at a change bar feature a while ago as
> "Experimental change bar feature" (can be found with google). The
> conclusion is that I couldn't find a way to do this that worked well
> enough to include in Scintilla.

I track undo/redo stat myself on each line, then use SCI_SETLINESTATE/
SCI_GETLINESTATE to write/read line undo state :
bool isProcessed = false;

int fromLine = _pEditView->execute(SCI_LINEFROMPOSITION, notification-
>position);


if ((notification->modificationType & (SC_MOD_DELETETEXT |
SC_MOD_INSERTTEXT)) &&
(notification->modificationType & SC_PERFORMED_USER))
{
//printStr(TEXT("user type"));
int undolevel = _pEditView->execute(SCI_GETLINESTATE, fromLine);
if (undolevel < 0)
undolevel = 0;
_pEditView->execute(SCI_SETLINESTATE, fromLine, ++undolevel);

_pEditView->execute(SCI_MARKERADD, fromLine,
MARK_LINEMODIFIEDUNSAVED);
if (notification->linesAdded > 0)
{
for (int i = 0 ; i < notification->linesAdded ; i++)
{
_pEditView->execute(SCI_MARKERADD, ++fromLine,
MARK_LINEMODIFIEDUNSAVED);
}
}
}

if ((notification->modificationType & (SC_MOD_DELETETEXT |
SC_MOD_INSERTTEXT)) &&
(notification->modificationType & SC_PERFORMED_REDO) &&
(notification->modificationType & SC_MULTISTEPUNDOREDO))
{
//printStr(TEXT("redo multiple"));
isProcessed = true;
int undolevel = _pEditView->execute(SCI_GETLINESTATE, fromLine);
if (undolevel < 0)
undolevel = 0;
_pEditView->execute(SCI_SETLINESTATE, fromLine, ++undolevel);

_pEditView->execute(SCI_MARKERADD, fromLine,
MARK_LINEMODIFIEDUNSAVED);
if (notification->linesAdded > 0)
{
for (int i = 0 ; i < notification->linesAdded ; i++)
{
_pEditView->execute(SCI_MARKERADD, ++fromLine,
MARK_LINEMODIFIEDUNSAVED);
}
}
}

if ((notification->modificationType & (SC_MOD_DELETETEXT |
SC_MOD_INSERTTEXT)) &&
(notification->modificationType & SC_PERFORMED_UNDO) &&
(notification->modificationType & SC_MULTISTEPUNDOREDO))
{
//printStr(TEXT("undo multiple"));
isProcessed = true;
int undolevel = _pEditView->execute(SCI_GETLINESTATE, fromLine);
if (undolevel > 0)
--undolevel;
else
undolevel = 0;
_pEditView->execute(SCI_SETLINESTATE, fromLine, undolevel);
}

if ((notification->modificationType & (SC_MOD_DELETETEXT |
SC_MOD_INSERTTEXT)) &&
(notification->modificationType & SC_PERFORMED_REDO) &&
(notification->modificationType & SC_LASTSTEPINUNDOREDO) && !
isProcessed)
{
//printStr(TEXT("redo LASTO"));
int undolevel = _pEditView->execute(SCI_GETLINESTATE, fromLine);
if (undolevel < 0)
undolevel = 0;
_pEditView->execute(SCI_SETLINESTATE, fromLine, ++undolevel);

_pEditView->execute(SCI_MARKERADD, fromLine,
MARK_LINEMODIFIEDUNSAVED);
if (notification->linesAdded > 0)
{
for (int i = 0 ; i < notification->linesAdded ; i++)
{
_pEditView->execute(SCI_MARKERADD, ++fromLine,
MARK_LINEMODIFIEDUNSAVED);
}
}
}

if ((notification->modificationType & (SC_MOD_DELETETEXT |
SC_MOD_INSERTTEXT)) &&
(notification->modificationType & SC_PERFORMED_UNDO) &&
(notification->modificationType & SC_LASTSTEPINUNDOREDO) && !
isProcessed)
{
//printStr(TEXT("undo LASTO"));
int undolevel = _pEditView->execute(SCI_GETLINESTATE, fromLine);
if (undolevel > 0)
--undolevel;
else
undolevel = 0;
_pEditView->execute(SCI_SETLINESTATE, fromLine, undolevel);
}

if (notification->modificationType & SC_MOD_CHANGELINESTATE)
{
int undolevel = _pEditView->execute(SCI_GETLINESTATE, notification-
>line);
if (undolevel == 0)
{
_pEditView->execute(SCI_MARKERDELETE, notification->line,
MARK_LINEMODIFIEDUNSAVED);
}
}


It works pretty good, except for the xml/html document - undolevel is
not zero even there's nothing to undo for this line.
I guess it's due to xml/html style set to 7 bits instead of 5 bits,
but I don't see why.

Do you have any idea to walk around it?

Regards,
Don

Neil Hodgson

unread,
Feb 16, 2009, 3:43:04 AM2/16/09
to scintilla...@googlegroups.com
Don:

> I track undo/redo stat myself on each line, then use SCI_SETLINESTATE/
> SCI_GETLINESTATE to write/read line undo state :

LineState was meant for use by lexers and is currently used by the
Ada, AVE, COBOL, D, HTML, Lua, Pascal, Perl, POV, PS, Rebol, Spice,
TACL, TADS3, TAL, TCL, and YAML lexers. If you use it for other
purposes it will probably be overwritten by these lexers and the
unexpected values will confuse the lexers.

You could maintain your own per line data structure which would
have to handle line insertions and deletions. I'd like to make the
per-line data in Scintilla more generic in the future bit it requires
a bit of work.

Neil

almostautomated

unread,
Feb 22, 2009, 1:13:53 AM2/22/09
to scintilla-interest
Heya Don,

Interestingly enough, a line change marker is also what I am working
on at this time. I'm implementing it from a plugin perspective to
your N++. Looks like this has been a 'wish list' item for some time,
hopefully a strong workable solution is found.

Using the linestate is definitely not a good idea as each lexer is
free to do with it as they please. For instance, that Npp PoweShell
lexer uses it as a bitmap field to track indicator start/end positions
for multi-line highlight indicators that are removed from leading
whitespace, and that required the 1st bit and the two end words.

Have you looked at making up an undo buffer for markers? That's the
direction I'm exploring, and I guess the code for undo/redo handling
will pretty much be the same for a container as a plugin, so if I can
get it working I'll post back to this thread as well as the N++ one.

almostautomated

Don

unread,
Feb 27, 2009, 12:42:10 PM2/27/09
to scintilla-interest
almostautomated,


> Interestingly enough, a line change marker is also what I am working
> on at this time.  I'm implementing it from a plugin perspective to
> your N++.  Looks like this has been a 'wish list' item for some time,
> hopefully a strong workable solution is found.

That's the first idea I got. However it's surely easier to do it
inside Notepad++.

> Using the linestate is definitely not a good idea as each lexer is
> free to do with it as they please.  For instance, that Npp PoweShell
> lexer uses it as a bitmap field to track indicator start/end positions
> for multi-line highlight indicators that are removed from leading
> whitespace, and that required the 1st bit and the two end words.
>
> Have you looked at making up an undo buffer for markers?  That's the
> direction I'm exploring, and I guess the code for undo/redo handling
> will pretty much be the same for a container as a plugin, so if I can
> get it working I'll post back to this thread as well as the N++ one.

Finally, I use Notepad++ internal structure to memorize undo state.
It's still in experience step.
You can check it from SVN.

Let me know if you have better idea/implementation.

Don
Reply all
Reply to author
Forward
0 new messages