V16 Linux auto completion for process and open

[CodeBender]

For process windows:
Is there any way to make auto-complete of paths behave like I am used to with terminal windows?
Meaning - pressing tab _once_ completes up to ambiguities - then the list (which is nice) instead of pressing twice to get the only choice?
To me this is a waste of keystrokes (and adding significant confusion) pressing once opens the list of options and second cycles through (the eventually only option)
SlickEdit just help me in case I like to have an option.

For open command input (e path):
I type in a (incomplete) directory name (completion works as expected) then a second tab and it takes away the completion. Not pressing the second tab and a '/' instead to commit the completion, then a tab takes away the whole input and starts cycling through the list.
Again - SlickEdit just help me in case I like to have an option.

I'm coming from V9 which gets pretty hard to handle on Fedora 15 64Bit :-)
The process window integration and fast completion of file names would be main reasons for me to stay with SlickEdit. Using the mouse with all these nice file open dialogs is just pain if managing large amounts of files. But what I found is that input methods got inconsistent and worse (I mean confusing and slower).
Is there any way of configuring this?

[Matthew]

I see what you mean about having to "Double TAB" if there is only one possible match in the directory listing. I'll set that up as an enhancement request for SE 2012. I'm not sure if that can be addressed via a hotfix in SE 2011.

We always try to focus our features to allow you to get at your code fast without having to reach for the mouse. In addition to the regular modal file open dialog, we also have the "Open" tool window. If you haven't used that, I recommend giving it a shot. It's not super-obvious in the UI, but you can actually type absolute directory paths in the File Name: entry field as a quick way to change the current directory.

The e command on the SE command line is great, but it gets even better if you're using it in conjunction with a project. No matter what the full path to the file is, just typing a portion of the file name will start returning matching files from your project.

[Clark]

I just added some code for 16.0.1 so that the first Tab in the process buffer inserts the longest prefix.

The command line completion is still the same. Space bar on the command line inserts the longest prefix and Tab and '?' display possible matches. This is consistent with how completion works in SlickEdit's dialog boxes but possibly does not make sense for the command line where Tab can only mean do completion (not tab to next control). At some point, we should change the tab key on the command line to be consistent with the new code I just put in for pressing Tab in the process buffer.

[CodeBender]

About the open dialog - I'll check. I been using SlickEdit for more than 10 Years now, starting with the text-version under OS/2. And I was really happy to be able to use SlickEdit when I moved to Linux. I don't like to use projects, setups, IDE and such stuff. I don't even know how this works. I use my own structure and makefiles or have to use the one of my clients and have to navigate in there fast. Command-Line/Process buffer integration and fast directory path completions have alway been the major benefit for me. The file list popup for the e command is a really neat addition (although it should not stay on top if changing the focus to another window). However - I hate updating and buying new features that I don't need and that make stuff more and more complex and I have to learn again (and struggle switching them off) - and this with almost every update of my operating system. Although I'd sure be willing to pay for maintenance. I think it would be way cool if it just worked and worked and worked - like one of these older cars.