If one opens a file in TextMate and then renames that file in the Finder, TextMate does not pick up the change and saving the opened file will result in the file being saved with its original name.
I only mention this as I am user coming from BBEdit and am used to it picking up file name changes upon activating the editor window.
I'm not sure which is the best approach but I like the idea of files not being dependent on their name; the ability to re-open a file despite its name having been changed is a great thing so perhaps this should apply to when a file is currently opened?
Thanks in advance,
-- Paul
On May 5, 2006, at 11:41 AM, Paul Mucur wrote:
If one opens a file in TextMate and then renames that file in the Finder, TextMate does not pick up the change and saving the opened file will result in the file being saved with its original name.
I only mention this as I am user coming from BBEdit and am used to it picking up file name changes upon activating the editor window.
I'm not sure which is the best approach but I like the idea of files not being dependent on their name; the ability to re-open a file despite its name having been changed is a great thing so perhaps this should apply to when a file is currently opened?
I personally would not like if TM were to do that. No Cocoa application does that AFAIK.
Gerd
On May 5, 2006, at 9:51 AM, Gerd Knops wrote:
I personally would not like if TM were to do that.
How come?
No Cocoa application does that AFAIK.
I thought they all did that. For instance, open a PDF in Preview, then change the name in Finder. When you switch back to Preview, the new name will be shown. OmniOutliner does the same thing with its documents, and I'm sure there are many more examples. I wonder why TextMate seems to be the exception here.
Trevor
On May 5, 2006, at 11:07 AM, Allan Odgaard wrote:
On 5/5/2006, at 20:03, Trevor Harmon wrote:
[...] I wonder why TextMate seems to be the exception here.
Because the API required for this is in the Carbon library. But 2.0 will make use of it.
Only if there are no unsaved changes I assume.
On 05/05/2006, at 9:42 PM, Matthew Gilbert wrote:
On May 5, 2006, at 11:07 AM, Allan Odgaard wrote:
On 5/5/2006, at 20:03, Trevor Harmon wrote:
[...] I wonder why TextMate seems to be the exception here.
Because the API required for this is in the Carbon library. But 2.0 will make use of it.
Only if there are no unsaved changes I assume.
It doesn't make any difference as the file that is moved is the one that was on the disk, TM keeps an alias to it and doesn't have to care where it is.
You can also rename the file without anything getting lost. All in all life is MUCH better for the user.
Looking forward to seeing this, it is sadly missing. On the cocoa- carbon issue, I note that subethaedit handles file moves and renames transparently, and i am pretty sure it is cocoa. Perhaps they went to the trouble of using the carbon wrappers under cocoa, but perhaps there is another way to get this feature, which exists already?
On 5/5/2006, at 22:47, Timothy Bates wrote:
[...] On the cocoa-carbon issue, I note that subethaedit handles file moves and renames transparently, and i am pretty sure it is cocoa. Perhaps they went to the trouble of using the carbon wrappers under cocoa, but perhaps there is another way to get this feature, which exists already?
NSDocument do use aliases. So any Cocoa application basing its MDI on that, should get them -- that said, it’s not a problem to call Carbon stuff from Cocoa, but when I started programming on Mac, I rarely looked outside Cocoa, nor was I, as a non-Classic user, really familiar with aliases, so such feature did not seem “lacking” to me, on the contrary actually, as when I did switch to Mac, they had aliases use the inode over the file path, which often meant that programs used the wrong files (those in the trash).
-
Allan Odgaard -
Gerd Knops -
Matthew Gilbert -
Paul Mucur -
Timothy Bates -
Trevor Harmon