Release 1.4.5 github.com/facelessuser/ScopeHu … /st3-1.4.5:

• Fixed multi-select tooltip copy link issues
• Better scope extent detection
• Small formatting changes

Earlier it was asked if ScopeHunter can just display scopes, and the answer is yes. By default, scope is the only think enabled. All other advanced things must be enabled by the user. So here is just scopes.

I think we can call this done until Jon tweaks the API. Formatting may change a little if Jon adds new CSS and/or HTML capabilities, but functionality is complete unless anyone finds any more bugs.

Not works. Nothing happens when select either menu on Command Pallete
ST3 b3071, installed via Package Control
I tested the default tooltips still work:self.view.show_popup('Hello, <b>World!</b><br><a href="moo">Click Me</a> <style>color=red</style>', on_navigate=print)
My User Settings:{ "show_popup": true, "show_statusbar": true, }

Did you restart sublime after installing?

yes, I did restarted ST
btw, I’m on Win 7 x64, STx64

I can’t think of any windows specific things that would break it. Are you getting errors in the console?

reloading plugin ScopeHunter.scope_hunter reloading Packages/ScopeHunter/scope_hunter.sublime-settings reloading plugin ScopeHunter.scope_hunter_notify Unhandled exception in thread started by <function sh_loop at 0x0000000004984488> Traceback (most recent call last): File "scope_hunter in C:\Users\Fichte\AppData\Roaming\Sublime Text 3\Installed Packages\ScopeHunter.sublime-package", line 629, in sh_loop AttributeError: 'NoneType' object has no attribute 'ignore_all'

Edit: That only happens when disabling and enabling the plugin btw. You should close the sh_loop thread in plugin_unloaded.

Other than that it works fine. I’m just a bit annoyed by the verbosity, imo the information can be condensed quite some.

Edit2: Your usage of the global keyword is also rather inconsistent. Sometimes you use it (when you don’t need to) and sometimes you don’t. You generally only need to use it when assigning to a non-local variable, reading will be forwarded upwards.

Edit3: In fact, I would prefer nonlocal in pretty much all cases since you define the default value very early in the code and it’s a more defensive style of coding because trying to reference a non-existant nonlocal identifier raises while globaling one just creates it (and is not a great idea in general).

Yeah, that is a scenario I haven’t bothered to test. I can look into that. So, basically it works in Windows; that’s what I thought because I haven’t changed anything since Friday (when I last tested Windows) that would be platform specific.

I am open to suggestions.

Yeah, some of that could be cleaned up, but it isn’t really a big deal. I only really need it when I am directly changing the variable. I can modify the object all day long without needing to use “global” since I am not changing the actual variable, but everything works, so that kind of stuff usually gets overlooked.

Release 1.4.6

Thanks to @FichteFoll for finding it, a bug where when disabling and reenabling a package caused an error has now been fixed. This bug actually existing on a number of my plugins that employ the same threading mechanism, so it was good to get this fixed across the board.

I have verified this works in OSX and Windows. So I will need more info from you, @Binocular222, if I am to troubleshoot your issuer further. I would look in the console, and also check if other plugins are somehow interfering, double check your settings file is not corrupt, and possibly consider a Sublime revert as I am unable to reproduce your issue.

Still nothing happens, even console display nothing

Make sure the package isn’t disabled in Package Control (I’ve seen package control do that on occasion, but I imagine you wouldn’t see the plugin commands in the command palette if that was the case; but check anyways). If that doesn’t work, try a Sublime revert. Right now, that is the best I can offer as I am on Windows x64 ST3x64@3071 and it is working fine for me. Without any additional info, I can only assume you have some local anomaly that no one else has; I simply cannot fix what I cannot observe to be broken, I am sorry I can’t do more.

Release 1.5.0

Changes

• Tooltips are less verbose
• Tooltips are more compact
• Tooltips now generate images for color boxes
• CSS changes to tooltips
• Better control of tooltip content
• Dividers between multiselect scopes
• Added messages.

Important!
Tooltips now only work on 3072. There were some changes in the Sublime API that Scope Hunter is now taking advantage of, so if you want tooltips to still look good, please upgrade Sublime to 3072 or disable tooltips.

There have also been some settings changes to give users even better control of the info shown:

• Discontinue show_color_scheme_info settings.
• Added styling, selectors, and file_paths options to show respective info.
• Remove css_file setting. ScopeHunter now always uses either dark or light css depending on brightness of the user’s color scheme. So if you would like to change the tooltip theme, please override those in the settings file.

Given some time, I may be able to generate transparent color boxes that show a checkered pattern behind it. Completely possible now that I am generating images for color boxes .

Had a little more time and got transparent color squares working which will be included in the next release.

I probably won’t make another release until I am certain the tooltip API isn’t going to change much anymore, or when the next public beta hits.

ScopeHunter 2.8.0 is released and handles .sublime-color-scheme files. Should show results based on overrides as well. Some things it may have shown before may not be shown now due to the way data is acquired via the new API, but a plus side is ScopeHunter will now always show the most up to date info while before it could show slightly old info if the color scheme was updated behind the scenes.

Again, let me know if you run into bugs in the latest release.

Just an FYI for people using ScopeHunter on 3150+. Due to the new override system of scheme files, and the fact that the API only exposes the merged final style, I can’t provide info anymore like the scope responsible for bold or italic, or what scope influenced the background etc. So the fact that they aren’t shown was done on purpose.

I have the ability to parse the format, but I don’t have an easy way to aggregate all the overrides and essentially import a single merged copy. It could be done if I scanned all the packages and merged each override (assuming I could reliably get the order correctly), but I imagine there is no solid way to guarantee I’d get the order correct…and I’m not going to spend time scanning all the packages. If there ever is a way to pull in the fully merged copy of the scheme to parse it raw, then this will change, but since that is not currently possible, some info you may be used to is omitted.

Relevant discussion:

I believe you should be able to execute sublime.find_resources('Name.sublime-color-scheme') and load the resulting files in order. The only thing this wouldn’t get you is if the file was in an extracted override versus inside of a .sublime-package file.

Thanks @wbond, it’s something to consider. find_resources sounds like a good approach. I have to now decide how much I care to pursue this . With enough logic, I’m sure I could resolve all this override logic. Using load_resources would definitely solve where I’m extracting from. Though I guess you also have to be aware if the unpacked override is a sublime-color-scheme…so you can’t just blindly call load_resources.

@wbond, I assume if the unpacked and packed theme style format varies, the sublime-color-scheme is preferred, is that the appropriate assumption? I gather this only because syntax seem to work that way, so I imagine Sublime would treat color schemes the same.

If I were to do this, I won’t know when one of the overrides change, so reloading would be based solely off when preferred scheme updates in the view or preference file (but to be honest, this is no different than it was pre 3150). I could also add a manual refresh trigger in the popup.

I’ll consider this.

Haha, I understand!

Alright, it was actually pretty easy to add support for overrides. So 2.9.0 adds back familiar features and hopefully aggregates all the overrides proper. Report bugs if you find them.