diffutils-devel
[Top][All Lists]
Advanced

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

Re: Improvement to choose more logical places for changed regions


From: Piotr Siupa
Subject: Re: Improvement to choose more logical places for changed regions
Date: Sat, 10 Apr 2021 18:39:12 +0200

It has been over two week since my first mail and there is still no answer.
I'm starting to suspect maybe I'm doing something wrong.
I'm quite new to mailing lists and open source. If there are any problems
with what I'm sending, please tell me, so I can fix that. I'm doing what I
can to adhere to your standards but it is always easy for newbies to miss
some important point that everyone assumes is just common knowledge.

Anyway, I've improved the code and removed most/all of the bugs. It's still
not 100% finished but it's not a hasty draft anymore.
This version works well enough for my personal use so I'm not sure if I'm
going to refine the code any further until I get confirmation you're going
to consider including it to the official repository.
I'm attaching the git diff with the current origin/master.

Also, In my previous mail, I wasn't entirely correct about the requirement
to use option `-c` or `-u`.
The "problem" is caused by the memory optimizations and the correct flag to
use is `--horizon-lines`. I think this should remain like that since it
looks very much like an intended optimization.

On Thu, Mar 25, 2021 at 6:01 PM Piotr Siupa <piotrsiupa@gmail.com> wrote:

> Hello,
>
> There is a very common situation when I'm adding/removing an entire
> function to/from e.t.c. The diff often shows the added/removed text to
> start in the middle of the function and end in the middle of the next
> function if its starting lines match. (Attached files "f1" and "f2" have
> some silly pseudo-code which shows an example of that situation when
> diffed.)
> I think this inconvenience can be very easily fixed by using a heuristic
> that the exact position of the changed region should be chosen in that way
> that it starts and ends on the shortest lines possible. This is a simple
> heuristic but it should cover 90% of the cases.
> I've modified the code as a proof of concept (attachment "source_diff")
> and it seems to work quite well. (The code is not quite finished nor tested
> and it requires option -c or -u to work but it's good enough to show the
> idea.) I will finish it if I get a green light for it.
>

Attachment: diff
Description: Binary data


reply via email to

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