I’m posting this now because I’m close to the RC1 with only a few things left to do…
I developed it because I wanted a solution more efficient than having to open the menu between 5 and 10 times to open 5 pairs of settings files, for example, by linking everything into a single command so I could group settings files based on area - such as key / mouse maps, Sublime settings, Syntax based, Plugin based ( 10 files in mine now, but there will be a lot of different files for all of the mapping available ), syntax files ( an option to open all supported by the plugin would be great and right now that’s 12 languages )… all into a single settings window…
Previously each time you’d run edit_settings you’d end up with a new settings window, and when running open file you’d pollute your work-area… This addon lets you open as many files as you want - categorized or grouped - into a single settings window!
I was also concerned at how many plugins took the extra time required to add a new singular open-file link to their settings files instead of using less time to set a base file, user file and default contents with edit_settings meaning the user would also need to take even more time to open, and pollute their working environment instead of using a settings window, the default and user config files for each offered…
So I wanted to make something which stood out and plugin developers could use to ensure the settings window was not only able to host many files, but be efficient at managing all of those files too ( file linker, possible the close system ) but what was also backwards compatible so developers didn’t need to learn something completely new and odd by simply altering the accepted states of the default variables - I’ve done that… but I’ve also allowed them to use a different method which gives them access to more features until I add it to the non file_list way…
This release is here to gain insight through user / developer feedback…
What’s missing and what is too much? Which extendable variables are missing, and which are unnecessary? What other features do you expect, or would use for something of this nature? Have you encountered any issues? etc…
Some of the extendable vars may be removed as some of the aliases, while they may make sense to have shorter versions, doesn’t make sense to have some of the defaults with prefixes especially as they are targeted while mine are somewhat generic and possibly confusing - so I do plan on making my additions meet the standards of the others especially as newer ones may be added…
I may also rename some of the defaults - ie folder is for the Sublime Text Window Session System / Project System and it’s for either the folder( s ) added, or the folder where the session save file resides - I will need to play around with it to ensure they all have unique paths so I can properly identify what it is for, along with a few others…
This is edit_settings_plus as it currently stands - Note, there are still things left to do but it is incredibly useful as it stands in its current pre-release form and I have yet to notice any unexpected issues as of yet…
To Do: I’ve been working on other things in this project, and on other projects so some things have been delayed…
- Add res:// support - This is the most important item on the list… straightforward to implement but it affects many components such as the OpenFile system, the ExpandedVars system, and more…
- Add like-file linking so it doesn’t need to be an identical file name match if no other is found ( minimum will be file name without extension )
- Add file link micro-caching so a search only ever needs to happen once if a file doesn’t have another link already set
- Add micro-caching when files are opening - although with my system they can be opened together but aren’t necessarily - although adding it for the times it does would still improve efficiency…
- Add more expandable variables based on user input
- Standardize expandable variables to be named more like default vars - ie keep ext OR extension but not both… or remove it in favor of the default file_extension - unless users want a shortened option - but there isn’t really any reason to have so many as the same thing…
- Find any other var extract / expanders to implement like sublime.extract_vars( )
- Remove any function which isn’t being used ( keep it as vanilla as possible ) - although another version will be released with my libraries which will make use of the helpers and be shorter ( and the expandable vars call will be external because it can be used in many other places and many other commands so there’s no reason to add the same code to every command I intend to replace )
- Find another way to grab the package folder name which alled the command - right now I’m using file OR an argument when you call it to define it - but I’d like a more dynamic way which won’t require edit_settings_plus.py to be in every single package which wants to use that feature dynamically…
- Extend the system which removes the user group if there are no more views in the user group or base group ( in this case move all views from the user group to the base group ) so that it runs when a view has been closed so you’re given a larger work area as soon as it is available…
- Add a few more file_list args such as base_default, user_default, user_syntax, base_syntax so default data doesn’t need to be the data at the top of the file for base files ( although they currently don’t open because I haven’t added res:// support but once I do I’ll add an option to allow non-existing base files to open with default data or not ) or to force a view to use a specific syntax without requiring all of the files in the file list to share the same or forcing you to separate the base / user files into different lines just to use a different highlighter… possibly adding the same variable support to the base arguments outside of file_list so they’d act as base_file, user_file and default does if they are lists ( where the data for user_file and default lines up together )…
- Possibly add the edit_settings default feature of closing like-files when their counterparts are closed
- Possibly add an option or arg to detect which windows are open - if a settings window is open already then add the views to it instead of creating more than one window… I’d make it user definable how many settings windows can be open at any given time and how to share if more than 1 is set…
Once these are done than RC1 is ready…
edit_settings_plus is designed to be added to your package, and included via the package reloader or another file which doesn’t really do anything but is auto loaded ( because I’ve found the commands, etc… will not auto load for some reason unless included - or they won’t work despite other files being auto included - but importing the file means the event listener is cloned and executes more than once which is why I have a thread locker variable )
To help with development and the learning process I’ve added 3 default commands which you need to add to your context or main menu, or to your package commands file… they are:
-
{ “command”: “edit_settings_plus_show_all_expandable_vars_simple” },
- This opens up a new scratch file and lists all of the expandable vars without much information - useful when you’re aware of what everything does but want to copy / paste the commands or as a quick reference - they’re auto populated with the data pertaining to the last active view, as no view / window args are used…
-
{ “command”: “edit_settings_plus_show_all_expandable_vars” },
- Similar to the _simple variant except every single argument, or most, have comments fully explaining what they are for…
-
{ “command”: “edit_settings_plus_menu_open_all_sublime_prefs” },
- This opens up to 16 Default and Default (PLATFORM) Sublime Text Configuration Files, Key / Mouse Maps, the Language Highlighter Definition file and the Language / Syntax User Configuration File.
- Note: This command shows the different ways you can open the same files using default edit_settings command arguments ( base_file, user_file, and default ) which can be None, a String, or a List of Strings of files using the Expanded Arguments in ANY of them… OR using the new file_list which takes a List populated with Dict entries containing one to many of base_file, user_file, default and other options [ with more to come ] such as the syntax arg which forces the files in that Dict to use a specific file highlighter [ For instance, using JavaScript for the expandable vars works great, and using JSON has a lot of ugly red-background lines appear because I don’t use JSON format ] )…
Another post with more information…
A lot of developers seem to use edit_settings or open_file to open a single settings file and neglect to open both the default / base and user file which is possible with edit_settings meaning you have to open > navigate to the package menu > navigate to the appropriate entry > and select it - twice to open the 2 files…
I highly recommend opening the default and user file at the same time and calling it settings so users don’t need to re-navigate for the same thing, or just to view what options are available to them when they go to edit the user settings…
I developed something to further extend it, and it is still in the works alongside a few other projects… edit_settings_plus allows you to open unlimited number of files in the same settings style with with or without write protection for default files - and the ability to open a single group only if that’s how you want to open files…
I made it because my plugin has many different files and I didn’t want my users to have to spend a minute simply fumbling with the menu in order to open all of the settings files, and then having to drag them to a single window… or make some hack to open all of them and hardcode it someway… and I wanted a lot more expandable variables than are available to us by default ( edit_settings doesn’t even give us access to the sublime.extract_variables( ) which has a lot of useful data )…
I recommend setting up your layout so - if you don’t have many files to open: open them all in one go ( with my file linking system when a user clicks Preferences in the base group - Preferences in the User group is displayed on the right and vice versa - so they don’t need to fumble in order to see what values are available to them, by default )…
I still need to work on a few things - but it’s about ready for testers ( need to add res:// support and some other things ) but take a look and let me know what you think 
Original post:
Here’s my edit settings plus command to open all 12 files… Preferences Base / User, Preferences (PLATFORM) Base / User, Key Bindings Base / User, Key Bindings (PLATFORM) Base / User, Mouse Bindings Base / User, Mouse Bindings (PLATFORM) Base / User…
The command I use is ( Oh, you can open up 2 files max at a time with edit_settings using base_file for the left side, and user_file for the right / user side… default, the var for the default contents is used for the user file if contents don’t exist ):
##
## Command - Open ALL Sublime Base / User Preferences - Keymaps included...
##
class acms_menu_settings_open_all_sublime_prefs( sublime_plugin.WindowCommand ):
## Defaults
__default_prefs__ = '//\n// Sublime Text - Configuration - User\n//\n{\n\t$0\n}\n'
__default_prefs_platform__ = '//\n// Sublime Text - ${platform} Configuration - User\n//\n{\n\t$0\n}\n'
__default_keymap__ = '//\n// Sublime Text - Base KeyMap Configuration - User\n//\n{\n\t$0\n}\n'
__default_keymap_platform__ = '//\n// Sublime Text - ${platform} KeyMap Configuration - User\n//\n{\n\t$0\n}\n'
__default_mousemap__ = '//\n// Sublime Text - Base MouseMap Configuration - User\n//\n{\n\t$0\n}\n'
__default_mousemap_platform__ = '//\n// Sublime Text - ${platform} MouseMap Configuration - User\n//\n{\n\t$0\n}\n'
__default_syntax_settings__ = '//\n// Acecool - Code Mapping System - ${syntax} Syntax Configuration - User\n//\n{\n\t$0\n}\n'
## Syntax File Links
__syntax_python__ = 'Packages/Python/Python.sublime-syntax'
__syntax_javascript__ = 'Packages/JavaScript/JavaScript.sublime-syntax'
## The Menu Entry Caption
def description( self ):
return 'Sublime Text Preferences - ALL 14 + Syntax Def & Config'
## Whether or not the menu item is enabled
def is_enabled( self ): return self.window.active_view( ) is not None
## Run the command
def run( self ):
## Run the command
self.window.run_command(
## Command is edit_settings_plus with the following args
'edit_settings_plus',
{
## Developer set to True means the base / left group is not read only - removing the arg defaults to False so you can't edit the base / left group files... only use them for reference...
'developer': True,
## Debugging set to True enables all print statements to show what's happening in the world of edit_settings_plus
##'debugging': True,
##
## Note: If you use arg file_list: { ... } where each entry as ... is a { } containing base_file, user_file, and default ( all OPTIONAL ) you can add syntax arg to force a particular syntax highlighter on a file... more options later...
## You can use the arguments base_file and user_file as a single file, None, or a List of files
## ( and they do not need to match the lengths of the others - although for default it should match, even if you use None if a later file needs default data you will need None to occupy the space of each one which doesn't up to the last one you want to have default data... )
##
## Note: I've left both uncommented to show what they look like when aligned nicely vertical vs horizontal... I used helper vars to save space..
##
##
## Files included are * 2: Preferences, Preferences (PLATFORM), KeyMap, KeyMap (PLATFORM), MouseMap, MouseMap (PLATFORM), Syntax Definition File and Syntax User Settings - so 14 files...
##
'base_file': [ '${default}/Preferences.sublime-settings', '${default}/Preferences (${platform}).sublime-settings', '${default}/Default.sublime-keymap', '${default}/Default (${platform}).sublime-keymap', '${default}/Default.sublime-keymap', '${default}/Default (${platform}).sublime-mousemap', '${syntax_path}' ],
'user_file': [ '${user}/Preferences.sublime-settings', '${user}/Preferences (${platform}).sublime-settings', '${user}/Default.sublime-keymap', '${user}/Default (${platform}).sublime-keymap', '${user}/Default.sublime-mousemap', '${user}/Default (${platform}).sublime-mousemap', '${user}/${syntax}.sublime-settings' ],
'default': [ self.__default_prefs, self.__default_prefs_platform, self.__default_keymap, self.__default_keymap_platform, self.__default_mousemap, self.__default_mousemap_platform, self.__default_syntax_settings ]
##
## Note: The following isn't required - it serves as an example to show what this would look like if file_list was used instead of the 3 default args for edit_settings above...
##
'file_list':
[
## Base / Left Group File User / Right Group File Default contents for the User / Right Group File if it doesn't exist!
{ 'base_file': '${default}/Preferences.sublime-settings', 'user_file': '${user}/Preferences.sublime-settings', 'default': self.__default_prefs__ },
{ 'base_file': '${default}/Preferences (${platform}).sublime-settings', 'user_file': '${user}/Preferences (${platform}).sublime-settings', 'default': self.__default_prefs_platform__ },
{ 'base_file': '${default}/Default.sublime-keymap', 'user_file': '${user}/Default.sublime-keymap', 'default': self.__default_keymap__ },
{ 'base_file': '${default}/Default (${platform}).sublime-keymap', 'user_file': '${user}/Default (${platform}).sublime-keymap', 'default': self.__default_keymap_platform__ },
{ 'base_file': '${default}/Default.sublime-keymap', 'user_file': '${user}/Default.sublime-mousemap', 'default': self.__default_mousemap__ },
{ 'base_file': '${default}/Default (${platform}).sublime-mousemap', 'user_file': '${user}/Default (${platform}).sublime-mousemap', 'default': self.__default_mousemap_platform__ },
## Note: Because I added syntax here, both of these syntax files will be highlighted using the JavaScript definitions... If I wanted each to be highlighted differently I would need to put base_file and syntax on one line, and the next user_file, default, and syntax args in their own Dicts.
## I am planning on adding user_syntax and base_syntax args so they can be on a single line... I may even add the args to work outside of the file_list system...
{ 'base_file': '${syntax_path}', 'user_file': '${user}/${syntax}.sublime-settings', 'default': self.__default_syntax_settings__ 'syntax': self.__syntax_javascript__ },
]
}
)
// One call to open all relevant files… This is so useful that I’m surprised it isn’t included by default in Sublime Text… Seriously - being limited to a single user and base file is very limiting especially if your plugin has custom settings files and you want the default settings files to open up ( if you allow the default preferences file to override them, and in most cases it does this automatically? )
// One Extended Args System to create a TON of useful arguments / expandable variables to shorten the length of each file name ( I plan on adding more - at the least I’ll probably add single arg for full path to all of the default files, and all of the default files in the user dir )…
This is the current list:
//
// Acecool - Code Mapping System - Extracted Vars Example
//
// Note: Because of our use of several sources - some values may be identical and some vars may be shortened - treat these as aliases...
//
{
//
// Acecool Library / Extract Vars
// sublime.active_window( ).extract_variables( )
//
${version_sublime} 3143
${platform} Windows
${architecture} x64
${arch} x64
// Important Paths
${cache} C:\Users\Acecool\AppData\Local\Sublime Text 3\Cache
${packages_installed} C:\Users\Acecool\AppData\Roaming\Sublime Text 3\Installed Packages
${packages} C:\Users\Acecool\AppData\Roaming\Sublime Text 3\Packages
${user} C:\Users\Acecool\AppData\Roaming\Sublime Text 3\Packages\User
${default} C:\Users\Acecool\AppData\Roaming\Sublime Text 3\Packages\Default
${package} C:\Users\Acecool\AppData\Roaming\Sublime Text 3\Packages\AcecoolCodeMappingSystem
${user_package} C:\Users\Acecool\AppData\Roaming\Sublime Text 3\Packages\User\AcecoolCodeMappingSystem
// Active File when edit_settings_plus was called Data:
${file_path} C:\AcecoolGit\acecooldev_sublimetext3\AppData\Sublime Text 3\Packages\AcecoolCodeMappingSystem
${file} C:\AcecoolGit\acecooldev_sublimetext3\AppData\Sublime Text 3\Packages\AcecoolCodeMappingSystem\AcecoolCodeMappingSystemPlugin.py
${file_name} AcecoolCodeMappingSystemPlugin.py
${file_base_name} AcecoolCodeMappingSystemPlugin
${file_extension} py
${extension} py
${ext} py
// Active File Syntax Information
${syntax} Python
${language} Python
${lang} Python
${user_syntax} C:\Users\Acecool\AppData\Roaming\Sublime Text 3\Packages\User\Python.sublime-settings
${syntax_ext} sublime-syntax
${syntax_file} Python.sublime-syntax
${syntax_path} Python/Python.sublime-syntax
// Menu > Project / Sublime Text Window Session Data
${folder} C:\AcecoolGit\acecooldev_sublimetext3\AppData\Sublime Text 3\Packages\AcecoolCodeMappingSystem
${project} C:\AcecoolGit\AcecoolCodeMappingSystem.sublime-project
${project_path} C:\AcecoolGit
${project_name} AcecoolCodeMappingSystem.sublime-project
${project_base_name} AcecoolCodeMappingSystem
${project_extension} sublime-project
// Misc
${repo} https://bitbucket.org/Acecool/acecooldev_sublimetext3
}
This isn’t me posting about something I have and no one else - I am planning on releasing edit_settings_plus because of the lack of functionality edit_settings has - and I plan on extending a lot of the other default commands too with my extended expandable vars…
The things I have left on edit_settings_plus before final release is: Finish res:// vs path to… detection for files… Finish making sure it is 100% stand-alone… and adding micro-caching to the file linker ( when you click on a file in one group, the same name file in the other group gets focused too ) so it doesn’t need to loop through the other group each time you click - maximum of once… and standardize the expandable vars to make it look more vanilla and possibly add some more - waiting on thread responses…
This is edit_settings_plus as it currently stands - Note, there are still things left to do but it is incredibly useful…
If you want to try it out and give me your opinions, that’d be great…
Default commands are ( You will need to add them to a context menu, main menu, or package commands file for them to show up and be usable )…:
##
## Developer Command - Opens an empty file containing a list of all of the expandable vars, and their values from the window where it was called from
##
## Add to Main / Context sublime-menu using - It'll be named '[ edit_settings_plus ] Show all Expandable Vars - Simple'
## and will open an empty non-existent document showing each variable, and it's return value...
##
## { "command": "edit_settings_plus_show_all_expandable_vars_simple" },
##
##
## Developer Command - Opens an empty file containing a list of all of the expandable vars, and their values from the window where it was called from
##
## Add to Main / Context sublime-menu using - It'll be named '[ edit_settings_plus ] Show all Expandable Vars'
## and will open an empty non-existent document showing each variable and it's return value, in a heavily commented / described form...
##
## { "command": "edit_settings_plus_show_all_expandable_vars" },
##
##
## Command - Open ALL Sublime Base / User Preferences - Keymaps included...
##
## Add to Main / Context sublime-menu using - It'll be named 'Sublime Text Prefferences - ALL 14 + Syntax Def & Config':
##
## { "command": "edit_settings_plus_menu_open_all_sublime_prefs" },
##
Note: The 16 file opener may not open ALL default files ( if they do not exist in the file system they won’t be opened )… I still need to add support to check res:// locations before giving up… But it is nearing its release so I may as well allow testers
The included 3 commands give an idea of whats possible… and give a nice / easy list of variables which can be used ( to grow soon )…
I also have some housecleaning to do, and other tasks as mentioned… but hopefully this helps…
Oh - for the package detector to work - the file needs to be in the package you want to detect - otherwise you’ll need to manually add a package var… I’ve added commented out version as an example… for repo to display anything other than my repo, you’ll need to use the arg too…