Consider merging two project

[WarWithinMe]

Hi there. I should have send you an email instead of making a new issue :)

Well, I launched a xvim project a while ago. Feel free to go ahead and have a look...

What I'm thinking is that, we are almost doing the same thing, why not merging our projects into one instead of wasting time to achieve the same thing.

Tell me about your thoughts.

Regards..

[JugglerShu]

Hi, Thanks for the comment.

Yea, I noticed that there is a similar plugin after I released 1st version of my XVim...(And the name is almost the same).

The current main difference between my XVim and your xVim is followings ( if my understanding is right)

• xVim is SIMBL plugin and its target is not only XCode but also other editors. (XVim is targeted to only XCode)
• The main goal of xVim is to provide Vim keybindings to Text Editor. (XVim is trying to implement not only key bindings but commands like ":w" or "/","?" and so on)

My current goal is really simple."Make XCode enough confortable for Vim users" So I would like to implement more ex-commands and buffer switching(which will be switching tabs in XCode).

So.... if its still possible to support these things while we support other editors it would be really good idea to merge two projects. Or we can share some basic vim concept as base project and use them in each plugin implementation.

Anyway we should keep discussing how we can cooperate each other.

Let me know your thoughts about this.

Regards,

[WarWithinMe]

Actually, I was also consider implementing command mode and search mode. But it's pretty hard when you are alone to do so.

The reason why I choose SIMBL to support applications other than Xcode is that I think almost 90% of the functionality will work across apps. Only some will be app specific, like :w ...

When I'm working on my project, Xcode is the first-class citizen. Which means the functionality would be available for Xcode first.

The only thing we have to do is try to make it extensible, which shouldn't be very complex. In this way we can easily make support for other app if we want. It's perfectly OK to leave the feature un-implemented for other apps. Since we can't really support all of them, can we? (To tell the truth, I'm feeling a little bit regret to say that xVim will support the other apps, especially after SublimeText2 is out).

If you want to focus on making Xcode good enough for vim-er. You can still tell people that it's Xcode specific plugin, I'm OK with that. Just consider making it extensible.

[JugglerShu]

Yea, that is good idea to make it extensible to other apps. At least we can share the most of the current implementation of Vim operations.

But, where should we start? Do you have any idea already?

If so let me know. If not, let's think the design of the extensible vim plugin component.( I think we can take several approach for this)

[mike-hoegeman]

just some comments as a xVim "user". i chose to use xVim because it has the command mode line. i'm not all that interested in it supporting anything except Xcode (at the moment anyways) personally. i can see the "coolness factor" of allowing that but i wonder how much it will actually get used. if xVIm had the "." command and the s// search and replace command mode functionality i'd be reasonably happy with it as is. there some quirkyness in the fact that the xcode text editor machinery seems to like to treat newlines as "first class citizens" whereas vi keeps them mostly out of the way. that's kind of annoying but i can live with it.

[WarWithinMe]

@mike-hoegeman Well, my point is, with a little effort (almost just writing some string in the info.plist), many of the functionalities can be available in other apps. I'm not saying making the command line should appear in every other apps, since it's not necessary. But making hjkl available in other apps is helpful, since sometimes, we might need another editor to do our jobs. BTW, if you have already try my version, you will notice that I have kinda overcomed the 'newlines quirkyness'.

@JugglerShu こんにちは. It think is easy to identify which functionality is application specific. We can just put all those specific functionality into one place/class. The rest is to wait for somebody to subclass it and override the implementation. As I'm thinking stopping my project, since I'm now a web-developer... =, =... I will port all of the functionality that I've done to yours. I will fork yours and make some pull request. In the meantime, I think you should avoid implementing what I have done in my project (checks the wiki pages in my), so that we won't make the same thing twice.

[JugglerShu]

@WarWithinMe OK. I will be really good that you can port the impl to our code. I think the most valuable thing which can be ported is the "correct navigations". Current navigations implemented in "XVimTextObjectEvaluator" is a kind of lazy implementations. Some of them are the just reuse of XCode behavior or some are just not implemented.

Let me know if you have any question about the design of my XVim.

Thanks!

[WarWithinMe]

Well, I find XVimEvaluator is kinda 'messy'. I can't make it clear which inherits which. It would be great if the hierarchy is described with some comments.

[mike-hoegeman]

i don't have anything against any of that. sorry if it sounded like i did. i don't know that much about SIMBL. it would be nice if you didn't have to use SIMBL to load if you didn't want to. but i don't have any compeling arguments for saying that other having one less thing to complicate matters is sometimes nice.

good to hear that you have some stuff to work around the newline differences.i was going to look at some of that but if your stuff has that worked out that sounds nice.

On Sat, Feb 25, 2012 at 9:38 PM, WarWithinMe reply@reply.github.com wrote:

@mike-hoegeman Well, my point is, with a little effort (almost just writing some string in the info.plist), many of the functionalities can be available in other apps. I'm not saying making the command line should appear in every other apps, since it's not necessary. But making hjkl available in other apps is helpful, since sometimes, we might need another editor to do our jobs. BTW, if you have already try my version, you will notice that I have kinda overcomed the 'newlines quirkyness'.

@JugglerShu こんにちは. It think is easy to identify which functionality is application specific. We can just put all those specific functionality into one place/class. The rest is to wait for somebody to subclass it and override the implementation. As I'm thinking stopping my project, since I'm now a web-developer... =, =... I will port all of the functionality that I've done to yours. I will fork yours and make some pull request. In the meantime, I think you should avoid implementing what I have done in my project (checks the wiki pages in my), so that we won't make the same thing twice.

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/10#issuecomment-4178912

[mike-hoegeman]

i found that to be the case also.

On Sat, Feb 25, 2012 at 11:31 PM, WarWithinMe reply@reply.github.com wrote:

Well, I find XVimEvaluator is kinda 'messy'. I can't make it clear which inherits which. It would be great if the hierarchy is described with some comments.

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/10#issuecomment-4179347

[WarWithinMe]

One thing important is.. The new line... Mac use 'CR' only. It would be painful if we also support the 'CR/LF' and 'LF'...

[mike-hoegeman]

i think you mean mac osx uses "newline" \n line endings only (like most unixes do. and not carriage/linefeed line endings \r\n (like windows does)

the old mac os versions (prior to the darwin flavored ones) used a single \r for line endings

there's the "end of line NSCharacterSet" that i used in some the of the patches that i did that avoids hardcoding the end of line characters stuff but i can see how sometimes it's easier to assume a single well known character. if you do want to make that assumption it might be nice to use a DEFINE like XVIM_EOL so that if some brave soul wants to go in later and fix it to support multichar EOLS it will be a little easier. This would only apply for where you want to use the editor in a non xcode (and non mac osx source code) application and even then it's not obvious where that would be i guess ..

[JugglerShu]

yea I have been worry about it Ill write some comment and make the code clean as soon as possible

Sent from my Android phone with K-9. Please excuse my brevity.

mike-hoegeman reply@reply.github.com wrote:

i found that to be the case also.

On Sat, Feb 25, 2012 at 11:31 PM, WarWithinMe reply@reply.github.com wrote:

Well, I find XVimEvaluator is kinda 'messy'. I can't make it clear which inherits which. It would be great if the hierarchy is described with some comments.

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/10#issuecomment-4179347

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/10#issuecomment-4179353

[WarWithinMe]

@mike-hoegeman Well for now, \r and \n is consider a newline, so using only \r or \n should work fine. I won't consider \r\n anymore...

[JugglerShu]

Just for easy description( Ill write document later) Here's a hierarchy of evaluators and easy explanation.

XVimEvaluator - Evaluator base
   |- XVimNumericEvaluator - Handles numeric input
      |- XVimTextObject - Handles motions (As I commented in the code, the name is not really proper)
            |- XVimNormalEvaluator - Handle normal mode. If XVimTextObject handled motion, this evaluator just move the cursor to the end point of the motion.

And Most of the command which takes "Motion" as argument they are derived from XVimTextObject.

XVimTextObject
   |- XVimVisualEvaluator - Handles Visual mode (Move cursor as per motion and expand the selection)
   |- XVimDeleteEvaluator - Handles 'd' command.

... And so on.

An evaluator which takes argument to determine the motion ( like 'f' ) I'm currently implementing another structure. (Current implementation of XVimSearchLine evaluator can not be used from like 'd' command )

I hope this helps you guys.

Thanks.

[JugglerShu]

@WarWithinMe

I looked at your merging of 'xVim' to 'XVim' and I found that its a little too big changes for me to merge it to my own repo soon. As you already know, the current code base is not well written and need a kind of refactoring. Merging you code may make the refactoring more difficult.

I'm not saying that merging your code is bad. I would like to, but I want to keep it controllable. So I will merge your code a little by little. Of course you can keep merging and developing it in your own repo.

Let me know if I'm saying something not practical as per open source developing best practice. I really do not know how I should handle this kind of thing...

Thanks.

[WarWithinMe]

No, you are doing it wrong way... I've fork your project as 'XVim-1' in my account and have made some commits to it.

For now, all you need to do is to refactor your code or implement those functionality you want. (Still, it's best to avoid those I've done, since I'll port mine to yours).

When I thought my forked project reaches a stable state, I'll pull all the commits from your project, merge them, and make a pull request for you. At that time, you should pull from my forked project and everything will work fine.

[WarWithinMe]

That's to say when your repo and mine have both reached to a fairly stable state (no more big refactoring), I'll adapt all of my commits to yours, avoiding breaking the structure... Until then, you can think of my fork as unmergeable.

[JugglerShu]

OK. Thanks. Anyway I keep developing it.

[JugglerShu]

I haven't caught up the discussion about newlines. What we should use as a newline in Mac? I found that [NSCharacterSet newlineCharacterSet] can be used to find newline... ( Is this what you guys are talking about?)

I used it in XVimSearchLineEvaluator like

[source rangeOfCharacterFromSet:[NSCharacterSet newlineCharacterSet] options:NSBackwardsSearch range:NSMakeRange(0, original.location)]

Is this fine?

To make this issue clear I'll make another issue.

[tomlu]

I'm spring cleaning the issues, this seems like we could close it.

[JugglerShu]

OK. But I still have some intension to make it independent from XCode. Its not right now so I'll make the issue then.