Repository navigation
difflib side by side diff support, diff.py s/b/s HTML option #40030
Description
| BPO | 914575 |
|---|---|
| Nosy | @tim-one, @loewis, @doerwalter, @brettcannon, @rhettinger |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2004-08-29.22:40:57.000>
created_at = <Date 2004-03-11.23:50:27.000>
labels = ['extension-modules']
title = 'difflib side by side diff support, diff.py s/b/s HTML option'
updated_at = <Date 2004-08-29.22:40:57.000>
user = 'https://bugs.python.org/dmgass'bugs.python.org fields:
activity = <Date 2004-08-29.22:40:57.000>
actor = 'tim.peters'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2004-03-11.23:50:27.000>
creator = 'dmgass'
dependencies = []
files = ['5852', '5853', '5854', '5855', '5856', '5857', '5858', '5859', '5860', '5861', '5862', '5863', '5864', '5865', '5866', '5867', '5868', '5869']
hgrepos = []
issue_num = 914575
keywords = ['patch']
message_count = 58.0
messages = ['45507', '45508', '45509', '45510', '45511', '45512', '45513', '45514', '45515', '45516', '45517', '45518', '45519', '45520', '45521', '45522', '45523', '45524', '45525', '45526', '45527', '45528', '45529', '45530', '45531', '45532', '45533', '45534', '45535', '45536', '45537', '45538', '45539', '45540', '45541', '45542', '45543', '45544', '45545', '45546', '45547', '45548', '45549', '45550', '45551', '45552', '45553', '45554', '45555', '45556', '45557', '45558', '45559', '45560', '45561', '45562', '45563', '45564']
nosy_count = 9.0
nosy_names = ['tim.peters', 'loewis', 'doerwalter', 'nnorwitz', 'brett.cannon', 'rhettinger', 'jimjjewett', 'dmgass', 'asouzis']
pr_nums = []
priority = 'high'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue914575'
versions = ['Python 2.4']
Activity
dmgass commentedon Mar 11, 2004
lib/difflib.py:
Added support for generating side by side differences.
Intended to be used for generating HTML pages but is
generic where it can be used for other types of markup.
tools/scripts/diff.py:
Added -m option to use above patch to generate an
HTML page of side by side differences between two
files. The existing -c option when used with the new -m
option controls whether contextual differences are
shown or whether the entire file is displayed (number of
context lines is controlled by existing -l option).
NOTES:
(1) Textual context diffs were included as requested. In
addition, full and contextual HTML side by side
differences (that this patch generated) are also included
to assist in analyzing the differences and showing an
example.
(2) If this functionality is worthy of inclusion in the
standard python distribution, I am willing to provide more
documentation or make modifications to change the
interface or make improvements.
(3) When using Internet Explorer some font sizes seem
to skew things a bit. Generally I've found the "smallest"
to work best. If someone knows why, I'd be interested
in making any necessary adjustments in the generated
HTML.
dmgass commentedon Apr 9, 2004
Logged In: YES
user_id=995755
In the time since submission I've found that the interface to
the chgFmt and lineFmt functions (arguments of mdiff) should
include both the line number and an indication of side
(from/to). The use for it I've found is for dropping anchors
into the generated markup that it can be hyperlinked from
elsewhere.
dmgass commentedon Apr 29, 2004
Logged In: YES
user_id=995755
Also, I will need to submit the fix for making it behave nice
when there are no differences!!
jimjjewett commentedon Jun 11, 2004
Logged In: YES
user_id=764593
Thank you; I have often wished for side-by-side, but not quite
badly enough to write it.
That said, I would recommend some tweaks to the formatting.
"font" is deprecated; "span" would be better.
On my display, the "next" lines don't always seem to be
counted (except the first one), so that the anchors column is
not lined up with the others. (This would also be fixed by the
separate rows suggestion.)
Ideally, the line numbers would be in a separate column from
the code, to make cut'n'paste easier. (Then you could replace
font.num (or span.num) with td.linenum.)
Ideally, each change group should be a separate row in the
table. (I realize that this probably means a two-layer iterator,
so that the line breaks and blank lines can be inserted
correctly in the code columns.)
dmgass commentedon Jun 24, 2004
Logged In: YES
user_id=995755
I just attached an updated patch. I based the patch on
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I
saw today on viewCVS.
The following enhancements were made:
diff.py for example)
HTML Tidy)
by viewCVS.
HTML less susceptible to browser quirks.
patch.
It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and
cut text from a single column (right now text is selected from
the whole row including both "from" and "to" text and line
numbers.
B) solving the line width issue. Currently the "from" / "to"
column is as wide as the widest line. Any ideas on wrapping
or scrolling?
As of now the only feature I may want to add in the near
future is optional tab expansion.
Thanks to those that have commented here and emailed me
with suggestions and advice!
doerwalter commentedon Jun 25, 2004
Logged In: YES
user_id=89016
Submitting difflib_context.html to validator.w3.org gives 2333
errors. The character encoding is missing and there's no
DOCTYPE declaration. The rest of the errors seem to be
mostly related to the nowrap attribute (which must be written
as nowrap="nowrap", as this is the only allowed value).
Furthermore the patch contains a mix of CR and CRLF
terminated lines.
dmgass commentedon Jul 2, 2004
Logged In: YES
user_id=995755
With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional). Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.
loewis commentedon Jul 15, 2004
Logged In: YES
user_id=21627
The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.
dmgass commentedon Jul 16, 2004
Logged In: YES
user_id=995755
Since I have not gotten any feedback on the user interface I
took the liberty to tweek it the best I thought how. Since I
consider this new functionality very solid I went ahead and
created changes to the documentation and test suite.
Per Martin v. Löwis (loewis) instructions I generated a patch
which hopefully meets his needs. My CVS access is limited to
the web interface and thus the patch is based on the latest
checked in as of today:
python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17
Note, I am not very familiar with .tex but it seemed straight
forward. I editted the file by hand and it should be very close
to what I intended. Unfortunately I am not set up to convert
the .tex to HTML. I may try that next week.
dmgass commentedon Jul 16, 2004
Logged In: YES
user_id=995755
Since I have not gotten any feedback on the user interface I
took the liberty to tweek it the best I thought how. Since I
consider this new functionality very solid I went ahead and
created changes to the documentation and test suite.
Per Martin v. Löwis (loewis) instructions I generated a patch
which hopefully meets his needs. My CVS access is limited to
the web interface and thus the patch is based on the latest
checked in as of today:
python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17
Note, I am not very familiar with .tex but it seemed straight
forward. I editted the file by hand and it should be very close
to what I intended. Unfortunately I am not set up to convert
the .tex to HTML. I may try that next week.
asouzis commentedon Jul 17, 2004
Logged In: YES
user_id=57486
The diffs look cool but if the to and from lines are
identical an exception is thrown:
File "<string>", line 23, in makeDiff
File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
summary=summary))
File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
if not diff_flags[0]:
IndexError: list index out of range
(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)
Perhaps you should add the case of two identical files to
test_difflib.py.
thanks
33 remaining items
dmgass commentedon Aug 10, 2004
Logged In: YES
user_id=995755
Raymond -- I am new to the Python-Dev community so I can
only assume you would be the one to apply this patch and
check it into CVS since this patch is assigned to you.
Because of that and the fact that you have looked it over to
some degree I would like to hear your opinion on when you
think this should get it. It would be helpful to know if it is
going in 2.4 and what work needs to be done on my part. I
would rather do the work sooner than later for everyone's
comfort level. It may be a good break from reading about
@|decorators :-)
I have found documentation on how to generate the HTML
documentation from the .tex file I patched in order to check
my work more accurately. My suspicion is that Linux is the
platform that would be easiest to build the documentation
since it would already have most of the tools (I have a Suse
Linux system at home but am not very familiar with it).
Windows is still the most convenient platform for me to work
under right now. Unfortunately I do not yet have broadband
(or internet) on my Linux home system only dial up on my
home Windows system :-( and high speed on my Windows
system at work. Any suggestions on which platform to use
and the easiest way to obtain all the source files to get
started would be appreciated -- I can be reached directly at
dan.gass_at_gmail_dot_com.
dmgass commentedon Aug 13, 2004
Logged In: YES
user_id=995755
Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never? Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower. In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break. I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping). I
would break on the exact column number (not worrying about
breaking on whitespace). I'll also put some type of
continuation marker in the line number column (probably a
single ">").
I did get a hold of Raymond. He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now. I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.
Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file. My changes are OK.
jimjjewett commentedon Aug 13, 2004
Logged In: YES
user_id=764593
(1) I don't have checkin privs, so I can't help there.
(2) Line wrapping is tricky - I couldn't think of a good way
to do it, which is why I didn't mention it earlier. Your way
sounds as good as any, so long as it is easily overridden
(including a "no wrap" option)
dmgass commentedon Aug 16, 2004
Logged In: YES
user_id=995755
I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.
Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release? It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use. I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.
rhettinger commentedon Aug 16, 2004
Logged In: YES
user_id=80475
+1 on exposing as little of the API as possible.
brettcannon commentedon Aug 17, 2004
Logged In: YES
user_id=357491
+1 on minimizing the API as well. Easier to expose more of an API later
than to retract any part of it.
dmgass commentedon Aug 17, 2004
Logged In: YES
user_id=995755
I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
Based on this and the feedback so far I am proposing the
following API simplifications:
I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods. This should warn those looking at the
internals that things may change in future releases. We may
want to consider making additional public interfaces in the
future when more experience is gained.
HtmlDiff.__init__():
using expand_tabs() string method).
HtmlDiff.make_file():
HtmlDiff.make_table():
remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).
remove 'summary' argument (this added a summary attribute
to the <table> tag and I believe would not be used much if
at all). A user could always do a string search and replace
on the <table> tag to insert this after the fact.
HtmlDiff.make_file():
talked into removing these). These arguments are for
controlling the window title and any markup to be inserted
just above the table. Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).
ANY OTHER API SIMPLIFICATION IDEAS?
brettcannon commentedon Aug 19, 2004
Logged In: YES
user_id=357491
Don't have to look this up to see if this is already supported, but the only
thing that I could see people wanting is a way in inject their own
stylesheet. Otherwise it sounds good to me.
dmgass commentedon Aug 19, 2004
Logged In: YES
user_id=995755
Should we expect the user to search/replace the style sheet
in the generated HTML? I'm on a simplification kick and
this would keep the API from getting bigger. I'm inclined
to do the same for title and headers so I could eliminate
them from the API.
I have completed the line wrapping functionality and the
simplifications/streamlining talked about to date. I'm
currently testing and updating the documentation. Hope to
post it late tonight or tommorow.
If there is anything else that should be changed, now would
be a good time to speak up!
Thanks again for everyone's help.
dmgass commentedon Aug 20, 2004
Logged In: YES
user_id=995755
Updated the patch as follows:
to make_file and make_table methods.
(as discussed).
for the public make_table and make_file methods (as
discussed).
NOTE1
I've attached the patch (you will also need the new file
test_difflib_expect.html). I've zipped the patched code as
well as example side by side differences of the patch. Diffs
ending with _UPDATE.html show differences between the
patched code and the last version of the patched code (what
I've done since my last posting). Diffs ending with
_PATCH.html show differences between the patched code
and what I obtained from CVS a month or so back:
python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17
NOTE2
I will not be monitoring emails or this patch from Saturday
Aug21 thru Wednesday Aug25. When I break my internet
silence I'll see if I've blundered this update (unlikely because I
tested it pretty well but none the less possible). If
everything went well I will be soliciting Python-Dev to try to
get this in alpha3. I need someone with checkin privledges to
do it. Should I be trying to gather more support for its
inclusion or does this only need to be done to convince
someone with checkin privledges to apply the patch?
loewis commentedon Aug 29, 2004
Logged In: YES
user_id=21627
Based on Tim's approval, I have applied this patch as
libdifflib.tex 1.18
difflib.py 1.23
test_difflib.py 1.11
test_difflib_expect.html 1.1
ACKS 1.279
NEWS 1.1118
diff.py 1.4
If you want to make further changes to the code, please
submit them as diff against the current CVS, in a new SF
patch. Please generate this diff through "cvs diff -u" if
possible, as this will put the proper file path into each
chunk, so that patch does not need to ask what file each
chunk applies to.
tim-one commentedon Aug 29, 2004
Logged In: YES
user_id=31435
Dan, there's a problem you need to fix: all .py files in the
core are run thru reindent.py, which, among other things,
chops invisible trailing whitespace off lines. Some of your
new lines in difflib.py and in test_difflib.py do have invisible
trailing whitespace (especially inside triple-quote strings), and
test_difflib fails when that junk is removed.
Repairing this is probably just a matter of running reindent.py
on those files, then generating a new
test_difflib_expect.html. Please verify that's all that's
needed. If you say it is, I'll do that and check in the result.
Else we'll have to revert the checkin.
dmgass commentedon Aug 29, 2004
Logged In: YES
user_id=995755
Tim, sorry for the inconvenience. I ran reindent.py over
all the .py files and duplicated what you saw --
test_difflib.py does fail due to white space being removed
from triple-quoted template strings.
You are correct, the proper action is to run reindent.py
over the .py files and regenerate test_difflib_expect.html.
(It can be done by temporarily uncommenting three lines in
test_difflib.py on the lines following "# temporarily
uncomment".) I went through this exercise and verified the
new expectations are OK. (After regenerating, you may want
to open test_difflib_expect.html just to make sure it
renders reasonably for a sanity check.)
I would volunteer to generate a new patch file but I do not
have direct access to the CVS archives and this would
probably create as much work for you as I save. I
appreciate your offer to help. If there is anything else I
should do let me know by posting here or emailing me
directly at dan.gass at gmail.com.
Thanks,
Dan
tim-one commentedon Aug 29, 2004
Logged In: YES
user_id=31435
Thanks, Dan! I checked the changes in. The new HTML file
wasn't obviously damaged, but since I'm not intimately
familiar with what it's intending to show, I could well be
missing something. If it looked OK to you when you tried it,
I'm not gonna argue <wink>. Looks good!