On Thu, Jan 24, 2008 at 02:57:38PM -0500, Charles E Campbell Jr wrote:
> That bufnr(".") was an example, folks. Not the purpose of the
> suggestion. The problem is that its difficult to find bugs in plugins
The problem with the example is that it's not an error at all. bufnr()
serves several different purposes:
1. Given a number, check if that buffer exists
2. Given a full filename, check if that buffer exists
3. Given a full filename, return the buffer number
4. Given a partial filename, check if a matching buffer exists
5. Given a partial filename, return the buffer number
6. Given "" or "%", return the current buffer number
7. Given "#", return the alternate buffer number
8. Given "$", return the last buffer number
Now, you're after 6, but your mistake is causing 4 to be answered
instead. If there is an error here, it's that the API is so
overloaded that it invites these kinds of issues. But as it stands,
bufnr(".") is not an error, it's just a different use of the same
function. An option that changed this to an error would eliminate
perfectly valid uses of the function.
> because vim is forgiving of errors -- which is a good thing for users.
In the context of programming (and Vim scripting), silently ignoring
real errors is doing users a disservice, as I'm sure you'd agree.
Cheers,
Tim Pope
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
