Paolo Bonzini wrote:
> > /gl_MODULES(/ {
>
> you would need a "ta" here too, to reset the flag.
>
> > :a
Yes. It is unprobable that there will be a comment on a gl_MODULES line,
but it's more robust to do as you say. Applied.
> > s/)/)/
> > tb
> > N
> > ba
> > :b
> > s,^.*
Since you are already pointing out that your sed program is likely unportable,
I don't know any sed that would choke on it, actually.
/gl_MODULES(/ {
you would need a "ta" here too, to reset the flag.
:a
s/)/)/
tb
N
ba
:b
s,^.*gl_MODULES([[ ]*\([^])]*\).*$,cached_sp
Added wdiff-bugs. The previous messages in this thread:
http://lists.gnu.org/archive/html/bug-gnulib/2008-06/msg00264.html
http://lists.gnu.org/archive/html/bug-gnulib/2008-06/msg00271.html
On Tue, Jun 24, 2008 at 7:00 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Ludovic Courtès wrote:
>> You pr
Ludovic Courtès wrote:
> You probably already thought about it, but why not use `wdiff' for that?
I think before you can recommend wdiff,
1) there should be a release on ftp.gnu.org that does not dump core at
every invocation, (*)
2) the program should support colorized output like we kno
Hi,
Eric Blake <[EMAIL PROTECTED]> writes:
> On m4, I'm currently playing with multiple branches, each of which has
> imported
> a different set of gnulib modules via 'gnulib-tool --import'. I'm finding it
> very difficult to track which modules have been imported to which branches by
> usin
Eric Blake wrote:
> The task of tracking changes to gnulib-cache.m4 would be a lot easier if
> modules were listed on a separate line, as in the proposed patch; then there
> is
> no longer any line-wrapping of the gl_MODULES portion of the file, and the
> added or deleted modules diff independe
