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)?
Andy Edits
[quote=“singw”]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)?[/quote]
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.
[quote=“agibsonsw”]
[quote=“singw”]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)?[/quote]
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.[/quote]
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 https://forum.sublimetext.com/t/highlighting-lines-changed-from-the-last-commit/5867/1#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.
@singw
Mmm 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.
[quote=“agibsonsw”]@singw
Mmm 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.[/quote]
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?
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 just rustled up the following code that, when pressing Save, produces a summary of the saved edits:
I wonder if this is of interest?
[code] def on_pre_save(self, view):
_ = adjustEdits(view)
saved_edits = view.get_regions(“edited_rgns”)
newview = sublime.active_window().new_file()
edit = newview.begin_edit()
for i, r in enumerate(sorted(saved_edits)):
editline, _ = view.rowcol(r.begin())
newview.insert(edit, newview.size(), "\n-----\nLine: " + str(editline) + '\n')
newview.insert(edit, newview.size(), view.substr(r))
newview.end_edit(edit)[/code]
I’ve added this to my repo in case anyone wants to explore it as an option.
Just add a setting “output_edits”: true and every time you Save it will produce a summary view, which can be saved or abandoned.
Edited: It is “output_edits” (not “output_options”).
@singw Perhaps I’m over-thinking this. I’ve updated it to read the following settings:
"saved_scope": "keyword",
// whether to outline saved edit-regions
"saved_edits": true,
// whether to create a summary of edits on save
"output_edits": false
If ‘saved_edits’ is true then pressing save will outline the edited-regions with the scope given by ‘saved_scope’ (defaults to keyword). Let me know how you get on with this.
‘output_edits’ determines whether to produce the output summary on save, as mentioned in my previous post. Andy.
[quote=“agibsonsw”]@singw Perhaps I’m over-thinking this. I’ve updated it to read the following settings:
"saved_scope": "keyword",
// whether to outline saved edit-regions
"saved_edits": true,
// whether to create a summary of edits on save
"output_edits": false
If ‘saved_edits’ is true then pressing save will outline the edited-regions with the scope given by ‘saved_scope’ (defaults to keyword). Let me know how you get on with this.
‘output_edits’ determines whether to produce the output summary on save, as mentioned in my previous post. Andy.[/quote]
Thanks for your work!
But outlining the edited regions is quite distracting for me, I prefer just an icon on the gutter.
And after I used the above settings, no icons any more on changes, but only those outline.
Yes, it is distracting. Also, editing within a ‘saved’ region, it still shows as a saved region.
I’ll probably remove this feature, and the edits-summary, tomorrow (although they don’t do anything unless we add their settings).
Andy.