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.
Related
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.
There are some files like .bashrc or linux config files (cannot remind them right now), which contain lines of information inserted by different software/apps/libraries, e.g. when they were installed.
Is there any way to differentiate information in such files, i.e. to know which lines belong to which software? Maybe there is some convention for that? If yes, where can I learn about it. If no, how do software clean up their configuration and other property in OS files on uninstall?
A note about tags:
I mentioned low-level languages as well as linux and shell because I think only guys from those techs may know the answer.
"Is there any way to differentiate information in such files, i.e. to know which lines belong to which software" - No.
You are dealing with plain text files and there is no way to tell who put what into those files. It may have been a program you installed/ran or it may have simply been a user editing the file in a text editor - you don't know.
You also have no way of knowing whether the contents of the file is well formed or not until you parse it.
If the file does not parse (is messed up) you have two options: 1) read what you can and discard everything else. 2) give up and tell the user the file is garbage
In any case, you cannot trust the information in the file. Anyone could have put it there.
I saw that there is a lua plugin for eclipse and there is a docpage on the awesome main page api_doc and all the .lua files in /usr/share/awesome/lib.
So I thought it must be possible to create a Library or Execution Environment so that one has tabcompletion and docview.
So I tried making my own Execution Environment:
wrote the standard .rockspec file
downloaded the documentation made an ofline version of it and put it in docs/ folder
ziped the files and folders in /usr/share/awesome/lib
ziped all up
tried it out ... and it failed.
When I try to view a documentaion for a .lua file I get "Note: This element has no attached documentation."
Questions: Am I totaly wrong in my doing (because I have the feeling I am)? Is there any way to edit the rc.lua with tabcompletion and docview?
Koneki will probably take a while to setup, but it's definitly worth it. Going for the".doclua"(by using version 1.2) would certainly make it, but I doubt that using a script to generate the information you need, would work out on the long run.
Most likely, you'll probably pass a bit of time to define what kind of object you're dealing with every time you come across one. The right to do, would be to actually take the time to see if the object/module/inner type inherit from an another object, so can actually have more completion feature as you keep using autocomplete to go from one object to another by pressing "dot"+ctrl_space.
In an ideal world, one person could probably make it right and share to other, so they can enjoy a full featured autocomplete editor.
Found solution for eclipse.
First off the idea of setting up an Execution environment was the wrong one.
So the whole thing about downloading the doc although.
For more information on that visit eclipse Wiki for LUA Development Tool.
The right thing to do is to add a source folder which contains the /usr/share/awesome/lib directory.
The bad news is that my comment from above was totally right, which means one has to configure each .lib file in /usr/share/awesome/lib to meet the requirements of the Documentation Language described here.
Than editing the rc.lua (which one can add to the project in eclipse) works with tabcompletion and doc view.
Since the Documentation Language used in the lib files is similar to the one used by "LUA Development Tool" one has not to change many things. Maybe there are even scripts for that.
First off, I was about to write a long list of if/else statements in vim and realized that 1) there was a better way to do what I was trying to do and 2) SO would be ripe with help on the subject. So! I have a variety of files spread about like
foo/src/file01.C
foo/src/file02.cc
foo/src/file03.c
foo/include/file01.hh
foo/include/file02.h
foo/include/file03.h
If you notice that the C/H, cc/hh, c/h extension may or may not match then you are keen and I'd like you to please help. I've look at things like the following vim scripts from the Vim wiki for "Easily switch between source and header file" and although I only dumped a few hours into a.vim without success, it doesn't seem that the others would work via the docs on that page. So can anyone help out on how to make this work?
A good lead I had was a quick How to Easily Switch between Header and Source topic, but still couldn't make it work.
I guess what I really want is how to avoid the multiple if statements and use real matching to do what I want. I want to look into another directory and if look for a header file of the same name with any familiar extension if it was a source C/C++ file, or look for a source file of any regular extension if it was a header file. Thanks for your help!
UPDATE: I specifically want to open the file in a new tab. I live on vim tabs!
I recommend using the FSwitch plugin. https://github.com/derekwyatt/vim-fswitch
This does exactly what you need out of the box. It is better than a.vim in more than one way, being a rewrite of the idea behind a.vim.
The link you posted presents it as a solution, too.
I have just installed it to my vim configuration and it does its job well.
Enjoy.
Just to make sure I was using the most current version, I downloaded the latest a.vim script (2.18) and copied it into my ~/.vim/plugin directory.
You can define certain variables in your ~/.vimrc file to get a.vim to recognize alternate file extensions.
To get the files in your example to match their alternates I added the following to my ~/.vimrc:
let g:alternateExtensions_C = "H,hh"
let g:alternateExtensions_hh = "C"
These are global variables that allow you to override what's already defined. You'll have to define
both relationships (they don't work both ways).
You can see what the current mappings are by typing:
:echo g:alternateExtensionsDict
If you need to define other mappings, follow the same pattern. What comes after the underscore is the file extension you're editing. What's in the double quotes is a comma-separated list of alternate extensions.
let g:alternateExtensions_<ext> = "<list,of,alt,ext>"
If you have a different directory structure, you can define what paths to search by overriding the g:alternateSearchPath variable. ../src and ../include are already included by default.
:echo g:alternateSearchPath
To open the alternate file in a new tab:
:AT
By the way, the a.vim script is pretty well documented. You might want to open it up and take a look. I found a setting or two that I didn't know about and I've been using it for years ;o)
I hope that helps.
IMO your best option is to adopt existing scripts to use :tabf instead of :e or whatever the scripts use right now to open the counterpart file. You can also try to make the change configurable and submit it to the script author. (I'm pretty sure many would find the enhancement useful.)
That reminded me of a trick I used very long time ago. Instead of guessing where the corresponding source/header files are, I have used at the top of file special comment containing relative path to the counterpart file. Switching was as simple as finding the special comment, extracting file name and opening it. Problem was similar to yours in that file extensions were not predictable. My rational solution was to stop guessing and denote counterparts explicitly in the source code. (This days I would have probably tried to put the relationship table into an external file with a standard name and look it up in VIM using the upward search.)
Two helpful things
:he 'path'
:he tabfind
So you would do
:set path=../,/usr/include/,/home/buildagent/SDKROOT/mysdk/inc
:tabfind error_codes.h
to open error_codes.h from somewhere exotic without having to specify it. Note how vim globbing is very very flexible, so you might not need mucht
:argadd ./**/*.[h,H] | tab sall
will open all header files under the current directory, regardless of how many levels deep. Be careful running this command on a large tree or with symlinks outside the tree
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.