Activity for tkdiff
-
Duncan Roe posted a comment on ticket #89
The patch below fixed it for me. But you are right about the others: tkdiff failed for me in a clean git repository. I found a CVS repo where cvs diff worked and tkdiff failed there as well. So the attached patch fixes all 3. --- tkdiff 2022/08/29 02:46:16 1.6 +++ tkdiff 2022/08/29 04:07:07 1.7 @@ -3175,6 +3175,7 @@ # rev is what we will tell svn cat to access # cmit is how we express the range to 'svn diff' set cmit(2) [set rev(2) ""] + set MSG [set msg {}] if {$revs == 0} { # Sets up BASE -> WC...
-
michael-m posted a comment on ticket #89
W.r.t. the glitch with MSG: its an admittedly ugly construct that is intended to optionally pass back messaging that may have occurred to the calling proc (hence the uplevels). What I find disconcerting when looking at this again, is I would think to work properly each layer of the call stack should have initialized its OWN local level as having empty values, such that the check at the end (where you say it dies) could then decide whether to pass the value UPWARD if anything happened in the current...
-
OK. You win - cant argue that logic - But as far as its origin, I suspect it was a leftover from an earlier implementation attempt that should have been updated but got skipped. Mea Culpa.
-
w.r.t. tildechk, sure, you could remove the Dbg. The flows look OK to me: Err is either set in the block starting if {$g(conflictset)} or inside the associated else block, within the block starting if {$N <= $pths} which is always false since $pths is 0, and which sets tildechk. So the later line if {$Err} { set msg $tildechk can only fire when tildechk exists. The Dbg is outside the block starting if {$N <= $pths} so tildechk may or may not exist.
-
The change from an ORlogic to ANDlogic affects code which is new at 5.5. Looks to me like a simple typo: there is no way you want to be in that code with an SCM other than Vpath.
-
w.r.t. tildechk, sure, you could remove the Dbg. The flows look OK to me: Err is either set in the block starting if {$g(conflictset)} or inside the associated else block, within the block starting if {$N <= $pths} which is always false since $pths is 0, which sets tildechk. So the later line if {$Err} { set msg $tildechk can only fire when tildechk exists. The Dbg is outside the block starting if {$N <= $pths} so tildechk may or may not exist.
-
Hmmm. I tend to disagree - although it certainly needs more investigation. Note that the original failure is based on an undefined value (tildechk) but only because that value was requested via a Debugging message argument list. That suggests there is a program-flow that REACHES the Dbg statement, that also manages to avoid the code that establishes "tildechk". I'd want to identify that "flow" condition first and perhaps decide if "tildechk" should maybe simply be REMOVED from the Dbg statement,...
-
tkdiff -rREV1 crashes
-
tkdiff fails to highlight in-line changed characters
-
Wow. Actually had to go find when this happened (was V5.1) - quite a while. Apparently all the other issues with in-lining managed to keep this obscured since then. Excellent catch and problem analysis. Next release will definitely contain this.
-
While I think this fix is correct (in that revs should not be decremented), plain tkdiff still fails at inquire-svn line 97 with define autoSrch {1} in .tkdiffrc. Will investigate further. A mistaken tkdiff -v (hoping to see version number) also fails the same way.
-
tkdiff -rREV1 crashes
-
tkdiff fails to highlight in-line changed characters
-
DorothyR posted a comment on ticket #85
FTR this is what happens when you invoke the wish8.5 that Apple ships, from the terminal: DEPRECATION WARNING: The system version of Tk is deprecated and may be removed in a future release. Please don't rely on it. Set TK_SILENCE_DEPRECATION=1 to suppress this warning.
-
There are actually a couple of topics buried in this overall ticket - This particular one addressed a problem of the TkDiff window not opening right away when requested- but if you read further on, the original poster noted that they ABANDONED this approach as it turned out to be meaningless. I am NOT a "Mac-person" but it would appear that the vintage of TCL/TK that comes bundled with Monterey is badly flawed. Installing a newer version was found to do the trick - but it must install BOTH Tcl AND...
-
Michael modified a comment on ticket #85
Where do you put this command? in the ~/.basrc ? My tkdiff seems installed but it is black since I upgraded my Mac to Montery 12.4. I have tried 'brew install tcl' too, but my display is still black. Thank you for your help.
-
Where do you put this command? in the ~/.basrc ?
-
tkdiff crashes on startup with a 4.3 .tkdiff
-
Version 5.5 issue
-
DIY fix for incorrect inline highlighting
-
Official TkDiff Version 5.5.1 Released
-
tkdiff released /tkdiff/5.5.1/tkdiff-5-5-1.zip
-
-
Update CHANGELOG for V5.5.1
-
Minor logic errors in Pref-morphing repaired for fast-track V5.5.1 release
-
Good catch! Obviously the "unset" should have been to the variable - NOT its interpolated value; that was just plain brain-dead typing! Regarding the oversight of 'opts(fRecurs)' your fix is dead-on. I neglected to take into account the introduction of a "once-upon-a-time" Pref variable creation in the evolution of intermediate versions, for which the PRESENT conversion may (or may not) have actually passed thru (which is where it would have been created). Adding the existence check allows EITHER...
-
tkdiff crashes on startup with a 4.3 .tkdiff
-
The patch actually fixes 2 errors: --- tkdiff 2022/08/15 03:29:49 1.1 +++ tkdiff 2022/08/17 10:36:46 @@ -930,7 +930,7 @@ # (maintaining the evolutionary chain) if {[info exists "prefsFileVersion"]} { set opts(prefsVrsn) $prefsFileVersion - unset $prefsFileVersion + unset prefsFileVersion } # 3rd (PERMANENT location of the 'File Version') @@ -953,7 +953,9 @@ # "ignoreRegexLn" and "ignoreEmptyLn" became bit-Based booleans. # 4. "diffcmd" is now DERIVED (as opposed to user-SET) thus will be # rewritten...
-
tkdiff crashes on startup with a 4.3 .tkdiff
-
I tried deleting ~/.tkdiffrc and tkdiff 5.5 (from SourceForge) started up OK
-
Official TkDiff Version 5.5 Released
-
V5.5 is now (11Aug2022) technically OFFICIAL (although admittedly the release ANNOUNCEMENT has not been written yet - recovery from surgery slowed things down a bit),,,, I cant answer why "brew update" seems to have given you the EARLY ALPHA version: I don't use a Mac, and have zero idea WHERE it is pulling from, but the official zipfile is correct (as noted by the original poster, above). The original poster had independently grabbed the ALPHA version - AHEAD of any kind of official release. Perhaps...
-
Sait Umar posted a comment on ticket #86
The zip file seems to contain the fix for this.
-
Shikhanshu Agarwal posted a comment on ticket #86
My "brew upgrade" updated tkdiff to 5.5 and now its breaking with the same error as reported in this ticket: Error in startup script: can't read "FV": no such variable while executing "popmsg "Your Preference file (V$FV) appears to be NEWER than the $g(name) V$CV currently running. This MAY NOT operat..." invoked from within "if {[file exists $g(rcfile)]} { if {[catch {source $g(rcfile)} error]} { set startupError [join [list "There was an error in processing yo..." (file "/usr/local/bin/tkdiff"...
-
-
-
Repair spurious typos, mangled wrap protection and new-user prefs logic faults
-
And this is why we hadn't released anything yet - there were a handful of other mistakes that we detected and resolved. I apologize if I hadn't made that clear... The sad part of unpaid open-source software is that doing the necessary work to test, resolve, and ultimately FIX problems takes TIME that often doesn't exist when and where it would be most convenient. Unfortunately, I've had a number of other NON-software related issues to deal with lately and I am just getting to the point where I can...
-
Doing the above bracket change resulted in a different error, again when no .tkdiffrc exists. Seems like something may not be defined when we skip the pref file reading block. Error in startup script: unknown option "-wrap none" while executing "$widget configure {*}$opts(textopt)" (procedure "build-client" line 103) invoked from within "build-client" (procedure "create-display" line 32) invoked from within "create-display" (procedure "main" line 91) invoked from within "main" (file "/usr/bin/tkdiff"...
-
Actually our records indicate repairing line 932 was NOT sufficient (although it WAS necessary). The entire processing of preference-morphing should only be attempted when a preexisting preference file was actually READ (as performed by the immediately preceding code block). In short, this means MOVING the close-brace on line 901 until just past the code block containing the "appears NEWER" message. The GOOD news is that testing has since been completed and release of V5.5 is commencing as we speak....
-
Hello Michael, unfortunately correcting the "i" does not solve the problem of not having a preexisting .tkdiffrc file (e.g. a new user). In this case one still gets the above message and tkdiff does not start. FYI.
-
Testing hadn't been fully completed as yet since the major commit for V5.5 (which is why there has not been a formal release), but nevertheless, you are correct. Removing the errant "i" from the variable name on line 932, should result in proper behavior from the code in question. We applaud your industriousness in checking out the soon-to-be-released version, and appreciate your reporting of it. Rest assured we have repaired this and the actual release is imminent.
-
Version 5.5 issue
-
Version 5.5 issue
-
V5.5
-
Sever Tkt85 access
-
My pleasure. I will incorporate the fix into the next release (so you don't lose any ground), and close this ticket. Thank you for the assistance with confirming the fix, Not sure there is a lot I can do about this menu-click thing, practically all of that code is part of TK itself and even if I report it, it could be forever to get fixed, and even longer to make it out into the world. Enjoy!
-
tkdiff 5.4 shows up with a completely black window in macOS Monterey
-
@vampm You did it. The issue is fixed. No more dropdowns in weird places! Just one last "issue" (which is not much of a big deal at all). And it has been there since the beginning of this thread, nothing new introduced in your experiment. The first time tkdiff opens, the Preferences window doesn't open when I click on Edit -> Preferences. The "Edit" text on the menu bar remains highlighted. Then I click on Edit -> Preferences again, and it works fine then. And subsequently too. So probably some another...
-
Fix off-by-one due to typo
-
support access for Tkt85
-
Use ttk::combobox for the pulldown list of diff chunks
-
"use ttk::combobox for the chunk pulldown"
-
@vampm * I use tkdiff in iTerm2 (terminal emulator) * I mainly use it as "git difftool" (so git calls it with LOCAL and REMOTE files) * I also use it directly via command line to diff two files (tkdiff file1 file2) * I was using that function to make the "Wish" window show up over other windows, but I have already stopped using that to rule it out as a cause for the issue. It makes no difference. Using tkdiff directly on command line has the same issue. * Yes, let me know what extra command line...
-
Phooey! Well you DID find a 20yr old BUG - just not the one that explains your problem.... I have one or two more ideas, but its gonna take a bit to lash some code together to try and ferret this all out. So in the meantime, let me ask a question or two. When you invoke "tkdiff" are you doing so from a commandline in some terminal emulator ? I ask because your "snippet" to solve the "shows up under other windows" problem reads like a SHELL 'function' definition. More importantly, CAN YOU invoke it...
-
@vampm First off, just wanted to say that you are awesome at writing explanations and instructions. Extremely detailed, covering all questions that may pop into the user's head upfront etc. Just amazing stuff. Your attention to detail and spending time on being explicit is much appreciated. Secondly, bad news, 5.4.1 did not fix the dropdown issue either :( See attachments. Let me know if I can provide some debug info from my system etc. which may help you.
-
missed edit
-
Yes, of course! Send me your fix and I will test it out.
-
tkdiff 5.4 shows up with a completely black window in macOS Monterey
-
You may have found a 20-year old bug that was just WAITING for you to tickle it!!! But we have a small problem, that YOU could help solve - WE found something in the code that is VERY suspicious, but, as you know, WE cant make the problem occur! If we sent you a specially modified version, would you be willing to TRY IT and tell us if the weirdness of the drop-down list "goes away"? If you agree, I will send you a replacement "tkdiff" script, that you can simply "drop into place" (aka. rename the...
-
I'd note that this dropdown issue may be an argument in favor of using Tk's native combobox/dropdown widgets instead of homegrown ones. (ongoing friendly argument.) The problem is that Aqua and Cocoa are nothing like X11 and no doubt uses opposite approaches at times. (been there with trying to integrate two diametrically opposed programs - blech.) The Tk developers who take on the herculean (and/or sisyphean) task of making it all work with the Cocoa API make the best calls they can, and it's safer...
-
Yes, I don't have a $HOME/.tkdiffrc, and adding one did not help. But here's what I discovered! There's some bug in tkdiff on macOS Monterey that is making the dropdowns act wonky. See the attached two screenshots. When I first open tkdiff, the dropdown on top left shows up outside of where its supposed to be, and is waiting for my input. Preferences doesn't open until I click that dropdown (and then it goes back into its place) When I open preferences window, multiple dropdowns are rendered outside...
-
Strangely enough your answer alone may tell me enough. FYI - On MacOS (like linux) the default preferences file would (theoretically) exist at the filename: $HOME/.tkdiffrc But you ALSO said this is a brand new installation on a machine you have never RUN TkDiff on! Worse, you claim you cant even GET to the preference window which kinda infers you have never CREATED a preference file on your Mac platform! So I wouldn't be surprised to learn that the filename shown above DOESN'T EXIST. Thus your "runtime...
-
Sorry, I did not use tkdiff previously on the mac as it never worked for me. Only now I decided to create this ticket. I previously used to use it on linux. Also, I don't know where the preferences file is, can you tell me? Thanks, Shikhanshu On Mon, Apr 18, 2022 at 9:26 PM michael-m vampm@users.sourceforge.net wrote: One last thought - could you upload a copy of your preference file to this ticket? I'm curious what the default values were overridden with that might explain the rather bizarre behavior...
-
One last thought - could you upload a copy of your preference file to this ticket? I'm curious what the default values were overridden with that might explain the rather bizarre behavior you are/were seeing. There is no fundamental reason you should be UNABLE to view the preference settings, and your description of menu accelerators and such is exceptionally odd. Perhaps there is something IN your current settings that is at the root of this. Also, you suggested this Mac installation was something...
-
Nevermind, looks like I can't close it :) Will let some overlord do it.
-
That's another problem. I am just unable to open the Preferences window at all. Nothing happens. But since its not reproducible at your end, I guess something must be wrong with my setup. I can live with it as at least I am able to use tkdiff as my git difftool. Thanks for the help! Closing the ticket.
-
Just my 2-cents... The "q" to quit was admittedly the norm forever, in the days BEFORE users could assign their own hotkeys (V5.1, IIRC). However when we added the new hotkey capability we felt it might be SAFER to require two fingers on the keyboard to abruptly EXIT, at least as a DEFAULT for new users. You are free to RE-ESTABLISH whatever keys you would prefer at your own discretion, and that would include reverting BACK to the simple "q". I recommend reading the builtin Help on preferences to...
-
The dropdown thing doesn't happen for me, and Edit->Preferences works. The "x" for quit doesn't work - I never tried that before. I do find that Tk is a little squirrelly on MacOS though. The first time I ran the new 5.4 tkdiff, I had a problem with applying preferences, but I couldn't replicate it after that.
-
Well, I can use "Command+Q" to quit instead, that works. Still wondering why the preferences won't open. And also, whenever I open a new diff, the dropdown for diff positions shows up for some reason and doesn't go away until I select one of them. It even persists even if I move out of tkdiff window and go to some other window.
-
That's right. "brew install tcl-tk" worked. Thanks. And now tkdiff opens up fine! However, unlike on linux, I am unable to use "q" to quit from it. I typically use "tkdiff" as my git difftool, so I can just let git invoke it back to back on all changed files. I review the changes, and press 'q' to quit and move to next file. Now 'q' doesn't work. I noticed that when I click the File menu, the "Exit" option has a keyboard shortcut of "<" (which seems weird, and also, doesn't work). Also, nothing happens...
-
Sorry, "brew install tcl-tk."
-
Yes, just "brew install tcl." That's about as "official" as we get around here :-) Even if you get Apple's tk working, it's 8.5 I think. 8.6 works much better. I have the macports version too, which runs with the Xquartz you can get from there. I'm a unix/linux baby too, and I like to use X11 on my Mac sometimes.
-
Yes, just "brew install wish." That's about as "official" as we get around here :-) Even if you get Apple's tk working, it's 8.5 I think. 8.6 works much better. I have the macports version too, which runs with the Xquartz you can get from there. I'm a unix/linux baby too, and I like to use X11 on my Mac sometimes.
-
Good point. I had hoped that "tkdiff" brew formula will bundle with it any dependencies. "which wish" is "/usr/bin/wish" (i.e. bundled with Monterey). So should I just do "brew install wish"? Or something else/more too? By the way, I was able to get around the "opening in background" problem using this snippet from some forum: function tkdiff() { command tkdiff "$@" & command osascript -e "delay 0.5" -e "tell application \"Wish\" to activate" } Is that good? or is there a "more official" way to fix...
-
What does "which wish" say? If you haven't installed tcl-tk from homebrew, you'll need to. Whatever tcl-tk is on Monterey is wholly obsolete and inadequate if I remember correctly.
-
tkdiff 5.4 shows up with a completely black window in macOS Monterey
-
DIY fix for incorrect inline highlighting
-
Theoretic V5.4.1 - Fixes 'Blanks' suppression results plus invalid bindings
-
line highlighting doesn't honour ignore-whitespace-changes flag properly
-
Changed the status on this ticket in light of recent developments. As of V5.4, the requested functionality now exists. The underlying issue was one of PERFORMANCE, not a lack of desire. Hope this gives you what you were looking for
-
-
minor adjustments (no downloads as yet)
-
-
-
Official TkDiff Version 5.4 is released
-
virtually insignificant yet more definitive constraint
-
V5.4
-
V5.3.1
-
LOL. Does anybody these days even REMEMBER what "Wumpus" was ? Anyway, I cant say for sure, but my guess is somewhere in your early exploration you were sitting in your HOME directory when you caused Git to initialize. I'm pretty sure Git simply uses wherever the CWD is to say "here is where the REPO will live", and it plants a hidden directory there. Afterward you may have switched to a more legitimate sub-directory and did it again. From a Git perspective, you would now have TWO REPOs . And while...
-
Elwood Downey posted a comment on discussion Open Discussion
Thanks for the extra tips, all good. I just realized I do have a $HOME/.git file but I'll be darned where it came from. I'm gradually trying to learn to use git on a project but it's not rooted off $HOME. Git still feels like a cave full of dark and twisty passages -- I expect to find a Wumpus lurking at every turn. Cheers!
-
Quick afterthoughts - If looking for other ways to switch among different SCM influences one way would be to make sure TkDiff cant FIND both simultaneously. For instance don't work on a Git repository out of your HOME directory , which suggests your entire directory tree could belong to Git. Do your git work in a SUB-directory and ChangeDir there instead. Another approach might be to have different User-Preference files, each set to a different SCM choice, and then decide which to use by using the...
-
Thanks for the help. My apologies for the scare. I added "for me" in hopes it would temper the effect a little. Was not aware of these settings, sounds perfect. All the best...
-
Please don't go scaring the peoples that haven't read the online help... So YES - TkDiff indeed will choose GIT over RCS - but only by default. You need to go investigate the User Preference setting called: Prefer given SCM when detected and decide which way you want Tkdiff to behave for you in a default situation. I think you will find that we will allow RCS and Git to peacefully coexist and Prefer whichever SCM you want at the moment. Note that in addition to it being a user Preference, you ALSO...
-
Just a word to the wise. I mostly still use RCS for small projects and am grateful tkdiff still supports it. But I recently started a project that uses git. As soon as I started using git, tkdiff stopped finding my RCS files. Bottom line: I discovered git created ~/.git which tkdiff always found and thus assumed I wanted to use git for everything, even if there was an RCS dir in my CWD. Removing ~/.git allows tkdiff to work normally again. Of course I need that ~/.git when using git but at least...
-
During a consolidation sweep of changes in the V5.2 - V5.2.1 timeframe apparently a PORTION of an intended change that affected the Perforce support became garbled. This has been addressed in V5.3 and should now be back to normal.
-
When I upgraded from Big Sur to Monterey my tkdiff started doing the same as @AlanM. I ran "sudo port install tk" and after that tkdiff worked via ssh again.
-
tkdiff fails with files that contain special Tcl characters
-
Official TkDiff Version 5.3 is released
