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