This is not a suggestion by itself but a reply to many posts as I read through them.
You should be able to do this curretnly by creating an output panel and not showing it. Output panels behave just like normal views, except that they have a few settings overrides such as a disabled buffer.
Edit Preferences has a feature that lists all plugin-defined command names in a quick panel.
You can sort of do that already by tracking whether your quick panel is active and defining a key binding with a context that only triggers when this is the case. We do this for FileHistory to emulate Goto Anything's right arrow key feature and allow deletion of entries with the delete key (only if the caret is at the end of input).
What you should do instead is:
on_modified_async. If you intend to not do an action immediately on a modification that absolutely has to occur before the next one is encountered (imagine setting the view to read_only if a certain thing happened), you should always be using async events.
- Use an integer counter that you increase for each invocation of the command and register a timeout call via
sublime.set_timeout_async where you decrease it. When it reaches 0, you do whatever you want to do.
Although this is a rather common use case of modfication events, I currently don't see a nice API that's not too specific for this use case and would seem like an arbitrary specification of something that would be 20 LoC. Maybe setting the timeout in a class variable could work though.
Yes, please! I work with InactivePanes, which absolutely has to modify the color scheme since it changes the colors of all scope selectors. But all the other plugins like SublimeLinter or ColorHighlighter (or GitGutter even, which needs it for the gutter icons) really only want to add specific RGB colors so that they can use them in
add_regions and the conflicts are amazingly annoying.
There is a special
<character> key binding that will trigger for any character to be inserted in the view. The command's
run method is called with a "character" parameter containing the character to be inserted. With sufficient context specifiers, you should be able to do almost anything.
That wouldn't be an API though.
Some plugins only rarely have to show something in the gutter (SublimeLinter) and would rather have ST handle gutter conflicts by itself (maybe by automatically widening the gutter if the line is scrolled into view), while GitGutter would probably like to have its own dedicated column.
You do this by changing a the "folders" item in the window's project data and setting it with
window.set_project_data(), as you show in the sample code. The decision to use relative paths should be the plugin's, as well as the
Your main goal is to completely define a command's key mapping from within a plugin, correct?
I would rather have the context queries exposed (as suggested by @kingkeith here) and then a single addition of
is_active which replaces the behavior of a context object in a keymap. Keys should imo still be defined from keymaps since that makes them easier to override and is more consistent.