Sublime Forum

API Suggestions

#142

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
2 Likes
#143

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”.

0 Likes
#144

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.

1 Like
#145

How about making view.set_syntax_file extension agnostic? IMHO, it should prefer sublime-syntax over tmLanguage when no extension is specified.

6 Likes
#146

##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.

4 Likes
#147

Make sublime.expand_variables optionally throw on unknown variable

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.

8 Likes
#148

In addition to @rwols’s suggestion:

Make sublime.expand_variables leave the $ and the variable name if unknown.

For example:

>>> sublime.expand_variables('$hello', {}, soft=True)
$hello
4 Likes
#149

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.

3 Likes
#150

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.")
0 Likes
#151

Add possibility to get 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.

0 Likes
#152

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.

Background

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.

0 Likes
#153

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.

0 Likes
#154

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)

0 Likes
#155

You could also use a custom build target.

0 Likes
#156

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.

4 Likes
Get syntax associated with file extension
#157

##Make “Open File Prompt” part of the API
Importance: minor

Motivation: Some plugins want to process a file, maybe present it after the processing it in some way. There is currently no canonical way to ask for a file from the user on the API side. There is

sublime.run_command('prompt_open_file')

and this opens an “open file” dialog window; but there is no way to retrieve the selected file. See also this thread.

Proposed solution #1 (old):

New function in module sublime:

sublime.prompt_open_file(on_done, <folder>)

where:

  • on_done is a function (filepath, window) -> None that takes two argument and returns None:
    1. the filepath that the user selected. If the user pressed cancel, then filepath is None.
    1. the window where the open file dialog was started.
  • folder is an optional argument which, if given, starts the open file dialog in the given folder. If it is not given, then the starting folder is whatever the starting folder is when you run sublime.run_command('prompt_open_file')

Proposed solution #2 (better):

New function in module sublime:

sublime.file_selector_dialog(caption, <folder>)

where:

  • caption is a string for the caption
  • folder is an optional argument which, if given, starts the open file dialog in the given folder. If it is not given, then the starting folder is whatever the starting folder is when you run sublime.run_command('prompt_open_file')

The function blocks until the user has selected to open a file or cancelled the operation. If the user selected a file, the filepath is returned. If the user canceled the operation, None is returned.

Example usage:

class MyFileProcessorCommand(sublime_plugin.ApplicationCommand):
    def run(self):
        filepath = sublime.file_selector_dialog('gimme a file!')
        if not filepath:
            # User pressed "cancel"
            return
        view = sublime.active_window().new_file()
        contents = None
        with open(filepath) as f:
            contents = f.read()
        # process "contents" ...
        view.run_command('insert', {'characters': contents})
2 Likes
#158

@rwols

The thread I started, linked by rwols, wasn’t really about the lack of a file selector dialog in the API. However with that said it would be a helpful addition to the API.

I don’t think it should be called prompt_open_file(), it would be better to make it more generic, e.g. file_selector_dialog(). There is no need for an on_done callback, better would be for it to block until a file is selected or it is cancelled, then it could return the full path or an empty string on cancellation. The window the method is called from is not needed, active_window() can provide that. Finally since it is a generic file selector dialog the caption must be settable.

file_selector_dialog(caption, <optional_start_folder>)

0 Likes
#159

##Add --{installed-}packages-path command line option to subl

Importance: Medium

Motivation: Lots of plugin installation instructions (the “non Package Control way”) tell the user to “go to their packages folder”, sometimes supplying the full paths for Linux, macOS, Windows. This is pointless as this can just as well be provided by Sublime itself in the form a simple command line option. If Sublime provides it as a command-line option, every plugin author can just write something along the lines of:

If you want to install my package manually, run

$ cd `subl --packages-path`

and then

$ git clone https://github.com/author/package

Proposed solution #1:

Calling

$ subl --packages-path

will print the full path to Sublime’s packages folder. Calling

$ subl --installed-packages-path

will print the full path to Sublime’s installed packages folder.

2 Likes
#160

Way faster IMO

alias st="cd '$APPDATA/Sublime Text 3/Packages'"
0 Likes
#161

Doesn’t that only work on osx?

0 Likes