From jg at jasongarber.com  Mon Mar  2 09:57:04 2009
From: jg at jasongarber.com (Jason Garber)
Date: Mon, 2 Mar 2009 09:57:04 -0500
Subject: RedCloth 4.1.1 released
In-Reply-To: <da0b0c9e7fee8aa9fe57a870f629be86@ruby-forum.com>
References: <AC7527C4-F12B-43AA-9449-DFE54A350FC8@jasongarber.com>
	<da0b0c9e7fee8aa9fe57a870f629be86@ruby-forum.com>
Message-ID: <249440CA-FF1E-4DF5-92CB-7A81A3277B90@jasongarber.com>

I lost this one in my inbox; sorry!

Do you still have the same problem with 4.1.9?  I'm not aware that I  
changed anything to fix it, but just now I uninstalled echoe and  
RedCloth and then installed RedCloth 4.1.9 and it installed just fine  
without echoe.  If it doesn't work for you, please let me know!

I regret that echoe caused so much trouble.  I went with it instead of  
hoe because it didn't make itself a dependency (or so they said).  A  
bug in RubyGems 1.2 made it one, though.

Jason

On Jan 21, 2009, at 5:38 PM, Azul Blue wrote:

> Jason Garber wrote:
>> This release fixes problems with the echoe development dependency,
>> requiring RedCloth using CamelCase, and incorrect platform labels on
>> the win32 and JRuby gems.  All these were the result of switching to
>> echoe (like hoe, but it doesn't make itself a runtime dependency) to
>> do the cross-platform compilation and gem packaging.
> It looks like echoe would still be a dependency to me:
>
> :~$ redcloth --version
> RedCloth 4.1.1
> :~$ sudo gem uninstall echoe
> [sudo] password for utopia:
>
> You have requested to uninstall the gem:
>  echoe-3.0.2
> RedCloth-4.1.1 depends on [echoe (>= 0)]
> If you remove this gems, one or more dependencies will not be met.
> Continue with Uninstall? [Yn]  Y
> Successfully uninstalled echoe-3.0.2
> :~$ redcloth --version
> /usr/lib/ruby/1.8/rubygems.rb:578:in `report_activate_error': Could  
> not
> find RubyGem echoe (>= 0) (Gem::LoadError)
>  from /usr/lib/ruby/1.8/rubygems.rb:134:in `activate'
>  from /usr/lib/ruby/1.8/rubygems.rb:158:in `activate'
>  from /usr/lib/ruby/1.8/rubygems.rb:157:in `each'
>  from /usr/lib/ruby/1.8/rubygems.rb:157:in `activate'
>  from /usr/lib/ruby/1.8/rubygems.rb:49:in `gem'
>  from /usr/bin/redcloth:18
>
> Is that right? The programm that uses RedCloth also still reports that
> RedCloth could not be found if echoe is not installed.
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Redcloth-upwards mailing list
> Redcloth-upwards at rubyforge.org
> http://rubyforge.org/mailman/listinfo/redcloth-upwards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/redcloth-upwards/attachments/20090302/770773ec/attachment.html>

From jg at jasongarber.com  Thu Mar  5 09:47:48 2009
From: jg at jasongarber.com (Jason Garber)
Date: Thu, 5 Mar 2009 09:47:48 -0500
Subject: new format for specifying list classes?
Message-ID: <864B744D-F946-4A33-8AC0-996294BE03E6@jasongarber.com>

Hi, RedCloth folks.  The other day, I tried this:
>   *(class-one) one
>   *(class-two) two
>   *(class-three) three
thinking I'd get this:
>   <ul>
>   	<li class="class-one">one</li>
>   	<li class="class-two">two</li>
>   	<li class="class-three">three</li>
>   </ul>

But that's not how it works.  RedCloth 3 & 4 and Textile 2 both make  
the class/id you put on the first item in the list the class/id for  
the whole list.  When you put classes/ids on subsequent list items,  
RedCloth 3 blows up, Textile2 makes them completely separate lists,  
and RedCloth 4 puts classes on the wrong list items (I'm fixing that  
now).

Here's what PyTextile does:
> To style a list, the parameters should go before the hash if you  
> want to set the attributes on the <ol> tag:
>
> (class#id)# one
> # two
> # three
> If you want to customize the firsr <li> tag, apply the parameters  
> after the hash:
>
> #(class#id) one
> # two
> # three

What do you think?  Stick close to Textile 2 or go the PyTetxile way  
to expand Textile's breadth of expression?  It will break backward  
compatibility but I really want this feature. :-)

Jason



From work at whatcould.com  Thu Mar  5 14:27:23 2009
From: work at whatcould.com (David Reese)
Date: Thu, 05 Mar 2009 13:27:23 -0600
Subject: new format for specifying list classes?
In-Reply-To: <864B744D-F946-4A33-8AC0-996294BE03E6@jasongarber.com>
References: <864B744D-F946-4A33-8AC0-996294BE03E6@jasongarber.com>
Message-ID: <49B0279B.1050801@whatcould.com>

Funny, i was just trying to do this myself last week, and saw the same 
issue. I made it work (putting the class on the ul element), but it felt 
dirty. I just had the feeling it shouldn't work like that. almost 
resorted to html. (!)

This is a tough call...

My vote: onward an upward!  Make it work like it should have all along.  
If they're savvy enough to be adding classes to list elements in 
textile, they're savvy enough to figure out how to fix their old (kind 
of hacky) markup.

david

> Hi, RedCloth folks.  The other day, I tried this:
>>   *(class-one) one
>>   *(class-two) two
>>   *(class-three) three
> thinking I'd get this:
>> <ul>
>> <li class="class-one">one</li>
>> <li class="class-two">two</li>
>> <li class="class-three">three</li>
>> </ul>
>
> But that's not how it works.  RedCloth 3 & 4 and Textile 2 both make 
> the class/id you put on the first item in the list the class/id for 
> the whole list.  When you put classes/ids on subsequent list items, 
> RedCloth 3 blows up, Textile2 makes them completely separate lists, 
> and RedCloth 4 puts classes on the wrong list items (I'm fixing that 
> now).
>
> Here's what PyTextile does:
>> To style a list, the parameters should go before the hash if you want 
>> to set the attributes on the <ol> tag:
>>
>> (class#id)# one
>> # two
>> # three
>> If you want to customize the firsr <li> tag, apply the parameters 
>> after the hash:
>>
>> #(class#id) one
>> # two
>> # three
>
> What do you think?  Stick close to Textile 2 or go the PyTetxile way 
> to expand Textile's breadth of expression?  It will break backward 
> compatibility but I really want this feature. :-)
>
> Jason
>
>
> _______________________________________________
> Redcloth-upwards mailing list
> Redcloth-upwards at rubyforge.org
> http://rubyforge.org/mailman/listinfo/redcloth-upwards
>


From gerald at vanbeta.com  Fri Mar  6 02:11:54 2009
From: gerald at vanbeta.com (Gerald Bauer)
Date: Fri, 6 Mar 2009 08:11:54 +0100
Subject: new format for specifying list classes?
In-Reply-To: <864B744D-F946-4A33-8AC0-996294BE03E6@jasongarber.com>
References: <864B744D-F946-4A33-8AC0-996294BE03E6@jasongarber.com>
Message-ID: <1f058eab0903052311u29fac743scf87017b86d8aeac@mail.gmail.com>

Hello,

> Here's what PyTextile does:
>>
>> To style a list, the parameters should go before the hash if you want to
>> set the attributes on the <ol> tag:
>>
>> (class#id)# one
>> # two
>> # three
>> If you want to customize the firsr <li> tag, apply the parameters after
>> the hash:
>>
>> #(class#id) one
>> # two
>> # three
>
> What do you think? ?Stick close to Textile 2 or go the PyTetxile way to
> expand Textile's breadth of expression? ?It will break backward
> compatibility but I really want this feature. :-)

  I support/prefer the PyTextile way. Using the new semantics is a
great addition to mark steps/incrementals in presentations e.g.

(step)# one
# two
# three

  Let's you mark all list items at once.

#one
#(step) two
#(step) three

   Let's you mark individual items. I tried it before with the "old"
version of RedCloth/Textile but it was not possible [1].

   Cheers.

[1] http://groups.google.com/group/webslideshow/msg/a04c2b8a0dae3038

From stephen.bannasch at deanbrook.org  Wed Mar 25 21:29:25 2009
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Wed, 25 Mar 2009 21:29:25 -0400
Subject: fyi: RubyGems patched to support module-based VERSION strings
Message-ID: <p06240810c5f089051231@[192.168.1.106]>

Jason, fyi:

Eric Hodel just applied my patch to RubyGems to better support 
module-based VERSION strings.

   [#24392] support module-based VERSION strings
   http://rubyforge.org/tracker/?func=detail&atid=577&aid=24392&group_id=126

It will be in RubyGems 1.3.2

I was using this for of VERSION coding which is similar to what you 
are using in RedCloth and had some trouble with my jnlp gem (which I 
can't remember right now).

module Jnlp #:nodoc:
   # VERSION = '0.0.3'
   module VERSION
     MAJOR = 0
     MINOR = 0
     TINY  = 3
     STRING = [MAJOR, MINOR, TINY].join('.')
     class << self
       def to_s
         STRING
       end
       def ==(arg)
         STRING == arg
       end
     end
   end
end

From jg at jasongarber.com  Thu Mar 26 08:27:46 2009
From: jg at jasongarber.com (Jason Garber)
Date: Thu, 26 Mar 2009 08:27:46 -0400
Subject: fyi: RubyGems patched to support module-based VERSION strings
In-Reply-To: <p06240810c5f089051231@[192.168.1.106]>
References: <p06240810c5f089051231@[192.168.1.106]>
Message-ID: <BF342E70-8BAF-430A-8817-AF59CE882074@jasongarber.com>

Sounds great!  Thanks for figuring it out and submitting a patch.  I  
hadn't run into that particular difficulty, but I would have  
eventually, I'm sure.

Jason

On Mar 25, 2009, at 9:29 PM, Stephen Bannasch wrote:

> Jason, fyi:
>
> Eric Hodel just applied my patch to RubyGems to better support  
> module-based VERSION strings.
>
>   [#24392] support module-based VERSION strings
>   http://rubyforge.org/tracker/? 
> func=detail&atid=577&aid=24392&group_id=126
>
> It will be in RubyGems 1.3.2
>
> I was using this for of VERSION coding which is similar to what you  
> are using in RedCloth and had some trouble with my jnlp gem (which  
> I can't remember right now).
>
> module Jnlp #:nodoc:
>   # VERSION = '0.0.3'
>   module VERSION
>     MAJOR = 0
>     MINOR = 0
>     TINY  = 3
>     STRING = [MAJOR, MINOR, TINY].join('.')
>     class << self
>       def to_s
>         STRING
>       end
>       def ==(arg)
>         STRING == arg
>       end
>     end
>   end
> end
> _______________________________________________
> Redcloth-upwards mailing list
> Redcloth-upwards at rubyforge.org
> http://rubyforge.org/mailman/listinfo/redcloth-upwards