Cheers,
11011011

I disagree that full pathname is necessary, or even useful. Big long strings of similar-looking noise all look alike. What you want to see is the DIFFERENCES WITH A DISTINCTION.

On Mac OS X, one example of this is Property List Editor. A significant fraction of the files you edit with it will be named “Info.plist”, located in a “Contents” directory, which would make a recent-files list extraordinarily useless.

So what PLE does is show the “Info.plist” name followed by ONLY the unambiguous part of its actual location, which is usually the enclosing “Xyzzy.app” app-bundle folder, or whatever the nearest actual enclosing folder is.

For example, I have 9 “Info.plist” items, 4 of them from a .app context, 3 from a .SpeechVoice bundle, and 2 from a .SpeechSynthesizer bundle.

So I say the solution is to show JUST ENOUGH context, with JUST ENOUGH difference, that a glance alone will tell the user what’s going on.

Sadly, not even Property List Editor does this in the editing-window’s title-bar, where it would be even more useful. However, all its windows support the cmd-click to reveal a popupmenu of the entire path to the file. Still, this is not good enough, because it’s not clear enough AT A GLANCE. If I always had the discipline or presence of mind to cmd-click before editing, then there isn’t even a problem. It’s precisely because I’m NOT disciplined and error-free that I need the context at a glance.

I couldn’t count how many times I’ve done this, but I’m *starting* to get smart to it and check which file I’m on before I start.

Or compiling a file and having the class-file in the wrong place so that you edit the right file, but execute the wrong one.

Perhaps you could have a FileReader class debug version which prints every filename it opens, which in the production version is disabled. Doesn’t help with classpath-searches though

If you would actually be in awe of a tool-tip, well, you need to get out more.

Different versions of the same file
Different files with the same name

The first is the case where you have a backup file somewhere (and that’s the one you’re editing). The solution, as you rightly point out, is to only have one copy of a file. Fortunately, that’s pretty easy to manage; don’t have backup files. Use a version control system (e.g. subversion) instead. That way, your files are always the version control system and there’s only one file available. When you’ve finished with updates (and of course, checked it in!) then delete the file from disk. It’s not necessary to keep it around, and you can get it out again afterwards.

More importantly, don’t let live systems read from files on the file system; get them out of version control. This might be accomplished by having a version checked out on a regular basis (with a CVS tag so you don’t have to use HEAD; I use STABLE, for example). Alternatively, if you’re using subversion, you can even mount the version control system via a WebDAV share (simple enough on most Unix operating systems, and to a lesser extent, even ‘doze boxes). Of course, you’d want the version control system to be local to the server to make it fast, and this presupposes that you’re sending source directly to the server and not needing an intermediary compile step.

Secondly, files with the same name but different projects. This often crops up with generic files (like ’style.css’) and you’re not sure what you’re editing. There seems to be two ways of handling this; either give each project’s file its own name (e.g. styleCafeAuLait.org), or have a ‘common’ set of files that are checked into source control that you pull out into your project. I guess if you’re editing in an IDE, one other approach is to close all projects that you aren’t working on, which has the effect of not allowing you to edit those files (multiple projects open with ‘.classpath’ will show up in Open Resource in Eclipse, for example). I don’t believe the project set filters do that.

If you’re doing a lot of development work in Eclipse, you can have separate workspace. I’d recommend that you have a different workspace for each different major project/system that you’re working on. That way, when it starts up, you know you’re in ~/CafeAuLaitWorkspace instead of ~/CafeConLecheWorkspace and you’ll only see projects related to that that you’ve already checked out.

In a nutshell; version control is probably the way to keep them separate, and use the partitioning mechanisms in your IDE/editor to keep unrelated projects apart (or better still, delete after synchronizing them or close them when you’re not working on them). Neither of these will help if you have multiple copies of ’style.css’ in the same project though.

gnu emacs (and other emacsen?) offers some help in preventing this problem: files of the same name are suffixed with <n> according to the order they were opened. This is almost an effective solution for me … except the original file name is not updated to include a <1> suffix. So when editing the original file there’s no indication its one of a bunch.

I wish new IDE’s would adopt this convention including a <1> suffix for the original file when needed.

I wish new IDE’s would adopt this convention including a suffix for the original file when needed.

I’ve had a bit better luck with this bug in Eclipse when “sync editor with navigator” is on. When you’re editing the version from your build directory (doh!), it doesn’t have the right icon in the navigator. It’s subtle, though. It’d be nice if there was a line right below the editor tabs that showed the full path of the file you’re editing, instead of having to hover over the tab, or a warning “you’re editing a file that isn’t on your source path… Are you sure?”