La Vita è Bella

If you use vim for programming, then you can't live without ctags (can you?). ctags generate the "tags" file, vim and its plugins use this file to help your programming more efficiently.

By default, vim will only use the "tags" file under your current working directory. You can use this command to see it:

:set tags?

Generally, your "tags" file under you current working directory won't contain informations about system libraries (glibc, stl, etc.). If you miss them, you can generate tags file for your system libraries, and ask your vim to load them:

set tags+=/usr/local/include/tags
set tags+=/usr/include/tags

If you are working on a big project, which have many subdirectories, the "tags" file under each working directory may be not enough, as you also need some information about the functions under other subdirectories. So you can generate a "tags" file under your project root, and ask vim to load it when editing a file within your project:

autocmd BufEnter ~/work/myproj/* :setlocal tags+=~/work/myproj/tags

Thanks for Ryan Phillips, you can also add "tags;" (notice the semicolon) to your tags so that vim will automatically look up "tags" file in the file tree (":help file-searching" for document):

set tags+=tags;

To make it easier to use, I've also made a script named "projtags.vim" so that you need only set your project directories in your vimrc:

let g:ProjTags = ["~/work/proj1"]
let g:ProjTags+= [["~/work/proj2", "~/work/proj2.tags"]]

Happy vimming :P

Live Spaces made some change days before, and that makes me unable to see any live space pages.

When I use Camino to visit live spaces pages, I always get a "XML Parsing Error", even the page I'm visiting is not the RSS but a html. When I use Firefox or Safari, I always get a HTTP 500 error.

The "XML Parsing Error" is really weird. It seems that the live spaces server send a wrong "Content-Type" so that Camino treat it as a XML document and try to parse it use a XML tree, and that failed (with "view source" I can see the html source corretly).

But Camino didn't have a extension like live HTTP headers to see what Content-Type do the server send, thanks to smorgan on MozillaZine Forums, I can see it using curl.

This is what curl get:

McManaman:~ fishy$ curl -v http://spaces.live.com -o /dev/null 2>&1 | grep Content-Type
< Content-Type: application/xhtml+xml; charset=utf-8

This is what Camino will get:

McManaman:~ fishy$ curl -v http://spaces.live.com -o /dev/null -A "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4pre) Gecko/20070408 Camino/1.1b+" 2>&1 | grep Content-Type
< Content-Type: application/xhtml+xml; charset=utf-8

This is what Firefox will get:

McManaman:~ fishy$ curl -v http://spaces.live.com -o /dev/null -A "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0" 2>&1 | grep Content-Type
< Content-Type: text/html; charset=utf-8

And this is what Safari will get:

McManaman:~ fishy$ curl -v http://spaces.live.com -o /dev/null -A "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/418.9.1 (KHTML, like Gecko) Safari/419.3" 2>&1 | grep Content-Type
< Content-Type: text/html; charset=utf-8

As you can see, for some common browsers, such as Firefox or Safari, live spaces server send the right Content-Type. For unknown browsers (including curl, Camino, etc.), it claims that it's "application/xhtml+xml". Oh my god, what did they think they are doing? What can they get from this Content-Type? I can't understand this at all.

So the only word I can say is, "live spaces suck, one more time"

If you prefer DMG or CDR format, then you can just use Disk Utilities to make image of your disks. But if you prefer ISO format, then this is the way.

1. Insert your disk into your driver, of course.
2. Unmount it but didn't eject it. To do so, you need to type this command in your Terminal: "sudo umount /dev/disk1". "disk1" may vary depends on your other drivers.
3. Use dd to create the image: "dd if=/dev/disk1 of=/path/to/foo.iso". Again, "disk1" may vary.
4. When it's done, you've got the ISO image file, and you may eject the disk now. But as a bug in Finder, you can't eject a volume which you unmounted in Terminal in normal ways. Instead, you need to type this command in Terminal to eject it: "sudo diskutil eject /dev/disk1"

The Finder bug is really annoying, even a logout can't eject the disk, you must reboot your machine. But fortunately I've found the workaround on macosxhints.