Inception

Evidently, this is about the movie Inception. Nice film, but some doubts creep onto me.

1. Most troubling is the 'kicks'. Isn't the kicks supposed to be performed from outside the dream? Then why, toward the end, was the 4 people pulled out of the dream by 'kicking' themselves from within the dreams? Like jumping from that building in the last level then waking up in the third without perceiving a fall.
2. Gravity. 'There's no gravity when in a free fall'? Free fall != no gravity. There are two points that support this:
1. In free fall you receive a constant, non-changing force downwards, i.e. the gravity, that accelerates you constantly. The only problem is, it seems the human inner ear can only perceive angular acceleration and the speed of acceleration, or in other words, the speed the acceleration changes. In free fall, there's no acceleration.
2. In the movie, Arthur's free fall resulted in the loss of gravity in the second layer, while this loss of gravity did nothing to the gravity on the third level.
3. Limbo. What happens if you get killed or kill yourself in the limbo? Will you go one further level down or will you leave the limbo? It doesn't get explained either way. If the previous, then why would Cobb tell Saito to come back by killing himself? If the latter, why can't they escape limbo earlier by committing suicide? But then, that part were not in the film, which may actually become a possible thread for a sequel.
4. Subconscious attacks from Fischer? Aren't they supposed to be attacking the dreamer? Then why would they attack the cab that carried Fischer, Arthur, Saito and Eames when non of them is the dreamer? Some training, huh?
5. That 'idea' is the most resilient parasite. Once an idea grabs hold of the mind, it would be impossible to eradicate it? It isn't just about an idea, it's about faith: whether you believe in that idea. If it's just a simple idea, you can always put it off your mind with whatever means; but if you believe in it, well, you won't even bother to eradicate it.
6. Do you dream in a limbo when sleeping? What about that dream?

About possible expansions, speculation over the result of the movie are plenty, but for me, the toppling of that top doesn't seem like the kind of topic to continue on. It was nearly falling, and there really shouldn't be a way for it not to be reality. Instead, there are at least two places that's worth continuing on:

1. A prequel. What happened before this story? How did Cobb and Mal get lost in the limbo? What was that dream that led them to get together? There's lots to say.
2. Saito. How Cobb got to him, and most importantly, how Cobb got Saito back to reality. That sudden shift between the scenes seem like a possible start for another story.

Most wondrous is the way people get lost in limbo, because you simply can't tell the difference between going into a dream and coming out of one, except perhaps that you're drowsy when waking. And, it seems the traditional way of slapping yourself in a dream doesn't work. And it rings a bell, what about explaining the movie 'Groundhog day' with this dreaming? Only that person's entering and leaving the same dream every morning. It's up to the viewer.

Native vim for Android with mbyte and color

[Edit]
I've uploaded the compiled binaries for this version of vim, which can be found at http://cid-0e29e4b9a313ea5b.office.live.com/self.aspx/Releases/Vim%5E_Android%5E_With%5E_Multibyte.zip.Please copy the files to /data/vim (or any directory you can access that's not on the sdcard), set executable by chmod 7777 ./vim, export PATH, then you're good to go. The xxd file is also an executable that enables binary editing, may come handy if you're editing any binary files on android (discouraged).

I came across credentialitiy's 'Native Vim for Android' the other day, and it immediately solved my problem of wanting to program on Android with a powerful enough editor - Text Edit simply won't do. Here I'd like to first express my gratitude to credentiality for his excellent job on compiling Vim for Android in the first place.

But then nearly immediately, I found several problems: there's no color, either the environment color set using ":color somecolorname" command or syntax-highlighting; then, the jog-ball doesn't work.
If you're wondering if it's the problem of the terminal emulator, be assured that it isn't, as the 'ls' command that comes with busybox does show coloring on my terminal, while a version of bash compiled for Android accepts job-ball directional commands perfectly happily. And that troubled me for some while, till some extensive searches led me to a thread on LinuxQuestions.Org: http://www.linuxquestions.org/questions/aix-43/no-colors-in-vim-on-command-line-442695/. It turned out to be the setting of the 'TERM' environment variable and some initializations required by Vim to display colors in the terminal.
As it happened, it isn't the problem of just Android, it happened on other platforms too. So I added the lines of code to my vimrc, then it just worked!
Later on, I discovered that it is actually documented in vim. Just type ':help syntax' and scroll to the bottom of that help page.

Then problems arose about the mbyte support of that vim. I was quite astonished that it did have the 'encoding' setting, or the 'fileencoding' setting. Apparently, mbyte support wasn't compiled in. So I set out to compile one with that turned on.

It did take me some time to compile my first vim for android, and there was a mistake that bothered me for nearly an hour. Follow credentiality's instruction at 'Native Vim for Android'  to get your first vim for android compiled. Note that when configuring ncurses for compilation, there's a mistake in the instructions. Change:

CC=agcc ./configure --host=arm-eabi --without-cxx-binding

into:

CC=agcc.pl ./configure --host=arm-eabi --without-cxx-binding
 

After compiling vim, I found the appropriate configuration option in src/configure.in
Reconfigure with the following command:

vim_cv_memcpy_handles_overlap=no \

vim_cv_bcopy_handles_overlap=no \

vim_cv_memmove_handles_overlap=no \

vim_cv_stat_ignores_slash=no \

vim_cv_getcwd_broken=no \

vim_cv_tty_group=world \

vim_cv_terminfo=yes \

LDFLAGS="-L/path/to/ncurses-5.7/lib" \

CFLAGS="-I/path/to/ncurses-5.7/lib" \

vim_cv_toupper_broken=no \

CC=agcc.pl \

./configure --host=arm-eabi --with-tlib=ncurses --enable-multibyte


then patch the header file as instructed in credentiality's blog, and patch the following file:
src/mbyte.c:
Add:

#ifndef __amigaos4__

# define __amigaos4__

#endif




below other #include declarations.

As I figured out, that definition tricks vim into believing that there's no mblen() on the platform, which is true, as multibyte support is always faulty in NDK.

Then you can try it for yourself, it should work with Unicode encodings, I've tested UTF-8, UTF-16LE, but ANSI encodings like cp936 are still not supported. Good enough for me, at least I can now edit Chinese text documents with vim.

Photo (Still haven't figured out how to use the screenshot program):

Note that the photo has been post processed to remove lens distortion.