You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2006/02/03 13:18:21 UTC
[PATCH] Experimental svn diff -w
Hi,
Let me first make it clear that this is just for experimentation. This
patch is very incomplete, untested and probably buggy.
I'm experimenting with the -w (--ignore-all-space) option for the diff
library, both for 2-way and 3-way diff. This patch is a snapshot of what
I'm doing. I'd like others to take a look at the approach and play with
it for merge and blame.
I've implemented a line normalization function, which currently just drops
all space characters. We can add more options and tune this further. I
also modified the diff3 output routines to output the "modified" (i.e.
"mine") lines for common content rather than the "original" lines. This
obviously does not make any difference when you don't allow different
lines to be treated as equal, but now it is important.
To me, blame seems to work as expected: whitespace-only changes are
"transparent". Also, merge seems to do what I want (afdter the
abovementioned tweak).
The Plan
--------
If people like this, I plan to use the -x option for diff/diff3 options,
as we do for external diffs and allow GNU diff options, e.g.:
svn diff -x '-w'
Candidate options are:
-i --ignore-case (not sure about this; it has encoding problems)
-b --ignore-space-change (for ASCII whitespace)
-w --ignore-all-space (dito)
--strip-trailing-cr (maybe)
I would also like to do -p --show-c-function.
If we want to drag in a regexp library, we could do more general stuff,
but let's start with this basic stuff first.
Comments?
Thanks,
//Peter
Re: [PATCH] Experimental svn diff -w
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 3 Feb 2006, Jim Blandy wrote:
> On 2/3/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> > I've implemented a line normalization function, which currently just drops
> > all space characters.
>
> Have you tried a normalization function which simply replaces all
> whitespace sequences with a single space? Deleting whitespace in most
> programming languages concatenates identifiers, which is a change
> people would usually like to know about.
>
This is the difference between -b and -w. I think having both is useful in
different situations.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Gareth McCaughan <ga...@pobox.com>.
On Saturday 04 February 2006 01:09, Jim Blandy wrote:
> Have you tried a normalization function which simply replaces all
> whitespace sequences with a single space? Deleting whitespace in most
> programming languages concatenates identifiers, which is a change
> people would usually like to know about.
>
> Of course, that wouldn't help us in our current space-before-paren
> situation.
If there were a regex engine (let's say PCRE, for definiteness)
built into Subversion then you could do
svn diff --normalize-by-regex '\s+(\W)' '\1' \
--normalize-by-regex '(\W)\s+' '\1'
to eliminate all whitespace that doesn't have identifier characters
on both sides.
--
Gareth McCaughan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/3/06, Jim Blandy <ji...@red-bean.com> wrote:
> Have you tried a normalization function which simply replaces all
> whitespace sequences with a single space? Deleting whitespace in most
> programming languages concatenates identifiers, which is a change
> people would usually like to know about.
What do other diff programs do in this situation? Do they really
incorporate 'smarts' so that it won't concat identifiers in that
file's programming language? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
> Jim Blandy wrote:
>> On 2/3/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
>>
>>> I've implemented a line normalization function, which currently just
>>> drops
>>> all space characters.
>>
>> Have you tried a normalization function which simply replaces all
>> whitespace sequences with a single space? Deleting whitespace in most
>> programming languages concatenates identifiers, which is a change
>> people would usually like to know about.
>
> Yes, agreed. Basically you can get away with removing all whitespace at
> the start and end of the line, and compressing all other whitespace to
> a single space.
Except in Python (and Fortran (and Assembly) ...), where space at the
beginning of the line is significant. :)
>> Of course, that wouldn't help us in our current space-before-paren
>> situation.
>
> No, that's true. And this is something to keep in mind. Do we wish
> to ignore all whitespace? Or do we want to ignore all changes within
> whitespace; this excludes addition of whitespace where there was no
> whitespace before and the removal of all whitespace.
> Maybe both options should be available.
I think they should, too.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Sander Striker <st...@apache.org>.
Jim Blandy wrote:
> On 2/3/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
>
>>I've implemented a line normalization function, which currently just drops
>>all space characters.
>
> Have you tried a normalization function which simply replaces all
> whitespace sequences with a single space? Deleting whitespace in most
> programming languages concatenates identifiers, which is a change
> people would usually like to know about.
Yes, agreed. Basically you can get away with removing all whitespace at
the start and end of the line, and compressing all other whitespace to
a single space.
> Of course, that wouldn't help us in our current space-before-paren
> situation.
No, that's true. And this is something to keep in mind. Do we wish
to ignore all whitespace? Or do we want to ignore all changes within
whitespace; this excludes addition of whitespace where there was no
whitespace before and the removal of all whitespace.
Maybe both options should be available.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 4 Feb 2006, [UTF-8] Branko �^Libej wrote:
> Peter N. Lundblad wrote:
> > On Sat, 4 Feb 2006, Bruce DeVisser wrote:
> >
> >
> >> Peter wrote:
> >>
> >>> Let me first make it clear that this is just for experimentation. This
> >>> patch is very incomplete, untested and probably buggy.
> >>>
> >> I assume that means tabs will be supported as well. svn source
> >> policy is against tabs, but others have to deal with them.
> >>
> >>
> > Yes, all whitespace characters in the 7-bit ASCII range.
> >
> What about our famous ebcdic port?
>
I thought the ebcdic port was only server-side, but if it includes svnlook
(or the client), I guess Paul will handle this appropriately.
> >> Sander wrote:
> >>
> >>>> -i --ignore-case (not sure about this; it has encoding problems)
> >>>>
> >>> What's the benefit of this option? I'm trying to think of a use
> >>> case...
> >>>
> >> There are case-insensitive programming languages. Suppose a style
> >> standardisation (or standards change) is put into effect the same
> >> as subversion's whitespace standardisation now is: it would be
> >> nice if blame would work.
> >>
> >>
> > This is a good point. And to support this is probably as simple as using
> > apr_toupper and that would work in many cases. My concern is what to do
> > if/when we support other character encodings on the file content than that
> > specified by the locale. I'd like us to do that someday; I don't think
> > it'd be easy to support -i then.
> >
> Second of all, case-folding with toupper is wrong in general. But first
> of all, if we don't know the file's encoding, saying that we support
> case-insensitive diff could do more harm than good.
>
> I'm strongly against even mentioning case-insensitive diff until and
> unless we start noticing a file's internal encoding. And even then,
> case-folding is locale-dependent.
>
Yes, that's why I don't like it. We can't use the C locale-dependent
functions because they use the LC_CTYPE encoding and we can't just include
some parts of the unicode character database, because then we will have to
make up a way to portably get at the locale name... Uh, /me drops -i...
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
> On Sat, 4 Feb 2006, Bruce DeVisser wrote:
>
>
>> Peter wrote:
>>
>>> Let me first make it clear that this is just for experimentation. This
>>> patch is very incomplete, untested and probably buggy.
>>>
>> I assume that means tabs will be supported as well. svn source
>> policy is against tabs, but others have to deal with them.
>>
>>
> Yes, all whitespace characters in the 7-bit ASCII range.
>
What about our famous ebcdic port?
>> Sander wrote:
>>
>>>> -i --ignore-case (not sure about this; it has encoding problems)
>>>>
>>> What's the benefit of this option? I'm trying to think of a use
>>> case...
>>>
>> There are case-insensitive programming languages. Suppose a style
>> standardisation (or standards change) is put into effect the same
>> as subversion's whitespace standardisation now is: it would be
>> nice if blame would work.
>>
>>
> This is a good point. And to support this is probably as simple as using
> apr_toupper and that would work in many cases. My concern is what to do
> if/when we support other character encodings on the file content than that
> specified by the locale. I'd like us to do that someday; I don't think
> it'd be easy to support -i then.
>
Second of all, case-folding with toupper is wrong in general. But first
of all, if we don't know the file's encoding, saying that we support
case-insensitive diff could do more harm than good.
I'm strongly against even mentioning case-insensitive diff until and
unless we start noticing a file's internal encoding. And even then,
case-folding is locale-dependent.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 4 Feb 2006, Bruce DeVisser wrote:
> Peter wrote:
> >Let me first make it clear that this is just for experimentation. This
> >patch is very incomplete, untested and probably buggy.
>
> I assume that means tabs will be supported as well. svn source
> policy is against tabs, but others have to deal with them.
>
Yes, all whitespace characters in the 7-bit ASCII range.
> Sander wrote:
> > >-i --ignore-case (not sure about this; it has encoding problems)
> >
> > What's the benefit of this option? I'm trying to think of a use
> > case...
>
> There are case-insensitive programming languages. Suppose a style
> standardisation (or standards change) is put into effect the same
> as subversion's whitespace standardisation now is: it would be
> nice if blame would work.
>
This is a good point. And to support this is probably as simple as using
apr_toupper and that would work in many cases. My concern is what to do
if/when we support other character encodings on the file content than that
specified by the locale. I'd like us to do that someday; I don't think
it'd be easy to support -i then.
> >
> Sander further wrote:
> > >-b --ignore-space-change (for ASCII whitespace)
> > >-w --ignore-all-space (dito)
> >
> > Can't we just pick one option name?
>
[snip good explanation]
Yes, we need both for different situations as I replied earlier today.
Thansk for your input,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Bruce DeVisser <bm...@sympatico.ca>.
Peter wrote:
>Let me first make it clear that this is just for experimentation. This
>patch is very incomplete, untested and probably buggy.
I assume that means tabs will be supported as well. svn source
policy is against tabs, but others have to deal with them.
The various options proposed cover 99% of my uses of GNU diff,
and dropping any one of them would dramatically decrease that
percentage, so I think they are a good list.
Sander wrote:
> >-i --ignore-case (not sure about this; it has encoding problems)
>
> What's the benefit of this option? I'm trying to think of a use
> case...
There are case-insensitive programming languages. Suppose a style
standardisation (or standards change) is put into effect the same
as subversion's whitespace standardisation now is: it would be
nice if blame would work.
There are case insensitive platforms. If there is any dependence
on filenames in the versioned files relating to those platforms
(include files, directory listings, etc), -i would help. Eg, a
user versions zip archives listings, but depending on
the archive creation tool (of which several may be in use), name
case can be munged; and depending on the listing tool and user
preference, name case can be munged (eg, -L in unzip). Another
example: a makefile is updated using a tool by one user, by hand
by another user, and the two need to be merged together when
there may be unimportant differences in filename case.
>
Sander further wrote:
> >-b --ignore-space-change (for ASCII whitespace)
> >-w --ignore-all-space (dito)
>
> Can't we just pick one option name?
and Jim wrote:
> Have you tried a normalization function which simply replaces all
> whitespace sequences with a single space? Deleting whitespace in most
> programming languages concatenates identifiers, which is a change
> people would usually like to know about.
There seems to be some confusion. This is what -b does,
effectively treating one or more whitespace characters in a row
as a single space. (In GNU diff, whitespace at end of line is
folded into the newline and treated the same as if there were no
whitespace at the end of the line.) Thus the -b option means ignore
changes in the amount of whitespace, but don't ignore an
introduction of a whitespace sequence where none existed before,
or the removal of such a sequence in its entirety.
The -w option, on the other hand, will ignore the complete
removal or introduction of such a sequence.
Both options have their advantages, and I have switched between
them depending on what I'm diffing.
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Jim Blandy <ji...@red-bean.com>.
On 2/3/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> I've implemented a line normalization function, which currently just drops
> all space characters.
Have you tried a normalization function which simply replaces all
whitespace sequences with a single space? Deleting whitespace in most
programming languages concatenates identifiers, which is a change
people would usually like to know about.
Of course, that wouldn't help us in our current space-before-paren situation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Sander Striker <st...@apache.org>.
Peter N. Lundblad wrote:
> On Sun, 5 Feb 2006, Sander Striker wrote:
[...]
>>>My concern is, besides rooneg's good point about being able to use the GNU
>>>diff option names, that we may bloat our own "option space", especially if
>>>we want more diff options later.
>>
>>While this is true, I feel that we are jumping through hoops to not have
>>subcommand specific options. In case of diff, merge (and maybe blame) these
>>are almost unavoidable (with exception of the long option names ofcourse).
>
> I don't understand what you're getting at in the last paragraph. I think
> if we don't got he -x route, we should just include long option names for
> these,
+1.
> even though it seems like the short forms are available (at least
> for the cmdline client). I have no strong feeling about this. Do others
> have an opinion?
It would be nice to have short options available for diff/merge/...,
without having them lost for other purposes. But this would break our
contract of having short options mean the same with all subcommands.
That was what I was getting add. But maybe it's best to just leave the
short options for now. IOW, now I think about it more I agree with
Garrett.
[...]
> Since we're not outputting the normalized lines, there is no difference.
> If we implement --ignore-eol-style, we want to keep some eol marker to
> differentiate the case of no newline at end of file.
Yes, that's the point. I consider the newline at EOF significant enough
not to strip.
> If we just do --ignore-eol, we can just drop the eol marker completely
> when normalizing as brane suggests. Maybe that's more useful.
I don't see that as more useful, just as slightly easier to implement.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sun, 5 Feb 2006, Sander Striker wrote:
> Peter N. Lundblad wrote:
> > On Fri, 3 Feb 2006, Sander Striker wrote:
> [...]
> >> I wonder if we want options to our own code to be passed with -x.
> >> I can see it for eXternal commands.
> >
> > I'm not entirely comfortable with -x/--extensions being used as if our own
> > diff library was some external applications.
>
> Yes, that's what I felt too.
>
> > My concern is, besides rooneg's good point about being able to use the GNU
> > diff option names, that we may bloat our own "option space", especially if
> > we want more diff options later.
>
> While this is true, I feel that we are jumping through hoops to not have
> subcommand specific options. In case of diff, merge (and maybe blame) these
> are almost unavoidable (with exception of the long option names ofcourse).
>
I don't understand what you're getting at in the last paragraph. I think
if we don't got he -x route, we should just include long option names for
these, even though it seems like the short forms are available (at least
for the cmdline client). I have no strong feeling about this. Do others
have an opinion?
> >>>--strip-trailing-cr (maybe)
> >>
> >>Hmm, in that case I would say go for --ignore-eol-style.
> >
> > I'm wondering what exactly the semantics would be. Treat all line endings
> > as the platform line endings, or treat all line endings as LF?
>
> What's the difference? On comparison they will be the same in both
> cases no? In that light normalizing to LF seems easiest, but
> that's a meer implementation detail.
>
Since we're not outputting the normalized lines, there is no difference.
If we implement --ignore-eol-style, we want to keep some eol marker to
differentiate the case of no newline at end of file. If we just do
--ignore-eol, we can just drop the eol marker completely when normalizing
as brane suggests. Maybe that's more useful.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Sander Striker <st...@apache.org>.
Peter N. Lundblad wrote:
> On Fri, 3 Feb 2006, Sander Striker wrote:
[...]
> I reallized that the output routines don't make use of the chunks read by
> the token reading functions, so I'll normalize once when reading the
> chunks.
+1.
[...]
>> I wonder if we want options to our own code to be passed with -x.
>> I can see it for eXternal commands.
>
> I'm not entirely comfortable with -x/--extensions being used as if our own
> diff library was some external applications.
Yes, that's what I felt too.
> My concern is, besides rooneg's good point about being able to use the GNU
> diff option names, that we may bloat our own "option space", especially if
> we want more diff options later.
While this is true, I feel that we are jumping through hoops to not have
subcommand specific options. In case of diff, merge (and maybe blame) these
are almost unavoidable (with exception of the long option names ofcourse).
>>>--strip-trailing-cr (maybe)
>>
>>Hmm, in that case I would say go for --ignore-eol-style.
>
> I'm wondering what exactly the semantics would be. Treat all line endings
> as the platform line endings, or treat all line endings as LF?
What's the difference? On comparison they will be the same in both
cases no? In that light normalizing to LF seems easiest, but
that's a meer implementation detail.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
> On Fri, 3 Feb 2006, Sander Striker wrote:
>> eter N. Lundblad wrote:
>>> -strip-trailing-cr (maybe)
>>>
>> Hmm, in that case I would say go for --ignore-eol-style.
> I'm wondering what exactly the semantics would be. Treat all line endings
> as the platform line endings, or treat all line endings as LF?
>
Do the same as when you're ignoring whitespace: when you normalize the
token, strip away any EOL sequence. When outputting, use the current line.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 3 Feb 2006, Sander Striker wrote:
> Peter N. Lundblad wrote:
> > Hi,
> >
> > Let me first make it clear that this is just for experimentation. This
> > patch is very incomplete, untested and probably buggy.
>
> Great disclaimer ;).
>
Having seen other toy patches been put down as if they were intended for
commit, I thought that was safest:-)
> > I've implemented a line normalization function, which currently just drops
> > all space characters.
>
> Ah, yes, that's one way to do it, and cheaper than the other way: providing a
> different token compare function.
>
I reallized that the output routines don't make use of the chunks read by
the token reading functions, so I'll normalize once when reading the
chunks.
> > To me, blame seems to work as expected: whitespace-only changes are
> > "transparent". Also, merge seems to do what I want (afdter the
> > abovementioned tweak).
> >
> > The Plan
> > --------
> >
> > If people like this, I plan to use the -x option for diff/diff3 options,
> > as we do for external diffs and allow GNU diff options, e.g.:
> > svn diff -x '-w'
>
> I wonder if we want options to our own code to be passed with -x.
> I can see it for eXternal commands.
>
I'm not entirely comfortable with -x/--extensions being used as if our own
diff library was some external applications. My concern is, besides
rooneg's good point about being able to use the GNU diff option names,
that we may bloat our own "option space", especially if we want more diff
options later.
> > --strip-trailing-cr (maybe)
>
> Hmm, in that case I would say go for --ignore-eol-style.
>
I'm wondering what exactly the semantics would be. Treat all line endings
as the platform line endings, or treat all line endings as LF?
> > I would also like to do -p --show-c-function.
>
> I guess you only need to modify the output functions to implement
> this.
>
Yeah.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Sander Striker <s....@striker.nl>.
Peter N. Lundblad wrote:
> Hi,
>
> Let me first make it clear that this is just for experimentation. This
> patch is very incomplete, untested and probably buggy.
Great disclaimer ;).
> I'm experimenting with the -w (--ignore-all-space) option for the diff
> library, both for 2-way and 3-way diff. This patch is a snapshot of what
> I'm doing. I'd like others to take a look at the approach and play with
> it for merge and blame.
>
> I've implemented a line normalization function, which currently just drops
> all space characters.
Ah, yes, that's one way to do it, and cheaper than the other way: providing a
different token compare function.
> We can add more options and tune this further. I
> also modified the diff3 output routines to output the "modified" (i.e.
> "mine") lines for common content rather than the "original" lines. This
> obviously does not make any difference when you don't allow different
> lines to be treated as equal, but now it is important.
Right, makes sense.
> To me, blame seems to work as expected: whitespace-only changes are
> "transparent". Also, merge seems to do what I want (afdter the
> abovementioned tweak).
>
> The Plan
> --------
>
> If people like this, I plan to use the -x option for diff/diff3 options,
> as we do for external diffs and allow GNU diff options, e.g.:
> svn diff -x '-w'
I wonder if we want options to our own code to be passed with -x.
I can see it for eXternal commands.
> Candidate options are:
> -i --ignore-case (not sure about this; it has encoding problems)
What's the benefit of this option? I'm trying to think of a use
case...
> -b --ignore-space-change (for ASCII whitespace)
> -w --ignore-all-space (dito)
Can't we just pick one option name?
> --strip-trailing-cr (maybe)
Hmm, in that case I would say go for --ignore-eol-style.
> I would also like to do -p --show-c-function.
I guess you only need to modify the output functions to implement
this.
> If we want to drag in a regexp library, we could do more general stuff,
> but let's start with this basic stuff first.
>
> Comments?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 3 Feb 2006 dberlin@dberlin.org wrote:
> > I would also like to do -p --show-c-function.
> >
>
>
> I went to go attack this a few months ago, but at least all the diff
> programs i'm aware of do this using a regexp library.
>
> Personally, I can't see another way either unless you are going to write
> the same regexp matcher by hand.
>
> (The regexp is somewhat trivial, as is changing the output functions).
>
For -p, it is ^[a-zA-Z_$]; I guess we don't need a regex library for
that. If we want -F, we'll need a regex library, yes.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by db...@dberlin.org.
> Hi,
>
> Let me first make it cle
>
> I would also like to do -p --show-c-function.
>
I went to go attack this a few months ago, but at least all the diff
programs i'm aware of do this using a regexp library.
Personally, I can't see another way either unless you are going to write
the same regexp matcher by hand.
(The regexp is somewhat trivial, as is changing the output functions).
> If we want to drag in a regexp library, we could do more general stuff,
> but let's start with this basic stuff first.
>
> Comments?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/3/06, Marc Sherman <ms...@projectile.ca> wrote:
> Peter N. Lundblad wrote:
> >
> > If people like this, I plan to use the -x option for diff/diff3 options,
> > as we do for external diffs and allow GNU diff options, e.g.:
> > svn diff -x '-w'
> >
> > Candidate options are:
> > -i --ignore-case (not sure about this; it has encoding problems)
> > -b --ignore-space-change (for ASCII whitespace)
> > -w --ignore-all-space (dito)
> > --strip-trailing-cr (maybe)
>
> If these options are being handled by the built in diff library,
> shouldn't they be real options to the svn command, rather than parsed
> out of the -x parameter?
No, they should not. We already have precedent for handling diff
options separately from the rest when using external diff tools,
there's no reason to be different for our internal tools. If we did
use regular options, that would mean that our diff options would
pretty much have to be different than those of GNU diff (the most
commonly used external diff tool), which would be pretty annoying for
users.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Marc Sherman <ms...@projectile.ca>.
Peter N. Lundblad wrote:
>
> If people like this, I plan to use the -x option for diff/diff3 options,
> as we do for external diffs and allow GNU diff options, e.g.:
> svn diff -x '-w'
>
> Candidate options are:
> -i --ignore-case (not sure about this; it has encoding problems)
> -b --ignore-space-change (for ASCII whitespace)
> -w --ignore-all-space (dito)
> --strip-trailing-cr (maybe)
If these options are being handled by the built in diff library,
shouldn't they be real options to the svn command, rather than parsed
out of the -x parameter?
By the way: very cool. Cool enough that I just changed my mind about
how fast I think 1.4 should be pushed out :). At my job, our trunk
branch just went through a major whitespace change due to an exception
handling refactor, and I've been doing all the merges to trunk by hand.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Experimental svn diff -w
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/3/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> The Plan
> --------
>
> If people like this, I plan to use the -x option for diff/diff3 options,
> as we do for external diffs and allow GNU diff options, e.g.:
> svn diff -x '-w'
>
> Candidate options are:
> -i --ignore-case (not sure about this; it has encoding problems)
I don't see this as especially useful...
> -b --ignore-space-change (for ASCII whitespace)
> -w --ignore-all-space (dito)
I've only ever used -w, FWIW.
> --strip-trailing-cr (maybe)
Might be useful I guess.
> I would also like to do -p --show-c-function.
I will build a statue in your honor and worship you as a god. ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org