4 ms·

I’d say if the file got renamed, the editor should just use the new filename. The name of the file is just metadata, not its identity.

by bouke 5y ago

CrazyStat 5y ago
How is the editor supposed to know the new filename?
- bouke 5y ago
  Try renaming a file from the Finder currently open in Numbers (macOS). Notice how Numbers picks up the new name. So definitely possible, on macOS at least.
  - laszlokorte 5y ago
    On MacOS the file name is only meta data, ie the file has an internal id that does not change, but on other platforms filesystems the filename might be the identifier.
- mkj 5y ago
  If it's renamed in Linux the inode number will remain the same. (Good luck finding where the new file is, I guess Sublime would spot it if it's within the currently opened directory/project with inotify)
- samus 5y ago
  Every operating system supports subscribing to file and directory changes. That is how the editor can detect there was a change in the first place.
argvargc 5y ago
This is not a good solution for two reasons: 1) If the file was renamed and its contents changed - what should the editor do? Load the changes underneath the user? If yes: user #1 mad because now the only copy of file contents was wiped in OS, and now by the editor in what was originally a mistake. If no: user #2 mad because updating file outside of editor didn't update it within editor as they'd hoped. 2) If the file was only renamed - but renamed by mistake - to something generic or wrong: user #3 mad because original filename (which may also have been a location) is now lost. In all cases, the optimum solution is to clearly indicate to the user that the file name or contents have changed, preserve both the contents and the filename/location, and give the user the option as to how to deal with this given their particular situation. This should be a separate indication than that what seems to be currently offered which is to conflate user initiated changes, and OS initiated changes as the same thing. If this is the case, they are not the same thing, and this should be clearly reflected in the UI so that the user is alerted and can decide what to do.

I’d say if the file got renamed, the editor should just use the new filename. The name of the file is just metadata, not its identity.

by bouke 5y ago

I’d say if the file got renamed, the editor should just use the new filename. The name of the file is just metadata, not its identity.

CrazyStat 5y ago

How is the editor supposed to know the new filename?

bouke 5y ago
Try renaming a file from the Finder currently open in Numbers (macOS). Notice how Numbers picks up the new name. So definitely possible, on macOS at least.
- laszlokorte 5y ago
  On MacOS the file name is only meta data, ie the file has an internal id that does not change, but on other platforms filesystems the filename might be the identifier.
mkj 5y ago
If it's renamed in Linux the inode number will remain the same. (Good luck finding where the new file is, I guess Sublime would spot it if it's within the currently opened directory/project with inotify)
samus 5y ago
Every operating system supports subscribing to file and directory changes. That is how the editor can detect there was a change in the first place.

argvargc 5y ago

This is not a good solution for two reasons: 1) If the file was renamed and its contents changed - what should the editor do? Load the changes underneath the user? If yes: user #1 mad because now the only copy of file contents was wiped in OS, and now by the editor in what was originally a mistake. If no: user #2 mad because updating file outside of editor didn't update it within editor as they'd hoped. 2) If the file was only renamed - but renamed by mistake - to something generic or wrong: user #3 mad because original filename (which may also have been a location) is now lost. In all cases, the optimum solution is to clearly indicate to the user that the file name or contents have changed, preserve both the contents and the filename/location, and give the user the option as to how to deal with this given their particular situation. This should be a separate indication than that what seems to be currently offered which is to conflate user initiated changes, and OS initiated changes as the same thing. If this is the case, they are not the same thing, and this should be clearly reflected in the UI so that the user is alerted and can decide what to do.