Robert Webb wrote:
> > > 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.
I don't see a change between 6.x and 7. In 6.x the ":buffer" command
also caused 'autowrite' to kick in.
> > > 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.
True, previously it would not search in other places until you to type
the CTRL-N that goes past the last match in the buffer. That's also the
reason why this changed, it sometimes postponed the search and sometimes
it was done right away. For the popup menu you want to get all matches
asap.
> > > 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.
Oh, if you go past that point you are asking for the last match. That
won't be there until all the matches have been found. Perhaps
previously it would give you an arbitrary match that happened to be the
last one at the moment.
> - 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.
There is some clever stuff that someone (you may know him :-) made long
ago to handle typeahead while still still searching. Unfortunatly it's
very complex and isn't well explained in the comments. Features added
later will no doubt interfere with what happens there.
I have looked into a complete overhaul of this code, but it is nearly
impossible to keep the mechanism 100% backwards compatible. Thus I only
cleaned it up a little.
I have problems reproducing this, as soon as the search stops it appears
to work properly.
> > > 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.
I don't think this would be consistent. C omni completion also works
fine without "." or "->". And for other languages it coule work more
clever, like using the context to figure out the type needed and only
complete that. Generally this means you need to do the omni completion
to discover if it finds useful matches.
I really see omni completion and traditional Insert mode completion as
two separate things. I want to chose which one to use. I would guess
it is like that for most people.
> > 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.
When I'm working on new code and I just added a struct then I know omni
completion won't find it yet and I'll use CTRL-P after "->". If it's a
struct that has many members I'll type a few characters and then use
omni completion. It's not a "hit a key and nobody knows what will
happen" completion, you need to keep thinking about what you are doing.
> > > 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;".
Overloading makes this very difficult. If Vim sees "Blah a" then it has
no clue that "Blah" is a typedef or anything else. For "struct Blah"
it's clear. Even for humans it's important to know what "Blah" is, thus
I mostly use "Blah_t" if it's a typedef. In these situations more
information == better readable code.
> > 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.
For me omni completion in C code works much faster then CTRL-N, because
it skips all the stuff in comments and strings. And doesn't dig in
include files. With less choices it's easier to pick the one I want.
> > 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.
Ordering is important to see what the effect will be if you type a few
more characters. Without alphabetical ordering there might be other
matches further down in the list.
--
hundred-and-one symptoms of being an internet addict:
13. You refer to going to the bathroom as downloading.
/// 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 ///
