Ruby $curbuf.number always returns 0 for Vim 7.3 on some platforms

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Ruby $curbuf.number always returns 0 for Vim 7.3 on some platforms

Wincent Colaiuta
Hi,

I'm the author of the Command-T plug-in, which is a Vim plugin partly
written in Ruby:

  https://wincent.com/products/command-t

I've received multiple reports from people on different platforms that
there is breakage running under 7.3 on their platform (I'm afraid I
can't reproduce on Mac OS X though):

  https://wincent.com/issues/1617

The apparent cause is that, for them, evaluating "$curbuf.number"
under Ruby _always_ returns 0, when it is supposed to return a
positive integer buffer number. To test, just do this:

  :ruby puts $curbuf.number

If you're on an affected platform/Vim, you'll always see 0. Otherwise
you'll see some positive integer.

The plug-in uses the buffer number in a couple of places to select and
close buffers; ie. basically doing stuff like:

  :silent b 23

And:

  :bwipeout! 23

These users report that a workaround is to use "$curbuf.name" for
those purposes instead. I'm reluctant to make this change to the plug-
in because I'm worried about the possible instability of the buffer
name over time.

So two questions:

  (1) is this a known bug in 7.3? (and if not, what information can I
gather from these users to help troubleshoot it)

  (2) is using "$curbuf.name" a "safe" workaround, or is it possible
that the value could change over time and introduce unexpected
behavior into the plug-in?

Cheers,
Wincent

--
You received this message from the "vim_use" 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
Reply | Threaded
Open this post in threaded view
|

Re: Ruby $curbuf.number always returns 0 for Vim 7.3 on some platforms

Nikolay Aleksandrovich Pavlov
Ответ на сообщение «Ruby $curbuf.number always returns 0 for Vim 7.3 on some
platforms»,
присланное в 12:09:44 21 августа 2010, Суббота,
отправитель Wincent Colaiuta:

I do not know, what for you are using $curbuf.number (perhaps, for closing list
of files), but the buffer name could change at least in the following cases:
1. when you open a buffer which is not attached to any file and then write it
somewhere. Example:
    new
    " echoes nil
    ruby puts $curbuf.name
    w file
    " echoes /path/to/file
    ruby puts $curbuf.name
    qa!
2. when you open an existing file and use saveas command. Example:
    e file
    " echoes /path/to/file
    ruby puts $curbuf.name
    sav file2
    " echoes /path/to/file2
    ruby puts $curbuf.name
    qa!
Buffer number will not change in these cases.

PS: Gentoo linux, amd64, vim version 7.3, ruby 1.8.7_p249: $curbuf.number
returns correct value.


Текст сообщения:

> Hi,
>
> I'm the author of the Command-T plug-in, which is a Vim plugin partly
> written in Ruby:
>
>   https://wincent.com/products/command-t
>
> I've received multiple reports from people on different platforms that
> there is breakage running under 7.3 on their platform (I'm afraid I
> can't reproduce on Mac OS X though):
>
>   https://wincent.com/issues/1617
>
> The apparent cause is that, for them, evaluating "$curbuf.number"
> under Ruby _always_ returns 0, when it is supposed to return a
>
> positive integer buffer number. To test, just do this:
>   :ruby puts $curbuf.number
>
> If you're on an affected platform/Vim, you'll always see 0. Otherwise
> you'll see some positive integer.
>
> The plug-in uses the buffer number in a couple of places to select and
>
> close buffers; ie. basically doing stuff like:
>   :silent b 23
>
> And:
>   :bwipeout! 23
>
> These users report that a workaround is to use "$curbuf.name" for
> those purposes instead. I'm reluctant to make this change to the plug-
> in because I'm worried about the possible instability of the buffer
> name over time.
>
> So two questions:
>
>   (1) is this a known bug in 7.3? (and if not, what information can I
> gather from these users to help troubleshoot it)
>
>   (2) is using "$curbuf.name" a "safe" workaround, or is it possible
> that the value could change over time and introduce unexpected
> behavior into the plug-in?
>
> Cheers,
> Wincent

signature.asc (205 bytes) Download Attachment