On Mon, Nov 13, 2006 at 04:06:56PM -0600, Bill McCarthy wrote: > 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}
Ok. This is some good info. > 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. Yeah I've noticed all the problems seem to be from "noautocmd"s, 'eventignore's, and non-"nested" "autocmd"s. > > 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 When my .vimrc is running, creating the BufAdd autocmds, all of the files (*.c) I think already have buffers assigned to them. I'm not sure, but this could cause the problem. A simple fix would just be a manual buffer count on VimEnter. I'm getting close to the best solution. > > [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. Yeah maybe a bug. > > -- > Best regards, > Bill > --Matt