Robert Webb wrote:
> > > Five issues with omni-completion.
> > >
> > > (1) How about adding an option to 'complete' to use omni-search?
> > > That way ^P and ^N can be used for everything. If omni worked
> > > well, then I'd probably put it first in the list, even before ".".
> >
> > Unfortunately that's very complicated, because, in general, omni
> > completion doesn't use the same pattern before the cursor. Thus it
> > could change a different part of the already typed text.
>
> Pity. I'd really like to not think about how I want the word
> completed, and avoid two keystrokes.
>
> How about this idea. When 'o' is present in 'complete',
> omni-completion is used if "." or "->" is found before the identifier,
> otherwise a normal completion is done. So if omni is used, then other
> completion types are not done. This is actually even better I think
> as we should know what matches are possible in these cases.
This has a chicken-egg problem: You can't reliably know if there is
something to omni-complete without doing it. "." and "->" only work for
C, other languages may work completely different. And even for C, when
omni completion doesn't find anything I want local completion (e.g., to
find a word in a comment).
Anyway, I often want to chose between using omni-complete or not. With
that 'o' in 'complete' that would not work.
> The problem I guess is that what I just said was C-specific. The
> ftplugin scripts would probably have to dictate somehow whether to use
> omni-completion or not. That is, if they recognise the context, they
> should take control, otherwise they let vim do its usual thing. Is
> there some existing mechanism in ftplugins that makes this doable?
>
> Btw, just noticed that omni-completion also doesn't work if there's a
> space between the "->" and the identifier. This will turn up
> sometimes. Ideally whitespace should be skipped, even if it means
> going back to a previous line.
This is to force people to write nice C code like I do. :-)
It's very well possible that the space was inserted to avoid including
that "->" in the completion, something unfinished.
> > You need to use the C style declaration, since omni completion works
> > for C
> >
> > struct Blah
> > {
> > float blab;
> > };
> > main()
> > {
> > struct Blah *b;
> > b->bl <---- Cursor at end of this line.
> > }
>
> Ah, OK, thanks. I think most C compilers would accept "Blah *b"
> by the way, without the preceding "struct", but I notice that doesn't
> work.
I don't think that is official C code (C99 perhaps, but I don't like
that standard anyway).
> > > (4) Actually since I have other files here too, it wasn't the only
> > > completion, but it was interesting that the "Blah" completion came
> > > last in the list. Why? Would be great if completions from the
> > > current file were listed first, followed by completions from other
> > > files with same name but different extension (usually header
> > > files), followed by matches from any other files.
> >
> > The completions are listed alphabetically sorted. I'm not sure if
> > using another method is that much better, there would be a jump from
> > "static" to global matches at some point, that might come unexpected
> > if you thought it was alphabetical.
>
> Ideally you want to get the matches in the order from most to least
> likely (likely to be the one you want, that is). Alphabetical is
> irrelevant here. Matches from the current file are by far most
> likely, then matches from the matching header file, then from other
> files. If you are using completion to search through more than about
> 20 matches, then likely you will cancel and just type in the word
> manually as it's really not saving you any time.
I don't agree. What is "most likely" is hard to decide, it depends on
what you are doing. It's not unusual to use lots of library functions
and only a few local things. And for the local things (e.g., variable
names) non-omni completion often works better (they are not in the tags
file).
Also, when using the longest match alphabetical is probably better.
> Normal completion with ^P/^N is not alphabetical. It is in order of
> proximity within the file.
Yes, and that's quite arbitrary for words that are further away. But
it's good to have this for words very close, ones that you can see.
> If you think alphabetical might be a useful alternative, then it could
> be an option in 'completeopt'.
Ah, yes, a chance for another option!
> > You can remove "preview" from 'completeopt'. It's there by default,
> > because it's easy to remove, while it's hard to discover that this
> > possiblity exists.
>
> It's also hard to discover what it is and how to get rid of it, and as
> I said, it just shows info that was already shown on the completion
> menu anyway. I find it odd that it hangs around after the completion
> is finished too.
That's so that you can see function arguments while you are typing them.
--
A)bort, R)etry, P)lease don't bother me again
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
