I have an LG Optimus, and the touch response is horrid. The phone works well in other areas, but UI responsiveness and text input accuracy aren't among them.
ClearCase is certainly popular, but I don't think it ever had a feature that was a big milestone in version control history. Client side software with a view of the source is already covered in the author's point #4, and ClearCase doesn't do this better than the others (quite the contrary, in my experience).
Clearcase had two new additions: Branching/merging made easy(ier?) and the source code under version control was seen as a file system, a drive letter on your windows system.
Is there a Vim equivalent of Emacs's C-h k followed by the key combo, which basically says, "Tell me what the official command name is for this keystroke?"
I don't know of anything quite like that but the help can be searched by key, though only for the default key combinations, e.g. ":h i^a" would show the docs for the ctrl-a command in insert mode.
Note though that vim really doesn't have commands the same way as emacs does. That's why you generally see assigning one key combination to another instead of some "command name."
As a (mild) counterpoint, I've worked in Win16 code bases that were a nightmare to port to Win32, Win32 code bases that had to be half rewritten to run under the Win32-like API of WinCE, Visual Studio upgrades that broke swaths of MFC/ATL/STL code, and so on. As an end user, I've run apps that were designed for Win95 that choked under NT4, XP that choked under Vista, and so on.
I'm in awe of the backward-compatibility efforts that Raymond Chen and crew have put forth and explained in their blogs. No doubt things could be much worse. But I'm still tired of fighting Windows APIs, both as a developer and as an end user.
Indeed, the ability to work on code now and think about a commit later is freeing. As for the particular abstraction of how to represent the commit in progress... I like the working tree for that, rather than the index. It's just a better mental fit for me to unstage stuff I don't want to commit (via shelve/stash), _rerun unit tests_, do a simple diff without needing to remember the incantation for seeing what's in the index, and commit.
The term "strong" appears overloaded here. A language can be dynamically typed, but still have strong typing (in the sense that the language, whether at compile time or runtime, enforces what operations are allowed on a particular value).
If you use something like Git submodules, Mercurial subrepos, or Subversion externals, you can get the best of both worlds. Your repo contains just your code, but a fresh clone will set up dependencies automatically.
I've also seen really simple projects get by with just an "install_deps" task in the Makefile, which you run first thing on a new clone. ("The simplicity of Maven meets the dependency management of Make," the wags will say.)
Sure, this is a solution. But my confusion remains: why I should't put all these dependencies in the repository with the code that uses them? In the end, doing so I have (almost) all I need to produce the intended software artifact.
There are a few reasons to do this. One is to at least nominally separate code that's licensed differently than yours (something your lawyers may ask you to do). Another is to make it easier to share your tweaks to the third-party code among several of your own projects.
Seconded. AsciiDoc is enough like writing a plain-text e-mail that everything but the writing just falls away.
For a little more control, you can feed the generated DocBook to something like Remko's DocBook kit (https://github.com/remko/docbook-kit), which downloads and runs the various document processors for converting to PDF in stages--with gnarly XML config files available for each stage. This can be helpful for trying to match a specific conference template, for instance.
