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.
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.
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.
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.
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.
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)
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.
##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
:filepath
that the user selected. If the user pressed cancel, then filepath
is None
.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 captionfolder
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})
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>)
##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.
Yeah, I got confused . Anyway, it’s platform dependent is my point. So Sublime should make this issue platform-independent by providing a --packages-path
argument.
In some cases it’s really necessary to restart Sublime Text to get plugin to work correctly.
It would be great to have the chance to ask the user to restart ST and run this command if he/she doesn’t mind.
.
Originally posted on:
I opened a feature request to allow this on the Core issue tracker:
- Core$1794 API to set/change/move views between different windows
After that API addition, you can create the following package/plugin to create the command
gather_all_windows_here
import sublime
import sublime_plugin
class GatherAllWindowsHereCommand( sublime_plugin.TextCommand ):
def run( self, edit ):
windows = sublime.windows()
current_window = sublime.active_window()
windows.remove( current_window )
for window in windows:
for view in window.views()
current_window.attach_view( view.id() )
on_pre_build
/ on_post_build
This would, for instance, allow running eligibility test before a build starts. One of the most frequent support requests for my packages is about compilers not being in the user’s PATH
. An example for on_post_build
would be asking the user whether he wants to open a successfully transpiled document in the editor.
I just read this whole thread and couldn’t find this suggestion, but it’s a large thread so forgive me if I missed it.
This would simply add the API to be able to find the previous occurrence of a pattern.
I would suggest adding it as a flag to the already existing API. Something like sublime.REVERSE
or similar.
This feature has been requested before:
Way to update the Quick Panel items
I want to perform some work in background and update quick panel list items along the way
Right now I can only take user input, make full list and show it
Minihtml is being used to create the interface for debuggers, see: https://github.com/daveleroy/sublime_db
is it possible to get some relative CSS units? So these interfaces can resize when sublime’s window resizes
This would be useful. I already have to replace some of mine with ${x} just so it can be replaced properly later.