[scintilla] Availability of changebar-enabled SciTE

29 views
Skip to first unread message

Jiří Techet

unread,
Apr 29, 2010, 6:57:57 PM4/29/10
to scintilla...@googlegroups.com
Hi Neil,

is your scite branch with changebar available anywhere? I tried the
link mentioned in your original post here

http://groups.google.com/group/scintilla-interest/browse_thread/thread/2e5e1b82350886cc/adea77152522a434?lnk=gst&q=change

but it seems to be dead. I'd like to look at the code a little.

Thanks,

Jiri

--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla...@googlegroups.com.
To unsubscribe from this group, send email to scintilla-inter...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.

Neil Hodgson

unread,
Apr 29, 2010, 8:34:23 PM4/29/10
to scintilla...@googlegroups.com
Jiří Techet:

> is your scite branch with changebar available anywhere? I tried the
> link mentioned in your original post here
>
> http://groups.google.com/group/scintilla-interest/browse_thread/thread/2e5e1b82350886cc/adea77152522a434?lnk=gst&q=change
>
> but it seems to be dead. I'd like to look at the code a little.

Moved to
www.scintilla.org/scitecb.zip

The Notepad++ people implemented a change bar for Notepad++ so it
may be worthwhile looking at their work.

Neil

Jiří Techet

unread,
May 1, 2010, 4:14:39 PM5/1/10
to scintilla...@googlegroups.com
On Fri, Apr 30, 2010 at 02:34, Neil Hodgson <nyama...@gmail.com> wrote:
> Jiří Techet:
>
>> is your scite branch with changebar available anywhere? I tried the
>> link mentioned in your original post here
>>
>> http://groups.google.com/group/scintilla-interest/browse_thread/thread/2e5e1b82350886cc/adea77152522a434?lnk=gst&q=change
>>
>> but it seems to be dead. I'd like to look at the code a little.
>
>   Moved to
> www.scintilla.org/scitecb.zip
>
>   The Notepad++ people implemented a change bar for Notepad++ so it
> may be worthwhile looking at their work.
>
>   Neil
>

Thanks a lot Neil.

Actually I'm porting the changebar for geany which fits my needs
better than codeblocks that I was using previously as my IDE for a
huge C++ project at work. But I've realized that I can't live without
the changebar any longer - it's so much useful. codeblocks also has
the changebar ported to a recent version of scintilla + clearly marked
what changes are related to the changebar in the sources. I just
needed the original version to see how you initialize the changebar in
SciTE (codeblocks use wxScintilla so it's a bit harder to see).

I was wondering - wouldn't it be better to merge the changebar into
the mainline? There are already a few projects using it and I think
it's a bit unfortunate that each of them has to maintain their own
branch of scintilla just to have the changebar feature. I know that
you are dissatisfied with the memory consumption and precision of the
current implementation (even though from my practical experience I
haven't seen any disastrous effects of it - you can be pretty sure
you're always below the memory consumption of Eclipse without a single
document opened ;-). But if you declare this feature as "highly
experimental" in the documentation and describe its limitations, I
think nobody can complain they haven't been warned. If the developers
decide to use it, its their own responsibility (they'll probably
propagate this into the settings dialog of their editor so the
editor's user would see something like "enable changebar (be careful,
highly experimantal)" in the settings so everybody will be warned).
But for those who want to use changebar it will be easy to enable and
the developers won't have to maintain their own branch of scintilla.

Just an opinion of a real fan of this feature.

Cheers,

Jiri

Neil Hodgson

unread,
May 1, 2010, 7:30:21 PM5/1/10
to scintilla...@googlegroups.com
Jiří TechetÖ

> I was wondering - wouldn't it be better to merge the changebar into
> the mainline? There are already a few projects using it and I think
> it's a bit unfortunate that each of them has to maintain their own
> branch of scintilla just to have the changebar feature.

If there is a variant that works well I'd like to consider it but I
don't currently have time to look closely at implementations.

> I know that
> you are dissatisfied with the memory consumption and precision of the
> current implementation (even though from my practical experience I
> haven't seen any disastrous effects of it

It was always seen as optional. It really is not good enough to use.

Neil

Jiří Techet

unread,
May 3, 2010, 7:17:03 PM5/3/10
to scintilla...@googlegroups.com
On Sun, May 2, 2010 at 01:30, Neil Hodgson <nyama...@gmail.com> wrote:
> Jiří TechetÖ
>
>> I was wondering - wouldn't it be better to merge the changebar into
>> the mainline? There are already a few projects using it and I think
>> it's a bit unfortunate that each of them has to maintain their own
>> branch of scintilla just to have the changebar feature.
>
>   If there is a variant that works well I'd like to consider it but I
> don't currently have time to look closely at implementations.
>

The codeblocks changebar implementation seems to work. I've already
ported it to geany without any major problems. But I think the
codeblocks people just took your implementation without improving
anything so there will be the same limitations as in the original
implementation. I will happily provide a patch on top of mainline if
you agree merging it - just let me know. I would make a few changes
though - e.g. remove SC_MARKNUM_CHANGEUNSAVED and
SC_MARKNUM_CHANGESAVED from SC_MASK_FOLDERS so the behaviour of
SC_MASK_FOLDERS remains unchanged. On the other hand I don't have much
time myself either so I won't spend time fixing the problems.

>> I know that
>> you are dissatisfied with the memory consumption and precision of the
>> current implementation (even though from my practical experience I
>> haven't seen any disastrous effects of it
>
>   It was always seen as optional. It really is not good enough to use.

But in order to have an overview of what has been changed in a file
it's much better than good enough. Actually, even one-colour changebar
(that doesn't distinguish between saved/unsaved changes) would already
be a great help. Just wondering - would such a simplified changebar
suffer from high memory consumption too? (You don't describe how you
mark the save point so I don't know what's needed for it.)

Side note: I'm not sure I completely understand your description of
the changebar implementation (and I haven't studied the implementation
itself):

"Now an undo step number is saved for each line so if a 4 line file is
loaded and line 2 then line 0 are changed, the current state looks
like [2, 0, 1, 0]. Since history is stored so that this can be
restored when undo is performed the history contains [[0,0,0,0],
[0,0,1,0]]."

Why is it stored like this? I don't get it, but maybe I'm overlooking
something. Just intuitively what I would store for each line is the
number of undo's needed to return to the unmodified state. That is, in
your example the current state would be (written vertically - easier
for my brain to grasp):

1
0
2
0

With this encoding you don't need to keep the list of history states
because the history is stored implicitly - doing one undo step means
subtracting

1
1
1
1

from the non-zero fields. So the previous undo step would be

0 - gets unmodified, yellow disappears
0
1
0

and after subtracting once again you get

0
0
0 - yellow disappears
0

Of course with this implementation you would have to keep the redo
history, but memory-wise this is much better as redo steps are
discarded once the file is modified and people usually do only several
undo steps so there won't be so many redo steps stored (contrary to
the full file's undo history in your implementation). So if you
support say 2^16 undo steps, this implementation will consume
2*linenumber bytes.

Now it would be nice if it worked like that, but I don't expect you
haven't considered this possibility. So please tell me what I overlook
here :-).

Jiri

Neil Hodgson

unread,
May 5, 2010, 1:24:17 AM5/5/10
to scintilla...@googlegroups.com
Jiří Techet:

> (You don't describe how you
> mark the save point so I don't know what's needed for it.)

The save point is just a step number. It may be before the current
point, after the current point if the user has undone to before the
file was saved. It may even be outside the undo history when the file
was saved then an undo was performed and another edit. The
before-the-save-point situation complicates change bars although it
may be an acceptable simplification to treat this as a special case
with a different display style.

> Why is it stored like this? I don't get it, but maybe I'm overlooking
> something.

This feature has some subtleties. I don't really have enough time
to think myself back into the state where I kinda understood it but
one of the major problems with most approaches is splitting and
merging lines and the lack of permanent line identifiers.
Now, what do you do when one step deleted a line end and thus
merged (in the forward direction) two different values into one? You
can start to make special cases such as saving a copy of the table
whenever the number of lines changes.

Jiří Techet

unread,
May 8, 2010, 6:24:02 PM5/8/10
to scintilla...@googlegroups.com
I see. While it would be possible to have some sort of graph that
would record new line insertions (split) and deletions (merge), it
definitely complicates things (with not so clear benefit).

OK, back to my original question - do you think it would be possible
to merge the current implementation of the changebar as an optional
feature to the mainline, or is it no way for you given its
limitations? As I said, I would provide a patch doing that.

Jiri

Neil Hodgson

unread,
May 9, 2010, 5:16:56 AM5/9/10
to scintilla...@googlegroups.com
Jiří Techet:

> OK, back to my original question - do you think it would be possible
> to merge the current implementation of the changebar as an optional
> feature to the mainline, or is it no way for you given its
> limitations?

No. As I said: "It really is not good enough to use". I think that
a good implementation of this feature will be found but it just hasn't
seen enough investigation yet to reveal it.

If you feel that it is good enough and is worth your effort to
support and maintain then you could start a project that provides this
either as an altered version of Scintilla or as a set of patches.

Neil

Jiří Techet

unread,
May 11, 2010, 10:40:03 AM5/11/10
to scintilla...@googlegroups.com
On Sun, May 9, 2010 at 11:16, Neil Hodgson <nyama...@gmail.com> wrote:
> Jiří Techet:
>
>> OK, back to my original question - do you think it would be possible
>> to merge the current implementation of the changebar as an optional
>> feature to the mainline, or is it no way for you given its
>> limitations?
>
>   No. As I said: "It really is not good enough to use". I think that
> a good implementation of this feature will be found but it just hasn't
> seen enough investigation yet to reveal it.

OK, I'll put it on my list of things I would like to improve and maybe
in the future when I have more time I'll think more about a better
solution.

>
>   If you feel that it is good enough and is worth your effort to
> support and maintain then you could start a project that provides this
> either as an altered version of Scintilla or as a set of patches.

I think no extra branch is needed - the codeblocks people already do
that - even though they have some additional codeblocks specific stuff
in their branch of scintilla, every addition is commented so it's a
matter of 15 minutes to extract the changebar code from it. My point
was to have it in the mainline so other people can use it directly
without making their (or depending on other) branches. But I
understand your position.

Thanks,

Jiri
Reply all
Reply to author
Forward
0 new messages