"edit" command always wants to open relative to the directory of current buffer

[evanratt]

Using v19:

In Options->File Options-->Open, I have "Set current directory when switching buffers" turned Off and "e/edit command Smart Open" set to "Smart Open off". Indeed, when I switch buffers, typing "cd" on the command line shows me the root of my src tree, as it should (ie. "d:\PROJECT_NAME\src").

However, when I open a file using "edit" (bound to Ctrl-X Ctrl-F), if I start typing a relative path name, I find that autocomplete is trying to match files and directories relative to the current buffer, as well as relative to root of my src tree. This is confusing and seems broken, and worked in v18. Am I missing another option somewhere?

[Dennis]

This is a new feature in the file name completion in v19.  Frequently it is convenient to be able to quickly open a file in a the same directory as the current file.  Unfortunately, there is no option to turn it off, just like there is no option to turn off completion for files in the workspace.

[evanratt]

In that case, may I strongly request you consider adding an option to control this feature? In this project, I know where the file I want to open is, and just want completion to help me get to that file; here, it's getting in my way. This feature seems to duplicate some of the functionality that Smart Open provides, and I have that disabled for a reason.

This has been proving annoying enough to me today that I may just end up sticking with v18 for the time being.

[LBCEi]

I don't know if this is relevant for your use case, but I almost exclusively use the 'ep' command (edit in project) instead of 'e' (edit), on the SE command line.  I just hit escape, type 'ep<space>' and start typing the filename to get autocompleted suggestions (without all of the path stuff that you get with 'e').

For a relatively simple project without duplicate filenames (I'm not sure how this would be handled as I, fortunately, don't have this issue in my projects), it works very well.

You might also consider looking into directory aliases to speed access to frequently used folders.

Just some thoughts that may or may not help.

Best regards.

[evanratt]

Thanks for the tip. I do actually use the ep command sometimes (particularly if I'm not familiar with where something is in the codebase), but I really do want the 'e' command to work as I expect.

Our projects have source and data trees. I have the source trees tagged and included in the project, but I often want to open a text-based data file in Slickedit. I have my SE projects set up to always have the working directory set to d:\ProjectName\src, for example. I'm very used to using the 'e' command and typing ..\d<space>\l<space>\langfile.txt, for instance, with the spaces expanding "data" and "lang". This new behavior is getting in my way when I do that.

It's also getting in the way when I'm already editing the aforementioned langfile.txt, for instance, and I want to open the file "d:\ProjectName\src\physics\physics.cpp". I normally would use the 'e' command, type "p<space>" to expand "physics", etc (remember, my working directory is d:\ProjectName\src). Now, typing "p<space>" it doesn't know if I mean to expand "physics" in the src directory, or param.txt in d:\ProjectName\data\lang.

I've been using SlickEdit since 2003 (I think), and this is the first time I can recall that a "feature" like this has been implemented with no way to disable it. And it seems like a rather extraneous feature--if I wanted Smart Open type functionality, I would enable Smart Open, or I would use the 'ep' command that LBCEi mentioned. If I'm using the 'edit' command, I want the most simple, "dumbest" open command possible--I know what I'm doing, and now the editor is getting in the way of my doing it.

Hope I'm not coming across as ranting too much, but as I'm sure is the case with many people on this forum, I've become really attached to SlickEdit over the years, and have it configured precisely how *I* want it to work--it's not pleasant to find the editor fighting my workflow, now.

[Dennis]

I will add an option to disable the feature.  It will either go into the next hot fix, or the first patch (19.0.1).

I understand your pains, but you have to admit, that if you were in langfile.txt and you wanted to open param.txt, the feature would have been tremendously useful to you.

[evanratt]

Thanks, Dennis. I appreciate the quick reply and that you take users seriously--one of the best things about this editor!

Yes, the feature could be useful, and I may actually use it in that situation. I know it wasn't added maliciously just to spite me...