Activity for tkdiff
-
Andreas Metzler posted a comment on ticket #100
Hello, sorry in hindsight I see that my report should have been more verbose: I looked at the licenses/copyright info and found that it obviously had not seen any update for 20 years while SVN showed more than 150 changes after that. That could not be right. Looking over the commiters I saw that their number was small (no one-commit authors) and therefore suggested the list above. I did not do a full in depth review. I am no lawyer either but the FSF site has some guidance where the bar for a copyright...
-
DorothyR modified a comment on ticket #100
I'm not sure I (dorothy robinson) really deserve a copyright here. I did act as interim mantainer for, well, a fairly long interim, but I mostly just tweaked the user interface and command parsing a little bit, and accepted some patches.
-
I'm not sure I (dorothy robinson) really deserve a copyright here. I did act as interim mantainer for, well, a fairly long interim, but I mostly just tweaked the user interface an command parsing a little bit, and accepted some patches.
-
michael-m posted a comment on ticket #100
Not entirely certain of the rules (if any) governing this. While Bryan was clearly a major force in the early days of the tool and has contributed much - not only in actual code, but even an IDEA that I subsequently utilized FAR LATER, and thus is clearly a missing attribution (as is Dorothy, who presided longer than anyone, over uncounted modifications by my reckoning); yet badukaire (according to my records) contributed a patch (not in 2012, but 2005?) which then languished until I joined in 2017!!...
-
Here's the relevant tcl9.0 manpage https://www.tcl-lang.org/man/tcl9.0/TclCmd/chan.html#M48 On Sun, Jun 22, 2025 at 12:52 PM DorothyR dorothyr@users.sourceforge.net wrote: Filetype gives a clue, although I don't know how or why this happened $ file * cvsdiff: POSIX shell script, ASCII text executable dirdiff: POSIX shell script, ISO-8859 text executable tkdirdiff: POSIX shell script, ISO-8859 text executable [bugs:#101] Invalid multibyte or wide char in test file causes crash with tk9.0 Status: open...
-
Oh great it's the copyright string: 776:Copyright � 1999-2005 Paul Mackerras Here's the relevant tcl9.0 document https://www.tcl-lang.org/man/tcl9.0/TclCmd/chan.html#M48
-
Oh great it's the copyright string: 776:Copyright � 1999-2005 Paul Mackerras
-
Filetype gives a clue, although I don't know how or why this happened $ file * cvsdiff: POSIX shell script, ASCII text executable dirdiff: POSIX shell script, ISO-8859 text executable tkdirdiff: POSIX shell script, ISO-8859 text executable
-
Invalid multibyte or wide char in test file causes crash with tk9.0
-
Please update copyright info in README.txt
-
avoid TclTk 9.0 'namespace' interactions
-
improper logic supplying default revision values to 2/3rds of 12 SCMS repaired
-
Primarily to support TclTk 9.0 (and compensate for lost V8.x.x deprecations)
-
Dorothy is correct. The preference in question is on the 'General' tab of the Preferences dialog window and labeled 'Text window size' expressed in a WidthxHeight format. As the windows are side by side, that means the width of the TOOL is actually computed as TWICE the requested width (plus all the other things like scrollbars, etc). Furthermore, on the 'Appearance' tab, another preference (Text widget options) allows you to specify the FONT those text windows should USE, and is the base unit of...
-
In Edit->Preferences-General there's a Text Window Size setting. It doesn't appear do do anything on Apply, but if you Save and then restart it will be used next time.
-
Skeet Monker posted a comment on discussion Help
Love tkdiff !! The best visual diff'ing tool I have found. By default, tkdiff opens in a window that is about 75% the width of my screen. Each time I manually stretch the window to widen it to about 98% - 100% width. Is there a preference setting, or command option, to change the default window width ? Is there a line in the tkdiff script which could be edited to expand the default window width ? Thanks much!
-
Wow. I hate to admit this, but you ARE correct (frankly, that whole line should have been ELIMINATED a long time ago - which is what I intend to do going forward). Feel free to delete it as it is ALREADY covered by the one on line#32! Better yet, place an octothorp (#) as the first char ON that line (making it a comment); that way you'll still have the same line numbers in YOUR script as the 'official' one, in case you need to report yet MORE issues! The only reason it worked until now is because...
-
Sait Umar posted a comment on ticket #99
I have the line 32 but also line 15359
-
Wait - line #32 (package require Tk 8.5-) should be the ONLY place to have needed editing -- where (and why) did you make a SECOND edit?? A text searches only turns up seven additional occurrences of a 8.5 string of text, ALL of which are buried within comments, and as documentation, need not change NOR have any effect whatsoever.
-
Yes, putting 8.5- works as well (in two places). Thanks!
-
OK - so with regard to the version-check failure. I personally would contend that this is a coding bug, but whomever wrote it originally probably failed to interpret closely the exact syntax required to express the notion of a minimum, but open-ended semantic. Instead, what was actually written was a minimum, but terminated at the next MAJOR version. Accordingly, while you stated changing the version (from 8.5 to 9.0 worked for you, the real fix should be the value "8.5-" (note the trailing dash...
-
In a general sense, perhaps. But by and large, TkDiff is written well within the bounds of classic TCL scripting only, and underwent a serious (>70%) code refactoring in the V8.5-8.6 time frame, making it thus relatively impervious to a majority of changes taking place in version 9.0. Such changes are mostly those of prior announced deprecations finally being removed because of the now new MAJOR version number(eg. 8 -->> 9). Many of whose 'deprecations' date back to pre-V8.6 which, given the glacial...
-
guardus posted a comment on ticket #99
Tcl 9 is incompatible with 8. See below links for major incompatibilities and more info. https://www.tcl-lang.org/software/tcltk/9.0.html https://core.tcl-lang.org/tcl/wiki?name=Migrating+scripts+to+Tcl+9 https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9 https://github.com/apnadkarni/tcl9-migrate
-
Gonna need some time to investigate. Technically the version check in TkDiff should only require a MINIMUM of TK 8.5, so I don't understand WHY 9.0 (clearly more recent) is unacceptable. The fact you say it seems to RUN is encouraging (it SHOULD, as Tcl/Tk has a history of generally maintaining backward compatibility). Post anything else you find to this ticket and I'll do the same with what I can learn.
-
Not compatible with tk 9.0
-
tkdiff released /README.txt
-
Update the README to say that the tk8.5 that comes with MacOS will not work, and recommend the version on Homebrew
-
Rui Chen posted a comment on ticket #98
yeah, I have an open PR on this. Can you add some warning notes in the README or script about the default tcl-tk? (and recommend user to install tcl-tk, if they install via brew, they will get it though)
-
I don't know when it started, but I get the same error just by invoking /usr/bin/wish (shell wrapper to /System/Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish) From Googling I get that this is a code signature problem with apple's wish. Anyway, invoking the default tcl-tk has produced a deprecation warning for years now, and I believe tkdiff hasn't run on it for several releases and w always say to use homebrew or macports. I think homebrew tcl-tk should be a...
-
tkdiff 5.7 does not work with macos tcl-tk (8.5)
-
highlight not working for last line difference
-
view -> inline compare (recursive) requires a reload to highlight changes
-
Well, a LOT has happened between V4.2 and V5.6; so the fact they might behave marginally different between then (over a decade ago) and now is not terribly descriptive of a "problem". Back then, the recursive approach reported EVERYTHING different in any given pair of lines. Over the past several years (and intervening releases) the recursive approach has become considerably more detailed and configurable. Nowadays you can specify exactly WHICH (if any) of the various suppression idioms (Blanks,...
-
Official TkDiff Version 5.7 is released
-
-
-
forgot to bump release to 5.7
-
chglog updated for release 5.7
-
OK. Turns out there were multiple issues (almost a wonder it functioned as well as it did) but nevertheless the fix(es) are now completed. For the record, the OBSERVED issue only involved Diff hunks whose "highlight-able" size (in lines) was SOME multiple of 5 PLUS 1; whereby the "plus 1" (aka that FINAL line) failed to get marked-up. As this is rather difficult to anticipate and CLEARLY data dependent, an updated release will be forthcoming shortly. Thank you again, both for spotting and reporting...
-
Inline instantiation realigned: prevents Heuristic+1 dropouts; broken syntax; better reading
-
Bookmark annotation prompt now tracks instance AFTER 1st use
-
highlight not working for last line difference
-
My, what sharp little eyes you have! All kidding aside, you appear to be correct, although it may take a little time to work out the exact triggering situation (eg. is it ANY 16-line hunk, the last physical hunk, only at file EOL, etc.). The 61 suggests its not some "power-of-2" related issue, but we will find out eventually. I applaud your industriousness for finding even the beginning of a "pattern". Will report more after I do some investigating. Standby.
-
Markku Ilmanen created ticket #97
highlight not working for last line difference
-
Add missing trigger event when recursive inlines are activated
-
rob m posted a comment on ticket #96
thanks! i just upgraded from 4.2 -> 5.6 so it is just the data point i have even if it is not all that useful. my tkdiffrc defaults to inline recursive to off but i like to toggle it on / off when looking at diffs to point out non-obvious things for whatever line i happen to be looking at. thanks again.
-
view -> inline compare (recursive) requires a reload to highlight changes
-
Well, a LOT has happened between V4.2 and V5.6; so the fact they might behave marginally different between then (over a decade ago) and now is not terribly descriptive of a "problem". Back then, the recursive approach reported EVERYTHING different in any given pair of lines. Over the past several years (and intervening releases) the recursive approach has become considerably more detailed and configurable. Nowadays you can specify exactly WHICH (if any) of the various suppression idioms (Blanks,...
-
tkdiff 5.6 with patch 189 on Ubuntu 22.04.3 LTS x64
-
view -> inline compare (recursive) requires a reload to highlight changes
-
Remove superfluos checks for tk_version 8.5
-
For MacOS, don't override the color options if Tk >=8.6, since it now handles the OS dark/light theming correctly.
-
Miscellaneous fixes:
-
Adjust math to attempt CENTERING Thumb of the DiffMap pseudo-scrollbar relative to the colorbars.
-
diff against '/dev/null' failes
-
Fair enough. While it seems a bit tedious to go to the trouble of running diff just to prove whats readily known, I agree the operational disruption (aborting) could be annoying. However, your suggested patch needs to handle more than just a Unix-like world (eg. "nul" on a Windows platform). As its likely you've already adjusted your own copy (having diagnosed the problem), the official fix will be available in an upcoming release (whenever that next occurs). Thanks for reporting the issue.
-
Allow implied "null content" (eg. UNIX "/dev/null" or Windows "nul") files to Diff, despite the obvious result.
-
Ubuntu 22.04.3 LTS x64
-
diff against '/dev/null' failes
-
Well, my reading of that recommendation, is you do that if you REQUIRE a specific SHELL to process the request. I suppose I could go look at the TCL SrcCode at how "exec" is implemented, but given that the user can cause the problem to disappear by changing the choice of SHELL in his environment, I'm fairly certain TCL is making use of it. That wouldn't logically happen if it always used /bin/sh. But the TCSH error report did talk about the rather odd (to me) arrangement of builtin Vars (status,...
-
Wait, I thought tcl exec ignored the user's shell, and would always use /bin/sh unless you do something like "exec $env(SHELL) ..." This page https://www.tcl-lang.org/man/tcl/TclCmd/exec.htm recommends that, if you want to pipe data generated in tcl to a shell command. The way I understood it, it shouldn't be dealing with the user's shell at all. But I'm notoriously careless about such things, so I could well be wrong.
-
Thanks for the extra info. Not sure how much it helped, BUT.... As Dorothy commented, TCSH itself isn't NECESSARILY the problem (she notes zero issues). This suggests (as she indicated) an "environmental" issue peculiar to your machine(s). And this is where things could get "sticky" - given something I stumbled across (thanks to Google). I found an old(er) RedHat bugzilla report (circa 2012, number 638995) that indicated an unfortunate patch in TCSH itself regarding how the exit code of a Shell command...
-
trod310 posted a comment on ticket #12
attachment for previous posting. Where it says Attachment: tkdiff works
-
Thank you for the reply, and fair enough on requiring more information. Let me try to outline my scenario a little more detailed here. 1. Same server my id is configured with administration rights and user is not. 2. Tkdiff was loaded on a network share and local disk on node with same results for the user “files are identical” 3. How, I execute program from either “network or local disk” location: ./tkdiff CHANGELOG.txt README.txt & Attachment: tkdiff_works As you can see from above the results...
-
I use tcsh so I can attest that it works fine. But since it seems to be related to environment, it makes me wonder if you have an alias for "diff" that invokes it with some options or something.
-
Ummm, OK - but your description is a bit vague. For one you neglected to supply HOW you were invoking the tool (what does your commandline look like?). You suggest that done thru BASH all is OK, but thru TCSH it 'fails'; but TECHNICALLY speaking "Files are identical" is merely a STATUS message - not a failure. Yet I'll presume you have actually provided some kind of filenames OF WHICH you honestly believe differences SHOULD occur. Perhaps a larger snapshot would have conveyed more information? For...
-
tkdiff message Files are Identical
-
Was poking about and noticed this had never been answered. My apologies. As of version 5.0, TkDiff (roughly June of 2020) has had the ability to SPECIFY which Version Control System you would prefer to use. Prior to that time, there was a fixed precedence list of all the various choices and the first one POSSIBLE was always chosen. Nowadays, while TkDiff still checks for which systems appear to be available, it will permit ANY that ARE found to be SELECTED as the "preferred" choice for any individual...
-
tkdiff 5.6 jumping around
-
All's well that ends well? Closing the ticket. Thanks for reporting (it's how things get better). For what its worth, a general review of the code under concern suggests it should NOT have been able to occur as described, but that doesn't mean it didn't happen for you. Apparently your computer wished to take off for the Thanksgiving break a day or two early (lol)! We will take this up should it ever be reported again.
-
Well, the problem has disappeared now. It was a problem on multiple machines. I presume some of the upgrades to Fedora 37 has fixed the problem. Must have been some graphical glitch. Thanks for your answers and if I see it again I will report it.
-
You can safely ignore the error message. While I agree it shouldn't happen, it is innocuous and unrelated to the original problem. Its most likely nothing but an unfortunate confluence of your mouse position at the time the main display comes into existence, and then happens to DETECT the mouse being moved OUT of some screen element that was expected to have popped-up a ToolTip (which never happened, because the move INTO the screen element was never seen). I've made a note to repair this.
-
Thank you for the extensive explanation. The problem is happening on desktop machines running Fedora 37 Linux, under KDE and NVIDIA graphics card. I just tried this on my laptop that is also running the same Fedora 37 but has Intel HD graphics. I tkdiff'ed the same files as on desktop and the jumping around is not there. I got an error message the first time I ran it but not on subsequent runs. The error messahe on laptop (I did not get this on desltop) was: can't read "g(tooltip_id)": no such element...
-
Your description comes across as somewhat vague; Not exactly sure what is meant by "jumping up and down". Presuming you are correct about no changes to the Tcl/Tk versions in the Fedora upgrade you made, I can only comment on the nature of the changes made for TkDiff V5.6. You should not have needed to remove the prior ".tkdiffrc" file, as all that would do is revert your personal preferences from whatever you had saved them as to NOW become the values that exist as the hardcoded (builtin) defaults...
-
OK....going back to 5..5.3 has the same problem, which it did not have before. The differnce is that I have updated my systems from Fedora 36 to Fedora 37. Versions of tk and tcl dif not change, 8.6.12.
-
tkdiff 5.6 jumping around
-
Official TkDiff Version 5.6 Released
-
merge window issues TK errors !
-
-
-
V5.6
-
Mostly good news. It definitely is a INTEGER .vs. REAL problem, but it was introduced IN V5.4 (which you reported as working). It appears it was intended to fix the very problem that is now occurring, but failed because it was applied in an incorrect physical location. That it worked (for you) is likely why it worked for me when it was originally fixed - purely on the inconsistencies of data used to test. Just need to reposition the fix properly and push it out the door. Thanks for bringing it to...
-
merge window issues TK errors !
-
Hmmm. That's not good at all. I was able to duplicate the problem (a GOOD thing) and after a QUICK look at the error message, I can see WHY it complains (0.12345.0 is NOT a well formed number). Now all that's required is to find what allowed that to happen. Off the top of my head it LOOKS like some equation was EXPECTED to return an integer - but DIDN'T; I just have to find out why! Sounds easy.... we will see....standby... P.S. - probably should have been written as a BUG ticket (Support is more...
-
shraga created ticket #11
merge window issues TK errors !
-
Official TkDiff Version 5.5.3 Released
-
-
-
Repair typo-caused crash PLUS ineffective prior VPATH-logic fix; also clarify help-info
-
tkdiff -rREV1 crashes
-
LATE UPDATE Its true that I earlier accepted the argument that the change from "OR" logic to "AND" SEEMED to support the notion that only VPATH-based files should be in the vicinity of the code being changed. But (it turns out) that was NOT the reason the "OR" was in place - it exists to recognize the case where VPATH is in effect but only a SINGLE FileSpec was provided, which REQUIRES an SCM to be involved - and if that IS VPATH, then the Rev data MUST be rewritten (because of how VPATH as an SCM...
-
Main screen comparison highlighting disagreees with current line
-
Not a bug. Just a distinction between HOW the two displays go about presenting the data. In the over/under single-line display, bytes are compared in a strictly POSITIONAL method (think arrays of chars where only the two chars in position "N" are ever compared). But in the MAIN display, it is sequential RUNS of chars that are compared (subject to specific suppression categories that mostly deal with optional White Space variations). They INTENTIONALLY do not show the same results (although its not...
-
Duncan Roe created ticket #93
Main screen comparison highlighting disagreees with current line
