Omnicompletion

[vgrichina]

I think vico's completion mechanism can be much improved from the current state. I think at least the following can be added without too big effort:

• settings in which buffers to search based on vim "complete" option
• completion using ctags
• pluggable completion for different languages

I plan to implement at least some of the above and to submit pull request, however I'd like to get feedback beforehand on general approach.

As I understand I need to add some command to ViTextView-vi_commands.m, e.g. complete_omni similar to complete_keyword. Then I can map it to <c-x><c-o> in keys.nu. For the completion itself I'd have to implement ViOmniCompletion class analogous to ViWordCompletion.

So basically most of the stuff will have to be done in Objective-C and by editing Vico source itself. However maybe I mistake and this can be done just by writing in Nu and making custom bundle, etc.? I'm open to suggestions on which approach I should take.

[Shadowfiend]

I think it's viable to do a first pass in Nu and then convert the slow parts to Objective-C as needed. Since you can see the Objective-C source, you can access anything that's in Vico's runtime from Nu, as long as you're not dealing in const char *s and such.

[vgrichina]

@Shadowfiend I am not sure where do I start with Nu approach though, where do I put my code? Any suggestions on where to start or maybe I need to RTFM?

[Shadowfiend]

I mean, you've already outlined what looks like a pretty solid approach. You can take that approach in Nu just as well as anywhere else. You can access any Vico class by name from Nu, though you may have to (load "Cocoa") to access Cocoa classes. current-text, current-view, and current-window are all shortcuts to various parts of the running application.

The only part you'd have trouble with is adding complete_omni, but you don't need to. You can map <c-x><c-o> directly to a Nu block, and then call into your ViOmniCompletion class (which you can also write in Nu) from there.

[Shadowfiend]

Oh, and sorry, as to where to put your code, I would start off by just putting it in a bundle and evaling it as you go. There are a couple of caveats (like you can't eval an ival block more than once in Nu; but they're also optional), but that's how I've developed my plugins to date.

[jordwalke]

@Shadowfiend would you consider "completion as you type" within the scope of your improvements?

[Shadowfiend]

I think @vgrichina was talking about implementing this, not me. At least not yet. I may get around to this if no one else has sometime soonish as I continue work on vico-ensime. At that point, I may also look into as-you-type completion.

[vgrichina]

@jordow I think its a topic for separate plugin, as I don't like such functionality :) I think once I'm done with my stuff, you can hack something together based on it too.

[jordwalke]

@vgrichina: Have you had time to explore this? I'd like to take a stab at adding the auto-ness to whatever you end up with.

[vgrichina]

@jordow no, haven't come to it yet

[jordwalke]

@vgrichina: I was taking a look at the autocomplete code last night. To make auto-complete-as-you-type possible, it seems I had to make ViCompletionWindow return NO from canBecomeKeyWindow. Then I started by making input_character not only insert the character, but also trigger the completion results by invoking [self presentCompletionsOf.. ]. Does this sound like the right direction in order to achieve AutoComplPop style completions (where the text you type is still inserted into the view, while the completions are automatically shown)?

[Shadowfiend]

This sounds good to me.

[Shadowfiend]

As a side note, #15 implements completion as you type. It'll probably get merged in in the next week or so, as I've been using it and it's generally been performing pretty well.

I'm thinking about implementing some improvements/pluggable completion, omni-completion style.