2 posts were split to a new topic: API Suggestion Discussion: open_readonly_package_resource
API Suggestions
Having some control over windows that we create would be useful:
sublime.maximize_window(window_id)
sublime.restore_window(window_id)
I think these wouldn’t likely return anything, but if they absolutely had to, I guess they could return a boolean indicating success or not. This is of minor importance, but it would make the user experience for my Side-by-Side Settings plugin a little nicer.
Add A “MenuText” Property To Snippets
Importance: Minor
Currently, snippets are displayed in the command palette either by their filename or, if provided, by their description
property.
An issue with this is that the user has to choose between a description
that is useful during auto-completion or one that is more suited to the command palette.
For example: I have a set of Sublime Text API snippets. I would like to be able to use description
to provide information about the snippet - but a need that takes priority is the ability to easily filter groups of snippets via the command palette. As such, my descriptions
essentially mirrors the snippet’s contents with the addition of a contextual prefix.
This allows me to easily find a snippet via the command palette by typing Snippet: [Context]
, but it makes the auto-completion display cluttered & redundant:
If I were to use description
for it’s intended purpose, I would lose the ability to contextually filter through snippets via the command palette:
Window Relative Popups
Importance: Trivial
view.show_popup
is currently displayed relative to the view. It would be useful to position popups in relation to the window for non-view related notifications. ( EG: centered in the window )
For example, I have a Messenger
module that displays notifications - one usage case of which is to inform users whether a toggle
command has been enabled or disabled for a particular feature.
I currently position it with view.visible_region().a
, but feel that notifications of this nature are more aesthetically suited to be window-centered ( much like the “Save Changes” dialog ), especially when multi-pane layouts are active.
Interface Suggestions
Interface Suggestions
I dont know how useful that would be for others, but maybe the option to open a file into a buffer instead of a view - but still manipulate it in similar ways i.e apply a syntax, select regions, clasify, etc.
Or maybe it is opened in a view but the view not attached to any window?
Interface Suggestions
##List of file indexed in the project
Importance: Major
Description: Basically give us access to the list of file that is displayed when pressing ctrl+P.
Motivation: Today I can only retrieve the project folder information and have to manually recreate the list of file of the project: this is very slow, and to be propose a responsive interface in my plugin I need to cache this information (with all the issue in maintaining an up-to-date list). This was already requested some month ago here by another user.
APIs to manipulate projects?
##Indexed symbol list in the project
Importance: Major
Description: Give access to the list of indexed symbols in the project which is displayed when pressing ctrl+shift+r. Result would be a tuple, similar to the result of window().lookup_symbol_in_index()
Motivation: Today there is two API (view.symbols() and indexed_symbols) which return more or less the same list of symbol in the current view, but there is noway to have access to all the symbol in the project.
##Scope information for indexed symbol
Importance: Major
Description: Add to the symbol list (from view.indexed_symbols() or the new one i’m requesting for the whole project) the associated syntax scope. The result would just an additional entry in the tupple which is returned today
Motivation: when displaying/iterating a list of symbol in a plugin it is quite often needed to get the information of the type of symbol since you won’t do the same kind of operation on a class or a function. It is possible to do this manually but it requires additional operation that seems unnecessary (since the scope is basically the reason why the symbol was indexed) and that can be too heavy to do, especially if we talk about the whole symbol list of a project.
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/auto_indent_tag.py"
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.get_entry_color(filename)
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.
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.