Hi, I just updated to 2.0.8, and there are a few bugs:
• Running a Python script with ⌘R hangs, producing no output in the HTML output window – the spinny thing continues to spin throughout – the Ruby stacktrace you get when closing the window with ⌘W – which comes up in a modal window alert – specifies an exception in a “kill” method, which is not an evidently obvious visible part of the bundle command text to which the window alert offers to take you • Starting up immediately after updating from TextMate 2.0.6 reset the theme of every open code window to plain black-and-white (this was easily remedied and wasn’t a showstopper in any way, though) • There have been a number of odd hard-crashes – the “Submit Crash Log” dialog would come up, saying that TextMate crashed, but the TextMate UI would still appear to be up and running; in some cases a part of the UI would prove to have been rendered unresponsive; in any case a force-quit was always necessary.
Here are logs from two of these hard-crash events:
• https://gist.github.com/fish2000/2b6957a0f722d006b5673b7440767a9a
Let me know if I can be of further assistance w/r/t this. 2.0.8 looks like it’ll be awesome, once some of these kinks are ironed out. Yes!
-fish (née Alexander Böhn)
On 22 Apr 2020, at 14:20, Alexander Bohn wrote:
I think both of these issues could be caused by a corrupted bundle index.
Try quit TextMate, delete this file, and see if ⌘R works again:
~/Library/Caches/com.macromates.TextMate/BundlesIndex.binary
The crash points to `__CFSocketManager` (system code), I have received a similar crash from another client, although that one I have seen before (but it’s rare).
Nonetheless, as it appears there might be an issue related to using `CFSocket`, I have switched to using a dispatch source instead, as that’s anyway a more modern (and thus nicer) API.
Please try 2.0.9 available by holding down option (⌥) when selecting TextMate → Check for Update.
I have run into this myself, since upgrading to 10.15, it’s when Apple throws up dialogs during startup, it can end in a “nested run-loop” state where the outer run-loop gets no events, but is blocking the UI (waiting for the user to respond to the dialog.
It’s a little tricky to work around with the current code, but I’m working on a major overhaul of this and more.
On 23 Apr 2020, at 3:56, Allan Odgaard wrote:
I just had a very unfortunate experience with 2.0.9. I noted it was available as a test build in this thread, and thought I'd try it as I've seen all manner of weird stuff with file content not refreshing etc. when files on disc change in 2.0.6 and wondered if there were improvements. I've not reported bugs about this because so far, I can never replicate anything.
2.0.9 launched and reloaded all my many windows - several temporary text files (unsaved, I've just relied on application state restore for so many years now that I don't even think about it) and and about 20 different projects in different windows across multiple desktops (I'm a very busy developer, heh). As ever, it didn't put anything back in the correct desktop spaces so I moved all the windows in Mission Control manually but then noticed one I wanted to close - but couldn't. TextMate didn't respond.
At this point I realised that while I could move windows and they'd gain focus, there was no way to interact. Typing and mouse clicks were totally ignored.
Then it got stranger. Quitting TextMate from the menu worked, surprisingly, but it immediately self-restarted! I force-quit it, and it restarted once more. I tried to shut down the computer, but TextMate cancelled the restart. Even "pkill -9 TextMate", which did seem to kill it off, didn't let the computer restart and I had to force-reboot.
A tedious Disk Utility check later, with TextMate automatically relaunched after the reboot and all its windows restored - nope, no good; can't click in anything. Quit it; restarts itself. I could't delete it even after "pkill -9" as the Finder insisted that the application was open and sure enough a moment later it reappeared. So this time I used "pkill -9 TextMate; sudo rm -rf ..." to forcibly remove the application before it had a chance to restart.
I then reinstalled 2.0.6 and - no windows. Nothing. Absolutely all my state, and all my temporary files including project notes, have disappeared. Wut?! Surely those are all in Library/Application Support, *not* stored in the application bundle?
Is there any way I can get any of that back? And what on earth is going on with TextMate 2.0.9's self-restart behaviour - it's practically a virus at that point, unkillable and crippling machine functions - is that a known bug, or a misfiring intended feature of some kind, or just yet another problem in Catalina at work (10.15.4)?
Thanks in advance for any insights.
On 23 Apr 2020, at 4:22, Andrew Hodgkinson wrote:
Regarding file changes: The code for this has been rewritten using a simpler API (provided by macOS) and it now watches parent folders. Previously if a parent folder was changed (renamed or deleted), TextMate would not notice it, so the open document would become “detached” from the file on disk (either not using the new path, or if the file got re-created, it would not notice changes made to the new re-created file).
This could possibly happen after running a git rebase or similar operation that would delete and recreate *folders* (with open documents) in your project.
For placing them on the appropriate desktop: There is currently no API to open a window on a specific desktop.
Apple’s own session restore support is able to do this, it’s not a drop-in replacement, but I am working on migrating to Apple’s system.
I’ve seen this issue before, both with TextMate and other applications. But new for macOS 10.15 (I think) is that it used to be, that one could switch to another application and back, to fix the issue, but this is not always the case with macOS 10.15.
That is pretty damn weird. So even after a reboot, TextMate kept relaunching? And still in a state where it didn’t get “proper” activation (no keyboard input)?
Apple does offer to relaunch applications if they terminate unexpectedly, but that is offered as an option, not automatic.
You should be able to find “untitled” (or unsaved) documents in `~/Library/Application Support/TextMate/Session`.
Metadata about the files are stored using extended attributes, to view this, run e.g.:
% xattr -l ~/Library/Application\ Support/TextMate/Session/untitled.txt com.macromates.backup.file-type: text.plain com.macromates.backup.identifier: C0498FF4-97E3-4E07-B020-9AF3AF4727D8 com.macromates.backup.modified: YES com.macromates.backup.tab-size: 4 com.macromates.backup.untitled-count: 1
I can assure you that TextMate does not do anything to try and make itself be relaunched repeatedly (which would require a helper process).
And it is not obvious to me how such a situation can even arise. There is “keep alive” support in their launch daemon system, but that is not for GUI applications, and I think their launch daemon support even stops keeping a process alive (relaunching) if it terminates too quickly.
On 23 Apr 2020, at 12:42, Allan Odgaard wrote:
Ah yeah, that kinda matches some of the weird stuff. Thanks for putting in the API migration effort to try and resolve it; will be nice to not have those issues arise in some future iteration.
OK - I figured it probably wouldn't be a simple fix, else it'd have happened ages ago.
Yes, this was very odd; not quite the same thing. In some previous examples of "doesn't respond", the window doesn't even look like it has focus even though it's sort-of-active, and switch-away-switch-back does indeed resolve it. In this case, it looked entirely active and normal, but just didn't respond to any input.
That's right - every bit as strange as it sounds. I've no explanation. In the end, it seems session restore data may have been corrupted somehow too, since when I finally got 2.0.6 installed back, it'd complain about having crashed at shutdown previously, and ask me if I wanted to restore windows. Saying 'yes' would lead to no windows at all, while saying 'no' would lead to one default empty document... And it did this *on every launch*. I had to delete it with an app cleaner to fully remove all related data before it settled down and started behaving normally.
As you say, this seems almost impossible without some kind of launcher. If there's nothing in the OS via e.g. flags/other API to say "relaunch me if I die" then the only explanation I can think of is some horrible problem in the Catalina window and/or desktop process manager (if they're separate things, who knows) which just kept relaunching it over and over, even after a reboot.
You should be able to find “untitled” (or unsaved) documents in `~/Library/Application Support/TextMate/Session`.
Thanks - yeah, I dug those out before deleting everything to get 2.0.6 working properly again.
Metadata about the files are stored using extended attributes, to view this [...]
Useful! Thanks.
Totally agree. It seems we've no choice but to chalk it up to even more super-lousy engineering in Catalina; yet another weird rotting-code bug that'll probably never be fixed. If I do ever manage to get anything replicable or diagnosed, I'll let you know.
Thanks for the detailed reply,
On 22 Apr 2020, at 20:42, Allan Odgaard wrote:
I just saw the same behavior on 10.14.6. (Keyboard and mouse input appear to do nothing, and TextMate immediately relaunches when quit/killed.)
An easy fix, in case anyone else runs into this: Restore 2.0.8 or older from a backup and replace 2.0.9 with it in your Applications folder. After that, quitting 2.0.9 will actually quit and you can launch the older version.
On 23 Apr 2020, at 19:14, Rob McBroom wrote:
Interestingly today I had two instances of this myself, both after rebooting (although on second run, TextMate was responsive).
I was able to study the stack trace of TextMate and I *think* 2.0.10 should avoid getting TextMate into this state.
-
Alexander Bohn -
Allan Odgaard -
Andrew Hodgkinson -
Rob McBroom