VIM is a powerful command-line text editor usually a default package in the majority of *nix distros (that includes Mac’s OS X). I believe there are ports available for other OSes, even winblows.

Firstly, vim is a man’s editor. Whiners and GUI lovers can stop reading now. Although, VIM offer GUI ports such as MacVim. Men with thick beards, please stay tuned.

The lightweight text-editor VS bloated IDE debate

It’s a matter of preference really. Some like to use IDEs such as Zend Studio for Eclipse, Eclipse PDT, phpeclipse, Komodo ActiveState, Dreamweaver (*oh dear*) etc. And some prefer lightweight editors such as Coda, Textmate, Notepad++, Textpad, GNU Nano, Emacs, Vi, VIM etc.

I use both Eclipse PDT (just installed version 2.0) and VIM 7.x. Lightweight editors and IDEs are powerful in their own right. I’m not going to argue that you should use one over the other. Use whatever works for you. This is not an evangelism post.

Some say the following about VIM

“vim is for people who like pain – I’ll know what to order at your bachelor’s party” – @donaldza

“#vim is great for scripts, configs etc but let’s be honest, this is the 21st century I still use it for merging/diff” – @donaldza

Okay, maybe just @donaldza has an issue the rest of us continuing reading

What VIM offers programmers (sysadmins too) in general

• powerful linguistic interface (ie. command-driven so your fingers never need to leave the keyboard)
• syntax highlighting
• so lightweight you can edit files over SSH connections on a distant remote server
• available on just about any *nix
• blah blah yada yada

Straight into the good stuff: Tips for PHP programmers

Assuming you’re already familiar with the basic editing features of such as copying, pasting, yanking, deleting and so forth. If not, try “vimtutor” from your *nix command-line.

This is a copy-paste of my .vimrc file. You can find yours in $HOME/.vimrc. If VIM is already open you can use the “:edit $MYVIMRC” command. I wouldn’t mess with the system-wide default (usually /etc/vimrc/vimrc). Other vim users on your server might not appreciate your preferences

Syntax highlighting. You gotta switch it on like this:


syntax on


Usually triggered by the file extensions you’re using. This list of extensions is configurable so you can highlight your .inc’s too. That’s an old habit you should toss btw. You might wanna change your terminal colour theme. White background works best with syntax highlighting. Then again you could also change VIMs colour theme.

Search highlighting.

set hlsearch

Includes simple and regex searches within VIM

Tabs as spaces.

Often you want X spaces instead of a real tab

set tabstop=4

Starting to get cool…

set autoindent

Autoindent remembers the indentation of the previous line and so your next line starts directly beneath. Python okes should appreciate this one

In the middle of a series of keystrokes?

set showcmd

Often vim has double-barreled commands that require a sequence of more than one keystroke. Showcmd displays on the footer of your screen informing you which command you have initiated

Search and show matches as you type

set incsearch

In the middle of issuing your full search phrase incsearch will highlight matched words. Useful when constructing a long-ish regex

PHP-specific highlighting

The general syntax highlighting offers some php syntax but not everything

" highlights interpolated variables in sql strings and does sql-syntax highlighting. yay

autocmd FileType php let php_sql_query=1

" does exactly that. highlights html inside of php strings

autocmd FileType php let php_htmlInStrings=1

" discourages use oh short tags. c'mon its deprecated remember

autocmd FileType php let php_noShortTags=1

" automagically folds functions & methods. this is getting IDE-like isn't it?

autocmd FileType php let php_folding=1

Note: This is just the beginning of code-folding. A number keystroke combinations exist to expand, contract foldings within the opened file

Syntax checking within VIM (sort of)

" set "make" command when editing php files

set makeprg=php\ -l\ %

set errorformat=%m\ in\ %f\ on\ line\ %l

To use, simply issue “:make %” command inside of VIM to check the syntax of your php against the interpreter. Syntax highlighting can only do so much

Highlighting matching brackets/parentheses

" set auto-highlighting of matching brackets for php only

autocmd FileType php DoMatchParen

autocmd FileType php hi MatchParen ctermbg=blue guibg=lightblue

This automatically highlights brackets and parentheses as the cursor passes over them. Colours configurable

Auto-completion of functions and constants

" autocomplete funcs and identifiers for languages

autocmd FileType python set omnifunc=pythoncomplete#Complete

autocmd FileType javascript set omnifunc=javascriptcomplete#CompleteJS

autocmd FileType html set omnifunc=htmlcomplete#CompleteTags

autocmd FileType css set omnifunc=csscomplete#CompleteCSS

autocmd FileType xml set omnifunc=xmlcomplete#CompleteTags

autocmd FileType php set omnifunc=phpcomplete#CompletePHP

autocmd FileType c set omnifunc=ccomplete#Complete

The above is really auto-completion for more than just PHP as you can tell. Auto-complete is triggered in the middle of typing the identifier

” Basically, while in insert mode, you can type <C-x> <C-o> to have vim attempt to autocomplete the current keyword. If more than one possibility exists, it shows a dropdown, and you can use your arrow keys to highlight the keyword that you wish to use.

But it gets better! Not only does it do this kind of autocompletion, but it also opens a small ‘scratch preview’ pane showing the function/method signature — i.e., the expected arguments and return value! ” – Matthew Weier O’ Phinney

Auto change to to editing file’s cwd


" auto switch to folder where editing file


autocmd BufEnter * cd %:p:h


Often one would open a file for editing in VIM from a different working directory eg. vim ~/somewhere_else/myfile.php. This command automagically changes vim’s current working directory to that of the file you’ve opened making it easy to open other files which are close by on the filesystem

Split-panes

Often you want to edit more than one file inside of VIM without having to open and close between them. Using “:split otherfile.php” and “:vsplit otherfile2.php” you can create horizontal and vertical split-panes respectively. You can of course split the same file across two-panes simultaneously using “:split %”

You can split splitted panes to infinity but…

Tabbed-panes are better

With the “:tabnew filename.php” or just “:tabnew” commands you have tabbed panes. voila! “:tabclose”, “:tabprev”, “:tabnext” does exactly what one would expect

You can also use keystrokes such as “gt” to jump between tabs quickly. Of course there are dozens more in-editor commands and keystrokes associated with the above tips/preferences. This post was merely meant to open your eyes to a whole new world of powerful lightweight text-editing. You can find a whole lot more in the resource links that follow and vim help! (“:help”)

More cool vim stuff

• http://linuxhelp.blogspot.com/2006/09/visual-walk-through-of-couple-of-new.html
• http://www.scribd.com/doc/263139/VIM-for-PHP-Programmers
• http://weierophinney.net/matthew/archives/123-Vim-7-code-completion.html

Stupid bug reports? They exist. See Scott McVicar’s blog post. He’s clearly had enough of truly idiotic “bug reports” and down-right silly feature requests for the PHP Project.

http://www.macvicar.net/blog/2009/02/stupid-bug-reports.html

Entertaining stuff. And this post wouldn’t be complete without my 2 cents…

In Scott’s post its clear he is dealing with a bunch of oddball users but as developers we often assume (without hesitation) that a bug report is superflous. Dumb users. Problem between keyboard and chair. I once had this attitude but sooned learned that if there really is a bug you’ll soon look like a sausage for not taking responsibilty for it. All software has bugs at some point in its lifetime. Can any developer honestly say that they’ve never released a bug-free program? Highly unlikely

So then, my personal approach (yes, personal) to a bug report that lands in my inbox: When you’re required to investigate a bug, do it with utmost sincerity. Give the user the benefit of the doubt. Go out of your way to prove they’re right. Brainstorm all possible causes for the buggy program output. You might learn something. Communicating via e-mail or bug-tracking tools is efficient but it lacks the personal touch. Don’t get me wrong you need these tools but if you’re able to call your user or meet with them that would be even better. This is the best approach to walk through the steps required to recreate the buggy event and/or program output. It saves a lot of to and fro.

It takes balls to tell the geeky developers of a certain software product “Erm, I think you guys made a mistake”. And equally so it takes great humility to accept responsibility for bugs. Programmers you are human. You make mistakes. Admit it sooner rather than later. Drop the ego. Investigate the bug with sincere determination. If its a bug… well fix it! Report back to the bug reporter (in full). Give them regular updates on progress. Be open and transparent.

Important: always give them praise for coming forward. They’ll love you for it. Whether it was a real bug or really a human mistake on their part. Either way, somebody is going to blush or feel a bit silly. Thats life.

<?=  $sHelloWorld ?>

thats all