Robert Webb srote:
> > 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.
That was long ago (1), now it falls back to the default label.
> > > 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).
Well, yes. But I would blame it on using 'autowrite'. That is a
dangerous option.
> > 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?! :-)
Of course! I only put credits for other people in the docs so we can
blame them if it doesn't work. :-)
> > 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 :-)
Everything is your fault unless proven otherwise. You also made it rain
two days ago (remember that butterfly you stepped on last year?).
> > 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.
For the search-ahead code the number of CTRL-N/CTRL-P typed are
remembered in a counter, and as soon as sufficient matches have been
found they are used. But it probably gets confused when suddenly going
to the other side of the linked list.
> > 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.
It also adds . or -> when needed. And it's much faster then searching
through include files.
> > 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.
Omni completion is still very new. I'm sure you can come up with an
improvement. But I want to make sure it doesn't bedome too complicated
and it remains consistent.
> > 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.
Why only when it fails? Omni completion could find some matches but not
the one the user wanted.
> > 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.
"intelligent" also means that it's (more or less) predictable. Unless
the user doesn't know what he is doing perhaps (but then he would be
using intellisense :-).
> > 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.
I suppose you could try searching for Blah to find out if it's a typedef
or something else. That actually already happens, but the current
script doesn't accept a struct without the struct keyword. I still
don't know in what C specification this is valid.
> > 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.
I think you are so much used to how it worked before that this is the
main reason you want it this way.
(1) 2 days is a long time if you're doing dozens of things in a day :-)
--
For a moment, nothing happened.
Then, after a second or so, nothing continued to happen.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
/// 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 ///
