LaTeX, Vim, and Line Breaks

Two of the nicer things in life are Vim and LaTeX. Vim’s a powerful, simple, modal editor, and LaTeX is essentially the greatest document preparation system in existance. Put these two things together, and they’re like Reese peanut butter cups; something even better is formed, something that is somehow greater than the sum of its parts.

Line breaks are also incredibly useful, as they vastly increase human readability. It’s very hard to read words that are broken up halfway through by the edge of your screen. Line breaks work around this problem by creating new lines in logical places, such as after words.

Adding line breaks to LaTeX files works beautifully, since LaTeX ignores single line breaks when processing your files. This makes it easy to greatly improve how readable your .tex files are. Vim has an easy configuration command to break lines around words once a certain character number is reached. But it’s inconvenient to reissue the :set tw 80 command every time you open a .tex file, and I don’t want any code to wrap in other files (as would happen if set in the .vimrc). So how can you get Vim to automagically break lines, but only in .tex files?

The answer is suprisingly simple. In your .vimrc, use the line:

au FileType tex set tw=80

That’s all there is to it. This command tells Vim to break lines around words at the 80 character limit, but only in tex files. You can replace the number 80 in the command with any other number of characters you might want to break at.

This just made the superb combo of Vim and LaTeX that much sweeter.

Mmm, awesome!

Advertisements

Review: Avatar

Note: Some minor spoilers are present in this post, but there’s nothing that will ruin Avatar for you.

I don’t know how it would be possible to not know about the movie Avatar these days. From newspaper headlines about it breaking box office records to other people talking about it, Avatar seems to constantly be in the background. And everybody is more than just a little pumped about the movie. One of my friends embodied the common opinion of Avatar:

Holy shit, Avatar’s basically the second coming of Jesus Christ combined with Santa Claus! It’s just that freaking awesome!

Overwhelming approval would almost be an understatement. It initially seemed like a repeat of the Transformers movies. All of my friends said that they were amazing, but when I finally saw them, there was really no substance, and I left the theatre with a sense of dissapointment. Yeah, there was lots of eye candy and running away from giant explosions in slow motion, but there was nothing behind that, and it ended up just seeming kind of lame.

I fully expected Avatar to be a reapeat of the Transformers experience. I almost wanted to hate it, since that way I could feel superior about having better taste and not being shallow. But I can’t. I was completely blown away by the entire movie, all two hours and 45 minutes of it. I wouldn’t hesitate to see it again if I get the chance.

You’ve probably been living under a rock if you don’t know the basic premise of Avatar, but I’ll quickly rehash it here anyways. The film is set on Pandora, an incredibly lush moon of the planet Polyphemus, located in Alpha Centauri. This planet happens to have a large amount of unobtainium, a resource that the people on Earth desperately want. A mining company, RDA Corporation, has set up base on Pandora so that it can mine for unobtainium and get ridiculously rich in the process. The problem with their plan is that Pandora happens to be populated by a large amount of Na’vi, the indigenous people (my sister described them as, “Magical ten-foot-tall blue people”). There’s also a great variety of other native species, many crazy sweet plants and animals. Of course, RDA Corp. doesn’t care about the local biodiversity. They just want to get the unobtainium so that they can make stupid amounts of money.

As part of the process, there’s a team of biologists that are there to try to make the company look more friendly in the eyes of their shareholders. These biologists have many high-tech tools, the most prominent of which are their avatars. Avatars are basically second bodies that take the form of Na’vi. The biologists can mentally take control of these avatars via what look like high-tech tanning booths.

The protagonist, Jake Sully, is an ex-marine who has lost use of his legs. He is completely untrained, but ended up on Pandora after his twin brother died. The avatars are tied to genetic material, so he was able to take over his brother’s avatar and allow the RDA to not loose money on a wasted Avatar. Jake Sully ends up meeting the indigenous Na’vi, and learning about their ways of oneness with their planet. He starts to understand the native people and love them, but at the same time, RDA wants to demolish their home so that they can mine the unobtainium. Jake is torn between the two, and his conflict between the Na’vi and RDA turns into the meat of the movie.

I can’t say that this is an incredibly unique plotline. Really, it’s a rehashed, futuristic version of Pocahontas. It may not be original, but it’s not a bad plot, and it does its job. The dialogue isn’t extraordinary, but it’s definately passible. The characters are fairly flat, but you don’t really notice. Despite these flaws, Avatar still manages to be magical.

Avatar is extremely similar to The Lord of the Rings in the way that it strikes you. For the whole length of the movie, you get totally sucked in, absorbed in the world presented before your eyes. Pandora seems like a truly magical place, so lively and vivid that you could reach out and feel the texture of the fauna. The world becomes real in front of you, and this is where the magic of Avatar lies.

Without a doubt, Avatar is one of the coolest experiences you will have in theatres. It’s 3D technology was very good, and only added to the immersion. Unlike the old red-green 3D glasses of the past that made me nausious (perhaps because I’m colourblind), the polarized lenses for RealD worked perfectly for me, and I never felt any dizzyness or nausia. The 3D was very tastefully done, with nothing that was in your face. I’m sure that the 3D is somewhat responsible for the world feeling so real, but I’d venture that it would still be totally watchable and almost as impressive on a two-dimensional screen.

Final Verdict

Avatar is an amazing film. While it may be average in terms of plot and characters, Avatar hits the ball out of the park in terms of immersion, spectacle, and enjoyment. The world that James Cameron has created is a wonder to behold, one that inspires the imagination. Truly, you owe it to yourself to go see Avatar in theatres and enjoy the marvel that it is.

Git: My (Not Exactly) Quick Reference

I decided to post a few of the scripts and config files I have going on github, making it easier to share files between my machines.  I’m brand new to Git, so I really had absolutely no idea how it worked before I started working with github.  Essentially all of my informaition came from the great introduction to Git, Pro Git, as well as the Git man files. This information is merely compiled into one page here. This post is a quick reference for myself, but if you find it useful, then great! (Note that I work on Linux machines, so this guide is very Linux-centric)

Preparation

Installation

Of course, you have to start by installing Git.  On Arch Linux, my distro of choice, this is as easy as the following:

# pacman -S git

However, this will vary depending on the distro you’re currently using. You’ll almost certainly find Git in your distro’s default repositories, but it’s not there or is outdated, you can grab the source for Git here: http://git-scm.com/download. Git depends on curl, zlib, openssl, expat, and libiconv, so make sure that those are all installed, too.

Configuration

Start by setting your name and email address. This is essential, as it is included in every single commit you do.

$ git config --global user.name "Your Name Here"

$ git config --global user.email your.address@yourdomain.com

Set your prefered editor. This editor will be called when you need to type a message.

$ git config --global core.editor vim

At this time, you might also find it useful to specify a diff tool. I use vimdiff.

$ git config --global merge.tool vimdiff

If you like coloured output, use the following configuration command:

$ git config --global color.ui auto

Make sure that Git will be dealing with line breaks properly.  This should set you up so that every commit converts line endings to LF, so that they are always LF in the repository you’re working with.

$ git config --global core.autocrlf input

You might find it useful to set up a few aliases, such as the following:

This makes it easier to remember the command to remove files from the staging area.

$ git config --global alias.unstage 'reset HEAD --'

Using the command “git last” will give you information about the last commit.

$ git config --global alias.last 'log -1 HEAD'

Pro Git reccomends the following for tab completion in Bash:

Download the Git source code, and look in the contrib/completion directory; there should be a file called git-completion.bash. Copy this file to your home directory, and add this to your .bashrc file:

source ~/.git-completion.bash

If you want to set up Git to automatically have Bash shell completion for all users, copy this script to […] the /etc/bash_completion.d/ directory….

Workflow

Initilizing a Git Repository

To start using a Git repository, it must be started first. This is as easy as the following command:

$ git init

This starts the git repository skeleton in your current directory, however, nothing is actually being tracked yet. The following goes through the process of adding a file, and then commiting it.

$ git add

$ git commit -m 'Comment about commit'

Clone a Git Repository

Cloning a Git repository will make a copy of the entire repository on your local machine. Note that this is not just a copy of the current working version, but the entire project, including all of the history. Note that in the following example, the portion in square brackets is optional, and merely specifies a custom name for the cloned repository.

$ git clone git://location/of/your/git/repository.git [my_repository.git]

Working with a Git Repository

To check the status of files (untracked, unmodified, modified, staged), use git status.

$ git status

Whenever you want to stage a file, you have to use git add to stage the current version of that file. Once staged, the file will be part of your next commit, as is. Note that if you add a file to stage it, and then change the file again, the version that is currently staged is the version before your last change.

The command

$ git diff

can be used to see what specific changes in files have been made but have not yet been staged. This command accepts arguments. Use —-staged to show changes that have been staged and will go into your next change.

$ git add

If you don’t want git to track some files (even as untracked), use a .gitignore file to list the files. From http://progit.org/book/ch2-2.html,

Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.

The rules for the patterns you can put in the .gitignore file are as follows:

  • Blank lines or lines starting with # are ignored.
  • Standard glob patterns work.
  • You can end patterns with a forward slash (/) to specify a directory.
  • You can negate a pattern by starting it with an exclamation point (!).

Glob patterns are like simplified regular expressions that shells use. An asterisk (*) matches zero or more characters; [abc] matches any character inside the brackets (in this case a, b, or c); a question mark (?) matches a single character; and brackets enclosing characters separated by a hyphen([0-9]) matches any character between them (in this case 0 through 9) .

Here is another example .gitignore file:

# a comment – this is ignored
*.a       # no .a files
!lib.a    # but do track lib.a, even though you're ignoring .a files above
/TODO     # only ignore the root TODO file, not subdir/TODO
build/    # ignore all files in the build/ directory
doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt

The final step is committing your changes once you are happy with what you have staged.

$ git commit

This will call upon your editor to write a comment about the commit. A comment is needed, otherwise the commit will abort. The option -v will tell you what files you are committing.

If you don’t want to bother with the staging area (useful for something like a simple edit of a file), you can simply change your file, and then use the command

$ git commit -a -m 'comment about the commit'

To delete a file, first remove it from the working directory, and then stop tracking it.

$ rm <filename>

$ git rm <filename>

You can use

$ git rm --cached <filename>

to remove a file from your staged area, but keep it in your working tree.

To move a file, use the mv that is built into git:

$ git mv <initial_file> <renamed_file>

Viewing the Commit History

The command

$ git log

is used to view the commit history. It accepts flags. -p will show the diffs of the commits. –n can be used, where n is a number, to limit to n number of entries. —-stat will show some abbreviated stats for each commit. There are many different ways to show the log history. To see all of the options available, check the Git documentation with:

$ man git-log

Undoing Changes

Be careful when undoing things. Git is designed to be fairly failsafe, but you can lose data when undoing changes. You can’t always undo these undos, so proceed with caution.

If you need to change a commit for some reason (say you forgot to add a file into the commit), you can use

$ git commit --amend

to reupload your current staging area and merge it with your last commit.

Say you accidentally move a file into the staging area when you didn’t mean to, or want to unmodify a modified file. Instructions on how to undo changes are present in the output of:

$ git status

Working with a Remote Repository

While you’re working with git, you’ll in all likelyhood have be working with remote repositories. While I’m working with files, I have my local version, and I work with my remote repository on the github servers. To see your remote repositories, use:

$ git remote -v

To add a remote repository and give it a name that you can easily reference, use the command git remote add. In the following line of code, replace the square brackets with their respective fields.

$ git remote add [name_for_repo] [url]

If you want to get more information about a certain remote repository, use the command:

$ git remote show [remote_repository_name]

You can pull information out of remote repositories. The following command will pull any new data that you don’t have into a new branch on your machine.

$ git fetch [remote_repo]

Note that you can set up git pull to somewhat automate fetching new information from remote repositories.

When you want to share your data with others, use git push to push your data upstream.

$ git push [remote-name] [branch-name]

Tagging Things

Tagging is very useful for keeping track of things like release versions. To see all of a project’s tags, use the command:

$ git tag

There are different types of tags that are available for use. Lightweight tags are simply pointers to a certain point in the history of a project. Annotated tags contain information about the tagger, date, the tagger’s email, contain a message, and are checksummed. Signed tags contain a GPG (Gnu Privacy Guard) signature. Annotated tags are generally reccomended. You can create an annotated tag using:

$ git tag -a v[version_number] -m 'comment about version'

If you want to create a lightweight tag, use no flag. To create a signed tag, use the flag -s.

To see information about a tag, use the command:

$ git tag show [tag]

You can tag a commit after the project has moved on. View the history of the commits with a command like the following one, and then use part of the checksum to tag a particular commit.

$ git log --pretty=oneline

0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile

$ git tag -a v1.2 9fceb02

Tags are not by default pushed to remote servers. To do so, you must specify them, much like remote branches.

$ git push origin [tagname]

If there are a large amount of tags you want to push, use the command:

$ git push origin --tags

Branches

Local Branches

Branches can be created with the command:

$ git branch [branch-name]

To delete a branch, issue the same command, but with the flag -d.

$ git branch -d [branch-name]

To switch to a previously created branch, use the checkout command.

$ git checkout [branch-name]

Merge you changes with the command merge. Issue the command from the branch you are merging into, and let [branch-name] refer to the branch that you are pulling in for the merge.

$ git merge [branch-name]

Sometimes, merges don’t go smoothly. If you have a problem with a merge, you have two options:

  1. View the output of $ git status The file(s) that barfed during the merge will be listed as “unmerged”. You can manually edit the files to resolve the merge issues. Find the section(s) that Git has changed (it will list what the file is like in both branches at this point of the file), and then edit it down to what you want the end result to be. After you finish, run
    $ git add [filename]
    to stage the file(s), marking them as resolved.
  2. Use a diff tool to assist in dealing with the conflict.
    $ git mergetool
    Once you’ve done so, you can tell the script that you resolved the conflict.

Once you are done with your changes, run

$ git status

to ensure that everything has been resolved. Once you are happy, run

$ git commit

to finalize the merge.

Unlike the branches previously discussed, remote branches exist in remote repositories.

Sources

All of the information on this page was pulled from two sources: The wonderful book Pro Git, by Scott Chacon; and the Git man pages. Sections that I’ve pulled directly from the sources are in block quotes and attributed in the surrounding area. Everything else somehow came from one or both of these two sources, but with the surrounding writeup written by me to paraphrase the source.