Why not just open and write to a file handle using python?
Because if you write the file to disk manually then users get repeated “File has changed on disk” messages (depending on their configuration). Doing things “the right way” means saving the view/buffer using Sublime’s API.
Clear the console.
sublime.clear_console()
I know it’s not really important, but when you create plugin, it would help to keep a scrollbar larger than 1px 
Matt
Hello @wbond,
I am working on a search plugin. For reference the UX is currently defined like this plugin: https://github.com/krasun/SublimeInternetSearch
In order to make a search I have to open the input with show_input_panel then make a request and finally populate search results with the show_quick_panel API.
From a user perspective, they are searching in the input (bottom left of the screen) and then getting results in the middle. With a field to further filter results but that doesn’t work for new searches.
That makes the user flow very clunky.
Would be awesome if we could have the same callback that we have on the input_panel with the show_quick_panel with access to the user input and the ability to modify the list on user input (bypass the match).
In a summary I would love:
Importance: Major
Difficulty: Should be pretty easy for you.
Thank you !
A function to check if a view is currently visible would be helpful in some situations, to check whether a plugin needs to update a view or not.
view.is_visible()
The function should return true, if the view is the active one in any group. For now I implement it like this, but I think it should be part of the View class as well as all the other new is_..._visible methods.
def is_view_visible(view):
"""Return true if the view is visible.
Only an active view of a group is visible.
Note: this should be part of the View class but it isn't.
"""
w = view.window()
return any(view == w.active_view_in_group(g)
for g in range(w.num_groups())) if w is not None else False
is_visible has fuzzy meaning though. What if it’s active but window is entirely covered by other window? Is it still visible then? Might be better to just call it is_active which would imply “in group”.
The “active view” is, by convention, the view in the window that has focus (or most recently had focus if a panel is open). This is what Window.active_view returns at least. By the way, that also works for inactive windows.
I also wouldn’t care about the window being covered by other windows, most specifically because ST wouldn’t even know this, so is_visible is fine.
How about making view.set_syntax_file extension agnostic? IMHO, it should prefer sublime-syntax over tmLanguage when no extension is specified.
##Make sublime.View and sublime.Window classes hashable
This is a minor request. I use View objects as keys in a dictionary sometimes. However they are not hashable. So I have to use view.id() as the key in the dictionary. The solution is very simple:
class View(...):
...
def __hash__(self):
return self.id().__hash__()
def __eq__(self, other):
return self.id() == other.id()
The same can be done for Window objects.
When parsing project settings, I usually do something like
blah = sublime.expand_variables(blah, self.window.extract_variables())
I’d like this function to throw when an unknown variable is encountered. For instance, ${project_path} is a well-known useful variable, but when people misspell it, it is seen as an unknown variable and is expanded to the empty string. I would like to detect this case, but it is not possible at the moment, unless I start hacking in my own variable parsing functions. So I propose to change the signature from
expand_variables(value, variables)
to
expand_variables(value, variables, <throw_on_unknown>)
where throw_on_unknown is a boolean parameter which is False by default. The thrown exception type should hold the name of the unknown variable as a string.
In addition to @rwols’s suggestion:
sublime.expand_variables leave the $ and the variable name if unknown.For example:
>>> sublime.expand_variables('$hello', {}, soft=True)
$hello
While just not replacing is way better than throwing up, I’m still against this because of the provoked inconsistency with primarily build systems. If build system replacement was adjusted accordingly, I’d be neutral on this change.
Or optionally return the expanded string and a set of variables that weren’t found, and replaced by the empty string ?
And the default build system could print a warning for not found variables ?
expanded, missed = sublime.expand_variables('$hello', {}, return_missed=True)
for var in missed:
print("Variable {var} was replaced by '' because it wasn't found in the settings.")
dpi_scale
DPI scale: 1.25
startup, version: 3126 windows x64 channel: stable
It would be great to have the chance to get dpi scale factor in the plugins.
I noticed there is currently no on_build event available. While I often thought about ways that for allow more powerful build tools, I never had a pressing case that would require an on_build event (in the past I circumvented this by having “build” run a shell script). That changed yesterday.
One of my packages automatically decompiles binary AppleScripts to plain-text and re-compiles them whenever the file is saved. I did not communicate this the package in the description, so yesterday someone posted an issue. Instead of saving, he used the available build tool that compiles plain-text AppleScript into a binary file. Compiling an already binary AppleScript does not throw an error by osacompile, instead the file gets “double-compiled”.
An on_build event (or maybe on_pre_build?) would allow me to run additional checks that help me decide whether to build or just use the existing save method of my package.
You can create an EventListener, implement on_window_command and check for the build command. There you can change the executed command with the return values.
Apply scopes for foreground text from a plugin, to allow making more complicated syntax highlighters than the current system allows (thinking of parsing files in the project to find all the types etc)
Importance: Minor
An API method to get whatever syntax path is currently associated with a specific file extension.
e.g. get_syntax_file(file_extension)
At the moment to get this info. something along the lines of this would be needed.
Thanks.