On Monday 21 February 2011, Ralf Wildenhues wrote:
> Hi Peter,
>
> * Peter Rosin wrote on Sat, Feb 19, 2011 at 12:28:53AM CET:
> > unindent ()
> > {
> > sed '
> > /^$/b # Nothing to do for empty lines, next line
> > please.
> > x # Get x<indent> into pattern space.
> > /^$/{ # No prior x<indent>, go prepare it.
> > g # Copy this 1st non-blank line into pattern
> > space.
> > s/^\([ ]*\).*/x\1/ # Prepare x<indent> in pattern space.
>
> tab before space, please; or even better, use ...'"$tab"'...
>
> > } # Now: x<indent> in pattern and <line> in hold.
> > G # Build x<indent>\n<line> in pattern space, and
> > h # duplicate it into hold space.
> > s/\n.*$// # Restore x<indent> in pattern space, and
> > x # exchange with the above duplicate in hold
> > space.
> > s/^x\(.*\)\n\1// # Remove leading <indent> from <line>.
> > s/^.*\n//' # Restore <line> when there's no leading
> > <indent>.
> > }
>
> I kinda like this.
>
Me too now. It is definitely clearer and simpler than the first version,
so my previous objection about code complexity has lost much of its force.
> It will be unintelligible without the comments, however.
>
I agree.
> gnulib-tool has a sed comment removal, search for
> $sed_comments. What I wouldn't like is invoking an extra sed in each
> test startup just to remove comments from a helper function, that will
> noticeably slow down things
>
Or the comments could be stripped lazily upon the first invocation of
'unindent'; e.g.:
sed_unindent_prog_raw='
sed program # with comments
'
unindent ()
{
if test x"$sed_unindent_prog" = x; then
sed_unindent_prog=`echo "$sed_unindent_prog_raw" | sed -e 's/ #.*//'`
fi
sed "$sed_unindent_prog" ${1+"$@"}
}
> (it could be removed at config.status time?);
>
But that would make more difficult to test with the same configuration
and different sed implementations.
> OTOH, this function will be faster than our current unindent.
>
> And I'll defer to Stefano's preference for or against complex code in
> the testsuite.
>
I'm ok with the last implementation proposed by Peter, as long as there
are sanity checks for it in the testsuite. I can write those BTW, as
I'm already preparing some other tests performing sanity checks on stuff
in `tests/defs'.
Regards,
Stefano
