Home > Archive > PerlTk > November 2006 > RFC: proposed Tk::DiffText megawidget
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
RFC: proposed Tk::DiffText megawidget
|
|
| Michael Carman 2006-11-10, 6:58 pm |
| I recently contributed a patch to tidyview to allow it to preview
Perl::Tidy changes as colorized diffs. Leif Eriksen (tidyview's author)
suggested making the functionality available as Perl/Tk megawidget. I
thought that was an interesting idea and have started work on it, but
I'd like some feedback from the community.
Tk::DiffText (working name) creates a Frame based composite widget
containing two ROText widgets. Each text area has a gutter for
displaying line numbers. Everything is locked to a single scrollbar.
At present the class has one method, diff(), which takes two data
arguments (normally file names, but it also accepts filehandles or raw
data), does a "diff" on them, and loads the marked up results into the
ROText widgets. There are a few options as well; e.g. ingoring case and
whitespace or showing differences within a line and not just between
lines.
This is *not* intended to replace the many fine diff/merge tools
available. It just brings basic diff capabilities to Tk apps in a
simple manner.
I'm soliciting feedback about interest, utility, choice of namespace,
and (most importantly) the API. This one method suits my purposes, but
I'm curious about how others would want to use it. Is there a reason to
allow loading a single frame without reloading both? Should the ROText
subwidgets be advertised to allow direct access to them? Maybe you
think I should use Text widgets instead of ROText. A richer API would
probably make the implementation more difficult, so I don't want to
overdo it unnecessarily.
-mjc
| |
| smallpond@juno.com 2006-11-16, 6:59 pm |
| Michael Carman wrote:
> I recently contributed a patch to tidyview to allow it to preview
> Perl::Tidy changes as colorized diffs. Leif Eriksen (tidyview's author)
> suggested making the functionality available as Perl/Tk megawidget. I
> thought that was an interesting idea and have started work on it, but
> I'd like some feedback from the community.
>
> Tk::DiffText (working name) creates a Frame based composite widget
> containing two ROText widgets. Each text area has a gutter for
> displaying line numbers. Everything is locked to a single scrollbar.
>
> At present the class has one method, diff(), which takes two data
> arguments (normally file names, but it also accepts filehandles or raw
> data), does a "diff" on them, and loads the marked up results into the
> ROText widgets. There are a few options as well; e.g. ingoring case and
> whitespace or showing differences within a line and not just between
> lines.
>
> This is *not* intended to replace the many fine diff/merge tools
> available. It just brings basic diff capabilities to Tk apps in a
> simple manner.
>
> I'm soliciting feedback about interest, utility, choice of namespace,
> and (most importantly) the API. This one method suits my purposes, but
> I'm curious about how others would want to use it. Is there a reason to
> allow loading a single frame without reloading both? Should the ROText
> subwidgets be advertised to allow direct access to them? Maybe you
> think I should use Text widgets instead of ROText. A richer API would
> probably make the implementation more difficult, so I don't want to
> overdo it unnecessarily.
>
> -mjc
Sounds interesting. A couple of things I thought of:
Make character set a configure option?
Doing file I/O seemed too unrelated to me at first, but then I
realized that for very large files, you don't want to read them all
into memory at once. Do you read a portion of the files? Can
you configure the amount?
-- S
| |
| Slaven Rezic 2006-11-16, 6:59 pm |
| smallpond@juno.com writes:
[...]
>
> Sounds interesting. A couple of things I thought of:
>
> Make character set a configure option?
I don't think this should be done in Tk::DiffText. Rather one should
use filehandles and mark the handles with the correct encoding (e.g.
by using binmode($handle, ":encoding(....)"))
Regards,
Slaven
--
Slaven Rezic - slaven <at> rezic <dot> de
Start a WWW browser - OS independent:
http://user.cs.tu-berlin.de/~eserte...erl/WWWBrowser/
| |
| Michael Carman 2006-11-16, 6:59 pm |
| On Nov 16, 10:36 am, smallp...@juno.com wrote:
>
> Doing file I/O seemed too unrelated to me at first, but then I
> realized that for very large files, you don't want to read them all
> into memory at once. Do you read a portion of the files?
No. Everything has to be in memory to do the comparison. The module is
a little memory-hostile at the moment. Pre-release versions required at
least three copies of each file (raw input, diff output, and Text
widget contents) and possibly a fourth (if you passed in a file as a
string). I've eliminated one of the copies already and have some ideas
for further improvements but they will require architectural changes.
No matter what I do, passing in raw data will always result in having
at least two copies in memory.
The real reason for supporting filehandles is to allow the user to set
IO layers (as Slaven deduced) and to allow capturing from another
process' STDOUT. (Hopefully, I haven't tried this yet.)
-mjc
|
|
|
|
|