regex search on ? and / needs to keep state to move past prev match on next search

[mike-hoegeman]

right now it creeps one character forward for each 'n' you do after the initial search. it needs to start the next search after the the entire match from the previous search.

i have some ideas on how to do this. basically keep a _nextSearchBaseLocation (similar to _lastSearchString) we probably also have to intercept (setSelectedRange) to also participate in maintaining _nextSearchBaseLocation by updating _nextSearchBaseLocation with r.location and then calling [super setSelectedRange r] search{forward/backward} would also update _nextSearchBaseLocation manually after it completed at search

[mike-hoegeman]

i'll can take a stab at this. is a hook into setSelectedRange where the other hooks take place the proper way to get the interpostition to get setSelectedRange overidden ?

[JugglerShu]

@mike-hoegeman Sorry, I can not understand well the english... Is your question "Where the hook should be written?" If so it can be in load method in XVim.m .

Are you trying to hook "setSelectedRange" in NSTextView? If so the hook affects all the NSTextView in XCode. If DVTSourceTextView overrides the method its ok to just hook it as I did in XVim.m. If not we should ADD a method called "setSelectedRange" to DVTSourceTextView.

I want to make my understanding clear. The reason you need to hook this method is when a user moves a cursor manually the _nextSearchBaseLocation should move accodingly. Is this right?

Sorry if my entire understanding is wrong.

[mike-hoegeman]

The reason you need to hook this method is when a user moves a cursor manually the _nextSearchBaseLocation should move accodingly. Is this right?

Yes that's the reason i want to hook DVTSourceTextView , because if the user moves the cursor the next search has to start from that new location. i tried it and it looks like it doing the right thing.

[JugglerShu]

OK now I understand what you are trying to. Hooking is a little tricky way so I want to avoid it if possible.

I found the following protocol. https://developer.apple.com/library/mac/#documentation/cocoa/Reference/NSTextViewDelegate_Protocol/Reference/Reference.html

And they have textViewDidChangeSelection: method. I think we can get this method called when a user move a cursor. Do you think you can use it?

The problem is when XCode is already using the NSTextViewDelegate to be notified something from DVTSourceTextView... We have to forward it to XCode...

[WarWithinMe]

Actually I've been experiment the hooking of the selection from the very beginning back in my project. And after a developer from chocolateapp commits the / and ? seach code to my project, I've make it work like the way MacVim does.

1 We do need to hook the methods of delegate of the DVTSourceTextView. The two methods I hooked is: textViewDidChangeSelection: and textView:willChangeSelectionFromCharacterRanges:toCharacterRanges:

The first one is used to ensure that when we have selection (maybe using mouse to select), we are in the Visual Mode. The second one will do many things, validate the selection (e.g. make sure the caret never place at newline character).

2 I think hooking setSelectedRange will be a headache. We will have two situation when we are doing regex search.

• We are in ex mode and the user keep changing the search regex.
• We are in normal mode or visual mode, the user presses n or N to find next search. In the first case, we log the selection range when we enter the ex mode, and whenever the search regex changes, we do a new search base on the logged selection range. In the second case, we are no longger in ex mode, we will do a search base on the current selection range of the editor.

[mike-hoegeman]

i committed something awaiting pull that seems to work

perhaps my hook into setSelectedRange is not entirely the correct way to update _nextBaseSearchLocation , but the basic scheme in combination with _nextSearchBaseLocation in the xvim object and my updates to searchForward/Backword in the xvim object seems to be working the way i would expect it to. i believe it handles the cases in item 2 correctly. i did some other fixes in searchForward/Backward to make it work moderately close to how vi works. there's an issue with the command text collection trimming off trailing whitespace that is non vi like for ? and / but other than that it's working fairly well. i'll make a new issue for that. i see where it's happening. i'll probably look at it tomorrow.

If there is a superior way for getting the selection/cursor location updates let me know or go ahead and change it if that's easier.