I share Sublime prefs between two machines (home, work) using Git.
My monitor at work has a higher DPI than my monitor at home, so in one of the two machines I'd like to override font_size.
I was hoping for:
The possibility to override using a command-line flag (to do something like subl --override-pref font_size=15), like kitty --override does.
Another level of prefs cascading below User.
, but I don't think any of this exists in Sublime. Language-specific config is not what I'm looking for, I want something global, but only in one of the two machines.
Ideas? Workarounds? Thanks.
The general mechanism at play for settings files is that when Sublime loads a sublime-settings file by name, it pulls all of the similarly named files across all of the known packages and combines them together (the same also happens for many other resource files) with content from later files overriding anything that appears in an earlier file.
The order that's imposed here is lexically by package, with Default always being first and User always being last. That's why the default settings are in the Default package and your custom settings are in the User package. Additionally syntax specific settings also apply (as do settings specific to projects).
Apart from this mechanism there's no direct way to override settings without some sort of manual intervention on your part. Potential solutions for this sort of problem include the following examples:
Don't sync the Preferences.sublime-settings file
If the file isn't synced across multiple machines, then this problem becomes moot because each machine can easily have it's own unique settings. The downside to that is that each machine then has it's own unique settings, which is a pain in the butt if you often move from machine to machine and things don't quite work the same way.
Use separate git branches
An alternative here if you're using git such as you are is to try and keep separate branches per host or per host type (like hi_dpi and reg_dpi or some such). Then on each machine check out the appropriate branch.
The obvious downsides here are having to try and cross-sync desired settings changes (for both User as well as any packages you might install) between branches, which is less than ideal unless you really love git.
Use extra Preferences.sublime-settings files
Here the idea is that you don't include the font_size setting in your User/Preferences.sublime-settings file at all. Instead, you use Browse Packages from the command palette to open the Packages folder, then create a new folder there with some arbitrary name. Inside of that folder include a Preferences.sublime-settings file that contains only the font_size setting.
Doing this on multiple machines, you can sync the settings in your User folder across machines without also syncing the preference that contains the font_size. As a note, if you create the file while Sublime is already running, you may need to quit and restart to get it to notice that the settings file exists; this only applies the one time, though.
Use a plugin
Looking at the link provided above, the ultimate trump card for any setting is a setting that's been applied directly to a view. Given that, you can use a plugin that selectively always applies a specific font size to any newly created or opened file:
import sublime
import sublime_plugin
import socket
class CustomFontListener(sublime_plugin.EventListener):
hostname = socket.gethostname()
def on_new(self, view):
if self.hostname in ("host1", "host1.example.com", "host2"):
view.settings().set("font_size", 20)
on_load = on_new
Now any time you open a file or create a new buffer, if the current hostname is in the list you've configured the view will immediately get an appropriate font_size applied; otherwise the one from the preferences would be used instead.
You could also extend this to be configurable via it's own settings file, apply a different font size depending on the host name, etc.
Settings in views are persisted in the sublime-session file and also in the workspace files associated with sublime-project files, so these settings will remain in place even across restarts.
Something to keep in mind is that the internal commands for changing the font size (via Preferences > Font or via the mouse wheel keyboard shortcuts) work by writing a new font_size to your user preferences.
If you're using separate preference files, then doing this will add font_size to your User settings and you will need to manually remove it and modify the other settings file.
If you're using the plugin, then these shortcuts won't seem to do anything because it applies a font_size that overrides the User preference, but in fact as outlined above your preferences file end up being changed and you may not notice right away.
So whichever way you go, if you tend to use those you may need to make manual adjustments to settings files in the aftermath. It's also possible to create smarter versions of those commands as well, if this is the sort of thing that happens often.
Related
How do you make a specific folder that has subfolders to be uneditable in Sublime text? ? I know it's possible but how ? Like i have some old projects that I want to use as a reference to study my old code, but i"m worried that I mistakenly edited some parts of that specific module / file, when I'm mindlessly touring around my code.. How do I do it ? like making a specific folder to be uneditable in sublime text that only modifying it can change it . I mean I tried installing this one package : https://packagecontrol.io/packages/Toggle%20Read-Only
But it still gives me a prompt whenever I want to changed something from a file
Your best bet is to make sure that your source code is covered by some sort of Source Control, such as git or Subversion; this is just always a good idea in general and unrelated to your particular question. Having your code under source control means that when you edit a file (accidentally or on purpose) you can see exactly what you edited or throw those edits away and go back to what you had if you want to. If you also push your code to an external server, such as GitHUb (if you use git) then you also have a cheap and easy off-site backup of your code as well.
That said, if you want to make files uneditable, that's more the job of your file system than the tools that you're using to edit the files (in this case Sublime Text).
All file systems and operating systems should have the concept of a read-only file, which sounds like what you want. A file being marked as read-only stops you from accidentally modifying it; depending on the software that you use, edits are either impossible or will need to be confirmed.
In your case, you can do this in a couple of different ways. If you only want to protect a couple of files, then you would do a Right click and choose Properties; in the bottom of the General tab there is a check box you can check to make that file read-only:
If you have many files, you can do the same thing by editing the properties of the folder that contains the code instead:
When you do this to a folder, the property set works a little differently; since you're modifying the folder as a whole, you need to click the box twice to change it from a square (shown above) to a check mark. When you apply the change, you will be asked if you only want to make files inside of that directory read-only, or all files in that folder as well as all folders under it; choose as appropriate.
Sublime will let you open read-only files and will also let you modify their contents, but when you try to save you will get a warning dialog telling you that the file is write-protected; you need to confirm if you want to actually save changes or not; (other software may not prompt with such a dialog and may just fail):
If you choose to save, you will remove the read-only attribute and make the file normal again.
If you want to make a file completely un-editable so that you can't even accidentally change the file, you can achieve that with a simple plugin in combination with making the file read-only (see this video if you're not sure how to apply a plugin):
import sublime
import sublime_plugin
import os
class ReadOnlyListener(sublime_plugin.EventListener):
def on_load(self, view):
if (os.path.exists(view.file_name())
and not os.access(view.file_name(), os.W_OK)):
view.set_read_only(True)
EDIT: The internal View Package Files command will open package resources from sublime-package files transparently and give them a filename that represents where they would exist on disk if they were not in the package file.
The plugin from the original answer would stop you from being able to use this command by noting that the file is not writable (because it does not exist on disk) and make the view read-only, which stops the file content from being displayed because the view can't be modified.
This is rectified in the edit above by only taking action if the file actually exists on disk (the View Package File command already makes files it loads in this manner read-only if they do not exist on disk).
This makes an event listener that checks every time you open a file to see if the file is writable, and if it's not it makes the view read-only. This distinction is Sublime specific; regardless of the underlying state of the file, you just can't make any changes to such a file at all. That doesn't stop you from saving the file even if you haven't made any changes, which would have the same effect as the above.
I save several projects in a same folder by manual click Project -> Save Project As...
and I used to use cmd + ctrl + p to open Switch Projectlist to switch between projects
and everything's works fine.
but today, I accidentally remove my Switch Project list in by click Project -> Open Recent -> Clear Items, so my Switch Project list is empty now...
I know I could add them back through reopen ALL my projects. due to the number of projects is pretty a lot, that will be kind of annoying to add them back one by one.
I wanna know if there's a smarter way to do that for me.
maybe import all my *.sublime-project files from folder or something.
thanks
Short of manually opening every project, I don't think there is any way to do something like this directly. There isn't a command or plugin endpoint that I'm aware of that lets you open a project by name or filename, so it's not possible to create a plugin to do the work, and Sublime doesn't have the ability to pre-load the list of packages directly either.
That said, it is possible to manually update the list of recent projects, but whether or not that is more or less work than opening all of the projects is something to consider.
If you use Preferences > Browse Packages from the menu or the command palette, a file browser will open on your Packages folder. From there go up one directory level and go inside of the Local folder, where you will find a Session.sublime_session file.
Sublime saves it's state into this file when you quit it, and uses it to restore state when you start it again. Here you will find all of the saved information, such as the windows and files that were open and so on.
Changing this file will change the data that Sublime loads, so you can modify the session file to set up the data that you want. You need to make sure that you modify the file while Sublime is not running or your changes will be ignored and clobbered away. Also it's a good idea to make a backup of the file before you start in case things go pear shaped.
Down near the bottom of the file you will find a top level key named workspaces, and inside of it a recent_workspaces key:
"workspaces":
{
"recent_workspaces":
[
"/home/tmartin/local/src/OverrideAudit/OverrideAudit.sublime-workspace",
]
}
This is where the list of recent projects is stored for use in the menu and the quick switch project command. Particular things to notice are that the entries are naming sublime-workspace files, and that the paths are absolute.
NOTE: On windows, the filenames stored in the session file are in a format like /C/Users/tmartin and not c:\users\tmartin; on that platform you need to make sure that you adjust the paths accordingly. As long as there is already at least one entry in the list when you look at the session file, you can easily see how to construct the paths that you need.
Despite the name of the commands and menu items, what you're actually switching between is different workspaces. Every sublime-project is associated with a sublime-workspace file, which acts as a dedicated sublime_session file for that particular project. This mapping is one-to-many in that you can have multiple workspaces for the same project file, allowing you to reference the same paths in multiple windows but have different window layouts.
While Sublime is not running you can edit this file to add in the full paths to all of your workspace files; when you start Sublime up the list will be populated (every sublime-workspace file knows what sublime-project it is associated with).
What remains is whether or not it's quick to come up with the list of files in a way that you can easily paste them into the session file.
I installed ColorPicker and it overwrote my key-binding (ctrl+shift+c). I'd like to change the ColorPicker binding to something else, however I'm unable to locate the definition.
If looked in Preferences > Package Settings > ColorPicker, but it only has Settings-Default and Settings-User neither of which contain the key-binding. I've also checked the Default & User key-bindings, to no avail.
How can I change the key-binding for ColorPicker?
Edit: Adding image of files for #OdatNurd
The definition for key bindings in a Sublime package come from the file Default (Platform).sublime-keymap, where Platform is one of Windows, Linux or OSX. Not all packages provide a menu entry for editing key bindings, though.
You can use PackageResourceViewer to open the file and see what the key binding is set to. You can modify the key directly in that file or copy it to your custom key bindings in your User package.
The latter is generally the better way to go because overriding a package file can cause problems when the package updates in the future; if it modifies a file that you have overridden, your override masks the package file which can potentially cause problems.
Sublime takes care to ensure that the User package is loaded last, so this is good place to put settings that you want to make sure don't get hoisted out from under you by packages.
My team lead just added a lot of binary files that shouldn't be in source control. I have to pick and choose my battles with him and this isn't one I think is worth bringing up, but I'd like to just ignore these files on my machine without affecting everyone elses. Is this possible?
We're using TortoiseSvn. I've honestly never used the command line so until I learn how to do that I would prefer a solution using the GUI. Thanks!
If all your files resides in a special directory, you could simply use the Add to ignore list from the shell-context menu.
From the settings/general tab you can also add global ignore patterns, based on extension.
I am trying to write a bash script to do a task, I have done pretty well so far, and have it working to an extent, but I want to set it up so it's distributable to other people, and will be opening it up as open source, so I want to start doing things the "conventional" way. Unfortunately I'm not all that sure what the conventional way is.
Ideally I want a link to an in depth online resource that discusses this and surrounding topics in depth, but I'm having difficulty finding keywords that will locate this on google.
At the start of my script I set a bunch of global variables that store the names of the dirs that it will be accessing, this means that I can modify the dir's quickly, but this is programming shortcuts, not user shortcuts, I can't tell the users that they have to fiddle with this stuff. Also, I need for individual users' settings not to get wiped out on every upgrade.
Questions:
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate? tweek the reference in the source of the dev version?
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be? the user will need to access some of this data, but it's mostly for internal use. I personally work in cygwin, and I like to keep this data on separate drive, so the path is wierd, I suspect many users could find this. for a default however I'm thinking ~/gpsdata/ -- would this be normal, or should I hard code a system that ask the user at first run where to put it, and stores this in the settings folder? whatever happens I'm going ot have to store the directory reference in a file in the settings folder.
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?? though there will always be an option to add a file or folder to the command line to use that as well (it processed files all locations listed, including the "inbox")
Where should the script its self go? it's already smart enough that it can create all of it's ancillary/settings files (once I figure out the "correct" directory) if run with "./foo --setup" I could shove it in /usr/bin/ or /bin or ~/.foo/bin (and add that to the path) what's normal?
I need to store login details for a web service that it will connect to (using curl -u if it matters) plan on including a setting whereby it asks for a username and password every execution, but it currently stores it plane text in a file in ~/.foo/ -- I know, this is not good. The webservice (osm.org) does support oauth, but I have no idea how to get curl to use it -- getting curl to speak to the service in the first place was a hack. Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Sorry for the list of questions, I believe they are closely related enough for a single post. This is all stuff that stabbing at, but would like clarification/confirmation over.
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate?
Have a default of ~/.foo, and an option (for example --config-directory) that you can use to override the default while developing.
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be?
If your script is running under a normal user account, this will have to be somewhere in the user's home directory; elsewhere, you'll have no write permissions. Perhaps ~/.foo/tracklog or something? Again, add a command line option, and also an option in the configuration file, to override this.
I'm not a fan of your ~/gpsdata default; I don't want my home directory cluttered with all sorts of directories that programs created without my consent. You see this happen on Windows a lot, and it's really annoying. (Saved games in My Documents? Get out of here!)
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?
As stated above, I'd prefer ~/.foo/inbox. Also with command-line option and configuration file option to change this.
But do you really need an inbox? If the user needs to run the script manually over some files, it might be better just to accept those file names on the command line. They could just be processed wherever, without having to move them to a "magic" location.
Where should the script its self go?
This is usually up to the packaging system of the particular OS you're running on. When installing from source, /usr/local/bin is a sensible default that won't interfere with package managers.
Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Yes, there is. But it's better not to, because it creates a false sense of security. Without a master password or something, secure storage is not possible! Pidgin, for example, explicitly stores passwords in plain text, so that users won't make any false assumptions about their passwords being stored "securely". So it's best just to store them in plain text, complain if the file is world-readable, and add a clear note to the manual to warn the user what's going on.
Bottom line: don't try to reinvent the wheel. There have been thousands of scripts and programs that faced the same issues; most of them ended up adopting the same conventions, and for good reasons. Look at what they do, and mimic them instead of reinventing the wheel.
You can start with the Filesystem Hierarchy Standard. I'm not sure how well followed it is, but it does provide some guidance. In general, I try to use the following:
$HOME/.foo/ is used for user-specific settings - it is hidden
$PREFIX/etc/foo/ is for system-wide configuration
$PREFIX/foo/bin/ is for system-wide binaries
sym-links from $PREFIX/foo/bin are added to $PREFIX/bin/ for ease of use
$PREFIX/foo/var/ is where variable data would live - this is where your input spools and log files would live
$PREFIX should default to /opt/foo even though almost everyone seems to plop stuff in /usr/local by default (thanks GNU!). If someone wants to install the package in their home directory, then substitute $HOME for $PREFIX. At least that is my take on how this should all work.