I use the File Manager constantly.
I was a point-and-click software developer for 10 years until I *truly* discovered the keyboard. I switched to EMacs\Epsilon @ five years ago (not by choice, many others on the team were using it), and learned to love the speed at which I can drive an editor with the keyboard. I'm now switching to SE since it has a larger installed and support base.
I should point out that I use symbol-based lookups in combination with file-based lookups. I've seen debates on this forum where people champion one over the other. I'm trying to use symbol-based lookups more but don't feel like it's the only solution, or that things should be either-or. Sometimes, you want to bring up a file, other times, chase a symbol.
I like this editor, but have had to wrestle with it a bit to make File Manager behave the way I'd like.
For starters, it's important to me to be able to navigate at a command prompt within the process buffer because I have DOS aliases I'd prefer to use (universal, whether I'm in SE, or not), and don't want to create a second set of aliases within SE (I'd imagine the same goes for users of BASH or other shells). As an aside, I LOVE the fact that the .process buffer isn't so "tightly coupled" with the editor (async) but wish it were more "tightly integrated", if you know what I mean. That's what I'm working towards.
One macro I wrote set the SE current directory to the directory at my .process buffer prompt. Another macro invokes this first one, then dir(). So I can CD to a directory in my .process buffer, then invoke a hotkey to bring up a File Manager listing, if I choose.
Clark or Lee, I also made a minor change to edit() so that, if a directory is returned from prompt() as the filename, you don't get an "invalid file" message, instead a File Manager listing is displayed. I think this would be a real value add for SE that wouldn't have any deleterious effect on existing users.
I also made some innocuous changes to the SE edit(), prompt(), and get_string() macros that provide optional behavior without breaking existing users. These optional parameters allow a caller of edit() to provide an initial value (rather than use previous value) and disable highlighting (which places cursor at end).
Another macro I wrote leverages these changes to set the current directory to the .process current directory, and populates the edit() window with this path. The user can then press 'Enter', bringing up a File Manager listing, or can start typing a file name at that directory (invoking file completion, etc...), or can backspace up the path, and so on.
These changes really helped me integrate the current directory of my .process buffer with the File Manager listing in SE. If anyone wants to know more, let me know, I can provide these three very short macros, and my (very minor) edits to edit()
BTW SlickEdit developer guys - the existing macros provided by SlickEdit can oftentimes be made more extensible simply by adding optional parameters for various things and maybe providing for callbacks, so that a user could override behavior internal to an existing SE macro by implementing a small macro of their own. It sucks to have to change SE-provided macros because then you need to port your changes forward when you upgrade.