Bram,
> > The example below is quite long, but I think it all comes down to
> > the "bunload" command.
>
> Vim never writes unless you tell it to. You must have an
> autocommand that does this or the 'autowrite' option is on.
I have 'autowrite' set, but didn't expect it to apply to :bunload.
Turns out it doesn't anyway, and it was the :b line causing the file
to be written (I also have nohidden).
The docs for 'autowrite' don't say that it applies to :b though.
It does seem to apply to :b, but should it? Or should this command be
considered more like :e, to which 'autowrite' doesn't apply?
Maybe there's no bug here, but the changed behaviour can cause a
script that worked in 6.3 to overwrite files unexpectedly in 7.0.
> > During insert-mode completion, is it useful to see all those
> > filenames go flashing past at the bottom of the screen? I find it
> > distracting, and too fast to be of any use anyway...
>
> Has always been like this.
Not really. It didn't used to search through other files until the
matches from the current file were exhausted. At that point you
probably wanted to see that it was busy doing something, but while you
are still getting matches from the current file, you don't need to
know that it's also looking ahead in case you exhaust them. You also
don't want to lose responsiveness when matches from the current file
may be all you need.
> I think the method used for ":vimgrep" is better: show the current
> file every second or so. So you know it's doing something but don't
> get all the names that flash by too fast to read.
Once matches from the current file are exhausted, the user may want to
see that vim is busy doing something, but until then it's just
distracting.
> > I also find that the menu doesn't always operate well until all
> > matches have been found. Seems to happen when I ^N/^P past the
> > top or bottom of the current menu list and then try going the
> > other way again to get back onto the list. It often seems to get
> > stuck on the second item, but then works properly once the search
> > is complete (which could be a while). Anyone else notice this?
>
> Depends on what Vim is searching for. The most used search
> mechanisms check for a typed key very often, but some of them only
> do this when finished. Then the response is slow if searching is
> taking a long time.
I don't think that's it. It gets stuck even while file names are
whizzing past still. I'm sure there'd be a check for a typed key
between files at least.
It seems to go like this:
- Hit ^P repeatedly and matches are returned working up from the
bottom of the menu.
- Hit ^N repeatedly and matches are returned working back down the
menu.
- One more ^N past the bottom returns the original text. Everything
is as expected so far (and as it was in 6.3).
- Another ^N and it gets stuck. It should return the top menu item.
Any further ^N's now do nothing.
- Hitting ^P after this brings us to the FIRST menu item. Huh?
- Further ^N/^P seem to remain stuck to the first two items on the
menu. ^N will go from the top menu item to the second, but no
further. ^P will go from the second back to the top, but no
further.
- Other combinations lead to other weird results, like getting stuck
at the top menu item then jumping to the second last item.
All the time file names are flashing past and I think the keys are
being read, just not interpreted properly for some reason.
I'm not sure whether all matches from the current file are still
returned first, as used to be the case, regardless of ^N/^P order.
Now it seems if the search completes you may head off into matches
from other files first.
> > 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).
Vim would need to ask the omni stuff whether it recognises the current
situation as something it can specifically handle. For C that means
an identifier followed by "." or "->" is found before the text to be
completed. Elsewhere omni would normally just complete tags, but in
that case the omni code should say that it doesn't specifically know
what to do, allowing vim to do its normal completion.
> Anyway, I often want to chose between using omni-complete or not.
> With that 'o' in 'complete' that would not work.
Do you ever want to choose immediately after "->"? Very rarely. Omni
should know what it's doing in that case. In a general case then yes
you probably want to avoid omni, but then ^P/^N should act the old way
in that case anyway, which is the whole point.
> > 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).
That's a bit harsh! Seems to be that it doesn't hurt to support this.
It's certainly standard C++ if not C. I much prefer this style of
coding to always doing "typedef struct Blah {...} Blah;".
> 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.
Still seems like it would be nicer to me for the local things to be
grouped together first, then the library functions. Typcially there
are many more library functions than local things, so you expect to
look through a lot of matches to find a library function, but not for
something local.
> And for the local things (e.g., variable names) non-omni completion
> often works better (they are not in the tags file).
Omni-completion is only really useful after "." or "->", since at
other times it is only completing tag names. Still makes sense to
look at members of local classes before global ones.
> Also, when using the longest match alphabetical is probably better.
Not sure what you mean here. Are you referring to the "longest"
option of 'completeopt'? Doesn't that just insert the longest common
part from all matches? Ordering doesn't affect this at all.
> > 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.
I've always found it very useful. It's like a move-to-the-front list,
where items are returned in the order of most recent use. Even if the
match comes from 200 lines away, it's probably more likely than one
from 2000 lines away.
Thanks,
Rob.
--
Robert Webb <[EMAIL PROTECTED]>,
Want to make polyhedra?
http://www.software3d.com/Stella.html
