Bug or feature? Unlike all other "window numbers" (count for Ctrl-W w,
return value from winnr() or tabpagewinnr(), etc.) which are 1-based
(top window is 1), v:beval_winnr is zero-based (top window is 0), as can
be ascertained with the following setting (in a Vim compiled with
+balloon_eval, of course):
:set beval bexpr='buf:'.v:beval_bufnr.'\ win:'.v:beval_winnr.'\
loc:'.v:beval_lnum.','.v:beval_col.'\ text:'.v:beval_text
Then hovering the mouse over text being edited shows that "win:" is
followed by a value one less than the current winnr(). AFAICT, this
inconsistency is not documented (if it is, I couldn't find it).
Also, with the same settings, one sees that v:beval_col is not a
"virtual column" (screen column) but a "byte offset from start-of-line".
For instance, hard tabs are counted as one "column" each regardless of
their actual displayed width.
Since making v:beval_winnr one-based or v:beval_col "virtual" might
break compatibility, I propose to leave the current behaviour unchanged,
but to document it.
For the record, I did this test with gvim 7.3.118 (Huge version with
GTK2-GNOME GUI) running in GUI mode. AFAICT the ballon-eval feaure is
not available in Console mode (no error, just no balloon).
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
21. Your dog has its own home page.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
