In the View API there is:
find_by_class(point, forward, classes, <separators>) that “finds the next location after point that matches the given classes.” where classes can detect word/line start/end and punctuation.
I’d like a similar API with scope selectors instead of classes.
There is find_by_selector(selector) but it returns the list of all the matching regions in the file, while I only need the next one matching.
It would be super nice to expose the dictionary related stuff, so we can spell check many languages at the same time in a single document
Just to extend this a bit further, how about the ability to to also change the line color in the minimap, also like in Atom?
A save command without side-effects
It would be nice to have a save command that does not produce any side effects, but only saves the view/buffer to file.
Currently, the save command is customized for for the use case where the user asks for the file to be saved, typically by pressing cmd+s (or ctrl+s). However, this action has side effects other than just saving the file. Most prominently, the save command will close auto-complete panels.
The problem: While the side-effects make sense when save is requested by the user, they make life harder for plugin developers who would like to save the file without closing auto-complete panels (or invoking other side effects). The auto-save package is one example of a plugin that has had to develop overly-complex solutions to work around the side effects of the save command.
The solution: Add the ability in the API to save the buffer without invoking side effects. It doesn’t matter too much exactly how this is done - whether via a completely new command, or through a keyword argument to the existing save command.
Importance: Minor (but also simple to implement…)
Notes (based on other comments):
Importance: Major
Sublime Text has 5 distinct types of overlays, each with slightly different styles and capabilities. They are:
I propose that all of the styles and capabilities of these overlays be made available to plugin developers, either via the existing API Window class show_quick_panel() method or by the addition of a variety of show_xxx_panel() methods.
This would be a wonderful addition to the API, please consider it.
A Two Column Overlay; like Command Palette
A Free Standing Overlay; like Quick Switch Project
Flags to control the Width of the overlay
show_quick_panel() bug fix needed, not working properly with 80% of themes
AUTO_EXPAND_WIDTH and TRUNCATE_TEXT_AT_WIDTH_LIMIT
Flags to control the Font Size
A flag to set NO initially selected row; like Show Files
selected_index to -1
A flag to prevent ST from stripping trailing whitespace
A method parameter to set the text in the overlay’s input box; like Goto ‘Anything’, and Command Palette
show_input_panel() API method does this with its initial_text parameter"" empty stringinitial_text should be given to the awesome ST fuzzy matching so that only matching rows get displayedinitial_text selected; like Command Palette does when it shows the most recently used textHave I missed anything that others would like?
Many thanks.
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.")