Subject: [sup-talk] forward is broken in svn

From: [email-masked] (Ian Taylor)
Date: Sat, 11 Aug 2007 15:34:38 -0400

When in the thread view mode, hitting 'f' on a message causes an
exception to be thrown:

thread-view-mode.rb:136 'compose' undefined method 'edit'

-- 
Ian Taylor, Technical Assistant
Computer Science Computer Engineering
http://www.csce.uark.edu itaylor at uark.edu
University of Arkansas

---

From: [email-masked] (William Morgan)
Date: Sat, 11 Aug 2007 13:26:22 -0700

> thread-view-mode.rb:136 'compose' undefined method 'edit'

This was fixed in r519 (2007-08-06 21:16:53 -0700).

-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Ian Taylor)
Date: Sat, 11 Aug 2007 17:35:22 -0400

> This was fixed in r519 (2007-08-06 21:16:53 -0700).

I'm sorry, but it doesn't appear to be fixed here. Just in case, here is
the whole exection:

The problem was: 'undefined method `edit' for #<Redwood::ForwardMode:0x2aaaab5044b8>' (error type NoMethodError)
A backtrace follows:
/usr/lib64/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:337:in `forward': undefined method `edit' for #<Redwood::ForwardMode:0x2aaaab5044b8> (NoMethodError)
        from /usr/lib64/ruby/gems/1.8/gems/sup-0.9/lib/sup/mode.rb:52:in `send'
        from /usr/lib64/ruby/gems/1.8/gems/sup-0.9/lib/sup/mode.rb:52:in `handle_input'
        from /usr/lib64/ruby/gems/1.8/gems/sup-0.9/lib/sup/buffer.rb:191:in `handle_input'
        from /usr/lib64/ruby/gems/1.8/gems/sup-0.9/bin/sup:186
        from /usr/bin/sup:16:in `load'
        from /usr/bin/sup:16

Also, I think in the Rakefile, doing require 'lib/sup.rb' doesn't work
as imagined. The requires within lib/sup.rb require 'sup/*' and so try
to load from the local gem repository. I looked at the hoe project's
Rakefile and I see them doing a trick which probably is what we want:

require 'rubygems'
require 'hoe'
$:.unshift 'lib'
require 'sup'

Also, I think the change of the VERSION to 0 for development is a
problem. I got this after installing dev version of sup (after removing
the old ones):
/usr/lib64/ruby/site_ruby/1.8/rubygems.rb:304:in `report_activate_error': RubyGem version error: sup(0 not > 0) (Gem::LoadError)
        from /usr/lib64/ruby/site_ruby/1.8/rubygems.rb:238:in `activate'
        from /usr/lib64/ruby/site_ruby/1.8/rubygems.rb:76:in `active_gem_with_options'
        from /usr/lib64/ruby/site_ruby/1.8/rubygems.rb:50:in `gem'
        from /usr/bin/sup:15

Maybe some really high version number would be good since gems does a
comparison for choosing which version to use?

---

From: [email-masked] (William Morgan)
Date: Sun, 12 Aug 2007 15:21:05 -0700

> I'm sorry, but it doesn't appear to be fixed here. Just in case, here is

Well now, that's a completely different backtrace! But I've fixed it
too.

> Rakefile and I see them doing a trick which probably is what we want:

Thanks. I see other projects doing this too. I've changed this in SVN.

> problem. I got this after installing dev version of sup (after
> removing the old ones):

Bah, I'm tired of trying to make these things do something reasonable
for SVN versions. I've changed the version back to 0.1 and SVN users
will just have to be aware of the overloading.