On Mon 13-Nov-06 8:54am -0600, Matt Zyzik wrote:
>> On Sun 12-Nov-06 7:54pm -0600, [EMAIL PROTECTED] wrote:
>>> Well I'm reporting the above "g:zbuflistcount" in my 'rulerformat'.
>> Don't you think you should have mentioned that?
>>> I really don't think I can afford the baggage of calling your function
>>> from within my 'rulerformat'.
>> No, for 100 buffers, my function would take nearly 4 ms on
>> a 800 Mhz PC. You could upgrade the function to capture,
>> for example, the number of existing, loaded, listed and
>> wiped buffers. Then write is simple map to give yourself a
>> little report whenever you want it.
> Since the ruler is updated very frequently (for example in insert mode
> every keypress I take)... I prefer not to have even a "fast function" in
> my 'rulerformat'. Did you get 4ms from tests?
The "No" I wrote means that I agree that calling a user
function that takes (on my computer) 4ms is too slow.
I tested by opening about 100 files and wrote a function to
call the posted function 1000 times. That test took a
little less that 4 seconds - hence the 4ms for the posted
function.
I also tested a "fast function" that I have in my statusline
(my stl contains %{virtcol('$')-1}). In my test function, I
replaced the call to the posted function with:
let x = virtcol('$') - 1
For 1000 iterations, the test took about .04 seconds, so the
"fast function" takes about 40 us (microseconds). I find
that to be an acceptable delay to give me the virtual column
position. My column position in 'stl' is:
%c%V/%{virtcol('$')-1}
> Your first comment about how the autocmds cause baggage is ridiculous. I
> don't care so much about "let var += 1" running every half an hour when a
> new buffer is created.
When I wrote that I had assumed you wanted buffer info from
a key stroke map such as \bc. The autocmd approach is not
necessary for that. It can also be unreliable. For
example, if a script writer loads a scratch buffer quickly
with the "noautocmd" prefix or ignore certain events with
'eventignore', your autocmd will not be triggered. And if
they failed to put that prefix on, say, a :bwipeout to clear
that scratch file, your count will no longer be accurate.
>> Or your map could also set a global variable to update your
>> ruler or statusline.
> That's true, but it would be unprofessional to have a constantly outdated
> variable appear on the ruler/statusline.
Then don't put it on the ruler/statusline. Write your own
ctrl-g to provide all the details you want. Alternately,
you could have an autocmd call your version of the posted
function after 'updatetime' or on another event and use the
variable updated in your ruler.
> I'm rather looking into trying to write a patch if people would confirm
> that these are actual bugs (with the BufAdd/BufDelete autocmds).
It is easy to confirm that neither BufAdd or BufCreate is
triggered when opening with: gvim *.c
[Set vbs and vfile after starting or using -V with gvim.]
Even though many buffers are added to the list, neither of
those events are triggered. I don't know whether that's WAD
or a bug - it certainly doesn't behave as I would expect.
--
Best regards,
Bill
