Activity for tkdiff
-
tkdiff released /README.txt
-
DorothyR committed [r199] on Code
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)
-
michael-m modified ticket #97
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.
-
Sait Umar posted a comment on ticket #94
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
-
While the issue is true, it is ALSO of little concern, and was ALREADY repaired, per response to a comment from ticket #90. No immediate release is planned, as the only visible perception is to the content of a normally silent debug-only message. It has zero effect on the operation of the tool itself. It will simply become part of whatever (and whenever) the next release occurs. PS. a much simpler patch is "string trim $opts(customeCode)" (at that same location) avoiding the setup costs of the regular...
-
tkdiff needlessly obeys 2 blank lines as custom code after save prefs
-
tkdiff -d suggested improvements
-
Unneeded. Ability exists via alternate methods.
-
tkdiff needlessly obeys 2 blank lines as custom code after save prefs
-
@vampm also explained that by having Dbg take an arg in braces, the interpreter doesn't need to expand the arg when debugging is off. Neat.
-
@vampm also explained that bu having Dbg take an arg in braces, the interpreter doesn't need to expand the arg when debugging is off. Neat.
-
better recognize EFFECTIVELY empty CustomCode
-
Scrub this: I should have used braces: @@ -1053,6 +1053,7 @@ ############################################################################### proc run-command {cmd {out {}}} { global ASYNc errorCode + Dbg {runcmd cmd=$cmd; out=$out} # Arrange for requested output format (given execution constraints) # N.B> 'fout' will become one of: a channel, a cmd indirection, or empty. A bit counter-intuitive perhaps, but it works. Also @vampm emailed me this: FYI - there is another way you COULD have watched what...
-
tkdiff -d suggested improvements
-
Official TkDiff Version 5.5.2 Released
-
tkdiff -rREV1 crashes
-
tkdiff fails to highlight in-line changed characters
-
-
-
-
Repair missing-Var crashes plus minor initialization faults
-
Agreed
-
Okay - so I cant explain why all the inquire-* procs seem to have lost their initializations for the MSG/msg variables, but they all need them for exactly the reasons already pointed out. Will be fixing that straight away (and because it AGAIN stops crashes, I suppose there will be a V5.5.2 appearing shortly as well). Regarding the "-v", Tkdiff has this odd rule about command line arguments (invented long before I got here) that states: Any arguments not understood to be valid TkDiff arguments are...