Hi,
There's a severe data loss bug in recent releases, including 2.0.16, where trying to undo an edit operation in the editor results instead in an undo of an operation in the file browser pane. If the sound is not muted, you may hear the sound of a file/folder being moved to the trash. But instead the file/folder just vanishes, loosing the work in those files/folders. When this bug occurs, restarting TextMate offers a temporary workaround. Until it happens again. I'm using macOS 11.2 if that's relevant. I'm a registered user of TextMate since version 1.x. Never until the latest releases I have come across this bug.
Cheers, Paulo
----------------------------------------------------------------- Paulo Moura Logtalk developer
TextMate has always been a bit deceptive in this regard. The browser pane and the file are two different places, in the same way that two different files are two different places. If you do something in the browser pane and do something in the file, and then say Undo, what is undone depends on where you are at that moment. Well, you can jump from the file to the browser without realizing it, so when you then say Undo you can get a surprise. m.
On Feb 23, 2021, at 5:06 AM, Paulo Moura via TextMate textmate@lists.macromates.com wrote:
Hi,
There's a severe data loss bug in recent releases, including 2.0.16, where trying to undo an edit operation in the editor results instead in an undo of an operation in the file browser pane. If the sound is not muted, you may hear the sound of a file/folder being moved to the trash. But instead the file/folder just vanishes, loosing the work in those files/folders. When this bug occurs, restarting TextMate offers a temporary workaround. Until it happens again. I'm using macOS 11.2 if that's relevant. I'm a registered user of TextMate since version 1.x. Never until the latest releases I have come across this bug.
Cheers, Paulo
Paulo Moura Logtalk developer
TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 14! https://www.oreilly.com/library/view/programming-ios-14/9781492092162/ iOS 14 Fundamentals! https://www.oreilly.com/library/view/ios-14-programming/9781492092087/ RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
I see this bug when I'm typing on the editor pane and then try to undo. I.e. without any switching to the file browser pane. Also, when at the browser pane, the only visual clue is that there isn't any more a cursor flashing in the editor pane.
On 22 Feb 2021, at 18:48, Matt Neuburg via TextMate textmate@lists.macromates.com wrote:
TextMate has always been a bit deceptive in this regard. The browser pane and the file are two different places, in the same way that two different files are two different places. If you do something in the browser pane and do something in the file, and then say Undo, what is undone depends on where you are at that moment. Well, you can jump from the file to the browser without realizing it, so when you then say Undo you can get a surprise. m.
On Feb 23, 2021, at 5:06 AM, Paulo Moura via TextMate textmate@lists.macromates.com wrote:
Hi,
There's a severe data loss bug in recent releases, including 2.0.16, where trying to undo an edit operation in the editor results instead in an undo of an operation in the file browser pane. If the sound is not muted, you may hear the sound of a file/folder being moved to the trash. But instead the file/folder just vanishes, loosing the work in those files/folders. When this bug occurs, restarting TextMate offers a temporary workaround. Until it happens again. I'm using macOS 11.2 if that's relevant. I'm a registered user of TextMate since version 1.x. Never until the latest releases I have come across this bug.
Cheers, Paulo
Paulo Moura Logtalk developer
TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 14! https://www.oreilly.com/library/view/programming-ios-14/9781492092162/ iOS 14 Fundamentals! https://www.oreilly.com/library/view/ios-14-programming/9781492092087/ RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
----------------------------------------------------------------- Paulo Moura Logtalk developer
Just lost two hours of work due to this bug. I created a new file using the file browser pane, renamed it, and added code to the file. Saved it. Then when to edit another file elsewhere in the same file tree. Did a mistake while typing, pressed cmd-z and got the sound of the first file being deleted. This happened without me switching to the file browser pane. Moreover, the file deleted was in a directory other than the one being currently displayed on the file browser. The file is *not* moved to the macOS trash. So, no recovery of the lost work.
On 22 Feb 2021, at 18:55, Paulo Moura via TextMate textmate@lists.macromates.com wrote:
I see this bug when I'm typing on the editor pane and then try to undo. I.e. without any switching to the file browser pane. Also, when at the browser pane, the only visual clue is that there isn't any more a cursor flashing in the editor pane.
On 22 Feb 2021, at 18:48, Matt Neuburg via TextMate textmate@lists.macromates.com wrote:
TextMate has always been a bit deceptive in this regard. The browser pane and the file are two different places, in the same way that two different files are two different places. If you do something in the browser pane and do something in the file, and then say Undo, what is undone depends on where you are at that moment. Well, you can jump from the file to the browser without realizing it, so when you then say Undo you can get a surprise. m.
On Feb 23, 2021, at 5:06 AM, Paulo Moura via TextMate textmate@lists.macromates.com wrote:
Hi,
There's a severe data loss bug in recent releases, including 2.0.16, where trying to undo an edit operation in the editor results instead in an undo of an operation in the file browser pane. If the sound is not muted, you may hear the sound of a file/folder being moved to the trash. But instead the file/folder just vanishes, loosing the work in those files/folders. When this bug occurs, restarting TextMate offers a temporary workaround. Until it happens again. I'm using macOS 11.2 if that's relevant. I'm a registered user of TextMate since version 1.x. Never until the latest releases I have come across this bug.
Cheers, Paulo
Paulo Moura Logtalk developer
TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 14! https://www.oreilly.com/library/view/programming-ios-14/9781492092162/ iOS 14 Fundamentals! https://www.oreilly.com/library/view/ios-14-programming/9781492092087/ RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
Paulo Moura Logtalk developer
TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
----------------------------------------------------------------- Paulo Moura Logtalk developer
On 23 Feb 2021, at 8:22, Paulo Moura via TextMate wrote:
Just lost two hours of work due to this bug.
Seconded. Critical issue. When the undo buffer becomes exhausted in whatever text file you're editing, Cmd+Z just silently now falls through to the file browser and wreaks havoc.
To others commenting, this is absolutely NOT anything to do with input focus. Focus is in the text editor window, not the file browser. Cmd+Z is undoing text edit changes normally, but if you reach the start of your undo buffer, suddenly it just silently starts hitting the file browser (and as the OP noted, it can even cause hard-deletion of files without going to the Trash).
I've stepped back to my prior "public" non-beta release of 2.0.6 for now as also just lost some work myself - doubtless this'll be fixed soon :-) but for safety right now I've no choice but to regress (it's my primary development editor). Earlier builds can be fetched from https://github.com/textmate/textmate/tags. There seem to be no ill effects, apart from theme settings reverting - unsurprising given the later versions have the dark/light mode switching that's not present in the older code.
I certainly didn't mean to doubt the reality of the bug! I just meant that I've been fooled by focus issues. Clearly this isn't merely that. This is a good warning to us all and is one of the reasons this is such a great list. m.
On Feb 25, 2021, at 1:23 PM, Andrew Hodgkinson via TextMate textmate@lists.macromates.com wrote:
On 23 Feb 2021, at 8:22, Paulo Moura via TextMate wrote:
Just lost two hours of work due to this bug.
Seconded. Critical issue. When the undo buffer becomes exhausted in whatever text file you're editing, Cmd+Z just silently now falls through to the file browser and wreaks havoc.
To others commenting, this is absolutely NOT anything to do with input focus. Focus is in the text editor window, not the file browser. Cmd+Z is undoing text edit changes normally, but if you reach the start of your undo buffer, suddenly it just silently starts hitting the file browser (and as the OP noted, it can even cause hard-deletion of files without going to the Trash).
I've stepped back to my prior "public" non-beta release of 2.0.6 for now as also just lost some work myself - doubtless this'll be fixed soon :-) but for safety right now I've no choice but to regress (it's my primary development editor). Earlier builds can be fetched from https://github.com/textmate/textmate/tags. There seem to be no ill effects, apart from theme settings reverting - unsurprising given the later versions have the dark/light mode switching that's not present in the older code.
-- TTFN, Andrew Hodgkinson Find photos, software, music and more at my home site, Bandcamp and GitHub: https://pond.org.uk / https://pondnz.bandcamp.com / https://github.com/pond _______________________________________________ TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 14! https://www.oreilly.com/library/view/programming-ios-14/9781492092162/ iOS 14 Fundamentals! https://www.oreilly.com/library/view/ios-14-programming/9781492092087/ RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
On 25 Feb 2021, at 1:23, Andrew Hodgkinson via TextMate wrote:
Just lost two hours of work due to this bug.
Seconded. Critical issue. When the undo buffer becomes exhausted in whatever text file you're editing, Cmd+Z just silently now falls through to the file browser and wreaks havoc.
Is this also macOS 11.2?
Unfortunately I don’t have any theory as to what can cause this newly observed behavior, so any further details would be useful, especially if there is a way to reproduce.
[…] and as the OP noted, it can even cause hard-deletion of files without going to the Trash
This will happen when “undo” (in the file browser) undos “New File”: But I should imrove that, so that if content has been added to the file, that content should go to the trash and not be lost forever.
On 25 Feb 2021, at 19:38, Allan Odgaard via TextMate wrote:
Is this also macOS 11.2?
Yes, 11.2.1. Suffice to say I regret updating quite profoundly; it's a pretty terrible OS, and that's after having tolerated Catalina for a year :-(
If there _is_ an OS behaviour change, it's presumably down to the cascade of events from one child of a parent window to another, when one of them doesn't handle a key press. There may now be a new distinction, or API change in the handling of a distinction between "consumed but not used" rather than just "ignored", with Cmd+Z at the end of the undo buffer needing to the former.
Worst-case, it's just yet another new OS bug in apparently otherwise-unchanged functionality. If so it'll probably never be fixed and best we might hope for would be figuring out a viable work-around.
This will happen when “undo” (in the file browser) undos “New File”: But I should imrove that, so that if content has been added to the file, that content should go to the trash and not be lost forever.
For a short term patch release in the near future that would definitely help a lot, lessening the impact of this "fall through" behaviour with Cmd+Z although not solving it.
But then wouldn’t reverting to 2.0.6 fail to solve it? m.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 14! https://www.oreilly.com/library/view/programming-ios-14/9781492092162/ iOS 14 Fundamentals! https://www.oreilly.com/library/view/ios-14-programming/9781492092087/ RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
On Feb 26, 2021, at 8:52 AM, Andrew Hodgkinson via TextMate textmate@lists.macromates.com wrote:
On 25 Feb 2021, at 19:38, Allan Odgaard via TextMate wrote:
Is this also macOS 11.2?
Yes, 11.2.1. Suffice to say I regret updating quite profoundly; it's a pretty terrible OS, and that's after having tolerated Catalina for a year :-(
If there is an OS behaviour change, it's presumably down to the cascade of events from one child of a parent window to another, when one of them doesn't handle a key press. There may now be a new distinction, or API change in the handling of a distinction between "consumed but not used" rather than just "ignored", with Cmd+Z at the end of the undo buffer needing to the former.
Worst-case, it's just yet another new OS bug in apparently otherwise-unchanged functionality. If so it'll probably never be fixed and best we might hope for would be figuring out a viable work-around.
This will happen when “undo” (in the file browser) undos “New File”: But I should imrove that, so that if content has been added to the file, that content should go to the trash and not be lost forever.
For a short term patch release in the near future that would definitely help a lot, lessening the impact of this "fall through" behaviour with Cmd+Z although not solving it.
-- TTFN, Andrew Hodgkinson Find photos, software, music and more at my home site, Bandcamp and GitHub: https://pond.org.uk / https://pondnz.bandcamp.com / https://github.com/pond _______________________________________________ TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
On 26 Feb 2021, at 9:12, Matt Neuburg via TextMate wrote:
But then wouldn’t reverting to 2.0.6 fail to solve it? m.
Heh! Yes, of course, that's right, I didn't think of that... And then Allan wrote:
That made it click: The key equivalent is in a context menu, context menus are outside the regular view hierarchy, so that is what is causing the problem. I have pushed v2.0.19 which contains a fix for this
Great! That's awesome - thanks for such a quick fix. I've tried fiddling around for a while and cannot seem to persuade anything untoward to happen with Cmd+Z in text editor views now :-)
On 25 Feb 2021, at 20:52, Andrew Hodgkinson via TextMate wrote:
If there _is_ an OS behaviour change, it's presumably down to the cascade of events from one child of a parent window to another, when one of them doesn't handle a key press.
That made it click: The key equivalent is in a context menu, context menus are outside the regular view hierarchy, so that is what is causing the problem.
I have pushed v2.0.19 which contains a fix for this. Hold option (⌥) when checking for new build. Though it will be promoted to regular release shortly, given the severity.
I am terrible sorry for anyone who has been affected by this!
Thanks for quick fix! Would it be possible to highlight somehow the file browser when it gains focus?
On 25 Feb 2021, at 20:37, Allan Odgaard via TextMate textmate@lists.macromates.com wrote:
On 25 Feb 2021, at 20:52, Andrew Hodgkinson via TextMate wrote:
If there is an OS behaviour change, it's presumably down to the cascade of events from one child of a parent window to another, when one of them doesn't handle a key press.
That made it click: The key equivalent is in a context menu, context menus are outside the regular view hierarchy, so that is what is causing the problem.
I have pushed v2.0.19 which contains a fix for this. Hold option (⌥) when checking for new build. Though it will be promoted to regular release shortly, given the severity.
I am terrible sorry for anyone who has been affected by this!
TextMate mailing list -- textmate@lists.macromates.com To unsubscribe send an email to textmate-leave@lists.macromates.com
----------------------------------------------------------------- Paulo Moura Logtalk developer
On 25 Feb 2021, at 22:07, Paulo Moura wrote:
Would it be possible to highlight somehow the file browser when it gains focus?
Other than the color of selected items changing, I don’t see any obvious way to do this.
The normal focus ring does not work for controls that extend to the window borders, this is more of an OS level issue.
-
Allan Odgaard -
Andrew Hodgkinson -
Matt Neuburg -
Paulo Moura