Buffer refactor #535
Open
Buffer refactor #535
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
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.
|
I've been using this branch for a few days with no problem. Today, switching a tab, Xcode died and blamed XVim. I was switching from a tab with a comparison view to a tab with a regular editor. I did the same operation after restarting Xcode and everything worked. I'm posting it just in case it helps to spot something wrong, but this doesn't look like something that I would be able to recreate. |
JugglerShu
force-pushed
the
develop
branch
2 times, most recently
from
dd0deb9
to
125c207
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a massive refactor, which brings with it several nifty features:
It has stability improvements all over the board, fixes for end-of-line motions, ...