ANSI escape codes are lost when restarting sublime

[matt1003]

Description: When restarting sublime text the ansi escape codes are lost for files that have already been processed by the ansi command. This is occurring because the escape codes are lost from the sublime text "undo" buffer when sublime text is restarted.

Reproduce Issue:

1. Open the file "ansi_test_file.text".
2. Set the syntax to "ANSI" via the sublime text menu.
3. Close and re-open sublime text. (note: the coloring has disappeared)
4. Set the syntax to "Plain Text" via the sublime text menu. (note: the escape codes do not return)

Potential Solution: On plugin initialization we need to force such files to be reloaded from disk, therefore reloading the lost escape codes. I am currently working on some patches to implement such functionality.

[jakkubu]

Reloading from disk will work for most cases, but what with files:

1. not saved anywhere
2. with unsaved changes (you may put some changes in text mode and then switch to ANSI)

[matt1003]

@jakkubu You raise valid points. What if we ran the "undo_ansi" command during "plugin_unloaded" for each view with the ansi syntax enabled. This would restore the escape code so that they are not lost when sublime is restarted. However the escape codes will still be lost when sublime aborts abnormally and the "plugin_unloaded" is not invoked (i.e. sublime crashes for whatever reason).

[jakkubu]

@matt1003 undo_ansi during pluggin_unloaded sound great, but when I try - it doesn't work - does it for you?

[matt1003]

@jakkubu I have tried it using the on_close and on_pre_close event listeners and they do not seem to work either. I have verified that there are being executed when sublime is shutting down, however the changes made to the view's setting do not persist when sublime is restarted. It appears that the views' settings cache is being flushed to disk before the on_close/on_pre_close event listeners are invoked.

[jakkubu]

@matt1003 I found that view.settings() are saved to filename.sublime-workspace at sublime close. We can use it to save regions (actually there is "regions" in view settings, but it's empty). If we decide to use it we can:

• solve this issue
• make better 'ansi_undo'
• make editable ANSI view

What do you think? If yes I think we should do it in new branch, test current master on large files and release it.

[matt1003]

@jakkubu This is a great idea! Our dependency on view.run_command("undo") within the ansi undo command has been continually giving me headaches when dealing with that area of the code; if we could remove it that would be great!

[matt1003]

@jakkubu I have added the sublime.PERSISTENT flag to view.add_regions(...) which forces new regions to be added to the "regions" field in the view settings (as you described), see commit cb47052. As a result, these ansi regions are preserved when sublime is restarted, allowing for the text coloring to be automatically restored correctly when the corresponding view is opened.

Although this fixes the text coloring, the escape codes themselves are still being lost (as they are still being maintained in sublimes undo buffer). This dependency on the undo buffer is something that we really need to get away from. There is a direct one to one mapping from escape codes to ansi regions (correct?); so can't we just use the region itself to determine which escape codes need to be inserted back into the text when running the ansi undo command? Heck, we could even stuff the actual escape code into each region object itself, therefore ensuring that we restore the original escape code text when running the ansi undo command.

As a side note... we need to make sure that the ansi view doesn't break if the file is changed between closing and opening sublime. Hopefully this should be picked up by your check_left_ansi event handler.