I see no one ever answered this, so.. I will, for posterity at least. :)
On Tue, Jan 12, 2010 at 6:07 AM, Milan Radovich wrote:
> Hello,
>
> I noticed a strange behaviour of tag searching in deleted buffers.
> Following is a key sequence
> to perform after vim is started to reproduce the problem (spaces are
> used for readability only):
>
> <F1> <C-w>o /usr<CR> <C-]> :bd <C-^> /usr_01<CR> <C-]>
>
> I expected vim to find and jump to tag usr_01.txt,
Because you expected the word under the cursor to be usr_01.txt - it
normally is, because, according to :help 'iskeyword'
For a help file it is set to all non-blank printable characters except
'*', '"' and '|' (so that CTRL-] on a command finds the help for that
command).
So, the . in between usr_01 and txt is usually part of the word, in a help file.
> but instead get
> error 426 that tag usr_01 is
> not found. Actually the question is why does vim decides to use usr_01
> as a tag, instead of
> usr_01.txt, since if ":bd <C-^>" removed from a key sequence above,
> vim uses usr_01.txt
> as a tag. Obviously the problem is not in the fact that buffer was
> unloaded, since if ":bun"
> instead of ":bd" is used, the problem does not occur.
The difference being that :bun unloads the buffer, and :bd unloads the
buffer and unsets all of the options - including 'iskeyword', which
tells vim to include . as part of a word.
> I thought that maybe such a behaviour can be explained by the fact
> that ":bd" clears option
> values etc. for the buffer.
Yep. And when switching back to the buffer, vim just sees it as text,
not as a help file, so it doesn't re-apply all of the help-specific
tweaks.
> As the result, vim discards a list of
> buffer's tags from the memory
> and doesn't build that list again when it switches back to the
> previously deleted buffer.
No, the list of tags is never (afaik) cached.
> This
> explanation though is not that clear as well, since if the final
> "<C-]>" is replaced with "v9l <C-]>",
> vim does find the tag.
Because you're explicitly including the . in that command.
> Anyway, this behaviour seems like a bug.
>
> Do you have a better explanation for the behaviour above?
I hope you find the explanation good enough. :)
~Matt
--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
