Could someone confirm this bug?
RedCloth.new("!/image_r.jpg(description)!:image.jpg").to_html
<p><a href="image.jpg"><img
src="/image_r.jpg" title="description"
alt="description" /></a></p>
That is correct.
Then we just add an "a" (or anything else) to the end of the string:
RedCloth.new("!/image_r.jpg(description)!:image.jpg a").to_html
Incorrect result (link is missed):
<p><img src="/image_r.jpg" title="description"
alt="description" /> a</p>
It only happens when "(description)" is present.
Maybe RedCloth should include this case on test suite.
Tested on last stable version (4.1.9).
The problem doesn''t exist on 4.1.1.
P.S: a curiosity: why 4.1.9 follows 4.1.1, instead of 4.1.2?
Veja quais s?o os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
Rodrigo, thanks for reporting the bug. I''ve made a ticket for it at http://jgarber.lighthouseapp.com/projects/13054-redcloth/tickets/141-image-link-not-recognized-with-alt-text If you want to follow the status, sign in to Lighthouse. BTW, 4.1.9 followed 4.1.1 because I was trying to be cute. RedCloth 4.1.9 was the first release to be compatible with Ruby 1.9. Get it? In the end, though, it was a mistake. I''ve wanted to release another 4.1.x but I don''t want to do 4.1.10 because then you can''t compare version numbers as strings. Not to mention the fact that it''s just plain confusing So, expect the next version to be 4.2.0. On Apr 8, 2009, at 9:39 AM, Rodrigo Rosenfeld Rosas wrote:> > Could someone confirm this bug? > > RedCloth.new("!/image_r.jpg(description)!:image.jpg").to_html > > <p><a href="image.jpg"><img src="/image_r.jpg" title="description" > alt="description" /></a></p> > > That is correct. > > Then we just add an "a" (or anything else) to the end of the string: > > RedCloth.new("!/image_r.jpg(description)!:image.jpg a").to_html > > Incorrect result (link is missed): > <p><img src="/image_r.jpg" title="description" alt="description" /> > a</p> > > It only happens when "(description)" is present. > Maybe RedCloth should include this case on test suite. > > > Tested on last stable version (4.1.9). > > The problem doesn''t exist on 4.1.1. > > P.S: a curiosity: why 4.1.9 follows 4.1.1, instead of 4.1.2? > > > Veja quais s?o os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > _______________________________________________ > Redcloth-upwards mailing list > Redcloth-upwards at rubyforge.org > http://rubyforge.org/mailman/listinfo/redcloth-upwards
On Wed, 8 Apr 2009, Jason Garber wrote:> BTW, 4.1.9 followed 4.1.1 because I was trying to be cute. RedCloth 4.1.9 was > the first release to be compatible with Ruby 1.9. Get it? In the end, > though, it was a mistake. I''ve wanted to release another 4.1.x but I don''t > want to do 4.1.10 because then you can''t compare version numbers as strings.Are we going to be stuck with this idea forever? We ran into this when the successor to Ruby 1.8 could not be Ruby 1.10, breaking the odd/even as unstable/stable releases pattern. Version numbers are not strings, but even if they are (a) they should be parsed (Is Debian version "Woody".to_i.zero? ?), and (b): http://rubyforge.org/projects/natcmp/ Try searching for "natural order string comparison". I really think that Ruby needs a native class for versions. That way it would not be a subclass of String. I should have used Comparable for this, written about 7 months into using Ruby: http://www.cse.dmu.ac.uk/~hgs/ruby/revision.rb My point being this is not something doable by only the advanced programmer, even if this effort could do with improvement. The other reason Ruby didn''t have 1.10 as a stable release was C code checking based on single bytes per {major, minor, teeny} (or whatever you call the third one). Do you have any evidence for people comparing these (Redcloth) version numbers as if they were strings? If nobody does, then why worry about it? The clue is in the nomenclature: "version *numbers*".> Not to mention the fact that it''s just plain confusing So, expect the nextI don''t see that as confusing: it''s one of those things that is already tradition in this field less than 100 years old.> version to be 4.2.0. >Hugh
Thanks for the feedback. I picked up on the whole comparing version numbers as strings from here: http://www.ruby-forum.com/topic/179119 Right or wrong, being able to compare Ruby version numbers as strings was enormously helpful in that circumstance. I wish they would build version comparison directly into Ruby too! I have no evidence that people are comparing RedCloth version numbers as strings?and they probably aren''t?so it''s probably no big deal if I would make a 4.1.10. There was a 2.0.10 before, so there you go. Not that I have time right now to do anything that would deserve a new version. :-( Wish I did because I really enjoy hacking on RedCloth! Jason On Apr 9, 2009, at 8:46 AM, Hugh Sasse wrote:> On Wed, 8 Apr 2009, Jason Garber wrote: > >> BTW, 4.1.9 followed 4.1.1 because I was trying to be cute. >> RedCloth 4.1.9 was >> the first release to be compatible with Ruby 1.9. Get it? In the >> end, >> though, it was a mistake. I''ve wanted to release another 4.1.x but >> I don''t >> want to do 4.1.10 because then you can''t compare version numbers as >> strings. > > Are we going to be stuck with this idea forever? We ran into this > when the successor to Ruby 1.8 could not be Ruby 1.10, breaking the > odd/even as unstable/stable releases pattern. Version numbers are > not strings, but even if they are (a) they should be parsed (Is > Debian version "Woody".to_i.zero? ?), and (b): > > http://rubyforge.org/projects/natcmp/ > > Try searching for "natural order string comparison". > > I really think that Ruby needs a native class for versions. > That way it would not be a subclass of String. > I should have used Comparable for this, written about 7 months into > using Ruby: > > http://www.cse.dmu.ac.uk/~hgs/ruby/revision.rb > > My point being this is not something doable by only the advanced > programmer, even if this effort could do with improvement. > > The other reason Ruby didn''t have 1.10 as a stable release was C code > checking based on single bytes per {major, minor, teeny} (or whatever > you call the third one). > > Do you have any evidence for people comparing these (Redcloth) > version numbers as if they were strings? If nobody does, then why > worry about it? The clue is in the nomenclature: "version *numbers*". > >> Not to mention the fact that it''s just plain confusing So, expect >> the next > > I don''t see that as confusing: it''s one of those things that is > already > tradition in this field less than 100 years old. > >> version to be 4.2.0. >> > > Hugh > _______________________________________________ > Redcloth-upwards mailing list > Redcloth-upwards at rubyforge.org > http://rubyforge.org/mailman/listinfo/redcloth-upwards
Jason Garber escreveu:> ... > Not that I have time right now to do anything that would deserve a new > version. :-( Wish I did because I really enjoy hacking on RedCloth!You could find out what broke RedCloth, regarding this bug, for instance ;) I don''t know what version control system you are using but, on git, there is the "git blame" that could give you a hint of what broke RedCloth in 4.1.9 that was not present in 4.1.1. Fixing this but on 4.1.10 would be enough for a new version :) Best Regards, Rodrigo. _______________________________________________________ Yahoo! Mail - Sempre a melhor op??o para voc?! Experimente j? e veja as novidades. http://br.yahoo.com/mailbeta/tudonovo/