Quick and dirty word wrapping

ruby-talk
1

"Kroeger Simon (ext)" <simon.kroeger.ext siemens.com> wrote:
Hmm, nice, just one little thing:

str = '12345678901234567890'
puts str.wrap_to( 10 )
puts
puts str.wrap_to( 5 )

output:

1234567890
1234567890

12345
78901
34567
890

it 'eats' chars...

cheers

Simon

Hmmm.... Here is my quick fix for him ...

class String
     def wrap_to( col_width )
         str = self.gsub( /(\S{#{col_width}})(?=\S)/, '\1 ' )
         str.scan(/(.{1,#{col_width}})(?:\s+|$)/).flatten.join( "\n" )
     end
end

2

Very nice. My proprocessing didn't eat any characters, but it did allow for \S runs that were col_width+1 long, which the next step skipped over. David's lookahead does the trick nicely.

···

On Sep 14, 2005, at 4:04 PM, David Tran wrote:

"Kroeger Simon (ext)" <simon.kroeger.ext siemens.com> wrote:
Hmm, nice, just one little thing:
it 'eats' chars...

Hmmm.... Here is my quick fix for him ...

class String
     def wrap_to( col_width )
         str = self.gsub( /(\S{#{col_width}})(?=\S)/, '\1 ' )
         str.scan(/(.{1,#{col_width}})(?:\s+|$)/).flatten.join( "\n" )
     end
end

3

Following feels like a good replacement for the existing Nano String#word_wrap method. Using gsub! (seen below) instead of scan.flatten.join (seen above) was a bit (but not much) faster. The non-destructive method can be re-written to be a hair faster by not relying on the destructive one, but it doesn't feel worth the DRY violation to do so.

class String
     def word_wrap( col_width=80 )
         self.dup.word_wrap!( col_width )
     end

     def word_wrap!( col_width=80 )
         self.gsub!( /(\S{#{col_width}})(?=\S)/, '\1 ' )
         self.gsub!( /(.{1,#{col_width}})(?:\s+|$)/, "\\1\n" )
         self
     end
end

The existing nano methods with these names do not properly deal with words or character sequences that are longer than the wrap width, so while these new methods are a little slower (3.03s vs. 2.35s) they are more correct. More testing should probably be done on speed optimizations and edge cases, though.

···

On Sep 14, 2005, at 4:04 PM, David Tran wrote:

Hmmm.... Here is my quick fix for him ...

class String
     def wrap_to( col_width )
         str = self.gsub( /(\S{#{col_width}})(?=\S)/, '\1 ' )
         str.scan(/(.{1,#{col_width}})(?:\s+|$)/).flatten.join( "\n" )
     end
end

4

... I've been observing this discussion, and I'm wondering why people
wouldn't just use Text::Format, instead. It does all of this and
allows for hyphenation, too.

-austin

···

On 9/14/05, Gavin Kistner <gavin@refinery.com> wrote:

Following feels like a good replacement for the existing Nano
String#word_wrap method. Using gsub! (seen below) instead of
scan.flatten.join (seen above) was a bit (but not much) faster. The
non-destructive method can be re-written to be a hair faster by not
relying on the destructive one, but it doesn't feel worth the DRY
violation to do so.

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

5

Hi Austin,

I've been observing this discussion, and I'm wondering why people
wouldn't just use Text::Format, instead. It does all of this and
allows for hyphenation, too.

Probably b/c of "quick and dirty".

We have 10 loc vs. 1000 loc plus an addiitonal dependency.

Text::Format seems more appropriate for "big and serious". No doubt it
is an excellent lib. Your code is increadably well written as always.
Any chance I can include with Mega Modules?

T.

6

I've been observing this discussion, and I'm wondering why people
wouldn't just use Text::Format, instead. It does all of this and
allows for hyphenation, too.

Probably b/c of "quick and dirty".

We have 10 loc vs. 1000 loc plus an addiitonal dependency.

If RubyGems offered an "optional dependency", Text::Hyphen would be such.

Text::Format seems more appropriate for "big and serious". No doubt it
is an excellent lib. Your code is increadably well written as always.
Any chance I can include with Mega Modules?

So long as you comply with the licence as you redistribute, I don't
have an issue with it. On a slightly different aspect, though, I would
suggest that the nature of Mega change a little -- most of it should
probably be implemented as dependencies in RubyGems and provided as a
combined .tar.gz for those who don't want it as such. I have thoughts
on how this could be implemented in Rake, but I donno.

-austin

···

On 9/15/05, Trans <transfire@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca