Bram,
> You wouldn't type these things, they would be in a script. There it's
> not difficult to check for the existence of t:tabName.
>
> :set guitablabel=%{MyTabName()}
> func MyTabName()
> if exists('t:tabName')
> return t:tabName
> endif
> return ''
> endfunc
But as I said, if the expression given for guitablabel evaluates to an
empty string, you just get an empty string in the tab name instead of
getting the default name as expected. I just tried the above code,
and sure enough the tabs all became blank.
> > 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.
In 6.3 the buffer was marked as unmodified after writing it to a new
file name, so when I edit tags and save it as tags.vim, the tags
buffer was disposed of without saving. Now the modified flag is set,
so it overwrites the file. It's not a bug, but the changed behaviour
could cause some bad problems for some users with scripts that do
something similar to mine (edit a file, change it, save to another
file name).
> 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.
Previously it would give the next match in the current file. I
wouldn't call it an arbitrary match. It is hard to see how the
previous behaviour could work though with the new popup menu.
Pity, I did prefer it. I often use ^P to check the last couple of
matches, and if I know it's near-by, then I can use ^N a few times to
go back past the starting point to the next match or two after the
cursor. Now this is impossible without breaking the search and
starting it again in the other direction. 'complete' is supposed to
give the order that matches will be found, and I want all matches from
the current file first, regardless of what order I use ^N/^P.
> 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.
Aha, so it's my fault is it?! :-)
> Features added later will no doubt interfere with what happens
> there.
Hmm, not sure THAT's my fault, although if the code was hard to follow
I guess it could be :-)
> I have looked into a complete overhaul of this code, but it is
> nearly impossible to keep the mechanism 100% backwards compatible.
Yeah, I think this has more to do with a shift in paradigm than the
state of my original code.
> I have problems reproducing this, as soon as the search stops it
> appears to work properly.
Yes, once the search through (hundreds?) of header files is complete,
the menu works fine. It's only while the search is still going on
that there are problems.
Seems that when ^P/^N wrap, it should just wrap using the matches
found so far. So after returning to the original text, the next ^N/^P
should simply go to the first/last match found so far. Currently it
just gets stuck or confused until all matches are found. I don't
think this would depend on my search-ahead code at all.
> I don't think this would be consistent. C omni completion also works
> fine without "." or "->".
It just completes tags though, right? ^N/^P already match tags too.
> Generally this means you need to do the omni completion to discover
> if it finds useful matches.
My thinking is that there are certain situations where it's very
likely that omni completion will know best, such as after "." or "->"
for C. ^N/^P would check for that first, and if found, see if omni
finds any matches, if so use them. If any of that fails, use normal
completion.
I'll be able to write a mapping for most of that, except that if it
looks like omni should know best, but turns out not to return any
matches (eg code for a struct that hasn't been filled in yet), then I
don't think I can recognise that in a mapping and do a normal
completion instead.
> 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 "->".
In my above method, vim would use normal completion when omni fails to
return any matches, so this case would be handled.
> 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.
It would be "intelligent" completion :-) Just as completion on the
:-line is context sensitive. Same thing.
> Overloading makes this very difficult. If Vim sees "Blah a" then it has
> no clue that "Blah" is a typedef or anything else.
You know it's the type we're after though, right? We're completing
"a->blah" so we search back to the first use of "a" in this function
and find "Blah a". Blah must be the type, and there should be a tag
for it.
> 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.
If the code has less information, all the more need for vim to help us
with it :-)
> For me omni completion in C code works much faster then CTRL-N, because
> it skips all the stuff in comments and strings.
Fair enough. I always start member variables with "m" and use mixed
case, eg "mBlah". So I wouldn't find such matches in comments
generally. So I'd still put "o" in 'complte' if it was available :-)
> And doesn't dig in include files.
Nor should ^N/^P until matches in the current file, other loaded
buffers, and tags have been found. At least that's the way I've got
it up, to deliberately avoid searching in unloaded files except as a
last resort. I notice the default however is to search unloaded
buffers before tags. That's fine, each to their own.
Regarding alphabetical sorting, it really would be great if this could
be changed (optionally :-)) to current file first (and then header
file if possible!). I might type in just one or two letters, and
there may be hundreds of matching tags, but only one or two matches
from the current file. It is highly likely that these are the ones
I'm interested in. If not, they will represent only a small number
which I can easily skip through before wading through the many more
matches from all other files.
Thanks,
Rob.
--
Robert Webb <[EMAIL PROTECTED]>,
Want to make polyhedra?
http://www.software3d.com/Stella.html
