On 23 Apr 2020, at 4:22, Andrew Hodgkinson 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.

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.

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.

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.

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.

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.

[…] 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.

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.

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?

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

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)?

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.