Sublime Forum

When does a view object get destroyed?

#1

Does anyone happen to know when a view object gets destroyed?

I am able to create a new view using open_file(), close it immediately using run_command("close"), and still then happily access the settings using settings(). Is this safe?

temp_buffer = active_window.open_file(temp_file, sublime.TRANSIENT)
active_window.run_command("close")
active_window.focus_view(active_view)
syntax = temp_buffer.settings().get("syntax") # returns correctly

Also a related question:

Am I correct in thinking that settings are assigned to a view before open_file() returns because calling settings() while is_loading() still returns true seems to be perfectly fine?

temp_buffer = active_window.open_file(temp_file, sublime.TRANSIENT)
temp_buffer.is_loading() # returns true here
syntax = temp_buffer.settings().get("syntax") # returns correctly
temp_buffer.is_loading() # still returns true here

Thanks

0 Likes
#2

A view object is only a python representation of the real view. There may exist several view objects per view. Once created they live as long as any other python object depending on where it is used. You need to call view.is_valid() to check, whether the view still exists.

Same for the settings member. Once created it exists as long as the view exists but don’t need to point to a valid view. As settings are a merge of several files, a value read from an invalid view object might simply contain global settings only. Looks valid.

Settings don’t depend on a view’s content, so you can use view.settings() right after creation, even though file may still be loading.

5 Likes
#3

Interesting questions. Here’s some supposition for you which may or may not muddy the waters and/or may not already be things you know/have tried/have guessed. I’m definitely interested in what the gurus have to say on this one.

The fact that the view class has a method is_valid() seems to indicate that it is expected that a view object may hang around for an arbitrary period of time after the underlying buffer goes away. The view definitely would have to hang around until at least after the on_close callback is invoked, which happens right when the close command is executed.

Since the on_close_async handler would also need to have a view and presumably do something with it If I had to guess I would say that the standard garbage collection mechanism would be in control of when such an object goes away, which means that as long as you’re in a position to check, it’s going to still be there.

Based on the following code, the view object remains around (with it’s unique ID) but the buffer object goes away at some point, and when it does, the attempt to access the settings doesn’t throw an error but just returns None.

    def run(self):
        active_window = sublime.active_window()
        active_view = active_window.active_view()

        temp_buffer = active_window.open_file("c:/test.txt", sublime.TRANSIENT)
        active_window.run_command("close")
        active_window.focus_view(active_view)

        def check_valid():
            print("---")
            syntax = temp_buffer.settings().get("syntax") # returns correctly
            print(syntax)
            print("view ID", temp_buffer.id())
            print("Buffer ID", temp_buffer.buffer_id())
            print("Is valid", temp_buffer.is_valid())

        check_valid()
        sublime.set_timeout(check_valid, 1000)

Based on this and the principles of thread safety I would assume that is_valid would not just spontaneously start returning false while a command is still running and as long as its still reporting as valid the settings are still available.

This sort of glosses over how settings are specific to a view and not to a buffer though. Possibly whatever internal mechanism makes the buffer go away also tells the view and it’s specific settings are no longer needed because it’s not representing anything anymore?

Evidence seems to suggest that this is the case; in this case it can not only get the syntax, but also syntax specific settings (including custom settings that have nothing to do with the core).

Again, if I had guess I would say that the loading process would want to know at least the syntax being used so that it could process the syntax as the file was loading, and to do that it would make sense to apply all settings and not just the one.

3 Likes