Regression: Locator now shows the same path for `f ` command regardless of currently active file.

[vi]

Supposing I have two opened files:

• /home/vi/myproject/src/org/example/myproject/FooAbstractySingleton.java
• /home/vi/myproject/src/org/example/somelib/BarSingletonFactory.java

Before, when using Locator it started counting from /home/vi/myproject/src/org/example/myproject or /home/vi/myproject/src/org/example/somelib based on the currently opened file.

Now it just starts from /home/vi/myproject. Is it bad influence from FuzzyOpener?

[andreikop]

This is not a Regression, but rather a Revolution, which is currently in progress. I'll merge fuzzyopener to master when it looks ready to use. Now Enki doesn't change it's current directory when file changed, but follows File browser root.

In the future I expect 2 variants:

• You open /home/vi/myproject/src/org/example project and than than type barfa and foabsin to open the files. Doesn't matter which file is current.
• You open myproject/src/org/example/myproject and myproject/src/org/example/somelib projects in 2 independent Enki instances and use Alt+Tab to switch.

In both cases Locator is used only to open a file which is outside your project. And current directory (Locator and Ctrl+O directory) is always at current project root.

[andreikop]

Suggestions are welcome!

[vi]

This "revolution" looks like pushing users towards FuzzyOpen by breaking Locator.

I think Locator should work exactly the same as without FuzzyOpener. I often use Locator as a sort of ad-hoc file browser (because of "f " should all files in a predictable directory). I can nagivate up and down by typing additional ../s or choosing directories.

For FuzzyOpener, I'd instead preferred it to be closer to the "use current file's directory" Locator's logic.

In both cases Locator is used only to open a file which is outside your project.

That looks like abandoning Locator and adopting FuzzyOpener. And I want to keep Locator and use FuzzyOpener only when I want so (i.e. too much navigation in Locator).

At the current stage of FuzzyOpener development there can be some priority in keeping Locator undisrupted. I.e. fuzzyopen should be merged to master soonish, but unless user press Ctrl+M he should not feel any change. That includes Locator directory choice logic.

Obviously, you can add one more command like "g " or "F " that starts from project root, but "f " and the default should work like before.

I want FuzzyOpener to be a new feature for Enki, not a revolution (at least for now).

[vi]

Now Enki doesn't change it's current directory when file changed, but follows File browser root.

Was previous logic based on changing the current directory to and fro? Looks like a hack, there should be explicit logic in Locator like (pseudocode) setInitialDirectory(getActiveWindow()->getCurrentlyOpenedFile()->parentDirectory()). The same for "Open terminal" feature.

follows File browser root.

Maybe better "currently selected directory in File Browser" (which may be updated when you switch from file to file).

As I demonstrated, in Java projects there can be longish paths and moving from file to file is easier than moving from project root to a file.

[andreikop]

OK, I can start f command from the current file directory for now. And than when FuzzyOpener is ready, we will see what is better. I hope that you will not use Locator for in-project files, so it will be more predictable to start Locator from project root.

[andreikop]

I'm not sure what to do with the File Browser. I really liked it's current behavior, but I like Fuzzy Opener even more. And Fuzzy Opener is not possible without a project. So, for now @bjones1 's idea at #295 discussion looks the most reasonable.

[vi]

With enough of my ideas implemented, FuzzyOpener should also possible be outside a project.

Being locked to project room is also not comfortable when you are transferring something from one project to another (and have many files opened from both projects).

One another option is to add special explicit FuzzyOpen command like "add this directory to the scan list". Creating a separate issue for this: https://github.com/hlamer/enki/issues/306

[vi]

Updated Enki, l command got renamed to o, but the directory is still fixed.

I want some easy deterministic way to open a neighbouring file, with o command or with separate command. Syntax proposals:

• O sibling_file
• ./sibling_file
• o ./sibling_file (after ./ it should start displaying the "current directory" of currently active file)

The last and penultimate options looks consistent: no prefix - project root, / prefix - filesystem root, ./ prefix - current directory. Leading ../ should probably also ascent from current directory, not from project root.

Basically if user starts typing with /, ./ or ../ then he probably don't expect fuzziness.

[andreikop]

'/', '../', './' is recognized as deterministic open command now.

[vi]

As of cb117ce594a67ff7b30cec33d630342df9851cd9, ./ works just like o - it starts from the project root instead of opened file. Still no way to quicky browse and open (or create) a neighbour file.

Actually ./ and o shows the same list now, but ./ is also much slower and shows Loading just as FuzzyOpener.

[andreikop]

./ should not be slower. Now it works just like o. I'm near to finish with FuzzyOpen. Need to fix #309 and #310. Than it's time to think about what is Project , where is current directory and what is ./?

[vi]

For me ./ works as o, but also triggers FuzzyOpener's "loading".

I suggest the following bindings:

• o file.cpp - open $PROJECT_ROOT/file.cpp
• ./file.cpp - open neighbour file file.cpp. ./ should browse the directory where currently opened file resides (in or outside the project). Like before, non-existed files should be created;
• ../ - equvivalent to ./../;
• / - browse root (it works now);
• f file.cpptriggers fuzzy opener starting from $PROJECT_ROOT and searches for file.cpp;
• file.cpp is the same as f file.cpp;

When typing, for example, open.cpp, fuzzy opener's "Loading" should kick in only when I type op, not just o.

What should be the Enki process's current working directory should be implementation-defined. User does not directly see it. It may be just inherited from parent process, changed to project root, follow currently opened file, follow selection in file browser, etc. If main pane, preview pane or "Opened files" pane is active, Tools->Terminal should open the terminal in a directory that contains visible file. If File browser is active, it should open terminal in a selected directory.

What is a project root? Now I see it's inherited current directory. If should be overridable in File Browser (I don't usually use it). In file browser, I'd recommended to show project root in bold. There should be context menus on directory entries, one of items should be "Set project root" (or also "Add new project root" for multiple projects). Probably File Browser improvements should be a separate issue.

[andreikop]

305 is merged. Now it is fine with current directories. Project and File browser still to be designed.