singw wrote:Currently, "icon_current" is just for the modifying line.Is it possible to make the "icon_current" for the changes that is not saved (and the "icon_scope" is for saved changes)?

Hello. Are you referring to saving of the file? That is, you would like two sets of colour - one colour for saved changes?

If so, it would be possible - although I would prefer to use three colours (scopes). I would still want the current edit-region to be differently-coloured, as it is central to the whole algorithm.

I'll await your clarification. Andy.

Yes I am referring saving of the file. 1 color for saved changes, 1 color for edited but not saved changes.For more clear, please have a look on my previous post on other thread http://www.sublimetext.com/forum/viewtopic.php?f=5&t=7468#p31999 . After looking the attached screenshot inside that post, you may more clear on what I mean.

Currently the "icon_current" setting is for the last edited line, and "icon_scope" is for changed line (no matter saved or not).

For what you said "three colours", you mean 1 color for saved lines, 1 color for edited but not saved lines, and 1 color for last edited lines? That's also great. But the last edited lines also got the state of (saved) or (edited but not saved), so, it should be 4 colors. But seems like to much....right? So, I hope the 2 colors set and 3 colors set can be an option.

@singwMmm this is quite a detour from the original purpose of my plug-in; heading towards a Diff-tool or versioning system.

It would require maintaining two sets of regions, being able to combine them when needed, but still keep them distinct. It would also mean that every time a line is edited, the two regions are erased and recreated from scratch (this is how ST-regions work).

I shall think about this some more but, for the moment, I'll leave the plug-in as it is and concentrate on fixing any niggles, minor changes, etc.. Soz, Andy.

"I'm here to save your life. But if I'm going to do that, I'll need total uninanonynymity." Me Myself & Irene.

agibsonsw wrote:@singwMmm this is quite a detour from the original purpose of my plug-in; heading towards a Diff-tool or versioning system.

It would require maintaining two sets of regions, being able to combine them when needed, but still keep them distinct. It would also mean that every time a line is edited, the two regions are erased and recreated from scratch (this is how ST-regions work).

I shall think about this some more but, for the moment, I'll leave the plug-in as it is and concentrate on fixing any niggles, minor changes, etc.. Soz, Andy.

Why my idea is heading towards a Diff-tool or versioning system?The icons (edited, edited but not saved) will be cleared after the file is being closed, no need to save the changed icons' position, so nothing extra is being saved . When open that file again, those icons of the previous changes will not be show again. Just like the current behavior of this plugin.

"It would also mean that every time a line is edited, the two regions are erased and recreated from scratch"I don't quite understand what it means. Isn't the plugin change the icon when the edit position change now?

I don't quite understand what it means. Isn't the plugin change the icon when the edit position change now?

When a new edit-line is created, and we move away from this line, then the line is added to the existing edit-regions. However, it is not possible simply to add this new region. What happens is:

The existing edit regions are retrieved into a new list using get_regions();The new edited region is added to this new (temporary) list using append();This list is iterated (in sorted order) to collapse any adjoining or overlapping regions;The existing edit-regions are deleted (using erase_regions()) and re-created (from scratch!) using add_regions().

To maintain two distinct (saved and not-yet-saved regions) would require (after a line is edited):

Grab both sets of regions (and the new region);Merge these to a new list in sorted order;Iterate this list, merging any that are adjoining or overlap, but only if they belong to the same set - saved or not-yet saved;Split this list into two so that the region-sets saved and not-yet-saved can be reinstated.

A similar process would be necessary in order to produce the jump-lists. That is, to create jump-lists that appear in file-order, but still distinguish between saved and non-saved regions.

Another slight complication is to decide how to handle saved regions that overlap with non-saved regions.

Multiple-undo/redo behaves quite well currently - it took a bit of effort to control this behaviour . Their behaviour would need to be re-examined when there are two types of regions to maintain, and it may not be possible to control their behaviour to an acceptable level.

Ideas occurred to me to either collapse saved-regions to a single edit point, or to insert hidden content , but I doubt that either of these options are workable.

So I'm afraid I'm going to leave "as is" for the moment and concentrate on resolving any issues that arise/handling minor change requests. Of course, anyone is welcome to clone/fork my code and work on your suggestion .

Hope you're not too disappointed; Andy.

"I'm here to save your life. But if I'm going to do that, I'll need total uninanonynymity." Me Myself & Irene.