> man diff:
I read it.
> -d Change the algorithm to perhaps find a smaller set of changes. This
>makes diff slower.
This seems to reduce the number of <'d and >'d lines, not the number
of <<<'d and >>>'d blocks, so it is more or less the opposite of what I am
looking for.
Anyway...
Andre
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | Thanks for meddling with the math parser and array.C. Its always nice to
| > | clean up merge conflicts after a long weekend.
| >
| > Did you really expect that small cleanups would just ignore mathed?
|
| Sort of. Yes.
One option for you then is
> | Thanks for meddling with the math parser and array.C. Its always nice to
> | clean up merge conflicts after a long weekend.
>
> Did you really expect that small cleanups would just ignore mathed?
Sort of. Yes.
Especially if you are cleaning up pieces that are not used anymore [and just
happ
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Thanks for meddling with the math parser and array.C. Its always nice to
| clean up merge conflicts after a long weekend.
Did you really expect that small cleanups would just ignore mathed?
--
Lgb
Thanks for meddling with the math parser and array.C. Its always nice to
clean up merge conflicts after a long weekend.
Andre'
--
André Pönitz . [EMAIL PROTECTED]
> And seeming to be/become stable and bugfree?
Well, it could already draw nested macros of the same kind last time I
had a look...
Andre'
--
André Pönitz [EMAIL PROTECTED]
Andre Poenitz <[EMAIL PROTECTED]> writes:
| It would be nice if mathed could be left (more or less) untouched for a
| couple of days. I have a almost complete rewrite of the Macro stuff in the
| queue which is largish (including some changes to the parser).
And seeming to be/become stable and bu
fear the patch as a whole will break if mathed changes too
far without syncronization. And I certainly would not want to redo the
whole thing.
OTOH, I can't complete the patch right now since I have to do some work
for my main job... So, if you'd please take that into consideration
