From: "Allan Odgaard" mailinglist@textmate.org Subject: [TxMt] Re: Weird file not updating problem Date: August 21, 2016 at 2:56:20 AM PDT To: "TextMate users" textmate@lists.macromates.com Reply-To: TextMate users textmate@lists.macromates.com
On 20 Aug 2016, at 8:57, Jack Royal-Gordon wrote:
I made some changes to a file that was open as part of a Rails project (the whole project was opened) and saved the changes. TextMate showed the file as having no unsaved changes. However, inspecting the file outside of TextMate, I could see that the the changes were not saved.
And even pressing ⌘S did not change that? ⌘S will always save, even if it shows “no changes”.
Did press ⌘S several times, as when I ran the file and it did not work I thought I had forgotten to save.
Also, when you have a file open, you can use Bundles → Diff → Document With Saved Copy. This will run a diff util on the buffer and the file on disk, that should be able to confirm if somehow TM’s buffer is different with the file on disk after ⌘S.
That’s a good idea. Did not know about that.
I rebooted my computer and when TextMate reopened, there was the file with my changes showing (but which were not saved although again it showed as having no unsaved changes). I had to close the file, reopen it, and re-apply the changes before saving again in order to actually save the changes
So you rebooted, re-opened the file, and while TM found your (unsaved) changes, it would still not save on ⌘S. But closing file (again) and re-opening now did show the file on disk, and you could save?
Correct. When I reopened, it showed the file without the changes that did not save.
[…] I wanted to see if this was a known issue with 2.0-beta.12.
Nothing I have heard of before, but from the description above, it really sounds like TextMate was operating on a different file than what you was inspect on disk, that would explain all of the behavior perfectly, including rebooting and showing the updated file “with no changes”, yet after closing it and opening the (right) file, you now lost the changes, and had to re-do them.
Since I opened a folder in Textmate and was accessing files via the File Browser, I have a hard time imagining how it was accessing a different file. But I agree that that would explain all of the strange behavior.
So what should probably be looked into is, how did it get to operate on this other file, and where on disk was it?
Yes, that would be the question.
Did anything work on the files on disk (TextMate will track renames, hence if you open /path/to/file and then move it to /path/to/other/place, it will update its reference).
Should it ever happen again, you can right-click the proxy icon to see where the file is on dis, or use File Browser → Reveal Document.
I will do that. Thanks for the response.
Just discovered another similar occurrence that may add some more data. It appears that when I switch GIT branches, which causes some files in my folder to be changed, TextMate is not reloading the changed files (as it did in Version 1). What I used to get in V1 was that if there were no changes pending on the file when I switched branches, TM would quietly load the new version of the file; if there were changes pending, it would ask if I want to save the current TM copy or overwrite it from the copy on disk. But it seems like it might not be doing this (or at least not doing this consistently) on V2. All this makes me think that there might be an issue with TextMate’s file system handling under OS X.
Unfortunately, I only discovered this issue today (based on GIT history I can tell that it happened three days ago), so I wasn’t able to apply any of the suggestions from your earlier email. You can be sure that I’m keeping an eye on this now.
On Aug 21, 2016, at 9:56 AM, Jack Royal-Gordon jackrg@pobox.com wrote:
From: "Allan Odgaard" <mailinglist@textmate.org mailto:mailinglist@textmate.org> Subject: [TxMt] Re: Weird file not updating problem Date: August 21, 2016 at 2:56:20 AM PDT To: "TextMate users" <textmate@lists.macromates.com mailto:textmate@lists.macromates.com> Reply-To: TextMate users <textmate@lists.macromates.com mailto:textmate@lists.macromates.com>
On 20 Aug 2016, at 8:57, Jack Royal-Gordon wrote:
I made some changes to a file that was open as part of a Rails project (the whole project was opened) and saved the changes. TextMate showed the file as having no unsaved changes. However, inspecting the file outside of TextMate, I could see that the the changes were not saved.
And even pressing ⌘S did not change that? ⌘S will always save, even if it shows “no changes”.
Did press ⌘S several times, as when I ran the file and it did not work I thought I had forgotten to save.
Also, when you have a file open, you can use Bundles → Diff → Document With Saved Copy. This will run a diff util on the buffer and the file on disk, that should be able to confirm if somehow TM’s buffer is different with the file on disk after ⌘S.
That’s a good idea. Did not know about that.
I rebooted my computer and when TextMate reopened, there was the file with my changes showing (but which were not saved although again it showed as having no unsaved changes). I had to close the file, reopen it, and re-apply the changes before saving again in order to actually save the changes
So you rebooted, re-opened the file, and while TM found your (unsaved) changes, it would still not save on ⌘S. But closing file (again) and re-opening now did show the file on disk, and you could save?
Correct. When I reopened, it showed the file without the changes that did not save.
[…] I wanted to see if this was a known issue with 2.0-beta.12.
Nothing I have heard of before, but from the description above, it really sounds like TextMate was operating on a different file than what you was inspect on disk, that would explain all of the behavior perfectly, including rebooting and showing the updated file “with no changes”, yet after closing it and opening the (right) file, you now lost the changes, and had to re-do them.
Since I opened a folder in Textmate and was accessing files via the File Browser, I have a hard time imagining how it was accessing a different file. But I agree that that would explain all of the strange behavior.
So what should probably be looked into is, how did it get to operate on this other file, and where on disk was it?
Yes, that would be the question.
Did anything work on the files on disk (TextMate will track renames, hence if you open /path/to/file and then move it to /path/to/other/place, it will update its reference).
Should it ever happen again, you can right-click the proxy icon to see where the file is on dis, or use File Browser → Reveal Document.
I will do that. Thanks for the response.
How are you switching git branches? You can do this from within TextMate using the SCM bundle, and I would expect that to work.
Of course you can do it from the command line instead, but I would never expect _any_ program to understand what I'm doing if I'm going to switch git branches behind the program's back. And if you were to switch branches with the files in question open _and_ containing unsaved changes, I would expect the results to be unpredictable. I always close the project before changing branches, then reopen it. Sticking to that, I've never experienced any trouble (though of course there is always a chance something new is going wrong). m.
On Aug 21, 2016, at 7:52 PM, Jack Royal-Gordon jackrg@pobox.com wrote:
Just discovered another similar occurrence that may add some more data. It appears that when I switch GIT branches, which causes some files in my folder to be changed, TextMate is not reloading the changed files (as it did in Version 1). What I used to get in V1 was that if there were no changes pending on the file when I switched branches, TM would quietly load the new version of the file; if there were changes pending, it would ask if I want to save the current TM copy or overwrite it from the copy on disk. But it seems like it might not be doing this (or at least not doing this consistently) on V2. All this makes me think that there might be an issue with TextMate’s file system handling under OS X.
Unfortunately, I only discovered this issue today (based on GIT history I can tell that it happened three days ago), so I wasn’t able to apply any of the suggestions from your earlier email. You can be sure that I’m keeping an eye on this now.
On Aug 21, 2016, at 9:56 AM, Jack Royal-Gordon jackrg@pobox.com wrote:
From: "Allan Odgaard" mailinglist@textmate.org Subject: [TxMt] Re: Weird file not updating problem Date: August 21, 2016 at 2:56:20 AM PDT To: "TextMate users" textmate@lists.macromates.com Reply-To: TextMate users textmate@lists.macromates.com
On 20 Aug 2016, at 8:57, Jack Royal-Gordon wrote:
I made some changes to a file that was open as part of a Rails project (the whole project was opened) and saved the changes. TextMate showed the file as having no unsaved changes. However, inspecting the file outside of TextMate, I could see that the the changes were not saved.
And even pressing ⌘S did not change that? ⌘S will always save, even if it shows “no changes”.
Did press ⌘S several times, as when I ran the file and it did not work I thought I had forgotten to save.
Also, when you have a file open, you can use Bundles → Diff → Document With Saved Copy. This will run a diff util on the buffer and the file on disk, that should be able to confirm if somehow TM’s buffer is different with the file on disk after ⌘S.
That’s a good idea. Did not know about that.
I rebooted my computer and when TextMate reopened, there was the file with my changes showing (but which were not saved although again it showed as having no unsaved changes). I had to close the file, reopen it, and re-apply the changes before saving again in order to actually save the changes
So you rebooted, re-opened the file, and while TM found your (unsaved) changes, it would still not save on ⌘S. But closing file (again) and re-opening now did show the file on disk, and you could save?
Correct. When I reopened, it showed the file without the changes that did not save.
[…] I wanted to see if this was a known issue with 2.0-beta.12.
Nothing I have heard of before, but from the description above, it really sounds like TextMate was operating on a different file than what you was inspect on disk, that would explain all of the behavior perfectly, including rebooting and showing the updated file “with no changes”, yet after closing it and opening the (right) file, you now lost the changes, and had to re-do them.
Since I opened a folder in Textmate and was accessing files via the File Browser, I have a hard time imagining how it was accessing a different file. But I agree that that would explain all of the strange behavior.
So what should probably be looked into is, how did it get to operate on this other file, and where on disk was it?
Yes, that would be the question.
Did anything work on the files on disk (TextMate will track renames, hence if you open /path/to/file and then move it to /path/to/other/place, it will update its reference).
Should it ever happen again, you can right-click the proxy icon to see where the file is on dis, or use File Browser → Reveal Document.
I will do that. Thanks for the response.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 9! http://shop.oreilly.com/product/0636920044352.do iOS 9 Fundamentals! http://shop.oreilly.com/product/0636920044345.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
On 22 Aug 2016, at 4:52, Jack Royal-Gordon wrote:
Just discovered another similar occurrence that may add some more data. It appears that when I switch GIT branches, which causes some files in my folder to be changed, TextMate is not reloading the changed files (as it did in Version 1). What I used to get in V1 was that if there were no changes pending on the file when I switched branches, TM would quietly load the new version of the file; if there were changes pending, it would ask if I want to save the current TM copy or overwrite it from the copy on disk. But it seems like it might not be doing this (or at least not doing this consistently) on V2.
Right, so your issue is limited to files with local changes which you then change on disk, correct?
In this case TextMate will actually try to merge your local changes with the new version on disk, and if it can do this without merge conflicts, it updates the file.
But if the merge has conflicts, TM currently does nothing (it logs an error to console). Prior to beta 12 it would update the file with the merge conflict markers, but I found this behavior undesirable because we effectively “mangle” the local changes.
I do however plan to introduce a visual warning for this edge case, but unfortunately there was not enough time to get this done for beta 12.
-
Allan Odgaard -
Jack Royal-Gordon -
Matt Neuburg