complete status

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

complete status

Mark Guzman
All,
  I've fixed/added Range variable detection support. So now x=1..2
should be picked up as a Range properly.
I noticed while testing it that 1..2.<C-x><C-o> is not completed. The
same goes for [1,2] and {1,2}. I use that type of
stuff for iteration some times, so I'll be adding support for that.
Please test the current cvs version if possible.
  --mark

--
sic transit gloria et adulescentia
blog | http://blog.hasno.info/blog
wiki | http://wiki.hasno.info

_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: complete status

Doug Kearns
On Thu, Apr 27, 2006 at 02:41:59PM -0400, Mark Guzman wrote:
> All,
>   I've fixed/added Range variable detection support. So now x=1..2
> should be picked up as a Range properly.
> I noticed while testing it that 1..2.<C-x><C-o> is not completed. The
> same goes for [1,2] and {1,2}. I use that type of
> stuff for iteration some times, so I'll be adding support for that.
> Please test the current cvs version if possible.

Looks good.

The symbol problem is still there though ie "::name" is inserted.

Regards,
Doug

PS. Should we forward this one up to B?
_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: complete status

Mark Guzman
Doug Kearns wrote:

>
> Looks good.
>
> The symbol problem is still there though ie "::name" is inserted.
>
> Regards,
> Doug
>
> PS. Should we forward this one up to B?
>  
Doug,
  I've taken care of the ::name bug, or so it seems. I think this is a
good one to send to Bram. I'll continue testing on my end.
  --mark

--
sic transit gloria et adulescentia
blog | http://blog.hasno.info/blog
wiki | http://wiki.hasno.info

_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: complete status

Gavin Sinclair
On 4/29/06, Mark Guzman <[hidden email]> wrote:
> >
> Doug,
>   I've taken care of the ::name bug, or so it seems. I think this is a
> good one to send to Bram. I'll continue testing on my end.
>   --mark

Thanks for all the work on this, chaps.  I haven't even tried it yet
(shame on me).  Gotta get me some of that Vim 7.0!

Cheers,
Gavin

_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: complete status

Doug Kearns
In reply to this post by Mark Guzman
On Thu, Apr 27, 2006 at 02:41:59PM -0400, Mark Guzman wrote:

<snip>

> Please test the current cvs version if possible.

class Foobar < String
  def <C-x><C-o>
end

If you change the superclass of Foobar after the buffer has been
'loaded' attempting completion results in:

Error detected while processing function rubycomplete#Complete:
line   22:
TypeError: (eval):71:in `load_buffer_class': (eval):1:in `load_buffer_class': superclass mismatch for class Foobar

Which is inconsistent with its behaviour prior to changing the
superclass.

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: complete status

Mark Guzman
Doug Kearns wrote:

> On Thu, Apr 27, 2006 at 02:41:59PM -0400, Mark Guzman wrote:
>
> <snip>
>
>  
>> Please test the current cvs version if possible.
>>    
>
> class Foobar < String
>   def <C-x><C-o>
> end
>
> If you change the superclass of Foobar after the buffer has been
> 'loaded' attempting completion results in:
>
> Error detected while processing function rubycomplete#Complete:
> line   22:
> TypeError: (eval):71:in `load_buffer_class': (eval):1:in `load_buffer_class': superclass mismatch for class Foobar
>
> Which is inconsistent with its behaviour prior to changing the
> superclass.
>
> Regards,
> Doug
>  
Doug,
  Unfortunatly I can't seem to reset the ruby session in vim. So once
you load a class definition your stuck with the basic definition. What
you did attempted to reload the class, which would add on any new
methods normally. Its inconsistent because its effectively invalid,
imagine defining Foobar in a file and then later in the file defining it
again with a superclass. Ruby would spit out the same error. I'm not
entirely sure what can be done in that case.
  --mark

--
sic transit gloria et adulescentia
blog | http://blog.hasno.info/blog
wiki | http://wiki.hasno.info

_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: complete status

Doug Kearns
On Sun, Apr 30, 2006 at 01:07:18PM -0400, Mark Guzman wrote:
> Doug Kearns wrote:

<snip>

> > If you change the superclass of Foobar after the buffer has been
> > 'loaded' attempting completion results in:
> >
> > Error detected while processing function rubycomplete#Complete:
> > line   22:
> > TypeError: (eval):71:in `load_buffer_class': (eval):1:in `load_buffer_class': superclass mismatch for class Foobar
> >
> > Which is inconsistent with its behaviour prior to changing the
> > superclass.
> >
> > Regards,
> > Doug
> >  
> Doug,
>   Unfortunatly I can't seem to reset the ruby session in vim. So once
> you load a class definition your stuck with the basic definition. What
> you did attempted to reload the class, which would add on any new
> methods normally. Its inconsistent because its effectively invalid,
> imagine defining Foobar in a file and then later in the file defining it
> again with a superclass. Ruby would spit out the same error. I'm not
> entirely sure what can be done in that case.

Yes. I was really just wondering if we should, in the long term, be
catching these errors and outputting a more 'meaningful' error message.

I'm not sure allowing these to leak out as Vim errors is the best
approach. You'd be surprised how many users won't be able/willing to
determine the cause of the problem and see the script as simply broken.

Hopefully, I'll have some time to help you out soon...hopefully.

Thanks,
Doug
_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: complete status

Mark Guzman
Doug Kearns wrote:

>
> Yes. I was really just wondering if we should, in the long term, be
> catching these errors and outputting a more 'meaningful' error message.
>
> I'm not sure allowing these to leak out as Vim errors is the best
> approach. You'd be surprised how many users won't be able/willing to
> determine the cause of the problem and see the script as simply broken.
>
> Hopefully, I'll have some time to help you out soon...hopefully.
>
>  
Ahh, ok. I'll add some error handling around that spot. Something
meaningful like 'The class "Foobar" was already loaded, the new
definition conflicts with the old. Unable to determine completion.'
Some of these things don't occur naturally in my thought process yet, I
guess I'm a bit to much of a tinkerer.
  --mark

--
sic transit gloria et adulescentia
blog | http://blog.hasno.info/blog
wiki | http://wiki.hasno.info

_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel
Reply | Threaded
Open this post in threaded view
|

Re: complete status

Doug Kearns
On Mon, May 01, 2006 at 10:09:06AM -0400, Mark Guzman wrote:

<snip>
   
> Ahh, ok. I'll add some error handling around that spot. Something
> meaningful like 'The class "Foobar" was already loaded, the new
> definition conflicts with the old. Unable to determine completion.'
> Some of these things don't occur naturally in my thought process yet, I
> guess I'm a bit to much of a tinkerer.

It seems these new error messages are not seen because the standard Omni
status line is overwriting them. The completion list is also just
returning the initially loaded classes methods in this context. I thinks
it's better to fail in this case and return an empty list.

Is there something better than calling sleep to enable the user to read
an internally generated message?

Regards,
Doug
_______________________________________________
vim-ruby-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/vim-ruby-devel