Is there a way to turn off xemacs auto backup files in a specific directory only? - xemacs

XEmacs always creates a file named foo.txt~ when you edit foo.txt. This can be really useful but not really when you are using source control on your files.
I know you can use (setq make-backup-files nil) to turn it off altogether but was wondering if there was a way to turn it off only in particular directories.

The version control package will detect if you're in a CVS, RCS, or SCCS repository and disable backups. If you're using another VC backend like hg, git, or svn, you may need to install additional packages to enable emacs to detect their repositories.

Related

How to hack on installed perl6 module source?

I'd like to be able to view and make changes to the source code of installed (via zef) perl6 modules. How can I do that?
On my system, the module sources are under ~/.perl6/sources/ and there's also some kind of metadata file about the modules in ~/.perl6/dist/.
I can also use zef locate ... to show a module's source path, but making changes directly to the source files doesn't seem to have any effects (i.e., use the module from the REPL doesn't show my changes).
I'm guessing it's because the modules were pre-compiled, and perl6 doesn't pick up my changes and re-precompile the modules when I make changes directly to the module source files that way...
UPDATE: Deleting the corresponding pre-compiled files under ~/.perl6/precomp/... seems to work, but I'm not sure how and if that messes up anything.
I'd like to be able to view and make changes to the source code of installed (via zef) perl6 modules. How can I do that?
Please, don't do it that way. Installed modules are supposed to be immutable and as you've found out: if there is a pre-compiled version of a module available, it will not check if the original source file has been updated. That's because it doesn't have to, because it is considered immutable.
If you want to test changes on an installed module, please download the tar file / git clone the module's distribution, make changes you need in there, and then do:
zef install . --force-install
while in the top directory in the distribution. That will re-install the module and handle pre-compilation for you.

How do I commit my IntelliJ IDEA Global Library configuration into source code control?

I have IntelliJ IDEA 13.1 running on a number of machines, all with identical paths for the project and modules but different local user names. The .idea directory gets committed to the git repo. When I make changes to my Global Libraries those are not reflected on the other machines because that info is in
C:\Users\user\.IdeaIC13\config\options\applicationLibraries.xml
I want changes to Global Library settings to be required only once and applied everywhere.
Should I tell IDEA to look for applicationLibraries.xml under the .idea directory instead of in the local user's directory which is not under version control? how?
Solution was to go into Project Structure, right click on each Global Library and choose "Copy To Project Libraries..." then remove the original from Global Libraries. Then in each project remove the old global library and add the newly created project library. This way library data is stored in the .idea dir and not the user's dir.
The applicationLibraries.xml file, among others, are stored in a platform-dependent folder in the repo, for example in _linux or _windows. If this is your problem, read on.
For things like keymaps this is wanted because things work differently after all, but for libraries which either only contain jars, or contain binaries (dll/so) for all platforms, this is unwanted.
On the PC with the global libraries (assuming linux for now):
Copy the file from config/settingsRepository/repository/_linux to _windows,
Execute git add _windows/applicationLibraries.xml from the command line,
Restart IntelliJ,
Merge repo (not Overwrite remote)
This solved it for me, and now I have global libraries on all my computers, and not just my linux computers.

What is stored in Packages/User directory?

How to save/restore Sublime Text 2 configs/plugins to migrate to another computer? states that, to backup a Sublime Text 2 installation, a user should preserve the ~/Packages/User directory (from the user's local data folder on whatever OS they're using).
However, http://andrew.hedges.name/blog/2012/01/19/sublime-text-2-more-sublime-with-a-drop-of-dropbox and most other walkthroughs for using Dropbox to sync Sublime's settings specify three directories: ~/Packages, ~/Installed Packages and ~/Pristine Packages.
What is the functional difference between backing up just ~/Packages/User, and the other 3 directories?
I think that Packages/User is the one in which you are supposed to put settings (according to Sublime's official and unofficial documentation). However, some people put them in the other folders from time to time.
The Dropbox advice may be a hedge against poor practice.
From here:
Installed Packages is:
You will find this directory in the data directory. It contains a copy
of every sublime-package installed. Used to restore Packages.
These are the packages installed as sublime-packages. I don't think package control uses this, but if you install something as a sublime-package maybe you want to keep it?
Pristine Packages is:
You will find this directoy in the data directory. It contains a copy
of every shipped and core package. Used to restore Packages.
So essentially a list of .sublime-package files used to restore if you break something.
Packages is:
The packages used by Sublime Text, either installed as part of sublime, or the plugins.
User is:
The user directory is your personal directory, containing configurations, additional snippets, etc.
Below are my personal views on what to save, so feel free to ignore it if you would like.
I would have to agree with the post saying just save the User directory, as Package Control will grab all of the plugins in the list if they aren't already installed. I didn't see this mentioned in that post, but you can also add repositories (by specifying a URL) to Package Control, which allows you to install Packages outside of those submitted to Package Control, but still hosted somewhere. One of the arguments I can see to saving the Packages directory completely is if you are using plugins that aren't hosted anywhere (though these could probably be moved to the Packages directory without any problems).
The Installed Packages and Pristine Packages are used to restore packages, so I wouldn't think these would be needed, but I'm sure there is some use case where it is.
Anyways, realize I got off topic a bit at the end there, but hope everything before that helps clarify.

Geany IDE backup copy path

I just lost an entire script in Geany editor...
Is there a place where Geany saves a backup or cached copy somewhere?
Thank you for your help...
Geany does not automatically create backup files unless you enable the "Save Actions" plugin, and select "Auto Save".
It depends on what do you want. Geany can save a backup copy of the unedited file and also various options of saving the edit buffer. Read this nice wiki All you never wanted to know about file saving.
To backup scripts, use GitHub.
There are other VCS's (Version Control System), but Git has a strong feature set and is fairly easy to use. The real strength of Git, to my mind, is GitHub, which, so far as I know, is the only free-as-in-beer site which will let you create a large number of projects. It also seems to be well run, and I find many API's I like on that site.
Use VCS to:
1.) backup your code so that you don't lose it
1a.) backup offsite, such as to github in the event of your computer bursting into flames
2.) keep track of different versions, comments, etc
3.) collaborate! Give your code to the community. Or, fork someone elses code.
The caveat to all this is to omit passwords or other sensitive files. Don't upload a file with your credentials for logging into e-mail, for example. RTFM to see how to omit specific files with Git.
Finally, if you don't like Git there are alternatives, SVN has, in some scenarios, better syntax.
If you have just overwritten the file (Ctrl+S) and haven't yet quit Geany, you can just Ctrl+Z to the desired document state and save that file version.
If you have already quit Geany after that and haven't set up back up in Geany before, I am afraid that by means of Geany you cannot restore the file to the previous state.
Read this article about how to set up back up in Geany. Basically you can go to Edit -> Preferences -> Various (read the manual and the link above before changing these preferences) and:
disable use_atomic_file_saving (disabled by default)
enable use_gio_unsafe_file_saving (enabled by default)
enable gio_unsafe_save_backup (disabled by default)
This will always keep the previous version of the file (as a hidden file with ~ attached to its name) next to original.
Or you can install/enable the Save Actions Geany plugin and enable the Auto Save and Backup Copy options to automatically save files at a certain time interval and to keep a copy of previous file versions.

How to get RavenDB to recognize a plugin?

I'm trying setup the Versioning bundle in RavenDB: http://ravendb.net/bundles/versioning
The installation instructions are pretty straight forward:
Simply place the Raven.Bundles.Versioning.dll in the Plugins
directory.
I've tried this do this by creating a "Plugins" directory under the Server directory (the Server directory contains the Raven.Server.exe), and dropping Raven.Client.Versioning.dll into that Plugins directory.
However, when I run RavenDB after that (either from the command line or as a service), it doesn't give me any indication that it has recognized the plugin, and when I save/edit new documents no versioning is being applied.
I've tried running with the default plugin directory settings (which supposedly automatically looks in the Plugins directory), and I've tried manually adding the PluginsDirectory setting to Raven.Server.exe.config, to no avail.
Has anyone been able to get plugins working, specifically the versioning bundle? Do you hae to do anything special?
Mike,
It is supposed to just work. Take a look at the statistics, you should see the versioning trigger registered there.
It is important to ensure that:
You are using the same version of the dlls
You restarts RavenDB after copying the directory
You don't reference another Raven/PluginsDirectory in the configuration
It is probably better to follow this up in the mailing list.
For Raven v2, you'll also add the bundle name to the the Raven/ActiveBundles property on a database document. The names should be semicolon-delimited.
For example, I have a database called MidwestAnimalRescue. To enable the Periodic Backup bundle and the Versioning bundle, my document will look like this: