Tuesday, September 25, 2012

Essential Sublime Text 2 Plugins and Extensions

\Rating:

Essential Sublime Text 2 Plugins and Extensions

Siddharth on Feb 25th 2012 with 101 comments

Tutorial Details

Editor: Sublime Text 2
Availability: OSX, Linux, Windows

Sublime Text 2 is a relatively new code editor that I've been trying out for a while now. While it's still in public beta, it already offers a great mix of features and performance that has convinced me to switch from my trusted Komodo.

While I really do love the features available out of the box, as with most things in life, there is always room for more. With Sublime Text 2 being as extensible as it is, a big ecosystem has sprouted around it, catering to most of your web development needs, be they actually useful or catering to your whimsy. To that effect, today I'd like to share some of the plugins and extensions that I've found quite useful. While not all of them may appeal to you, I'm sure you'll a find a gem or two that will absolutely ease your workflow!

Zen Coding

Nettuts+ -- Essential Sublime Text 2 Plugins and Extensions

Zen Coding is an editor plugin for high-speed HTML coding and editing. The core of this plugin is a powerful abbreviation engine which allows you to expand expressions—similar to CSS selectors—into HTML code.

JQuery Package for Sublime Text

And where will all us be without jQuery? This is a Sublime Text bundle to help with jQuery functions.

Sublime Prefixr

A plugin that runs CSS through the Prefixr API, written by our very own Jeffrey Way, for Sublime Text 2.

JS Format

JsFormat is a javascipt formatting plugin for Sublime Text 2. It uses the commandline/python-module javascript formatter from JS Beautifier to format the selected text, or the entire file if there is no selection.

SublimeLinter

SublimeLinter is a plugin that supports "lint" programs (known as "linters"). SublimeLinter highlights lines of code the linter deems to contain (potential) errors. It also supports highlighting special annotations so that they can be quickly located.

Placeholders

I always find inserting placeholder, or filler, content to be a quite tedious affair. With this plugin, you can insert placeholder content and HTML in a cinch!

Sublime Alignment

I'm quite a stickler for properly formatted code. One thing to get right is lining up all those darn variable assignment so they look all organized and neat. With this plugin, all it takes is the press of key. A simple key-binding allows you align multi-line and multiple selections.

Clipboard History

Tired of having to swap out your clipboard's contents during a marathon hackathon? Keep a history of your clipboard items with this plugin and paste away as needed.

SublimeREPL

SublimeREPL lets you run your favorite interpreter inside a Sublime buffer. Languages supported include Python and Ruby.

DetectSyntax

DetectSyntax is a plugin for Sublime Text 2 that allows you to detect the syntax of files that might not otherwise be detected properly. This is specially helpful when you run into custom file formats — files used in templating is an excellent example.

Nettuts Fetch

This plugin automatically pulls in the latest copy of a file, simply by typing a keyboard shortcut. It'll perform a curl request to your specified URL and allow you to rest assured that, for all new projects, you're using the latest copy of a particular asset.

JsMinifier

It's a good practice to always minify your files during deploying to a production server. And this plugin will swiftly automate the process by minifying your JavaScript using the Google Closure compiler.

Sublime CodeIntel

SublimeCodeIntel is a code intelligence plugin ported from Open Komodo Editor to Sublime Text 2. It shows autocomplete information with the available modules in real time as well as display information about the current function in the status bar. Nifty!

Tag

This is a great plugin when you're working with a lot of markup. Tag is a collection of packages about, predictably, tags, mixed together in an effort to provide a single package with utilities to work with tags. Close a tag on a slash and tag indenting? Sign me up!

Bracket Highlighter

This plugin collection includes plugins to fold your code according to brackts, cycle through selecting tags and many more.

Case Conversion

Have a messy co-worker who completely ignores naming conventions? This plugin should save you a good chunk of time. Case conversions converts the current word between three of the most commonly used conventions.

Stackoverflow Search

StackOverflow is an absolute life saver — I can't count the sheer number of times it has saved my skin. This plugin lets you do a search on SO directly from your editor.

Sublime Guard

Remember Jeffrey using a gem called Guard in his super useful Rails tutorial? Well, this plugin provides a seamless interface for controlling Guard and viewing Guard output within Sublime Text 2.

Git

A nifty little plugin that integrates Git and Sublime Text and implements most of the commands that you'd use in real life. Diff viewing inside ST2 is a great time saver!

Sublime Change Quotes

This is one for the OCD among us. This plugin converts single to double or double to single quotes whilst attempting to preserve correct escaping.

Hex to HSL

Tired of constantly having to manually convert your colors' hexcodes to HSL? This plugin will automatically do it for you with the press of a button. Well, ok, three buttons. [Shift+Ctrl+U]

Source: http://net.tutsplus.com/tutorials/tools-and-tips/essential-sublime-text-2-plugins-and-extensions/

Ignoring files in git repositories

According to the man page, there are three ways to exclude files from being tracked by git.

Shared list of files to ignore

The most well-known way of preventing files from being part of a git branch is to add such files in .gitignore. (This is analogous to CVS' .cvsignore files.)

Here's an example:

*.generated.html
/config.php

The above ignore list will prevent automatically generated HTML files from being committed by mistake to the repository. Because this is useful to all developers on the project, .gitignore is a good place for this.

The next line prevents the local configuration file from being tracked by git, something else that all developers will want to have.

One thing to note here is the use of a leading slash character with config.php. This is to specifically match the config file in the same directory as the .gitignore file (in this case, the root directory of the repository) but no other. Without this slash, the following files would also be ignored by git:

/app/config.php
/plugins/address/config.php
/module/config.php

Local list (specific to one project)

For those custom files that you don't want version controlled but that others probably don't have or don't want to automatically ignore, git provides a second facility: .git/info/exclude

It works the same way as .gitignore but be aware that this list is only stored locally and only applies to the repository in which it lives.

(I can't think of a good example for when you'd want to use this one because I don't really use it. Feel free to leave a comment if you do use it though, I'm curious to know what others do with it.)

Local list (common to all projects)

Should you wish to automatically ignore file patterns in all of your projects, you will need to use the third gitignore method: core.excludesfile

Put this line in your ~/.gitconfig:

[core]
excludesfile = /home/username/.gitexcludes

(you need to put the absolute path to your home directory, ~/ will not work here unless you use git 1.6.6 or later)

and then put the patterns to ignore in ~/.gitexcludes. For example, this will ignore the automatic backups made by emacs when you save a file:

*~

This is the ideal place to put anything that is generated by your development tools and that doesn't need to appear in your project repositories.

Source: http://feeding.cloud.geek.nz/2009/12/ignoring-files-in-git-repositories.html

git ignoring files

ignoring files

committed 19 Jan 2009

We don't need Git to version everything in our projects, be it compiled source, files with passwords, or temporary files that editors love to create. Usually keeping stuff out of your VCS' hands is a task that is hard to manage and annoying to set up. Not with Git! Using the .gitignore file along with some other options, we're going to learn how to set up per-project and per-user ignores.

The easiest and simplest way is to create a .gitignore file in your project's root directory. The files you choose to ignore here take affect for all directories in your project, unless if they include their own .gitignore file. This is nice since you have one place to configure ignores unlike SVN's svn:ignore which must be set on every folder. Also, the file itself can be versioned, which is definitely good.

Here's a basic .gitignore:

$ cat .gitignore    # Can ignore specific files  .DS_Store    # Use wildcards as well  *~  *.swp    # Can also ignore all directories and files in a directory.  tmp/**/*

Of course, this could get a lot more complex. You can also add exceptions to ignore rules by starting the line with !. See an example of this at the GitHub guide on ignores.

Two things to keep in mind with ignoring files: First, if a file is already being tracked by Git, adding the file to .gitignore won't stop Git from tracking it. You'll need to do git rm --cached <file> to keep the file in your tree and then ignore it. Secondly, empty directories do not get tracked by Git. If you want them to be tracked, they need to have something in them. Usually doing a touch .gitignore is enough to keep the folder tracked.

You can also open up $GIT_DIR/info/exclude ($GIT_DIR is usually your .git folder) and edit that file for project-only ignores. The problem with this is that those changes aren't checked in, so use this only if you have some personal files that don't need to be shared with others on the same project.

Your final option with ignoring folders is adding a per-user ignore by setting up a core.excludesfiles option in your config file. You can set up a .gitignore file in your HOME directory that will affect all of your repositories by running this command:

git config --global core.excludesfile ~/.gitignore

Read up on the manpage if you'd like to learn more about how ignores work. As always, if you have other ignore-related tips let us know in the comments.

Source: http://gitready.com/beginner/2009/01/19/ignoring-files.html

Sunday, September 9, 2012

Creating a Shared Repository; Users Sharing The Repository

Commands discussed in this section:

git init –bare
git clone
git remote
git pull
git push

Scenario: Example Remote Repository

Let's set up our own little "remote" repository and then share it. (The repository will be "remote" to the users sharing it.)

In these examples, the other users sharing the repository will not be very remote since the repository will be on the same disk as the users' home directories. But the git workflow and commands are identical, whether the users and repositories are just a few millimeters away on the same disk, or on a remote network across the world.

Creating The Shared Repository

We'll have the repository created by the user gitadmin. The gitadmin's repository will be be the repository where everybody on the project both publishes their work and also retrieves the latest work done by others.

The scenario:

gitadmin will create a repository.
Other users, like Amy and Zack will then get ("git clone") copies of gitadmin's remote repository.
Changes will be pulled and pushed to and from gitadmin's repository.

Create Shared Repositories "Bare"

If you are creating a git repository for only your own use on projects or days when you just don't feel like sharing, you type:

gitadmin$ git init project1  Initialized empty Git repository in /home/gitadmin/project1/.git/

However, if you are creating a git repository for sharing with git clone/pull/fetch/push, Use the –bare option to git init:

gitadmin$ git init --bare project1.git  Initialized empty Git repository in /home/gitadmin/project1.git/

If you want to know why, see Shared Repositories Should Be Bare Repositories.

Bare Repositories End in ".git"

You might have noticed the –bare repository created above ended in .git. By convention, bare git repositories should end in .git. For example, project1.git or usplash.git, etc. The .git ending of a directory signals to others that the git repository is bare.

Amy is ready to add to the remote repository

In our example, since Amy's name begins with the first letter of the alphabet, she gets to work on the repository first.

Amy clones it:

amy$ git clone file:///home/gitadmin/project1.git  Initialized empty Git repository in /home/amy/project1/.git/  warning: You appear to have cloned an empty repository.

Git just told us the repository that Amy just cloned is empty.

We can now start creating files and publishing ("git push") them to the shared repository.

Amy wants to see if there are any branches in the repository she just retrieved/cloned:

amy$ cd project1  amy$ git branch

The empty output from git branch command showed are no branches in the new repository.

Amy creates her first file and commit's the new file to the repository.

amy$ echo The beginnings of project1 > amy.file  amy$ git add .  amy$ git commit -m"Amy's initial commit"  [master (root-commit) 01d7520] Amy's initial commit   1 files changed, 1 insertions(+), 0 deletions(-)   create mode 100644 amy.file  amy$ git branch  * master

The cloned, bare repository didn't have any branches, not even the master repository. When Amy did the first git commit, the master branch was created in Amy's local repository.

Amy tries to publish her local repository to the remote repository:

amy$ git push  No refs in common and none specified; doing nothing.  Perhaps you should specify a branch such as 'master'.  fatal: The remote end hung up unexpectedly  error: failed to push some refs to 'file:///home/gitadmin/project1.git'

Oops, that didn't work. The above happens on brand new, completely empty, branchless repositories (immediately after doing the git init –bare …).

Amy's local repository created the master branch, but the shared repository that gitadmin created does not have any branches on it still.

Amy will take git's advice and tell git the name of the branch she wants pushed to which remote repository. She must specify both the remote repository name and branch name.

What are the branch and repository names? Amy has been distracted lately and forgot the name of remote repository, so she'll use the git remote command to list the names of her remote repositories:

amy$ git remote  origin

She is shown there is only one remote repository named origin. The default remote repository when you git clone a repository is named origin, so the above output isn't surprising.

Similarly, Amy can find out the branch name in her local repository by using the git branch command:

amy$ git branch  * master

The branch name master isn't surprising either, since master is the default branch name for git.

Armed with the remote repository name (origin) and local branch name (master) Amy can now push (publish) the changes.

The git push syntax is:
git push [remote-repository-name] [branch-or-commit-name].
Amy will push the branch named master to the remote repository named origin:

amy$ git push origin master  Counting objects: 3, done.  Writing objects: 100% (3/3), 245 bytes, done.  Total 3 (delta 0), reused 0 (delta 0)  Unpacking objects: 100% (3/3), done.  To file:///home/gitadmin/project1.git   * [new branch]      master -> master

The last line above reports a new branch was created: the master branch (referred to in some places as the "source") on the local repository was mapped to the master branch (referred to in some places as the "destination") on the remote repository.

Amy will no longer need to type git push origin master, but will be able to type git push, since the master branch now exists on the remote repository named origin:

amy$ git push  Everything up-to-date

Zack wants to play too

Now it's Zack's turn to play with the repository. He clones it:

zack$ git clone file:///home/gitadmin/project1.git  Initialized empty Git repository in /home/zack/project1/.git/  remote: Counting objects: 3, done.  remote: Total 3 (delta 0), reused 0 (delta 0)  Receiving objects: 100% (3/3), done.  zack$ ls  amy.file

Above, the file Amy added, amy.file is copied from the shared repository to Zack's working directory.

Zack adds a file and pushes it up to the shared repository:

zack$ cd project1  zack$ echo I am zack > zack.file  zack$ git add .  zack$ git commit -m 'zack initial commit'  [master 05affb3] zack initial commit   1 files changed, 1 insertions(+), 0 deletions(-)   create mode 100644 zack.file  zack$ git push  Counting objects: 4, done.  Delta compression using up to 2 threads.  Compressing objects: 100% (2/2), done.  Writing objects: 100% (3/3), 283 bytes, done.  Total 3 (delta 0), reused 0 (delta 0)  Unpacking objects: 100% (3/3), done.  To file:///home/gitadmin/project1.git     01d7520..05affb3  master -> master

Note that Zack didn't have to do the git push origin master to create the master branch on the remote repository, since Amy had already created the master branch on the remote repository.

Amy wants to get the latest

amy$ git pull  remote: Counting objects: 4, done.  remote: Compressing objects: 100% (2/2), done.  remote: Total 3 (delta 0), reused 0 (delta 0)  Unpacking objects: 100% (3/3), done.  From file:///home/gitadmin/project1     01d7520..05affb3  master     -> origin/master  Updating 01d7520..05affb3  Fast-forward   zack.file |    1 +   1 files changed, 1 insertions(+), 0 deletions(-)   create mode 100644 zack.file  amy$ ls  amy.file  zack.file

Things are working pretty well: Amy and Zack are sharing nicely: They are contributing to ("git push") and receiving from ("git pull") the shared repository.

The above summarizes how to get moving with shared, remote repostitories. But there's a lot more fun you can have with remote repositories.

Source: http://www.gitguys.com/topics/creating-a-shared-repository-users-sharing-the-repository/

Tuesday, September 25, 2012