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
Excerpts from Ian Taylor''s message of Sat Aug 11 12:34:38 -0700 2007:> 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>
Excerpts from William Morgan''s message of Sat Aug 11 16:26:22 -0400 2007:> Excerpts from Ian Taylor''s message of Sat Aug 11 12:34:38 -0700 2007: > > thread-view-mode.rb:136 ''compose'' undefined method ''edit'' > > 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? -- Ian Taylor, Technical Assistant Computer Science Computer Engineering http://www.csce.uark.edu itaylor at uark.edu University of Arkansas
Excerpts from Ian Taylor''s message of Sat Aug 11 14:35:22 -0700 2007:> I''m sorry, but it doesn''t appear to be fixed here. Just in case, here is > the whole exection:Well now, that''s a completely different backtrace! But I''ve fixed it too.> 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:Thanks. I see other projects doing this too. I''ve changed this in SVN.> 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):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. -- William <wmorgan-sup at masanjin.net>