> > Another issue: it's a bit disconcerting that during insert-mode
> > completion the cursor goes to the end of the line rather than
> > staying in correct cursor position. I am talking about before the
> > menu appears and millions of file names are speeding past on the
> > status line. I'm using gvim on Win2000.
>
> In what situation does this happen? In the console and with GTK I
> don't see the cursor at all.
I tried it again, and now I can't see the cursor either! I'm on
Win2000. It was definitely there when I tried it before. Sorry, I
don't know what's different.
> > (2) Scroll windowA so that some of the space past the end of the
> > file is visible as "~" lines. Now use ^W+ or ^W- in either window
> > and the text in windowA jumps so that the last line is at the
> > bottom of the window (if you do it in windowA), or the second-last
> > line is at the bottom of the window (if you do it in windowB).
> > This scrolling is distracting and annoying. If I deliberately
> > scroll to show some lines past the end of the file, then the
> > window should stay scrolled that way until I choose otherwise.
> >
> > Neither behaviour was present in 6.3
>
> This was done to avoid that text goes to above the window, while
> there are (useless) ~ lines still displayed.
I often find myself deliberately leaving "~" lines at the end. Seeing
at least one gives me visual confirmation that I am in fact on the
last line of the file, but I think it's more aesthetic, about what
part of the screen the main text of interest is on. Sometimes I am
also lining up text from one window with another.
> It does a bit too much though, now the text scrolls down. I'll see
> if that can be avoided... This patch should help:
Thanks. Yes, when the window gets bigger the text should not scroll
down. But also when it gets smaller, the text should not suddenly
jump by lots of lines. If "~" lines are considered less important
than others (a reasonable decision :-)), then they should start
disappearing first, but not all at once when the window only shrunk by
one line.
> > 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.
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.
> 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.
> (a C++ version is being made, see www.vim.org in the scripts
> section):
Excellent, I'll try it out. Thanks.
> I can make the C completion use "class" just like "struct", that
> should complete a few more things, even though it still won't work
> in many situations. See the simple patch below.
Good idea.
> > (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.
Normal completion with ^P/^N is not alphabetical. It is in order of
proximity within the file.
If you think alphabetical might be a useful alternative, then it could
be an option in 'completeopt'.
> 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.
Thanks,
Rob.
--
Robert Webb <[EMAIL PROTECTED]>,
MineSweeper3D - Take Minesweeper to a whole new dimension!
http://www.software3d.com/Mines3D
