On 01-Jan-16, Bram Moolenaar wrote:
>
> I wrote:
>
> > Ken Takata wrote:
> >
> > > 2016/1/1 Fri 4:10:22 UTC+9 Bram Moolenaar wrote:
> > > > > 1. About diff.exe
> > > > >
> > > > > diff.exe from gnuwin32 is 32-bit binary, and it uses gettext and
> > > > > libiconv.
> > > > > Doesn't it conflict with 64-bit builds? diff.exe bundled with the
> > > > > official
> > > > > Vim 7.4 installer doesn't depend on gettext and libiconv, so I think
> > > > > using
> > > > > diff.exe from gvim74.exe is safer.
> > > > >
> > > > > Additionally, diff.exe is installed under the GvimExt directory, but
> > > > > it
> > > > > should be installed to the same directory as gvim.exe.
> > > > >
> > > > > https://github.com/k-takata/vim/commit/3624185df8c304669a6ad4a50d58dea6147cc0ac
> > > >
> > > > It's important that the diff program can handle different line endings.
> > > > There are many that won't work nicely. The diff.exe included in the
> > > > installer is an older version of GNU diffutils.
> > >
> > > Sorry, I don't understand well...
> > > Does the diff.exe included in the installer can handle different line
> > > endings?
> > > Is the diff.exe enough for our purpose? Or do we need more up-to-date GNU
> > > diffutils?
> >
> > The diff.exe I have included works well. I don't expect useful
> > improvements from later versions. When building it with another
> > compiler or libraries it's possible to make it behave worse.
>
> BTW: If someone wants to spend time on this, the best solution would be
> not to use an external diff program. Writing the temp files, invoking
> diff and parsing the result has a lot of overhead.
>
> There is a C# implementation that has a lot of comments, should be
> possible to turn this into a C implementation that we can include in
> Vim: http://www.mathertel.de/Diff/ViewSrc.aspx
> Rewriting it means we can apply the Vim license and have no problems
> distributing it. There are C implementations of diff, but they all
> appear to be either hard to include in Vim or have license issues.
>
> A few remarks:
> - The Item struct has its equivalent as diff_T in Vim.
> - The core algorithm works with an array of numbers. If done properly
> we can use this for lines of text AND for differences between two
> lines. This can improve the diff highlighting for changed lines.
> - The Vim ex_diffupdate() function, where it calls diff_file() and
> diff_read(), is where the algorithm would be invoked.
> - The code can compare two files at a time, the code for handling 3 and
> 4 files already exists in Vim.
> - We can probably drop all the code for writing the temp files and
> reading back the diff. I don't think there is a diff program that
> produces better results (and if there is, we should be able to update
> the code).
> - For short files or files with few differences we could run the
> algorithm on every change to keep the diff updated, instead of the
> workarounds that are currently in place. A simple solution would
> measure the time it takes to run the algorithm and abort if it's
> taking too long (with an option to set the timeout). And abort if the
> user types.
>
> Anyone who would like to work on this?
I have a patch that integrates a drop-in LCS implementation into vim.
It works, and I use it to reduce undo blocks on file reload to the
changes made in the reloaded file. It is also accessible to scripts.
My scripts use it every day.
It works on "string sequences", which is a thin layer that abstracts
access to buffer lines, lists of strings and characters in strings.
It also supports pushing a tokenizer in-between. The tokenizer code
includes a fast default tokenizer with some interesting properties,
and a regex-based tokenizer.
It should not be difficult to use it on a character-wise diff
between a pair of lines.
The only drop-in LCS implementation it currently works with causes
license issues.
I have been wanting to write an implementation of Myers' well-known LCS
algorithm which does not cause license issues, but this takes a bit of
time. I have been adapting LCS implementations for several purposes
already, this is part of my research projects.
Note that the existing diff tools that we all use every day bring in
heuristical speed improvements, and do pre- and postprocessing to
improve the results. These need to be included to achieve the same
level of quality.
My patch also includes the post-processing that we are used to expect,
but this must be re-written as well. And the pre-processing still needs
to be included.
I am also working on improving diff implementations / LCS algorithms for
software development, this is one of my core research and development
projects.
The improvements cannot be limited to work only from within an editor,
so they are first included in a stand-alone diff program.
For this reason, I would not drop support for parsing the output of an
external diff program, it could be worthwhile using it.
I also have an unfinished patch that implements parsing of the output of
a modified external diff program, to make an improved diff display. It
is unfinished and work in progress, and there are quirks, but in my vim
I already use it for all of my diff displays.
--
Olaf Dabrunz (oda <at> fctrace.org)
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
