This object will now be the main entry point to manipulate the content of
the textStorage, so that we don't have to extend the NSTextStorage with
categories.

XVimBuffer is now created each time we learn about a new Document that
responds to -textStorage which XCode documents do.

XVimBuffer also knows about the undo manager, and is used to be the target
of the specific vim action we mean to undo, which means that undoing the
cursor positions won't crash anymore (Layout managers and textviews come
and go, and it's not correct to make them the target of an undo
operation).

XVimTextStoring becomes a protocol that you implement when you intend to
give better alternatives than the default implementations from XVimBuffer.

This commit doesn't alter code, it merely moves some around, and adpt
callers.

This makes editing the text-storage faster than going through the view
obviously.

Use this as a proof of concept to reimplement the bulk of xvim_shift
as -[XVimBuffer shiftLines:column:count:right:block:]

The performance that this code reaches now is bluffing compared to the
previous one. It's still not nearly as fast as vim, but it's decent.

Note that the cursor position handling code is still messy, which makes
the number of parameters to that selector properly disgusting, but we're
getting there.

Move them to a proper ivar of the XVimBuffer instead
This is the beginning of moving a lot of stuff there, so that we can
capture the buffer state on undo/redo properly.

As a side effect, this means we now support CRLF properly for this
command, which should help for XVimProject#530

Fix a couple of issues in the XVimBuffer methods that this new code
spotted.

http://www.blackdogfoundry.com/blog/creating-an-xcode4-plugin/ says
-pluginDidLoad: is.

Hooker is really a disgusting hack which uses Hook classes for no good
purposes and does no compile time check.

Let's use this to modify the behavior of (typically) NSTextView and
NSTextStorage if they have xvim_* objects associated with them.

+[XVimView initialize] swizzles NSTextView like we used to do on the DVT
one. Nothing was really DVT speciic in the DVTSourceTextViewHook in the
first place. The swizzling does nothing if there is no XVimView associated
with the NSTextView, or if XVim is disabled.  All that is non specific to
XCode.

Rewrite IDEEditorHook as an IDEEditor+XVim category with swizzling.
In the -didSetupEditor override, detect when there are
DVTSourceTextView's that are the one we know what to do with.

Check their document has a file:// URL (so that the script editor in the
Xcode rules are ignored). If the textStorage happens to already be
created, allocate the XVimBuffer right away.

In theory we would have to check when the document for a given TextView
changes whether we still support XVim, but XCode actually destroys and
recreates the view each time you switch documents, so it doesn't matter.

It's disabled by default because it only make sense for debugging
purposes.

And fix a silly bug with the swizzling category when the class doesn't
override the selector we're swizzling.

it's replaced by XVimView/XVimBuffer.
It's a nice reference of the things to have though.

Do not hardcode XCode path to /Applications/Xcode 2.app, and find the
framework relative the $DEVELOPER_DIR, which will do what's right.

Upgrade warnings for XCode 5

It's been a huge help for development for me.

Fold the Tilde/Lower/Upper (and Rot13) into a single SwapChar evaluator.
Fix various repeat issues with those.

Use it in the normal, visual, GAction and GVisual evaluators as required.

This obviously uses the new undo architecture, hence should be faster

fixes 3r<Right>

This is a huge refactor that makes the code more independant, more
efficient, and acting on XVimView's and XVimBuffer's as much as possible.

In particular, this commit tries not to use any NSTextView methods to
modify the content, which has several important side effects:
- it's more efficient, since we don't go through all the XCode logic to
  handle edits (it's really a waste when we're doing block operationst
  typically), performance for several operations is visibly faster than it
  used to be;
- it's better for the user as this goes below XCode AutoCompletion code,
  and doesn't pop up spurious dialogs when you're in command mode anymore;
- this goes through our Undo logic which allows exact coalescing and
  cursor placement, instead of relying on the Appkit doing the right thing
  before. (and it doesn't for insertion, but we'll get to that at some
  point).

This commit also does tons of cleanups with the selection and movement,
notably fixing behavior when MOTION_END_OF_LINE ($) is used, as this
should be preserved, and wasn't

Note that for now XVimView is still XCode dependant, because I didn't
write a category to swizzle XCode classes, and didn't write a protocol
for the TextView yet. Such a protocol will include anything that is
rendering related, like placeholder handling. Indenting should go to the
NSTextStorage instead, as it's strictly content related.

I wouldn't be surprised there are a couple of regression, crashers, but
the test-suite passes, and I'm living on that patch now.

I had a bug because it's not on by default in XVim and a property was
automatically synthesized because I didn't implement the selector and had
no warning.

And implement all the forwarders all the way down.

Hide some -is* from the NSTextStorage category, move isLastLine as
isIndexOnLastLine on XVimBuffer.

btw it's not 100% correct because gv doesn't quite do the right thing yet.

Should fix XVimProject#533

Those functions are related to position of the index within the line.

This is now:
    -indexOfCharMotion:index:options:
    -indexOfLineMotion:index:column:

Implement _/+/-/$/CR/C_m/... using this.

Also rename and properly namespace MOTION_OPTION as XVimMotionOptions and
the MOPT_ prefix.

When normal-mode replace failed, it used to fail to quit insert mode,
which broke several motions. Make -escapeFromInsert take a boolean to know
whether in addition to quitting INSERT mode, we should also go backwards.

Replace also had an off-by-one that prevented to replace the Last char of
the line (a >= comparison really should be >).

Add a BAR selector to the XVimMotionEvaluator, and a new
MOTION_COLUMN_OF_LINE enum value.

The reason for that is that when undo is generated by XCode it can leave
us in really awkward places.

Example, go to the end of a line, type:

C<ESC>
i.<ESC>
u
<-- at this point, your cursor is on the end-of-line where it shouldn't be
since we're in normal mode.

When the undo are generated by us, this of course never happens (or would
be a bug).

Use the line endings we guess from the first line of the file.
This, really fixes dd for me on CRLF files now.

It also means we support Classic Mac line endings too (CR-ended lines)

Also compute the end-of-line to eat when deleting/yanking at the end
properly.

This should make things better for XVimProject#530

Reduce the number of calls on each keystroke by avoiding the
-selectorForInstance + instanceResponds + ... calls

Avoid using NSStrings to compute the selector, it does malloc()s, a simple
buffer + sel_getUid() is faster

Use the NS*FunctionKey values from Foundation instead of hardcoded values.
And now my XVim stops assert()ing when I use F13 by mistake.

Avoid using self.{modifier,character} but access the ivars directly, it's
faster.

Use iswprint() instead of isPrintable, it's supposed to do what's right...

both sound like a very bad idea, move that stuff to the XVimView where it
belongs. The less we swizzle, the better we are.