bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: untabify?


From: Jim Meyering
Subject: Re: untabify?
Date: Mon, 07 Dec 2009 11:05:41 +0100

Bruno Haible wrote:
>> I would be happy to do that to all of gnulib.
>> It is long overdue.
>
> Great!
>
> When? It's a disruptive change: Everyone who has patches on top of gnulib

Actually it need not be disruptive.
You just need a little rigor and a trick or two:

> will have to update these. But since we are in continuous development mode
> constantly, any time is as good as any other time. (Actually, *before* the
> Christmas vacations is better for those of us with little spare time.)
>
> Which set of files? I would say,
>   - m4/*.m4          yes
>   - lib/**/*.[hcy]   yes except the regex module
>     because the regex module is the only major source code for
>     which we still have bidirectional propagation between gnulib and glibc,
>   - lib/*.charset    no, as it needs a different treatment
>   - lib/*.class      no, as it's a binary file
>   - modules/*        no, as it contains Makefile snippets

Once all exclusions like this are recorded in the format suggested
by my little function, it is possible to automate the process of rebasing
one's local changes across the TAB-expanding commit.
I'll post a script or two and detailed instructions soon.

>> perl -MText::Tabs -ni -le \
>>       '$m=/^( *\t[ \t]*)(.*)/; print $m ? expand($1) . $2 : $_'
>
> How is this different from "expand -i"? Also, I would try both "expand"
> and "expand -i" and look at the differences one by one.

It's equivalent, as far as changes induced.

Using perl like that lets me do the update "in place" with a single
efficient command, whereas using expand -i would require a shell loop and
temporary files.  Far less efficient.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]