The latest dev channel build of Google Chrome now have a basic bookmark manager and cookie manager.

With a bookmark manager, even though it is very basic, Chrome for OS X has the basic set of features that I feel makes up a browser and might can make Chrome my default browser on OS X soon.

Looking back on my computer usage this past year, I realized that I’ve stopped using Windows. For the first time, I don’t even have a Windows computer at work. Having mostly used DOS/Windows (usually along side a linux server) for so long I didn’t expect that my usage to stop so quickly, but before I knew it I was doing everything I needed to do on another OS. One of the key changes that I made that contributed to being able to stop using Windows is that I stopped PC gaming. However, I would have expected that OSX would have been the primary OS following Windows (especially since I replaced my main Windows machines with a MBP), but the work horse OS that I used the most turned out to be Linux. Where consumer apps on Linux used to lag behind Windows and OSX, developers are now building them for Linux including media players (VLC) and programs like Picasa and Handbrake with the arcane interfaces that are often associated with the Unix world. I believe having these types of user accessible applications will drive Linux more then just having windows/osx-like window managers.

Sometimes I want to have my bash script behave differently based on how I call it without having to set up different parameter inputs. For example, I might have a script that can sync a file from a local server to one of two remote servers. I can make my script to take in parameters so I can call it using ’syncfiles -h serverA; syncfiles -h serverB’, but sometimes I forget what my params are and it’s easier to remember ’syncToA’ or ’syncToB’.

To do this is pretty simple, yet I always have to look it up each time so I’m writing this as note to myself.

Next, create symlinks to the original source files with the names you chose (i.e. ’symlink syncToA syncfiles’).

As pretty as GUIs are, sometimes it is most efficient to work in a text console which is why I find myself using GNU Screen. However, Screen’s command starts with CTRL-A which is also Bash’s move to start of line command. To have it work, use ‘ctrl-a a’.

Also, screen sets the value of TERM to be screen so if you have any settings based on the TERM value, update it appropriately.

One thing about using screen is that you lose your terminal’s scroll buffer so as line scroll past your view you can’t just use the scrollbar to move up to see what you missed. Instead, screen has it’s own scroll buffer that you can use. You can set the buffer size using ‘defscrollback #’ (where # is the number of lines) in your .screenrc or in the screen command line (ctrl-a). You can switch to the buffer with ‘ctrl-a [‘ (and exit buffer mode with ESC). Navigation follows normal VI keys.

Finally, I noticed that hitting the delete key didn’t send backspace as expected with using the OSX terminal. To correct that, add the following to your .screenrc:

This tip came from here.

I’ve always been an EMACS user on UNIX and it sometimes seems like it can do EVERYTHING. The one problem with EMACS is that a lot of production systems (and even many non-prod) won’t install it which means that when I’d have to use vi/vim and I’m just not as fluent with it. Especially since when I’m on those systems means that I’m trying to do fast debugging and navigation, being slowed down by my lack of experience with the editor is really frustrating.

I’ve decided to try to switch to VI/VIM to be the primary editor for awhile to force me to learn. There is no need to tell me that EMACS kicks butt (I agree), but unless you can get emacs installed everywhere, this is really more a decision based on my current situation.

Terminus is a very nice looking font that is well suited for programming editors and terminals.

It is an open source font and many linux distributions have it available. I haven’t tried any for OSX, but you can compile for xterm on OSX/X11 from macports.

Sometimes it is just more comfortable reading source code on paper, but printing directly from a text editor often gives an output that is ugly and wasteful. Just try opening up your source code in notepad, textmate, etc. and print. It might look very nice on your screen but on paper the fonts are big with lots of white space.

Printing source code is a different beast then printing narrative text and has some special requirements. The first is to include line numbers for easier reference. Different languages have different formatting and sometimes you want to print with color syntax to help find what you’re looking for. It can also be helpful to print two pages on one sheet so you can see more of the code and reduce paper waste.

On Windows/DOS, programmer editors usually have features for handling these types of pretty source code printing. Strangely, none of the editors I’ve seen on OSX have it (TextMate, Eclipse, Smultron, etc.) and since I’ve been dealing with code more I wanted a solution.

Fortunately, OSX’s UNIX underpinning allows me to use the classic enscript tool to handle this.

This generates a Postscript file (default), with 2 columns (2), quiet mode (-q), line numbers (-C) , using C syntax (-Ec), in color with Courier 8 pt font (-f), in landscape mode (-r) to a file called OUTPUTFILE (-p) from SOURCEFILE.

You can find different language syntax available for the -E option with “enscript –help-highlight” and you can set different output formats besides PostScript with the -W option (i.e. html).

“-p -” will tell enscript to print to stdout so you can pipe it to lpr.

Got Snow Leopard today and decided to upgrade. Install went smoothly and took about 30 minutes. The only glitch was after it was done I got that strange blue tinge screen, but a reboot corrected that. Here are the steps to upgrade:

Insert DVD and run the Upgrade installer.
Once upgrade, go to www.adobe.com to install the latest flash player since the one with Snow Leopard has a security hole.

— The next are optional —
Install XCode from the installer disc.
Install macport 1.8 for Snow Leopard
Follow the instructions to update macport packages: https://trac.macports.org/wiki/Migration

Tracking status of macports on Snow Leopard: http://trac.macports.org/wiki/snc/snowleopard

Three very common keyboard function that I use is to copy/paste/cut. For my hands, I found it more comfortable to use the CTRL key instead of the COMMAND (apple) key along with c/v/x. To change the key binding:

create/modify the file: ~/Library/KeyBindings/DefaultKeyBinding.dict

with the following:

/* ~/Library/KeyBindings/DefaultKeyBinding.dict */
{
"^z" = "undo:";
"^x" = "cut:";
"^v" = "paste:";
"^c" = "copy:";
"^a" = "selectAll:";
"\UF729" = "moveToBeginningOfLine:"; /* Home */
"\UF72B" = "moveToEndOfLine:"; /* End */
"\UF72C" = "pageUp:"; /* PageUp */
"\UF72D" = "pageDown:"; /* PageDown */

}

Applications that uses the Cocoa AppKit text edit objects (i.e. TextEdit). However, not every application will necessarily support this. I noticed that Firefox does not which is very annoying.

For more details, http://xahlee.org/emacs/osx_keybinding.html is very useful.

To swap ctrl and command in Firefox/Thunderbird edit ‘ui.key.accelKey’ to 17 (about:config in Firefox, advance config in Thunderbird). Specifically, you can use one of the following:

17 Control (windows style)
18 Alt (unix style)
224 Meta (Mac OS command).

There’s something to be said about Windows being the most used OS on the planet even if it is not the best OS out there. While Unix and it’s variants (BSD, Linux, etc.) are the most developer friendly OS, the sheer number of users for Windows mean that there are a lot of developer that write applications for it. This include programmer’s editors which is a class of software that I’ve always been interested in.

When I started to use OSX, one of the first things I looked for is a good editor. On Windows, the sheer number of choices (and there are many good ones) can be overwhelming. The competition on the Windows world is fierce which has helped to weed out the weak. What I found on OSX was that the most mature editors were the result of Apple using the BSD kernel and thus able run Unix editors such as EMACS or VIM and when it came to advanced IDEs, they were ports from other platforms such as Eclipse.

There are some native-OSX editors such as TextMate (commercial), Smultron (open source) and BBEdit/TextWranger (commercial), but while its users tout how advance they are, they are still behind what is available to Windows programmers. Features such as pretty printing, snipplets, split-screen views of files, etc. are either non-existence or just starting to get introduced to the Mac world even though they’ve been there since the days of DOS. It can be argued that those feature aren’t needed and I’ll admit that a lot of features I only use once-in-a-while. However, the decades of work that has been put into them has allowed them to be part of editors without being intrusive and when I need them they are there.

As a Windows/DOS and Linux user, I’ve been spoiled by these features and it surprises me that Mac developers not only do not have these, but that they don’t even know they exist.

For those interested:

DOS

#1 Brief

Windows

Editors:

#1 Visual Slickedit (commercial)
#2 UltraEdit (commercial)
Notepad++ (free — I’d rank it #1 free editor)

IDE:

#1 Visual Slickedit (as a general purpose IDE)
#2 Microsoft Visual Studio (Linking to the free “Express” edition)
#3 Eclipse

Unix

Emacs
VIM
Eclipse (IDE)

OSX

I’m not sure yet… I’m going to give Smultron a try and I’ve been using TextMate on-and-off at work.

Eclipse IDE