Sublime Forum

API Suggestions


log_commands - show the path to where the command is defined

I would love it if sublime.log_commands(True) would also show where the commands being executed are defined - i.e. WindowCommand: "Packages/Default/" for auto_indent_tag or "built-in Sublime Text WindowCommand" for commands that are built in to ST3 and not defined in a package.
This would also benefit end-users I believe, not just package developers.

Importance: Minor


Interface Suggestions
on_window_command doesn't pick up show_overlay

A way to tell programmatically when a TextCommand / WindowCommand / ApplicationCommand is visible or enabled.

Maybe something like view.get_command_availability(command_name), returning { 'visible': True, 'enabled': False }, after executing the appropriate command’s is_enabled and is_visible methods. Currently, these methods only seem to be used when the command is part of a menu or the Command Palette, and AFAIK, can’t be accessed by a plugin directly.

Importance: Trivial



Allow to change the color of a file in the sidebar

Importance: major
Description: each file in the side bar could have is font color changed. The Api could be something like:

sublime.sidebar.set_entry_color(filename, color)

Or a more pythonic interface with a dict-like syntax.

Motivation: it will allow to improve source control integration.


Interface Suggestions

##Access to Find in files result

Importance: minor

Description: the equivalent to “Find in files” (with the exact same arguments) that would return the result in a dictionnary instead of displaying the result in a buffer

Motivation: The “Find in files” of ST is extremely fast compare to doing an equivalent search in python, this would boost significantly the performances of some plugin. My personnal use case is trying to display a hierarchy of object and this requires looking in many files with some regexp.



Modifier keys for different actions in the Quick Panel

Importance: minor
Description: Currently, sublime.Window.show_quick_panel takes an argument on_done, which will be called once with the index of the selected item. I suggest that show_quick_panel accepts multiple callback functions for different modifier keys. The current on_done would be the default but would also accept different callbacks that are called when the user is holding down control, option, or command. With these additional callbacks, the user could perform a range of different actions with the same items in the quickpanel. Alfred App does that.


Interface Suggestions

Adding context to sublime mouse commands

Sublime key-binding commands have a context object where you can limit your key binding to, for example, a particular scope. The context object is very flexible and powerful. Unforetunately, we don’t have this context object for defining a sublime-mouse-command.
Having this feature will allow us to make much better plugins to enrich the user experiece with some mouse interactions.
Right now, if you define a sublime-mouse-command, it’ll be global and you’ll probably disable some other mouse interaction which will piss off user and that’s why I removed all mouse interactions from my plugins despite numerous feature requests.



YAML based format for color-schemes

read more about it here



Add focused attribute for sidebar in sublime-theme files

In sublimeText when you focus the sidebar with a shortcut, there’s no visual cue to tell you that the sidebar is focused.
If you introduce a new attribute for sidebar in sublime-themes, then themes can change the UI to indicate that the sidebar is focued.

Side Note: Please add some documentation on these special attribures like ‘expanded’, ‘selected’, ‘dirty’. Sublime theme documentation is missing in general.



Changing line color as additional gutter

Importance: Major

line_color or gutter_color could add a subtle color marker to the line like the example screenshot from Atom. This doesn’t replace @oivva suggestion. It extends it. With this addition there would be two things a plugin can modify in the gutter: a) add an icon (already possible and used by many plugin). @oivva suggestion would make it possible to add multiple icons. b) change the line color. The line color could be used to show git changes and the icon for linting or something else. Compared to multiple gutter icons, this does take away any space.



RenderIconAtPos(pos, icon, fn)

Sometimes you want to provide some contexual information that can not be part of the content of the view, something like the error message from the linter or showing an image or a chart in en external tool. Showing an icon beside the text that could trigger other api calls like showing a tooltip or opening another view would be really beneficial. something like this in intelliJ:



I haven’t worked with the tooltip API at all, but I’d love to see something like Atoms.

I know we have basic CSS, but full css styling along with a set of nice looking default CSS rules for tooltips and labels could go a long way.


Style of Inline Errors

I think you can get very close to something like this. You just need a linter plugin to take the time at put it in. The CSS is limited in the API, but it is sufficient for things like this.



Another API that I would like to see is the ability to force an update for the auto-complete list. Our code base is thousands if not hundreds of thousands of functions. I would like be able to serve up a subset of those functions once the user has entered more than 2 characters. I may have missed something with my limited testing of this functionality, but I think being able to inject a new set of data into an open autocomplete list might be helpful.



Interface Suggestions

Last one for now…The ability to affect a single on_query_completions using flags. I would like to create a plugin that will display autocompletions without the in-file suggestions, but since these flags affect all instances of on_query_completions, this is not easily doable.




Find in Region by selectors

One thing I would really like to see would be the ability to do a view.find_in_region_by_selectors(region, [selector1, selector2]), which would essentially be an upgrade to the existing view.find_by_selector method, to include:

a. a region within which to restrict the results
b. an array of selectors

The result would of course be sorted by position, and could include the entire scope of the region, or just the selector that matched, like this:

[(region, scope/selector), (region, scope/selector)...]


Firstly, I know that having an array for multiple selectors may seem pointless, because a selector can include a comma to perform an “or”. i.e. string, comment.
But the problem with this, is that, if the text matching the selectors are adjacent, the region returned will include all of them, and most of the time, it is much more useful to have them separate.


take a python file containing:

"hello world"#comment
"foobar" # another comment

using the following code:

[view.substr(region) for region in view.find_by_selector('string, comment')]

will return the following:

[’“hello world”#comment\n"foobar"’, ‘# another comment’]

Now, imagine that one wants to know the location of all the comments in the file and all the strings in the file, while preserving the order. With the current API, the “most efficient” workaround is to do this (view.substr is just for demonstration of what gets returned):

[view.substr(region) for region in sorted(view.find_by_selector('string') + view.find_by_selector('comment'))]

[’“hello world”’, ‘#comment\n’, ‘“foobar”’, ‘# another comment’]

which involves sorting a potentially incredibly massive list.

Now this is where the proposed region restriction comes in handy. Most of the time when I am developing plugins, I am only interested in a small subset of the file/view at a time, and I feel that being able to get results only for a particular region will make the plugin code easier to read/understand and write, while at the same time being more efficient. (Even if the same process would have to happen in the C code, it would be a lot quicker than processing it in Python I think.)

Importance: Minor

One possibility would be to alter the find_by_selector method, to include the new functionality, in such a way as not to affect existing plugins that rely on the current behavior:

  • make the region parameter optional (and come after the selector), and default to the entire view if None
  • if the selector parameter is a string, use the current functionality and return type (list of regions)
  • if the selector parameter is an array, return the list of tuples, where each tuple would contain the region and the scope of that region or the selector that matched.

I guess if multiple selectors matched, and the API would return the matching selector(s) as opposed to the scope at the region, then the return value of the matched selectors could be a list, to avoid repeating the region in the return value. i.e.:

[(region1, [selector1, selector2]), (region2, [selector1])...]

instead of:

[(region1, selector1), (region1, selector2), (region2, selector1)...]

find_by_selector and nested scopes

Sets of APIs to Improve one aspect of the performance of ST:

  1. application does not trigger “on load” when the app is opened. This means, that any package that needs that event should trigger it in a synthetic way. So imagine many packages doing this…
  2. application does not have “on application close”, so if you need to save to disk some data related to the views you have opened you need workarounds, like on_deactivated. So we hitting hard drive on every focus lost… because there’s no reliable way to save data about the views; and this workaround is not even reliable. [data that does not fit in ST view settings object, etc], imagine you need to save something to sqlite


All file events, give events for:

Any change on disk about a file/folder is created/changes/reloads/gets deleted, even if not opened. The current ugly hack is to recurse the folder till eternity.


Adding folder name completion and syntax highlighting to an existing plugin?

Dispatch events for when a view is scrolled, so we can for example scroll other unfocused views in relation to the current focused view. The current ugly hack is to loop forever and see if the scroll changed



This gonna be hard to explain and Im sorry, We need “light” versions of on_selection_modified and on_modified .

Because these two apis are too verbose and everyone use it wrong, Then later people complain ST lags, when they triggering heavy tasks on every key press or cursor move. Some people even believe they use it right because they move to threads, and actually this is worse, there’s no need to dispatch 30 gonna-be-useless threads because you hold a key to type or to move the cursor for a few seconds.

The current workaround for this is insane, you loop in a thread with while(True) and sleep, then try to check if the view/selection changed and also if it is worth to wait a bit more

I suggest something in the lines of ;

  1. on_after_selection_modified - event fires when the cursor stops moving for some given milliseconds
  2. on_after_modified - event fires when the user stops modifying the view for some given milliseconds

Interface Suggestions

This is a pretty curated list, and Im sure you will found some worth post, specially all of these related to bugs, ST API works most of the time but has some bugs that are really frustrating and defeats the purpose of having an api in the first place, because you need workarounds that does not couple correctly or does decouple with other functionality and everything becomes a workaround of a workaround to make things work.

This is the most important stuff. Current API should work, flawless, if does not because of some edge case, then explain it