Is it possible to distinguish it from an “honest” on_load that happens when a file is opened for real?
In my plugin I want to typecheck loaded files, so that the user instantly gets error highlighting and other good stuff. It’s usually 1-2s of background work, so it’s not a problem at all.
Except when I use goto anything. Then simply typing a name of the file I want might produce a bunch of file previews, each of them potentially triggering a typecheck. Now that might be a problem.
It looks like when previewed with Go to Anything, a view first gets on_activated with v.file_name() equal to None and then on_load.
To the contrast when opened normally, a view first triggers on_load and then on_activated with a non-empty name.
I’m having a similar problem. I want to ignore previews when single clicking in sidebar. However, it always triggers on_load, on_activated with view.file_name() NOT set to None, so there is no way to tell whether the file is being previewed or actually opened. It also triggers on_close on the previous file being previewed
The only time view.file_name() is None is with a new, not yet named file.
I looked at all the other properties, name(), buffer_id(), is_read_only(), is_scratch() but they are all the same between preview and opened file.
ST3 build 3126
Unfortunately, window.transient_view_in_group(window.active_group()) always returns None in on_load and on_close, with or without delay.
One helpful thing is on_close, view.window() is None when actually closing a view. If you are previewing file A and preview another file B, on_close will fire (because you are closing A) but view.window() will not be None.
For now, I just keep a count of # of opened views and do something on_load if the count goes up by 1 and something on_close if count goes down by 1 or view_window() is None. This means I get both false positives and false negatives but at least I’m not doing a bunch of extraneous stuff when I am browsing files.
I used a work around based on window.get_view_index.
https://github.com/FichteFoll/FileHistory/blob/master/file_history.py function “is_transient_view”.
Thanks. This is what I’ve figured out (possibly wrong)
There are two different cases (ST3):
when a plugin uses window.open_file with sublime.TRANSIENT flag, typically in an show_quick_panel on_select callback
on_load: view.window() is None
on_close: view.window().get_view_index(view)[1] == -1
So you CAN tell if view is transient, when there is no tab assigned
when you single click to open a file in the side bar, it is semi-transient. There is a tab assigned, but if you click on another file, it loads in same semi-transient view. If you start editing or double click on the file, view becomes non-transient. Here
on_load: view.window().get_view_index(view)[1] != -1 like a normal open
on_close: view.window().get_view_index(view)[1] == -1
So in this case, you don’t know if view is transient in on_load, and don’t know when it goes from transient to permanent (as indicated by change in tab appearance if your theme is configured for it).
So 90% there 
I guess that’s the best for now.
In my experience, this is the only reliable method I’ve found:
def is_transient_view(view):
if view is None:
return True
if not view.file_name():
return True
win = view.window()
if win is None:
return True
# Kinda sucks, but it seems to be the only reliable method:
# https://forum.sublimetext.com/t/6931
return view not in win.views()As far as I know, transient and semi transient nature of a tab is a property of the underlying sheet object of the target view. Maybe view.sheet().is_transient() is a more better solution?
Gonna improve my codes.