Which editor are you using, Vim or Emacs? And why?

Next time, when you are arguing with other people about which editor is better and trying to persuade others to use your favorite editor, just forget it. If you believe everything is in destiny, it is not an exception for the editor you choose. The choice is written on your fingers.

Several days ago, I learnt from Mike that the choice between using Vim or Emacs depends on your fingers. As he figured out, people have longer fingers prefer to use Vim, while people have shorter fingers prefer to use Emacs. It is amazing, but reasonable.

Using Vim, the most frequent key you hits might be the “Esc”. Vim has three modes: insert mode, command mode and visual mode. Command mode is the bridge of other two modes, and most of navigating and searching is done in command mode. So, when you are using Vim, you must: press “a” or “i” to start insert mode and input something, then press the “Esc” to enter the command mode and do navigation, then enter the insert mode again and then press the “Esc” to the command mode. Maybe some times you want to hit “v” to enter the visual mode to select something, and after that you must hit the “Esc” again back to the command mode. At most time, you are hitting the “Esc”. That’s why they call Vim “hit Esc to death”. Of course, you also need Ctrl and Shift in vim, but not so often. For example, when you select contents by line or by block, you will press “Shift+v” or “Ctrl+v”. When you want to jump to the end of a line, you will press “$”(Shift+4). But these cases are much rearer than hitting the “Esc”. So, when your fingers are long enough, you will find it very comfortable and easy to hit the “Esc”. Maybe that’s why you like to use Vim.

I have touched Emacs for little times. In Emacs, almost everything except for inputing text are done by “Ctrl+something”, “Shift+something”, “Alt+something”, or even “Ctrl+Alt/Shift+something”. That means at most time, one of your finger must hit “Ctrl”, “Shift” or “Alt”. That’s why they call Emacs “hit Ctrl to death”. Some Emacs fans even want to use pedals to help them hit hot keys. I have to twist my fingers to hit those keys. For some complicated combination of keys, I even don’t know how to hit them comfortably and elegantly. So I gave up Emacs soon to save my hands and fingers. Maybe people who have shorter fingers would fall in love with Emacs because they could hit these hot keys easily without twisting their fingers very much.

Although I prefer Vim, I don’t mean to comment Emacs and Emacs users. Emacs is also powerful, and even more powerful than Vim (at least in my mind). I admire Emacs users very much because they can learn so many hot keys by heart and use them gently and easily.

If you are still confusing about choosing Vim or Emacs, just check your finger. If your fingers are longer than most of your friends, then just choose Vim without hesitate and you will like the life of hitting the “Esc”. If your fingers are shorter than average and you find it’s uncomfortable to hit the “Esc” frequently, then you should definitely choose Emacs.

If you are still arguing with other people about Vim and Emacs, forget it, unless you want to cut some one’s finger to force them to use Emacs or lengthen some one’s finger to force them to use Vim.

If you are jeered by Emacs users for you are using such a disharmonious editor that has multiple confusing modes, you could respond them, “at least I have beautiful long fingers”. If you are sneered by Vim users for you are using such a complicated editor that requires a pedal to handle the hot keys, you could respond them, “at least my memory is better than you, since I could remember thousands of hot keys”.

Most people prefer webmail, especially Gmail. Webmail is very easy to use and does not require much configuration. Gmail is the most wonderful webmail. It groups messages by threads and it has a powerful searching tool. You can easily find out what you want from the mass.

However, one drawback of webmail is that you cannot access your mail off-line. Although Gmail started to support off-line email recently, I still think that keeping the emails in my local storage is safe and reliable. Moreover, an email client is generally much more customizable than webmail. So, I am using Evolution, which is the most powerful and standard email client in Linux, to receive and send email everyday.

As said in the beginning, I want to figure out what email clients my contacts are using. This work is not hard. There might be some fields in the header of email indicating which client this email is generated. The field could be named “X-Mailer”, “X-mailer”, or “User-Agent”. In Evolution, you can open the menu “Edit>Preferences>Mail Preferences>Headers”, and check the “Mailer”. Then you could see the Mailer information in your mails. Some mails are composed without the Mailer information. I don’t know why. We just ignore the mails without Mailer information.

Evolution stores mails in the folder “~/.evolution/mail/local/Inbox.sbd”. Under this folder, the files without extension are the mail files, which included all the contents of your mail. So, we can grab Mailer informations from these files.

First, we can use “grep” to filter the lines containing “X-Mailer”, “X-mailer”, and “User-Agent”. We can store them into a file.

cat mail-box-name | grep X-Mailer > outfile

cat mail-box-name | grep X-mailer >> outfile

cat mail-box-name | grep User-Agent >> outfile

“mail-box-name” is the name of the mail files. Carefully name the outfile. Don’t let it overwrite the existing file. My suggestion is that you can copy all the mail files to another place and do these operations there. It’s safe.

Now we get the outfile containing Mailer information. The next step is removing useless information from this file, such as the header “X-Mailer” or the version information. This is the most boring part. Maybe there are some sophisticated methods which could do this work automatically, but I am lazy to think them up. For me, I use Vim and block-edit the text (ctrl+v, then move cursor), and this work is done without much effort. Now we get the file like this:

…
Moto-EZX
Moto-EZX
Moto-EZX
Mozilla
Mozilla
Mozilla
Mutt
Mutt
…

Then we should count them. Use this command:

uniq -c inputfile > outputfile

Finally we get the file like this:

…
84 Evolution
182 Foxmail
1956 G2/1.0
…

Maybe we need some refinement for these data. For example, remove the very rare entries (e.g < 10), and remove the entries that are obviously web server, such as “ASPMail”, “PHPMail”, etc.

After refinement, there we come to the OpenOffice Spreadsheet for analyzing these data. Again, we use Vim and block-editing to separate the count and client name, and paste them into Spreadsheet individually. Then open “Insert>Chart” and generate your favourite chart.

Following is my data, in which the size of sample is 3003 (after refinement):

From the chart we can see the most popular email client of my contacts is Gmail (G2/1.0). Following are Thunderbird and Foxmail. Then it comes Evolution, Apple Mail, SquirrelMail, Outlook and SFUwebmail.

Which client are you using?

For me, the must-have feathers of a source browsing tool should be:

1. Syntax highlighting
2. Friendly user interface
3. Identifier and function search

If you are a Windows user, you might have heard about Source Insight, which is a non-free software. I haven’t used it, so I am not going to comment it.

For Linux user, the first tool I want to mention is Source Navigator. It is developed and supported by Red hat. It supports C, C++, Java, Tcl, FORTRAN and COBOL. It’s very powerful. But if you just want to browse sources, I don’t recommend you to use it. Since it GUI is developed in Tcl, an ancient programming language, the user interface is not very friendly. I bet you don’t like it.

Another wonderful software is Doxygen. Although it aims to generate documents various programming languages, including C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#, and to some extent D, you can treat it as a source browsing tool. It can generate documents in HTML format. So you can read them via Firefox. If the source code is well commented following JavaDoc’s style, a beautiful documents describing classes, variables, functions could be generated. If the source code is not commented in JavaDoc’s style, the documents could also be generated, but it just have source codes, without these detailed description about classes, variables, and functions. Doxygen can also generate class-graphs, call-graphs and other similar graphs in UML style, which will help you understand the source.

The disadvantage of Doxygen is that its search result is somehow coarse-grained. It cannot distinguish variables from functions in search result. And it cannot differentiate definition, declaration and reference. So, if you are dealing with a huge project, you may find it uncomfortable to read source generated by Doxygen.

The ultimate tool, in my view, is LXR, which stand for Linux Corss Referencer. Specially, it may be the best choice for you to read Linux source code. Although, namely, LXR aim for Linux source code, it suitable for other projects written in C/C++, COBOL, Java, Perl. It is a web based tool and you can read the source code via Firefox. It uses a database to management cross references. So the search result is very accurate. And it can differentiate definition, declaration and reference.

LXR is famous for its difficulty on setup and configuration. And its user interface cannot be called “beautiful”. Luckily, the next generation, LXRng (demo) is available now. LXRng has a very beautiful and friendly user interface.  Moreover, setup and configuration for LXRng is much simpler than LXR. However, it seems that LXRng currently only support C language. If you need it for C++, you need a slight hack:

Locate to your LXRng’s installation directory, then open this file:

lib/LXRng/Lang/C.pm

Find the following code from this file:

sub pathexp {
    return qr/.[ch]$/;
}

And change it into:

sub pathexp {
    return qr/.[ch]$|.cpp$/;
}

Then LXRng should support the C++ files.

Doxygen and LXRng could satisfy most of your requirement. Maybe reading source from Firefox is strange and unfamiliar to you, but I think you will going to like it if you just have a try. If you have no idea about how to use them, just go to their websites, where you can find plenty of documents and toturials.

The wiki I used in my homepage is Dokuwiki. The most great feature is that it does not require database connection. It’s very convenience for personal usage.

I have two Dokuwiki maintained. One is located in localhost, another in the webserver. I always edit the pages on localhost, and synchronize them to the webserver at times. Since Dokuwiki is totally PHP based, without database such as MySQL, I only need to synchronize some files.

All the changes on wiki are reflected on the folder “data” in your Dokuwiki path. So every time, I only need to synchronize this folder.

The best way to communicate with webserver is SSH. Fortunately, my webserver Godaddy support SSH access. Another thing need to concern is synchronizer. Here I use Unison. The best description of Unison comes from it’s the author of this software:

A file-synchronization tool for Unix and Windows
Unison is a file-synchronization tool for Unix and Windows, written
in OCaml. It allows two replicas of a collection of files and
directories to be stored on different hosts (or different disks
on the same host), modified separately, and then brought up to
date by propagating the changes in each replica to the other.

Unison offers several advantages over various synchronization methods
such as CVS, Coda, rsync, Intellisync, etc. Unison can run on and
synchronize between Windows and many UNIX platforms. Unison requires
no root privileges, system access or kernel changes to function. Unison
can synchronize changes to files and directories in both directions,
on the same machine, or across a network using ssh or a direct
socket connection.

Transfers are optimised using a version of the rsync protocol,
making it ideal for slower links. Unison has a clear and precise
specification, and is resilient to failure due to its careful
handling of the replicas and its private structures.

If you are using Ubuntu machine, you can install it from the repository just by one command:

sudo apt-get install unison

There is also a gtk front-end for this software: unison-gtk, but I think it’s useless at most time.

Now, another problem comes to front–in order to synchronize files with SSH, both installations of Unison on client and server are required. However, at most time, you don’t have the permission to install software such as unison on SSH server. Here, we attack this issue by SSHFS. It allows you to mount a remote folder on your machine via SSH.

Everything is OK. I wrote a small script to handle the synchronization:

#!/bin/sh
sshfs -o workaround=rename username@sshserver:/path/html/wiki wiki-remote/
echo "Synchronising with sshserver"
unison /var/www/dokuwiki/data ./wiki-remote/data 
  -fastcheck yes 
  -ignore 'Path cache' 
  -ignore 'Path locks'

Modify it to fit your actual environment. Note that the argument of sshfs command “-o workaround=rename”, this prevents the “renaming problem“.

All things done. Excute this script. Or, you could add an cron job to run this script automatically once per day. Have fun in synchronizing files with SSH!

Oppose with what I thought before, writing a big software is really a kinda art. The most important thing for one to write a good software is the architecture design. And the most important thing for architecture design is requirement analysis. Coding is simple and should not bother a developer so much. Because if you have some technical problem while coding, you can refer the document for the programming language you are using and solve it quickly. But if you find that your design goes all wrong, you must delete almost all your code and do it again. So, a good designer is more important than is good programmer in your team. And things are always that a good designer is a good programmer himself.

And a crucial thing for your team is having a leader. This is always be true in real software developing scenarios, but not as in taking courses. If you have no leader, you will definitely waste much of your time on arguing. Every one thinks that his design is the best. If you have a leader, you can easily determine which architecture you will use and which style of GUI you will draw, and so on. Meanwhile, your leader must be a experienced programmer as well as a experienced designer. He always has a brief view on how could you achieve your goal with the least overhead.

Another import thing is that all of your team members should under each part of your project. Such like the one do GUI must have the knowledge of database, and the one who are implementing background algorithm must know the message observer stuff. Basically they are not related with each other, but I don’t want to hear requests like this again: “can you store the hash map in database table?”.

Besides, all of you should use the same tools, and follow the same coding style. Coding style is very important. We failed in this because there’s no leader forced us to do so. Everybody has his own style, and the only common style for us is that each line ended with a semicolon.

The last thing is about user interface. Never write a dialog-based program like us, unless you are doing a cell-phone program. Dialog-based program is ugly and slow. As Rui said, the program should based on a main-frame which will not be changed often, and many functions can be accessed via menu, what is we lost. Dialog is mainly used when a ‘dialog’ is needed, not everywhere.

Although I will not likely to be a industry programmer, I think it’s useful to have a good skill for software engineering, and maybe it will help me develop systems in the future.

Finally, I will thank my teammates here: Chris(Hopefully not misspell your name here, ), Meng, Ting, Ian, and Jeff!

After 1Y0-259, all those students who are not sure about 70-536 and 1Y0-456, should try for the qualifying exams like 1z0-042 or 642-892 in order to figure out their interests.