Perl just saved me a heck of a lot of time, although I had to do a little old-school work too. I ended up creating a little edit decision list program.

The other night I needed to edit a really long article for The Perl Review. The computer screen just wasn't doing it, so I printed it, cut it up, rearranged the bits, and pasted them up. Now the really long article was cut down to something that would actually fit in the magazine.

From there, I had to transform the original text into the hard-copy pasted-up version I had. I could cut-and-paste all the ranges, of which there are many, but that would take a lot of mouse work and window switching. All the lines on the hard copy had line numbers, so I knew which lines numbers I wanted where.

Enter Perl. I typed in all the line ranges, in the order I wanted them. I then read those, parsed them, and printed out the corresponding line of the original file.

That gets me pretty close to a point where I can go back to the normal editing process.

#!/usr/bin/perl

my @lines = do { open F, "article.pod"; ( undef, <F> ); };

foreach ( <DATA> )
    {
    my( $start, $stop ) = m/(\d+).*?(\d+)/g;
    
    print "\n";
    foreach my $line ( $start .. $stop )
        {
        print $lines[$line];
        }
    print "\n";
    }


__DATA__
10-24
60-65
57-60
65-69
113-115
42-45
51-53
70
89
81
76-77
85
93-94
99-98
103-105
198-224
248-253
244-247
225-243
255-280
46-49
116-122
55-56
281-336
25-37
399-416
5-8
521-524
[download]

The only tricky part of the code is the array indexing. The line numbers start at 1, but Perl starts at 0. When I read the original file, I put an undef in the zero-th position of @lines. Then, everything lines up and I don't need any ugly offsets in the code. I probably could have fooled with the deprecated $[, but the undef works just fine.