Hi,
I’m running TextMate 2.0-beta.12.26 on OSX El Capitan (10.11.6)
I ran into the following issue today: While going through some code refactoring, I changed a couple of files, but I forgot to save one of these files (so it showed up half transparant in the file list sidebar). I then modified the name of the folder which contained that open file (I did that in TextMates file list sidebar). The project is in a git repo by the way.
After that I moved focus to another program (I’ve got TextMate set to automatically save on focus lost) but TextMate then switched to the open file, presenting me a modal sheet “No parent folder for <filename>. Do you wish to create a folder at <previous_name_of_renamed_folder>” with buttons ‘Cancel’ and ‘Create Folder’. None of these buttons are reacting to mouse clicks, space bar or return keys. Due to the sheet being modal, my only recourse is to force quite TextMate.
After relaunching TextMate, I found the file in the renamed folder (without the unsaved changes I made to it). I made the changes again, saved this time, changed the file name and then changed the folder name. On focus lost showed me the same modal sheet again! (after which I had to force quite TextMate again).
Now when I open this project in TextMate, it opens in the tab containing the above file, with the new contents, but with the *old* name. The file list sidebar shows the new name. As soon as I move focus elsewhere, it shows me the unresponsive modal sheet (with the old file name in the error message!), so I’m actually kind of stuck now…
Best regards, Bas
On 2 Nov 2016, at 17:47, Bas Van Klinkenberg wrote:
FYI the issue should be fixed in v2.0-beta.12.30 available by holding option when selecting Check for Updates in the TextMate menu.
The issue should only have affect the nightly builds, will likely push a new nightly build in ~12 hours.
As for renaming ancestor folders of open files, there are currently two known issues related to this, one is that TextMate does _not_ update the path of any open documents, so the open documents will effectively become orphans, the other issue is that each open document caches the inode read when opening the document, and when opening another document, if the inode of the other document is the same as an already open document, it will use the already open document (we do not compare the path since that would fail when using links). After “removing” a parent folder of a document, any open document in this folder does not have its cached inode cleared (since it does not detect the parent is gone until the user tries to save), which does lead to a situation where a document effectively has the wrong inode.
I am not sure if this fully explains the behavior you saw, but definitely renaming ancestor folders of open documents is currently something that should be avoided.
Thanks for the fast fix.
I ended up doing a git stash && git reset —hard && git stash pop in a terminal window after closing TextMate. This solved the issue for me (I only saw your previous mail in this thread after doing that, restarting TextMate with shift pressed would have been easier indeed).
Your explanation totally resonates with the behaviour I saw, looks like those were indeed the bugs biting me.
Best regards, Bas
-
Allan Odgaard -
Bas Van Klinkenberg